DMARC チェックを実行すると、自ドメインの _dmarc TXT レコードを取得し、それが受信側に何を指示しているかを分解します。ここでは、その結果の読み方と、最も重要な部分への対処法を説明します。
DMARC チェック結果の読み方
チェッカーは4つのことを報告します。有効な v=DMARC1 レコードが存在するか、適用ポリシー（p=）、SPF と DKIM のアライメントモード、そしてレポートの送信先（rua/ruf）です。健全な結果とは、レコードが1つで、ポリシーが none より強く、少なくとも集約レポートの送信先があり、誰があなたのドメインとして送信しているかを把握できる状態です。
3つの DMARC ポリシー：none、quarantine、reject
p=none- 監視のみ。失敗したメールも配信され、レポートを収集するだけです。これは出発点であり、目的地ではありません。p=quarantine- 失敗したメールは迷惑メール/スパムに送られます。最初の本格的な適用ステップです。p=reject- 失敗したメールは完全にブロックされます。これが目標であり、ドメインなりすましを止めるものです。
正しいロールアウトは none → quarantine → reject であり、レポートですべての正規送信者が通過していることを確認してから初めて次へ進みます。p=none のまま無期限にとどまるのは最もよくある DMARC の誤りで、まったく保護になりません。
SPF と DKIM のアライメント：SPF が通過しても DMARC が失敗する理由
DMARC は、SPF または DKIM が通過したかどうかだけをチェックするのではなく、それらが目に見える From アドレスのドメインとアライメント（整合）しているかをチェックします。メッセージは送信サービス自身のドメインで SPF を通過しても、そのドメインが From ヘッダーと一致しないために DMARC に失敗することがあります。aspf と adkim タグはその一致がどれだけ厳密でなければならないかを制御します。r（relaxed）はサブドメインを許可し、s（strict）は完全一致を要求します。その違いは当社の SPF アライメントの理解 ガイドで詳しく解説しています。有効な SPF レコードでも DMARC に失敗する場合、ほぼ常にアライメントの不整合が原因であり、通過してアライメントの取れた SPF レコードは、そもそも SPF が正しいことに依存します。
よくある DMARC の設定ミス
- レコードがない、またはホストが誤っている。 レコードは apex ではなく
_dmarc.yourdomain.comに置く必要があります。 - DMARC レコードが2つある。 許されるのは1つだけで、2つ目があると両方が無効になります。
p=noneのまま。 永遠に監視だけでは、適用はゼロです。ruaアドレスがない。 集約レポートがなければ、盲目のまま適用することになります。
集約レポートとフォレンジックレポート
集約レポート（rua）は、あなたのドメインとして送信するすべてのソースと、それらが通過したかどうかを示す日次の XML 要約です。ここで不正な送信者を見つけ、自分の送信者がアライメントしていることを確認できます。フォレンジックレポート（ruf）は、より深い調査のために個々の失敗メッセージを捕捉します。生の XML を読みやすくするために、当社の姉妹製品 DMARC Report がそれを解析して可視化します。
DMARC、SPF、DKIM は連携して機能する
DMARC は、2つのチェックの上に立つポリシー層です。SPF（送信サーバー）と DKIM（メッセージが改ざんされていないことを証明する署名）です。DMARC の適用には、通過してアライメントの取れた SPF の結果が必要なため、SPF レコードを有効かつ 10 回のルックアップ制限内に保つことが基盤となります。AutoSPF がそれを自動的に処理します。全体像は当社の DMARC ガイド でご覧ください。