DMARC
SPFとDKIM同様に、DMARCはドメイン所有者(DNSドメインを変更する権限を有する実体あるいはその集合)の概念を利用する。
SPFは配送サーバのIPアドレスが、SMTPのMAIL FROMコマンドで指定されたドメインの所有者によって認可されたものかどうかを確認する(MAIL FROMに含まれるアドレスはバウンスアドレス、エンベロープFrom、RFC5321.MailFrom等と呼称される)。これに加えて、DMARCはRDC5321.MailFromが5322.Fromと連携していることを確認する。
DKIMでは、電子メールのメッセージの一部にディジタル署名を施すことができ、そのときFromフィールドを署名範囲に加えなければならない。DKIM署名メールヘッダには、d=(ドメイン)とs=(セレクタ)タグが署名検証用の公開鍵をどのDNSから手に入れるかを明記される。署名が有効であれば、署名者がドメイン所有者であることが証明され、署名以降にFromフィールドが改ざんされていないことを保証する。DKIM署名はメッセージ中に含まれることもある。DMARCが必要とするのは、d=タグで指定されたドメインが、From:ヘッダフィールドで指定された送信者のドメインと連携している、有効な署名である。
2020年に、公式DMARCwikiのFAQでは、メーリングリストがstrictDMARCポリシのドメインからのメッセージを処理するためのいくつかの提案を掲載しており、その中ではメーリングリストが"From"ヘッダを自身のドメインのアドレスに変更するというものが最も多く実装されている。
2014年8月に、DMARCの問題に対処するためのIETFのワーキンググループが結成され、相互運用性の懸念と標準仕様と文書の改訂続行の取り組みを始めた。その間に、既存のDMARCの仕様は多くの人々に合意を得て実装されたeditorial状態となっていた。2015年3月、Independent Submission Streamに"Informational"(非標準)カテゴリでRFC 7489として公開された。
2017年3月、en:Federal Trade CommissionがビジネスにおけるDMARCの利用に関する調査を公開した。569のビジネスの3分の1がDMARCの設定を実装しており、10%未満がサーバに未認証のメッセージを拒否させるようDMARCを設定しているが、大多数はSPFを実装していることが調査によって判明した。
フォレンジックレポート(異常レポート)はリアルタイムに生成され、foタグに指定された値に基づき、SPFまたはDKIMあるいはその両方でfailとなったそれぞれのメッセージの編集されたコピーを含む。これらのフォーマットはAbuse Reporting Format(英語版)の拡張であり、"message/rfc822"または"text/rfc822-headers"を含む点で通常のバウンスのフォーマットと似ている。
フォレンジックレポートは他に以下のものを含む:
送信元IPアドレス
Fromメールアドレス
受信者のメールアドレス
メールのサブジェクト行
SPFとDKIMの認証結果
受信時刻
電子メールのメッセージヘッダ(送信元ホスト、電子メールID、DKIM署名、その他カスタムヘッダ情報)
集計レポートはふつう、1日1回XML形式で送られる。電子メールのサブジェクトは"Report Domain"、すなわちレポートが生成されたDNSドメイン名と、"Submitter"、すなわちレポートを発行するエンティティである。ペイロードは"!"で区切られた長いファイルネームを連結したものであり、レポートを発行する受信者、Unix形式のタイムスタンプで記されたレポート対象の開始/終了区間、任意の識別子、利用可能な可逆圧縮方式(.zip等) に基づく拡張子等を含む。 例: example.com!example.org!1475712000!1475798400.xml.gz.
XMLはヘッダによって構成され、レコードの後にレポートが参照するポリシとレポートのメタデータが続く。レコードはデータベースに関係として挿入することができ、表形式で見ることができる。XMLスキーマは仕様のAppendix Cで定義されており、元のレコードはdmarc.orgに例示されている。データの性質をうまく説明するべく、以下に関係の例を貼り付けてある。DMARCレコードはXSLを用いることにより直接HTMLに変換することも可能である。
各行は送信元IPと認証結果によって分類され、それぞれのグループにいくつ振り分けられたか(count)が渡される。