DMARC とは？アライメント、ポリシー、2026年のRFC
要約
DMARCはあるメッセージがあなたのドメインを主張しているがメール認証に失敗した場合、受信側サーバーが何をするか指示し、どこにレポートを送るかを指定するDNS TXTレコードです。SPFまたはDKIMが検証され、検証ドメインが見える From ドメインと一致したときにのみ合格します。p=noneの rua アドレスで開始し、アライメント失敗の送信者を修正した後、quarantineに移動してから reject に移動してください。2026年のRFC 9989改正はpctを t に置き換え、npとpsdを追加します。
DMARC とはメールサーバーに指示を与えるDNSレコードです。送信者が自分のドメインをFromヘッダーで宣言しているのに、実際にはメール認証に失敗している場合、受信側サーバーはどのような対応をすればよいか、そしてその結果をどこに報告するかを指定するものです。DMARC自体は認証機能を持ちません。SPFまたはDKIMが成功し、その認証に使用されたドメインが送信者が主張するドメインと一致しているかをチェックするだけです。
この一致をアライメント（alignment）と呼びます。そしてアライメントの理解不足が最も多い失敗原因です。メールがSPFに合格し、DKIMにも合格していながら、DMARCには不合格となることがあります。
DMARCはSPFとDKIMの上に構築されたポリシーレイヤーです
SPFは、あるドメインの代わりにメールを送信できるIPアドレスを指定します。DKIMはメッセージに署名をして、受信側が改ざんされていないことを確認でき、また署名ドメインがこのメッセージを送信することを承認していることを証明します。どちらも送信者が人間に見える形で指定するFromアドレスを検証しません。
DMARCはこのギャップを埋めます。単純な問いを立てます。送信者が人間に見える形で指定するFromヘッダーのドメインは、SPFまたはDKIMで検証されたドメインと一致しているか。Yes であれば、メッセージは合格です。No であれば、受信側はあなたが設定したポリシーを適用します。
DMARCレコードは _dmarc.yourdomain.com というDNS TXTレコードとして存在します。最小限で有効なレコードは次のようになります：
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"実装に必須のタグは3つです。p がポリシー、rua は集約レポートの送信先、そして adkim / aspf はアライメントのチェック方法を指定します。その他のタグはすべてオプショナルです。
アライメント失敗はよい設定でも起こります
SPFはエンベロープ送信者、Return-Pathドメインを認証します。DKIMは署名の d= タグに指定されたドメインを認証します。DMARCはこれらのうち少なくとも一つが Fromドメインと一致していることが必要です。完全一致（strict）で、あるいは組織レベルで一致（relaxed、デフォルト）するかのいずれかです。
これが現実で最もよく見かける失敗パターンです。チームが外部のメール送信プロバイダを通じてメールを送り、プロバイダが自社ドメイン（d=provider-mail.net）で署名をして、自社のバウンスドメインを使用しています。SPFに合格し、DKIMにも合格します。しかしDMARCには不合格になります。どちらのドメインも example.com と一致していないからです。
解決策は、カスタム送信ドメインを使うことです。自社ドメインの配下にDKIMキーを公開し、理想的には自社のサブドメインでカスタムリターンパスを設定します。どの主要なプロバイダもこれをサポートしています。ただし、デフォルトで有効になっていることは稀です。
3つのポリシー：none、quarantine、reject
p タグには3つの値があり、これらはスケジュールに沿って段階的に上げるステップではありません。
p=none: 受信側は通常通り配信し、レポートを送信します。最初の2〜4週間はこれを使用して、送信者をリストアップしましょう。p=quarantine: 受信側は不合格のメールをスパムやジャンク箱に移動させます。すべての正当な送信者がアライメント済みであることがレポートで確認されたら使用します。p=reject: 受信側はSMTPステージで不合格メールを拒否します。quarantine ポリシーが1度の送信サイクルを通して問題なく稼働したら使用します。
p=none は保護ではなくモニタリングです。2年間 none のままにされているドメインは、コンプライアンスチェックボックスは満たしていますが、なりすまし対策には何ら効果がありません。「何も破壊されないから」という理由でそこに留めておく誘惑を避けましょう。
p=reject は、あなたが管理するメール送信のみを行うドメイン向けの最終地点です。メーリングリストのトラフィックが多いドメインやレガシーフォワーダーを使用するドメインは、フォワーディングがSPFを破壊することが多く、本文を編集するとDKIMも破壊される可能性があるため、より慎重な対応が必要です。
GmailとYahooのルール変更がこれを急務にしました
2024年2月以降、Googleのメール送信ガイドラインでは、Gmail アカウントに1日5,000件以上のメールを送信するすべての送信者に、DMARCレコード、SPF、DKIMを発行することを要求しています。ポリシーは none でもかまいません。Googleはまた、バルク送信者に対して、Postmaster Tools での送信者報告スパムレートを0.30%以下に保つことを推奨し、0.10%未満を目指すよう奨励しています。
Yahoo Sender Hub は同じ基本的な要件を述べています：有効なDMARC ポリシー（少なくとも p=none）の発行、FromドメインはSPFまたはDKIMドメインと一致している必要があります。relaxed アライメントで問題ありません。
これらのルールに何が含まれ、何が含まれていないかに注意してください。要件は、レコードを発行すること、そしてアライメントが成功することです。ポリシーの強制（enforcement）ではありません。これはベースラインです。終了地点ではありません。
集約レポートが製品で、ポリシーがスイッチです
rua アドレスには、DMARCを認識するすべての受信側からの日次XMLレポートが届きます。各レポートには、送信元IP、メッセージ数、SPFとDKIMの結果、そしてアライメント成功の有無がリストされています。これが、忘れられていた送信者を発見する方法です：古いCRMエクスポート、誰かが2022年に配線した課金ツール、誰も所有していないサブドメイン上のマーケティングフォーム。
生のXMLは大量にあると読み込めません。rua をパーサーが処理できるメールボックスに送るか、ホスト型DMARC レポートサービスに送り、送信元でグループ化されたデータを見ます。目指すべき状態は：すべての正当な送信者が100%アライメント済みで表示されること、そしてそれ以外はすべて明確に「未知」と表示されることです。
実践的なロールアウト順序は以下の通りです：
p=noneとruaアドレスを発行します。2〜4週間のレポートを収集します。送信者インベントリを作成します。
アライメント失敗している正当な送信者ごとに、カスタムDKIMドメインまたはリターンパスで対応します。
p=quarantineに移動します。メール遅延についてのサポートチケットを監視します。quarantine が正当な失敗を示さないようになったら
p=rejectに移動します。
各ステップを分けて実施してください。ポリシー変更と新しい送信プロバイダを同じ週に追加することは、いかなる後退原因の特定も不可能にします。
DMARCbis はタグを変更しますが、あなたのレコードはそのままです
2026年、IETF は RFC 9989、RFC 9990、RFC 9991 を発行し、RFC 7489 を廃止しました。RFC 9989 がDMARC コアスペックです。集約レポートと失敗レポートはそれぞれ独立したドキュメントに移動されました。
レコード所有者にとって実践的な変更は小さいものです：
pct、rf、riは削除されました。t（テストモード）がpctに置き換わります。t=yはレポートをしますが、ポリシーは強制しません。npは存在しないサブドメインのポリシーを設定し、abc123.example.comのようなアドレスになりすましを防ぎます。psdはパブリックサフィックスドメインをマークします。DNS ツリーウォークが古いPublic Suffix List ルックアップに置き換わります。
既存の v=DMARC1 レコードは有効なままです。今日何も変更しないなら何も壊れません。新しいタグのプロバイダサポートはばらばらにロールアウトするため、何もしていないように見えるタグは、通常、受信側がまだ実装していないことを意味しています。
np タグはアーリーアダプターの価値があります。p がまだ none のままで np=reject を設定すれば、メール全体を強制対象に含めることなく、偽のサブドメインインチデント経路を閉じることができます。
サブドメイン、そしてデフォルトが継承される理由
組織ドメイン上のDMARC レコードはサブドメインにも適用されます（ sp で上書きしない限り）。この継承は便利ですが、罠にもなります。
マーケティング部門が news.example.com から別のプロバイダを通じてメール送信をしている場合、親のポリシーを継承します。そのプロバイダがアライメント済みのDKIMを用意する前に親を p=reject に移動させれば、ニュースレターが床に着地してしまいます。サブドメインが独自の送信者フレート，独自のロールアウトペースを持つ場合は、_dmarc.news.example.com に個別のDMARC レコードを公開します。
クリーンなアーキテクチャは最初からストリームをサブドメインで分離します。トランザクショナルメールを1つに、ライフサイクルメールを別の1つに、人的なメール処理をルートドメインに。それぞれが独自のDKIMキー、独自のレピュテーション、独自のDMARC レコードを持ちます。
Authentication-Results ヘッダーを読んでから推測してください
メッセージが失敗した場合、受信側サーバーは理由を記録します。Gmailでは「メッセージのソースを表示」で Authentication-Results ヘッダーが公開されます。これはどのダッシュボードよりも多くの情報を示しています。
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounce.provider-mail.net;
dkim=pass header.d=provider-mail.net;
dmarc=fail (p=NONE) header.from=example.com左から右に読んでください。SPFは bounce.provider-mail.net で合格しました。DKIMは provider-mail.net で合格しました。DMARCは失敗しました。なぜならFromヘッダーは example.com を言っているのに、どちらの合格ドメインも一致していないからです。
(p=NONE) という記述は、受信側が見たポリシーを示しています。none では、このメッセージは実際に配信されました。reject なら、SMTP ステージで拒否されて、送信者は顧客から知らされていたでしょう。
2つのチェックがほとんどのケースを捉えます。DKIM 結果の header.d 値が自分のドメインであることを確認してください。次に smtp.mailfrom ドメインが自分のドメインまたはそのサブドメインであることを確認します。
SPFはルックアップ制限があり、DMARCがそれを露呈させます
SPFは1回のSPF評価で10回のDNS ルックアップを許可しています。プロバイダごとの include: タグはそれぞれルックアップ予算を消費し、ネストされたinclude はさらに消費します。10回を超えると、SPF は永続的エラーを返します。これは失敗としてカウントされます。
5個から6個の送信ツールを持つチームは、SPF 失敗が見えなかったため、気づかずにこれに達するかもしれません。rua レポートが到着し始めると、パターンは明白です：1つの送信元が突然すべての受信側でSPF失敗し始めたのは、誰かが別の include: を追加した日からです。
この理由からも、DKIM アライメントを第一義的な成功パスとして頼ることが重要です。DKIMはほとんどのフォワーディング環境で有効に機能し、ルックアップ予算がなく、メッセージに結び付けられています。SPFを有効に保ち、しかしDMARC 成功をSPFだけに依存しないようにしてください。
DMARCができないこと
DMARCは正確なドメインなりすましを防ぎます。ルックアライクドメイン（examp1e.com）は防ぎません。コンテンツを判断することもしません。悪い送信者レピュテーションを修正することもありません。完璧にアライメントされたドメインが購入リストに送信していれば、それでもスパムランドに落ちてしまいます。
また、モニタリングも替わりません。アライメントはサイレントに破壊されることがあります：DNSの変更がDKIM セレクタを削除する、プロバイダがキーをローテーションする、新しいツールが知らない間に送信を開始する。レポートは、ユーザーが知る前に発見する方法です。
DMARCレコードは他の製造コンフィグと同じように扱いましょう。バージョン管理に属し、変更はレビューを通します。そして rua メールボックスには所有者がいます。
レコード発行前にチェックすること
これを一度走し抜いてください。単一のドメインなら1時間以下です。
あなたのドメインの代わりにメール送信を行うすべてのシステムをリストアップ：プロダクト、課金、サポートデスク、CRM、マーケティング、カレンダー招待。
それぞれがベンダーのドメインではなく、自分のドメインでDKIMに署名していることを確認してください。
プロバイダがサポートしている場所では、カスタムリターンパスを設定してください。
rua送信先を誰かが読むメールボックスに指定してください。p=noneで開始し、レビュー予定日をカレンダーに入れてください。ロールアウト中、毎週Google Postmaster Tools でスパムレートを確認してください。
ここから先へ
レポートを見たことがないなら、p=none と rua アドレス付きで発行して、2週間後に届いたレポートを読んでください。最初のレポートはほぼ確実に、誰も思い出さなかった送信者を少なくとも1つ名前上げます。次の具体的なステップは、それらのどれを保つか決めることです。