DMARCがSPFとDKIMに加えるもの
SPFとDKIMはそれぞれメッセージについて何かを証明しますが、どちらもその証明が受信者の実際に見るアドレスと関係していることまでは確認しません。DMARCはこの隙間を埋めます。SPFまたはDKIMが通過し、かつFromドメインとアラインしていることを要求したうえで、両方が失敗したときに受信側が何をすべきかを指示します。さらにレポートも届くため、あなたのドメインとして送信しているすべてのツールを確実に洗い出す唯一の方法になります。
レコードは _dmarc.yourdomain.com にTXTレコードとして置かれます。最小限で実用的なものは次のとおりです。
v=DMARC1; p=none; rua=mailto:[email protected]none、quarantine、reject の選び方
p=none は監視モードです。受信者側には何の変化もありませんが、レポートが届きます。p=quarantine は、認証に失敗したメールを迷惑メールに入れるよう受信側に依頼します。p=reject は拒否を依頼します。GmailとYahooは一括送信者にDMARCレコードを要求しており、強制（quarantine または reject）を、適切に運用されたドメインの証と見なします。
- DKIMを有効にしたメールボックスプロバイダー1社からのみ送信する新しいドメインは、たいていそのまま p=reject にできます。
- ツールや連携の履歴があるドメインは、p=none から始めて数週間レポートを読むべきです。
- pct を使って強制を段階的に導入しましょう。pct=25 なら、失敗メールの4分の1にポリシーを適用し、残りには弱いほうのポリシーを適用します。
- サブドメインがメールを送らないのであれば sp=reject を設定し、サブドメインのなりすましも防ぎましょう。
集約レポートとフォレンジックレポート
rua タグは、受信側が集約レポートを送る宛先を列挙します。これは、あなたのドメインとして送信したすべてのIPと、SPF・DKIMが通過してアラインしたかどうかをまとめた日次のXMLファイルです。ruf タグはフォレンジックレポート、つまりメッセージ単位のサンプルを要求します。これを今も送る受信側はごくわずかで、メッセージ本文が含まれる場合もあります。ほとんどのチームにとっては rua だけで十分です。
レポート宛先がレコードを公開するドメインとは別のドメインにある場合、受け取る側のドメインは yourdomain.com._report._dmarc.reportdomain.com に v=DMARC1 を含む承認レコードを公開する必要があります。ホスト型のDMARCレポートサービスは、これを自動で行います。
アラインメントモードとコールドメールツール
緩和アラインメント（既定）は、DKIMの署名ドメインやSPFのエンベロープドメインが、Fromドメインそのものか、そのサブドメインであることを許容します。厳格アラインメントは完全一致を求めます。コールドメールのプラットフォームはあなた自身のメールボックスプロバイダー経由で送信するため、Fromドメイン、DKIMドメイン、SPFドメインが一致し、緩和アラインメントはきれいに通過します。
問題が起きるのは、ツールが自社インフラから別のエンベロープドメインで、独自DKIMなしに送信する場合です。そのメッセージはアラインメントに失敗し、強制中のポリシーによって隔離されます。引き締める前にレポートを確認し、特別な理由がない限りアラインメントは緩和のままにしてください。InboxOneのドメインはDMARCレコードが設定済みで提供されるため、最初のキャンペーンから認証された状態で始められます。
