送信ドメイン認証DMARCとは？

メールの送信元アドレスの成り済まし対策の1つが、メールの送信側が、送信元ドメインを所有していることを証明するドメイン認証です。　

ドメイン認証の中にも様々な種類がありますが、最近多分一番多く実装されているのが Sender Policy Framework（SPF）と DKIM です。
ただ、SPFもDKIMも、仕様として万能な訳ではありません。

SPFやDKIMの欠点（というか限界）の1つが、メールの受信時に、SPFやDKIM検証で成功・失敗した結果を基に、どんな処理を行うべきなのか、アクションの定義が曖昧である事が挙げられます。

言い方を変えると、SPFやDKIMでの送信者認証に失敗した場合、受信者によってはメールを受信拒否しますが、多くの場合はヘッダを挿入したり、別のフォルダへ隔離するだけになってしまう、という事です。

実際に、受信するべきメールを受信できなくなる可能性を考えると、認証に失敗したメールを拒否しているケースの方が少ないのが現状で、こうなると、送信者認証の結果を、後の精度の向上につなげる事はできません。

＊Sender Policy FrameworkとDKIMにつきましては、こちらのページからご確認頂けます。

せっかくの送信認証結果を、後の効率化アップにつなげるためには何が必要でしょうか。

送信ドメイン認証が成功したのか失敗したのか、どうして失敗したのかといった報告、つまりレポートです。

そう、DMARC (Domain-based Message Authentication, Reporting & Conformance) です！
要は、レポーティングがキーなのですね。

もう1つ、DMARCで必要不可欠な要素が「ポリシー」です。
DMARCでは、認証にSPFやDKIMを使うのですが、この認証に失敗した時にどのように処理するのかというポリシーを、送信ドメインの署名と一緒に送信元の方で定義しておくわけですね。

DMARCはDNSへポリシーに関する記述を行うところから始まります。
例えば、「自社ドメインを語ったもののうち、SPFで認証に失敗したメールはブロックする」といった感じです。

この自社ドメインが入る場所なのですが、メールヘッダの中の From: をチェックします。
（メールヘッダについては、メールとSMTPについてのページをご参照ください。）

DMARCの実装からメール配信までの流れは次の通りとなります。　　　　　

1：DNSへ、SPF、DMARC、DKIMレコードを追記します。
2：ドメインからメールを送信します。
3：受信側のドメインがDMARCに対応していると、メールの受信時に送信元のDNSレコードをチェックし、認証に失敗したメールをどのように処理すればいいかを（ポリシー情報を基に）判断します。
4：メールを処理しつつ、SPFとDKIM署名の検証も行います。失敗した場合は、ポリシーに基づいた処理を行うのと同時に、レポートに失敗したメールの情報を記録します。
5：一日に一回、受信側のメールサーバーで、送信ドメイン毎のメールレポートを、送信元のレポート送付先アドレスへ送ります。レポートはZIPファイルとしてメールへ添付された状態で送られます。