DMARC RFCの説明：最新の電子メール認証のコアスタンダード

DMARC（Domain-based Message Authentication Reporting and Conformance）は、RFC 7489（Informational）で規定されている電子メール認証プロトコルである。その後継であるIETF DMARCbisドラフトは、プロトコルを更新および明確化し、RFC 7489を廃止することを目的としている。 

DMARCは、SPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）を基に構築され、なりすまし、フィッシング、不正使用からメールドメインを保護します。DNSでDMARCポリシーを公開することにより、ドメイン所有者は、認証チェックに失敗したメッセージをどのように処理するかを受信メールサーバーに指示する。この技術的基盤により、DMARCは現代の電子メールセキュリティと信頼の礎となっています。

DMARC RFCとは何ですか？

IETFはDMARCを RFC 7489(Informational）として2015年3月に発表した。これは、ドメイン所有者が、メッセージがDMARCの評価に失敗したときに受信者が何をすべきかを示すDNSポリシーを公開する方法を定義している。

このプロトコルはもともと、グーグル、マイクロソフト、ヤフー、ペイパルなどを含む業界コンソーシアムによって開発されたもので、DMARC orgの旗印のもとで活動していました。 DMARC.org.彼らの目標は、ドメイン・レベルの認証を通知し、強制する共通の方法を作成することによって、電子メール詐欺を減らすことでした。 IETFに提出され、RFC 7489として発行された。RFC 7489は標準化過程（Standards Track）ではなく、情報過程（Informational RFC）であるが、DMARCを実装するための事実上のリファレンスとなっている。

RFC 7489の内容とは？

RFC 7489は、以下の完全なフレームワークを定義している。 DMARC.この文書自体は技術的なものであるが、その主な目的は簡単である：

政策メカニズムの提供

DMARCを使えば、ドメイン所有者は、認証チェックを通過しなかった電子メールに対して受信者が何をすべきかを指示する明確なポリシーを公開することができる。

包括的なレポーティングのメリット 

DMARCは報告プロトコルでもある。つまり、ドメイン所有者は、どのメールが認証を通過し、どのメールが通過していないかのデータを得ることができる。これは、正当な電子メールと悪意のある電子メールを区別するのに役立ちます。

電子メール詐欺を減らす

DMARCは、RFC5322.FromドメインがSPFまたはDKIMで認証された識別子と一致しているかどうかをチェックする。これは、直接的なドメインなりすましを軽減するものであり、そっくりドメインや表示名の偽装を防ぐものではなく、間接的なメールフローの影響を受ける可能性がある。 

既存のスタンダードをベースとする

DMARCは、SPFおよび/またはDKIMの結果を使用し、識別子のアライメント、ポリシー(p=)、およびレポート(rua/ruf)を追加する。 

要件の技術的内訳

DMARCはアライメントを評価し、ポリシーを適用する。DMARCは、識別子のアライメントという重要な新要件を追加している。

DMARCがSPFとDKIMの結果をどのように使用するか

DMARCは、単にSPFやDKIMがパスするかどうかをチェックするだけでなく、RFC5322.Fromドメインとの識別子の整合性を要求する。

SPFアライメント

DMARCはSPF認証されたRFC5321.MailFrom（またはHELO）ドメインを使用し、RFC5322.Fromドメインと一致する必要があります。リラックスモード（aspf=r、デフォルト）では少なくとも組織一致、ストリクトモード（aspf=s）では完全一致である必要があります。

DKIMアライメント

DMARCはDKIMのd=ドメインを使用し、RFC5322.Fromドメインと一致することを要求する。リラックスモード（adkim=r、デフォルト）では少なくとも組織名、ストリクトモード（adkim=s）では完全一致でなければならない。

このアライメント要件は、DMARCのスーパーパワーである。認証結果をブランドの可視ドメインに直接リンクさせることで、攻撃者が以前悪用していた抜け穴を塞いでいる。

政策モード (p=)

DMARCレコードは、電子メールがDMARCチェックに失敗した場合に、受信者が従うべき3つのポリシーのうちの1つを指定します：

• p=なし：モニターのみ。
• p=隔離：失敗したメールが疑わしいというシグナルを送る (典型的な取り扱い: spam/junk)。
• p=reject： 失敗したメールは拒否されるべきであるという強いシグナル。RFCでは、ローカルなポリシー例外（例えば、既知の優良な送信者の場合）を認めていますが、主要なプロバイダーは通常、認証されていないなりすましの試みに対してこのポリシーを厳格に守っています。

レポート機能（RUA & RUF）

DMARCは2種類のレポートを通じて有用なフィードバックを提供する：

アグリゲートレポート（RUA）

RUAレポートは、DMARC結果の機械可読XML要約（通常、毎日）である。これには、送信IPアドレス、SPF/DKIMの結果、アライメントの詳細、メッセージ数などのデータが含まれる。しかし、これらの生のXMLファイルは、人間が簡単に読めるものではなく、専門的なツールなしでは手動で分析することは困難です。そのため PowerDMARC DMARCレポートアナライザーツールは、このプロセスを自動化し、複雑なデータを直感的な図表に変換します。

メッセージ固有の障害報告（RUF、しばしば「フォレンジック」と呼ばれる）

これらはオプションであり、プライバシーの観点からほとんど送信されない。多くの受信者はRUFを削除するか無効にしている。DMARCbisはこれらの懸念を文書化し、別の失敗報告草案を参照し、RUF報告をますます非推奨にしている。

DMARCbisと今後の変更

技術標準は急速に変化し、DMARCも例外ではありません。DMARCbisは、IETFによって正式化されたDMARCプロトコルの最新仕様です。DMARCbisは、IETFによって正式に策定されたDMARCプロトコルの最新仕様であり、過去数年間に学んだ教訓に触発され、DMARCを "Informational "RFCから正式な "Proposed Standard "へと進化させることを目的としています。 

DMARCの革命や放棄ではなく、進化であると考えてください。DMARCbisにおける主な変更点と明確化は以下の通り：

p=検疫行動

DMARCbisは、検疫のセマンティクスと受信者ガイダンスを明確にするが、依然として受信者の裁量を認めている。 

新用語とリストラ

DMARCbis はオリジナルの RFC 7489 に基づいているが、再構築され、一般ユーザーにとって読みやすくなっている。

仕様は現在、3つの別々の文書（RFC）に分かれている。これらには以下が含まれる： 

• 主な文書 メインドキュメント
• (注) 集計報告仕様
• その 故障報告仕様

また、いくつかの用語や言い回しも、より明確にするために変更されている：

• "報告書の消費者 "ではなく "報告書の受信者"
• "DMARCポリシー "の代わりに "ドメイン所有者評価ポリシー"
• p=quarantineとp=rejectの「実施」。
• p=noneの場合の "モニタリング "モード

問題報告

転送はSPFを破り、メーリングリストはしばしばDKIMを破ります。DMARCbisは現在、メーリングリストが一般的な受信者である場合、p=rejectポリシーを使用することを推奨していません。 

集計報告規則も強化されている。 より厳しくなっている。XMLレポートのフォーマットも、新しいタグを反映するように更新された。

RUFを阻止する

DMARCbisはプライバシーの懸念からRUFレポートの使用を推奨せず、別の草案で失敗レポートについて言及している。

DNSツリーウォーク

組織ドメインを決定するための元の方法は、不完全である可能性があるパブリックサフィックスリスト（PSL）に大きく依存していました。DMARCbisは、適用可能なDMARCポリシーを発見するための、より柔軟で信頼性の高い「DNS Tree Walk」アルゴリズムを正式に規定している。

新しいDMARCレコードタグと削除されたDMARCレコードタグ

pct"、"rf"、"ri "のようないくつかのDMARCタグは完全に削除される。代わりに、"np"、"psd"、"t "のような新しいDMARCレコードタグが追加されている。 

組織にとっての重要性

DMARC RFCを理解することは、以下のようないくつかの点で組織に役立ちます：

コンプライアンスの向上

グーグル、ヤフー、マイクロソフト、アップルのメールは現在 バルク送信者現在、Google、Yahoo、Microsoft、Apple Mailは、他のコントロール（SPF/DKIM、アライメント、低スパム率など）と共にDMARCレコードを公開することを大量送信者に要求しています。DMARCに準拠しない場合、メール配信に深刻な影響を与える可能性があります。

設定ミスを避ける

RFCの中核となる概念、特にアライメントを誤解していると、正当なメールをブロックしてしまう可能性があります。RFC 7489を知ることで、問題のトラブルシューティングやポリシーの設定を最初から正しく行うことができます。 

エラーを防ぐために DMARCレコードジェネレーターツールを使って有効なポリシーを作成することもできます。すでにレコードがあり、それをチェックする必要がある場合、PowerDMARC の DMARCレコードチェッカーを使用して、エンフォースメントポリシーに移行する前に正しく発行されていることを確認することができます。

多くの安全保障上のメリット 

p=rejectで適切に実施されるDMARCポリシーは、ビジネスメール詐欺や多くのフィッシング攻撃の主な原因である、直接ドメインのなりすましに対する最も効果的な防御策の1つです。DMARCを導入することで、従業員、顧客、ブランドの評判を幅広いメールベースの詐欺から守ることができます。

まとめ

DMARC RFCは、メール詐欺からドメインを保護するための強固な基盤となる枠組みを提供しています。これには、DMARCの設定と適用に関する、簡潔かつ明確な基準とガイドラインが定められています。DMARC RFCの規則を厳守することで、メールのセキュリティを向上させ、ブランドの評判を守り、配信率を高めることができます。 

さらに優れているのは、DMARCの効果的な実装と管理を手作業で行う必要がないことです。PowerDMARCプラットフォームは、迅速なセットアップから徹底的な監視と実施まで、すべてのプロセスを簡素化します。 

お問い合わせ PowerDMARC今すぐPowerDMARCチームにご連絡ください！

よくあるご質問

RFC 7489が発行されたのはいつですか？

2015年3月にRFC 7489が発行された。

誰がDMARCを使えるのか？

ドメインからメールを送信する組織や個人は誰でもDMARCを使用することができ、また使用すべきです。DMARCはライセンス料も制限もなく、誰もが利用しやすい標準であり、ドメインをなりすましから守ることができる。

なぜ大手メールプロバイダーは大量送信者にDMARCを要求するのか？

平均的なユーザーは、メッセージやメールが本物か偽物かを理解できないのが普通だ。そのため、メールボックス・プロバイダは、どのメールをプライマリ受信トレイに到達させるかについて注意しなければならない。DMARCはこの問題を解決するのに役立ちます。DMARCは、送信者、受信者、メールボックス・プロバイダの双方が協力してメール詐欺に対抗することを可能にします。2024年2月現在、Google/YahooはSPFまたはDKIM認証、p=none以上のDMARC、低スパム苦情率、RFC5322.Fromアライメントを要求しています。

DMARCの設定や適用を容易にするツールはありますか？

PowerDMARCでは、DMARCジェネレーターやチェッカー、ホスティングサービスなど、こうしたツールやサービスを多数提供しています！

• について
• 最新記事

アヤン・ブイヤ

シフトリーダー、インフラおよびメールセキュリティの専門家（勤務先： PowerDMARC

サイバーセキュリティの分野で13年以上の経験を持ち、インフラ、事業継続、リスク管理、Eメールセキュリティを専門とする。現在はPowerDMARCのシフトリーダーを務める。ネットワークとセキュリティの大学院ディプロマを取得し、脅威を軽減し、ビジネスの回復力を確保するための戦略的なセキュリティイニシアチブを主導してきた実績がある。

最新記事 by Ayan Bhuiya(全て見る)

• Microsoftのエラーコードの解決方法とトラブルシューティングガイド - 2026年6月22日
• 2026年の主要なDMARCプロバイダー、ベンダー、およびソリューション - 2026年5月15日
• 2026年のValimailの代替サービス・競合サービス トップ10 - 2026年4月28日