DMARCとは？なりすましを防ぐ仕組みと設定方法
ChatGPT
Claude
Gemini
Perplexity
Grok要旨
DMARCとは、SPFとDKIMのアライメントでなりすましを防ぐメール認証です。三つのポリシー、DMARCレコードと主要タグ、2026年の送信者要件、設定方法まで解説します。
DMARCとは
DMARC（Domain-based Message Authentication, Reporting, and Conformance）とは、ドメインの所有者が受信側のメールサーバーに2つのことを伝えるための、メール認証の標準規格です。一つは、メールが本当にそのドメインから送られたかを確かめる方法。もう一つは、その確認に失敗したメールの扱いです。SPFもDKIMも、単独では受信者が実際に目にする送信元アドレスを守れません。DMARCはその穴をふさぎます。
DMARCは、DNSに1つのレコードとして公開します。SPFとDKIMの上に成り立つ仕組みで、新しい認証方式を作るのではなく、両者の結果を表示上のFrom:ドメインに結びつけ、ポリシーとレポートの仕組みを加えます。この組み合わせによって、DMARCはなりすましやドメインを悪用したフィッシングを防ぐ対策になります。
DMARCの仕組み
DMARCポリシーは、_dmarc.yourdomain.comにTXTレコードとして公開します。自社ドメインを名乗るメールを受け取ると、受信側は次の3つをチェックします。
- SPFとDKIMの評価：送信元のIPがSPFレコードで許可されているか、メールに自社ドメインの有効なDKIM署名があるかを、受信側が確認します。
- アライメント：DMARCの核となる考え方です。SPFやDKIMが認証したドメインが、表示上の
From:ヘッダーのドメインと一致して初めて、合格とみなされます。攻撃者も自分が管理するドメインなら、SPFもDKIMも完全に有効なメールを送れます。自社のドメインを借用させないのが、アライメントの役割です。 - ポリシー：SPFもDKIMも一致しない場合、受信側はポリシーで指定された処理を適用します。
DMARCのアライメントとは
アライメントでは2つのドメインを比べます。SPFやDKIMが認証したドメインと、表示上のFrom:ヘッダーのドメインです。デフォルトのrelaxed（緩和）モードでは、組織ドメインが同じであれば一致とみなされ、mail.yourdomain.comはyourdomain.comと一致します。strict（厳格）モードでは完全一致が必要です。モードはadkimタグとaspfタグで方式ごとに指定します。strictはサブドメインからの送信のような一般的な構成を壊すため、ほぼすべてのドメインでrelaxedが正解です。
3つのDMARCポリシー
ポリシーはpタグで指定し、3つの値のいずれかを取ります。DMARCポリシーは対等な3つの選択肢ではなく、根拠を積み上げながら一段ずつ上るはしごです。
p=none：監視
p=noneは、認証に失敗したメールも通常どおり配信し、そのレポートを送るよう受信側に求めます。ポリシーを強化する前に、自社ドメインを名乗って送信しているサービスをすべて洗い出すための設定です。noneでは何も守られず、なりすましメールはそのまま届きます。出発点には最適ですが、とどまるべき場所ではありません。
p=quarantine：迷惑メールに隔離
p=quarantineは、失敗したメールを迷惑メールとして扱うよう受信側に求めます。正規のメールが誤って失敗しても迷惑メールフォルダから取り戻せるため、残りの送信元が正しく認証できるかを確かめる間の、標準的な中間段階になります。
p=reject：受信を拒否
p=rejectは、失敗したメールを配信の段階で拒否するよう受信側に求めます。メールボックスには一切届きません。これがポリシー強化です。完全一致ドメインのなりすましを実際に止められる唯一のポリシーであり、DMARC導入の全工程が目指すゴールです。サブドメインにはspタグとnpタグで個別のポリシーを設定できます。これらがなければ、ドメインのポリシーがサブドメインにも適用されます。
DMARCレコードの構成とタグ
DMARCレコードは一行のテキストです。典型的な初期レコードは次のとおりです。
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com各部分をタグと呼びます。現行の仕様であるRFC 9989で必須なのはvだけで、pは推奨です。それ以外はすべて任意です。
- v（バージョン）：常に
DMARC1です。位置が決まっている唯一のタグで、レコードの先頭に置きます。 - p（ポリシー）：失敗したメールに求める処理で、
none、quarantine、rejectのいずれかです。pがないか無効な場合、受信側は有効なruaアドレスがあればレコードをp=noneとして扱い、なければレコード全体を無視します。 - rua：受信側が集計レポートを送る宛先です。これがないレコードでは、根拠が何も集まりません。
- ruf：受信側が失敗レポートを送る宛先です。個々のメールのサンプルで、プライバシー上の理由から送らないプロバイダーも多くあります。
- spとnp：サブドメイン用と、DNSに存在しないサブドメイン用の個別ポリシーです。
- adkimとaspf：方式ごとのアライメントモードで、relaxed（
r、デフォルト）かstrict（s）です。 - t：導入中はポリシーを参考扱いにするよう受信側に伝えるテストフラグ（
t=y）です。旧仕様で割合を指定していたpctタグ（現在は廃止）の役割の一部を引き継ぎます。
pct、rf、riは、RFC 9989で廃止されました。受信側は未知のタグがあってもレコードを無効にせず無視するため、これらを含むレコードも引き続き機能します。有効な値と例を含むタグごとの解説はDMARCレコードガイドをご覧ください。自社ドメイン用のレコードを作るなら、公開すべきTXTレコードをそのまま出力するDMARC生成ツールが便利です。
レポートの役割：RUAとRUF
DMARCのもう一つの役割は可視化です。受信側は、レコードで指定した宛先に構造化されたレポートを送り返します。
- 集計レポート（RUA）は、自社ドメインで送信しているすべての送信元を、合格・失敗の件数とともにまとめた日次のXMLです。ポリシーを強化する前に、請求システム、ヘルプデスク、マーケティングツールといった見落としていた送信元を見つける手段になります。
- 失敗レポート（RUF）は、失敗した個々のメールのサンプルをほぼリアルタイムで届けます。プライバシーへの懸念から受信側の対応はまちまちで、実務の大半は集計レポートが担います。
p=noneから始める理由は、まさにこのレポートを読むことにあります。より厳しいポリシーで止められる前に、どの正規の送信元でSPFやDKIMの修正が必要かが分かるからです。DMARCレポートリーダーや、読み取りを代行するエージェントを使えば、生のXMLを、すぐ対応できる送信元リストに変えられます。
DMARCは2026年に必須か
2026年、一定量以上のメールを送るならDMARCは必須です。しかも要件には強制力があります。
- GmailとYahooは2024年2月から、一日におよそ5,000通以上を送る送信者に次の対応を求めています。DMARCポリシーの公開、SPFとDKIMの公開（DMARCが合格するよう少なくとも一方を一致させる）、迷惑メール報告率0.3%未満（推奨目標は0.10%）、マーケティングメールのワンクリック登録解除です。要件を満たさない大量送信メールは、ひそかにフィルタされるのではなく拒否されます。ルールはGoogleがメール送信者のガイドラインで、YahooがSender Best Practicesで公開しています。
- Microsoftは2025年、一般向けOutlook.comアドレスへの一括送信者に同様の要件を適用しました。SPF、DKIM、DMARCに失敗したメールはエラー550 5.7.515で拒否されます。詳細はMicrosoftのOutlook.comでのNDRエラー550 5.7.515の修正に記載されています。
- それ以下の送信量ではルールは緩やかですが、流れは一方向です。認証されていないメールは送信量にかかわらず迷惑メールに入ることが増えており、コンプライアンスの枠組みやサイバー保険の質問票でも、DMARCは当たり前のように問われます。
p=noneを公開すれば要件の文言は満たせますが、ドメインはなりすましに対して無防備なままです。要件対応のためのDMARCと保護のためのDMARCは、最初の一歩が同じだけの別のプロジェクトです。送信者要件の詳細は、到達率のハブページで解説しています。
DMARCが重要な理由
- 完全一致ドメインのなりすましを止める：ポリシーを強化すれば、攻撃者は
From:欄に本物のドメインを表示したメールを送れなくなります。これはフィッシングの中でも最も見破りにくい手口です。 - 送信状況が見える：集計レポートには、正規かどうかを問わず、自社ドメインで送信しているすべてのサービスが表示されます。多くの組織にとって、自社の送信の全体像を初めて把握できる機会になります。
- 到達率とブランドの信頼を守る：一貫して認証が通るドメインは、受信トレイに届きやすくなります。また、対応する受信トレイでBIMIのロゴを表示するには、ポリシーを強化したDMARCが前提条件です。
- 業界全体で測定できる：Palisadeの100,000ドメインのDMARC普及率統計では、現在の普及率とポリシー強化率の根拠となる件数、調査方法、ダウンロード可能なデータを公開しています。
DMARCの設定方法
DMARCの設定は、レコードの公開なら数分で済みます。ただし安全にポリシーを強化するには、数週間分の根拠が必要です。流れは次のとおりです。
- まずSPFとDKIMを確認：DMARCは両者の結果を評価するため、少なくとも一方が機能し、一致していなければ役に立ちません。
- レコードを作成：
ruaのレポート送信先を指定したp=noneから始めます。生成ツールを使っても、手で書いてもかまいません。 - DNSホストで公開：
_dmarc.yourdomain.comにTXTレコードとして、ゾーンに実際に応答しているプロバイダーで公開します。 - 集計レポートを読む：少なくとも送信サイクルの一巡分、通常は二〜四週間かけて読みます。
- 正規の送信元をすべて修正：認証やアライメントに失敗している送信元を、一つずつ直します。
- 段階的に強化：
p=quarantine、次にp=rejectへ進み、各段階でレポートを確認します。
DMARCのよくあるトラブル
うまく動かないDMARC導入の大半は、次の4つのいずれかです。設定ガイドでは、公開の手順に沿って各ステップでの対処法を説明しています。ここでは原因の診断という観点からまとめます。
レポートが届かない
原因はたいていレコードそのものです。ruaアドレスがない、または誤字があると何も集まりません。別ドメインのレポート送信先も、そのドメインが認可レコードを公開していない限り無視されます。まずDMARCチェックで自社ドメインが実際に何を公開しているかを確認し、そのメールボックスが任意の送信者からの大きなXML添付ファイルを受け取れるかを確かめてください。
正規のメールがDMARCに失敗する
ほぼ必ず、認証ではなくアライメントの問題です。ベンダーが自社のバウンス用ドメインでSPFに合格しても、そのドメインは表示上のFrom:アドレスと一致しないため、自社ドメインの合格にはなりません。対処法は、そのベンダーでカスタムDKIM署名かカスタムのReturn-Pathを設定し、認証されるドメインを自社のものにすることです。公開レコードではなく実際に届いたメールを調べるなら、受信メールでDMARCアライメントを確認してください。
レコードを公開したのに受信側から見えない
原因は主に2つです。一つは、別のネームサーバーがゾーンに応答しているのに、レジストラでレコードを追加したケースです。保存はできても、名前解決はされません。NSレコードが指す先で公開してください。もう一つは、DMARCレコードの数です。レコードは必ず1つにします。2つ見つけた受信側はレコードなしとみなし、ポリシーが知らないうちに効かなくなります。
転送したメールが失敗し続ける
転送では、転送元のIPがレコードに含まれないため、たいていSPFが壊れます。これは想定内で、問題にはなりません。有効なDKIM署名はメールと一緒に運ばれるので、DKIM側でDMARCは合格します。転送メールが両方のチェックに失敗するなら、対処法はSPFレコードを広げることではなく、元のプラットフォームでDKIM署名を設定することです。
DMARCbis（RFC 9989）で変わったこと
DMARCは最初の十年間、Informational（情報提供）として公開されたRFC 7489で定義されていました。2026年5月、IETFはDMARCbis改訂版を3つのStandards Track文書として公開しました。RFC 9989（コアプロトコル）、RFC 9990（集計レポート）、RFC 9991（失敗レポート）です。これらはRFC 7489と実験的なRFC 9091のPSD拡張を廃止し、DMARCをProposed Standard（標準化提案）に格上げしました。
DMARCbisは新しいプロトコルではなく、仕様の明確化です。互換性を壊す変更はなく、RFC 7489向けに書いたレコードはそのまま使えます。技術面で最も大きな変更は、組織ドメインの決め方です。RFC 9989はPublic Suffix Listへの従来の依存をやめ、DNS Tree Walkに置き換えました。受信側が送信元のサブドメインからDNSツリーをさかのぼり、公開されたDMARCレコードを探す方式で、サブドメインのポリシー検出がより予測しやすくなります。詳しくはDMARCbis（RFC 9989）の変更点をご覧ください。
根拠
出典と参考資料
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)：コアプロトコル、アライメント、DNS Tree Walk。
- RFC 9990: DMARC Aggregate Reporting：
ruaタグで受け取る集計レポートの形式。 - Google：メール送信者のガイドライン：一括送信者に対するGmailの認証、苦情率、登録解除の要件。
- Yahoo Sender Best Practices：Yahooによる同様の一括送信者要件。
- Microsoft：Outlook.comでのNDRエラー550 5.7.515の修正：一般向けOutlook.comが、認証されていない大量送信メールに返す拒否。
関連記事
よくある質問
よくある質問
DMARCの前にSPFとDKIMは必要ですか？
はい。DMARC自体は何も認証しません。SPFとDKIMの結果を評価し、アライメントを確認するだけです。SPFやDKIMが機能していない状態でDMARCレコードを公開すると、ポリシーを強化した時点で正規のメールがすべて失敗します。まず両方を設定し、From:ドメインと一致することを確認してから、DMARCを公開してください。
DKIMとDMARCの違いは？
DKIMは個々のメールに署名します。暗号署名によって、メールが署名ドメインに承認されたものであり、途中で改ざんされていないことを証明します。DMARCはその上にあるポリシーの層です。DKIM（またはSPF）が認証したドメインが表示上のFrom:アドレスと一致するかを確認し、何も一致しないときの処理と、レポートの送り先を受信側に伝えます。DKIMはメールを認証し、DMARCはその認証結果が自社ドメインにとって何を意味するかを決めます。3つのプロトコルはセットで機能します。詳しくはDMARC、DKIM、SPFそれぞれの役割をご覧ください。
DMARCは送信と受信のどちら向けですか？
両方が関わりますが、公開するのは自社が送るメールのためです。ドメインの所有者がDNSにポリシーを公開し、受信側のメールサーバーがそれを実行します。そのドメインを名乗る受信メールを一通ずつチェックし、失敗したメールにポリシーを適用します。つまりDMARCは送信側の身元を守るもので、それを実際に守らせるのは受信側です。
DMARCを簡単に説明すると？
DMARCは、世界中のメールサーバーに向けた公開の指示書です。書かれているのは3つ。メールが本当に自社ドメインから来たかを確かめる方法、確認に失敗したメールの扱い（配信する、迷惑メールに入れる、拒否する）、そしてそのすべてについての日次レポートの送り先です。レコード、タグ、アライメントといったその他の要素は、すべてこの3つの指示を支える細部です。
quarantineとrejectの違いは？
quarantineは、失敗したメールを迷惑メールフォルダに配信するよう受信側に伝えます。誤って失敗したメールも取り戻せます。rejectは受信そのものを拒否するよう伝えるため、メールは届きません。多くのドメインは、確信が深まるにつれてnoneからquarantine、rejectへと進みます。選び方はrejectとquarantineの違いをご覧ください。
DMARCでメールの到達率は上がりますか？
DMARCは、受信側がメールをフィルタしたり拒否したりする主な理由の1つを取り除きます。Gmail、Yahoo、Outlook.comはいずれも一括送信者に認証を求めています。一貫してDMARCに合格するドメインは、レピュテーションを積み上げる土台となる検証済みの身元を受信側に示せます。ただし受信トレイへの到達を保証するものではありません。認証済みのメールでも、受信トレイか迷惑メールかを決めるのはレピュテーションとエンゲージメントです。一連の手順は到達率改善ガイドで解説しています。
p=noneでGoogleとYahooの要件を満たせますか？
一括送信者の要件そのものは満たせます。ルールが求めるのはDMARCポリシーの公開で、p=noneもそれに当たります。ただし保護の面では不十分です。noneでは、なりすましメールがそのまま届きます。noneは、要件がたまたま認めている根拠集めの段階であり、ゴールではないと考えてください。
DMARCでメールは暗号化される？
いいえ。DMARCが扱うのは真正性とポリシーで、機密性ではありません。メールが本当に自社ドメインから来たかを検証し、証明できない場合の処理を受信側に伝えます。ただし接続をTLSで別途保護しない限り、本文は平文のまま送られます。
DMARCを公開するとニュースレターや転送メールが届かなくなりますか？
それらのメールが認証されていない場合に限ります。転送ではSPFが壊れることが多いものの、有効なDKIM署名はたいてい残るため、DKIM側でDMARCは合格します。リスクは、認証し忘れた正規の送信元です。ポリシー強化の前にそれを洗い出すために、p=noneの監視期間と集計レポートがあります。
RFC 7489はまだ有効ですか？
RFC 7489はRFC 9989、9990、9991によって廃止されましたが、既存のDMARCレコードを変更する必要はありません。DMARCbisに互換性を壊す変更はありません。すでに公開している構文を置き換えたのではなく、標準の位置づけを変え、内容を明確にしたものです。
執筆者
Samuel ChenardPalisade 共同創業者・CEO
Samuel ChenardはPalisade共同創業者兼CEO。Palisadeは1ドメインから数千まで対応する、IT部門・MSP向けのエージェント型DMARC。
Samuelの記事 →