電子メールを受信する際に、メールの送信者が名乗っている情報 (メールアドレス) が正しいのかを確かめることができれば、なりすましメールを見破ることができるようになります。また、なりすまされていないことが明確であれば、送信者のメールアドレス (送信者情報) から受け取るべきメールかどうかを判断しやすくなります。
SPF や DKIM それぞれ単体の送信ドメイン認証技術と、DMARC との大きな違いは、それぞれの認証結果のどちらかが pass すれば良いこと、メール受信者が直接みることができるメールヘッダ上の送信者情報 (From:ヘッダ) を認証すること、メール送信者が認証が失敗したメールの取り扱いを示すことができること、メール送信者が認証結果をメール受信者から受け取る仕組みが用意されていること、が挙げられます。
SPF で正しいメールがうまく認証できないメールの利用形態に、メール転送があります。逆に DKIM では、メールの送信経路によらない情報を元に認証しますので、メール転送には強いという特徴があります。一方で、SPF の特に送信側の導入は非常に簡単にできますので、メール受信側からみた SPF の普及率は高く、送信ドメイン認証の効果が得やすいのも特徴と言えます。このように、SPF と DKIM にはそれぞれが優位性を持っており、多くの場面で相互補完的な役割を果たします。つまり、どちらか一つの技術を選んで普及や機能強化していくより、既にある程度普及している技術を活用することで、総合的に効果を発揮すれば良いという考え方が DMARC であると言えます。
SPF や DKIM が認証する送信ドメインは、メールの受信者が送信者情報と思うメールヘッダー上の送信者 (From:) とは異なります。そのため、SPF や DKIM の認証が passしたとしても、必ずしもメールソフトウェアが表示している送信者情報がなりすまされていない、ということを示しているわけではありません。DMARC は、SPF や DKIM で認証した送信ドメインと、メールヘッダー上の送信ドメインとが同じであるか、同じ組織ドメインでなければ、DMARC としては認証されません。つまり、DMARC の認証が pass したということは、メール受信者に表示されている送信者情報のドメインがなりすまされていないことを示しますので、非常にシンプルでわかりやすいと言えます。
送信ドメイン認証が失敗した場合、それがなりすましメールであれば正しく機能したことになりますが、正常なメールが何らかの事情により失敗することもあります。こうした場合、メール受信側は送信側の状況や配送経路などを個別に把握することは難しいので、認証が失敗したメールの取り扱いの判断が難しい場合があります。DMARC では、送信側のドメイン上に DMARC レコードを設定し、その中で認証が失敗したメールの受信側の取り扱いをポリシーとして表明することができます。
理想的には、正常なメールの DMARC 認証が失敗しないことが望ましい状況です。しかしながら、送信されたメールがその後どういう経路を経て最終的なメール受信者に届くのかは、送信者でも把握することができません。例えば、送信されたメールが一度受信されたのちに別のメールアドレスに転送されることはよくあることです。こうした場合、SPF の転送問題により SPF が認証できないことは既に述べましたが、メール転送過程で電子署名対象のメール情報が何らかの影響で改変されて DKIM の認証まで失敗するかもしれません。
こうした状況をメールの送信側が把握することは難しく、仮に DMARC のポリシーを p=reject と宣言していた場合、メール受信者に届かない可能性も高いため、メールが届かなかったことが送信者も受信者も気がつかず、せっかく送信したメールが誰の目にも触れずに消えているかもしれません。また、こうした状況を予想するメール送信者は、なかなか p=reject とは宣言しづらいため、なりすましメールがメール受信者に届き続ける、という状況が続く可能性があります。DMARC では、認証の状況を集約してメール送信側にレポート送信したり、認証が失敗したメールをレポートする機能があります。メール送信側は、こうしたレポートを確認し、正しく送信されたメールが認証失敗していないかを確認できることにより、より強いポリシーを設定することもできるようになると考えられます。