DMARCとは？なりすましメールを防ぐ仕組みと設定方法をわかりやすく解説

「自社のドメインを名乗るフィッシングメールが届いた」「自分のドメインから送ったメールが迷惑メールに入ってしまう」といった悩みや、「メールの送信元認証にDMARCが必要と言われたが、何をすればいいのかわからない」という声は、年々増えています。

DMARC（ディーマーク）は、メールのなりすましを防ぐための仕組みで、SPFやDKIMと組み合わせて使います。近年は、GoogleやYahoo!、Microsoftといった大手メールサービスが、大量にメールを送る事業者に対してDMARCの設定を求めるようになり、企業だけでなく、独自ドメインを使うすべての人にとって、無視できない設定になっています。

この記事では、DMARCの基本的な意味から、SPF・DKIMとの関係、レコードの書き方、ポリシーの選び方、導入の進め方、2026年5月に行われた仕様の更新、確認方法、よくあるトラブルまでを、初心者の方にもわかりやすく解説します。

DMARCとは

DMARC（Domain-based Message Authentication, Reporting and Conformance）とは、メールの送信元ドメインが偽装されていないかを受信側が検証し、その結果に応じた扱い方（ポリシー）と、検証結果のレポートを、ドメインの所有者が指定できる仕組みです。

DMARCを設定すると、次のようなことができるようになります。

• 自分のドメインを騙った、なりすましメールを検出しやすくする
• 認証に失敗したメールを、受信側でどう扱ってほしいか（何もしない・迷惑メール扱い・拒否）を、ドメイン所有者が意思表示できる
• 自分のドメインを使って、どこからどれだけメールが送られているかを、レポートで把握できる

郵便にたとえると、SPFやDKIMが「差出人の身元を確認する手続き」だとすれば、DMARCは「身元確認に失敗した郵便物を、どう扱ってほしいかを、差出人の住所の持ち主が、郵便局に伝えておく取り決め」のようなものです。

なぜDMARCが必要なのか

メールの送信元を示す「From」の表示は、実は、送信者が自由に書き換えられてしまいます。そのため、銀行や通販サイト、宅配業者などを装った、フィッシングメールが後を絶ちません。

SPFやDKIMといった認証技術は以前から存在しましたが、それぞれ、次のような弱点がありました。

• SPFやDKIMは、「認証に成功したかどうか」を確認する仕組みで、認証に失敗したメールを、どう扱うかは、受信側の判断に任されていた
• SPFやDKIMが検証する対象と、受信者がメールソフトで目にする「From」の表示は、必ずしも一致するとは限らない
• 認証結果を、ドメイン所有者に知らせる標準的な仕組みがなかった

DMARCは、これらの課題を補うために作られました。ユーザーの目に触れる「From」のドメインと、SPF・DKIMで認証されたドメインが一致しているかを確認し、その結果に基づく扱い方を、ドメイン所有者が指定できるようにしたのです。

SPF・DKIM・DMARCの関係

メールの送信ドメイン認証は、3つの仕組みが組み合わさって動きます。

仕組み	何を確認するか	主な役割
SPF	メールを送ってきたサーバーのIPアドレスが、そのドメインで許可されたものか	送信元サーバーの正当性の確認
DKIM	メールに付けられた電子署名が正しく、途中で改ざんされていないか	メールの真正性・改ざんの有無の確認
DMARC	「From」のドメインが、SPFやDKIMで認証されたドメインと一致しているか。失敗した場合の扱い方の指定と、レポートの受け取り	認証結果の統合と、ポリシー・レポートの管理

DMARC単体では機能しません。DMARCを使うには、SPFまたはDKIMの、少なくともどちらか一方が、正しく設定されている必要があります。 実際の運用では、SPFとDKIMの両方を設定したうえで、DMARCを追加するのが一般的です。

DMARCの仕組み

DMARCによる検証は、次の流れで行われます。

1. 送信者が、ドメイン「example.com」から、メールを送信する
2. 受信側のメールサーバーが、メールを受け取り、SPFとDKIMの検証を行う
3. 受信側のメールサーバーが、「From」に書かれたドメイン（example.com）のDMARCレコードを、DNSに問い合わせて取得する
4. SPFまたはDKIMのどちらかが「成功」し、かつ、その認証されたドメインが、「From」のドメインと一致（アライメント）していれば、DMARCは「合格」となる
5. どちらも条件を満たさなければ、DMARCは「不合格」となり、DMARCレコードに書かれたポリシーを、判断材料の1つとして、受信側がメールを処理する
6. 受信側は、集計した認証結果を、DMARCレコードで指定されたアドレスへ、レポートとして送信する

アライメント（一致）とは

DMARCで特に重要なのが、「アライメント」という考え方です。

• SPFアライメント：SPFで検証されたドメイン（エンベロープFrom）が、「From」のドメインと一致しているか
• DKIMアライメント：DKIM署名に使われたドメイン（d=）が、「From」のドメインと一致しているか

一致の判定には、次の2種類のモードがあります。

モード	内容
リラックスモード（relaxed）	サブドメインが異なっていても、組織のドメインが同じなら一致とみなす（デフォルト）
ストリクトモード（strict）	ドメイン名が完全に一致する場合のみ、一致とみなす

たとえば、メール配信サービスを使って、自社ドメインのメールを送る場合、SPFやDKIMは「配信サービス側のドメイン」で成功していても、「From」のドメインと一致していないために、DMARCが不合格になる、というケースがよくあります。この場合は、配信サービスの設定で、自社ドメインでDKIM署名を行うようにするなど、アライメントが取れるように設定します。

DMARCレコードの書き方

DMARCの設定は、DNSにTXTレコードを追加することで行います。ホスト名は、必ず「_dmarc」 にします。

項目	設定値
ホスト名	_dmarc
タイプ	TXT
値	v=DMARC1; p=none; rua=mailto:[email protected]

ゾーンファイル形式では、次のようになります。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

主なタグの意味

DMARCレコードは、「タグ=値」を、セミコロン（;）で区切って記述します。

タグ	意味	例
v	バージョン。必ず先頭に書き、DMARC1とする	v=DMARC1
p	ドメイン自身に対するポリシー	p=none / quarantine / reject
sp	サブドメインに対するポリシー（省略すると、pと同じ）	sp=reject
rua	集計レポートの送信先	rua=mailto:[email protected]
ruf	失敗レポートの送信先	ruf=mailto:[email protected]
adkim	DKIMのアライメントモード（r：リラックス、s：ストリクト）	adkim=r
aspf	SPFのアライメントモード	aspf=r

なお、失敗レポート（ruf）は、メール本文などの個人情報を含みうるため、送信を制限・停止している受信側が少なくありません。実際の運用では、集計レポート（rua）を中心に確認するのが一般的です。

ポリシーの種類（none・quarantine・reject）

pタグには、3つの値のいずれかを指定します。

ポリシー	意味	受信側の主な扱い
none	特に何もしない（監視のみ）	通常どおり配送される。レポートだけが送られてくる
quarantine	隔離を求める	迷惑メールフォルダへの振り分けなど、疑わしいメールとして扱われやすい
reject	拒否を求める	受信を拒否される、または、それに近い厳しい扱いを受ける

p=noneは、メールの扱いを一切変えないため、「設定しても意味がないのでは」と思われがちですが、そうではありません。レポートを受け取って、現状を把握するための、最初のステップとして重要です。

DMARCの導入手順

いきなり厳しいポリシーを設定すると、正当なメールまで届かなくなるおそれがあります。次のように、段階的に進めましょう。

1. 送信元の洗い出し：自社ドメインでメールを送っているすべてのサービス（メールサーバー、メルマガ配信サービス、問い合わせフォーム、業務システムなど）を、リストアップする
2. SPFとDKIMの設定：それぞれの送信元について、SPFとDKIMを正しく設定する
3. p=noneでDMARCを開始：ruaを指定して、まずは監視だけを行う
4. レポートの確認：数週間程度レポートを集め、認証に失敗している正当な送信元がないかを確認し、あれば設定を修正する
5. p=quarantineへ移行：問題がなくなったら、隔離のポリシーに切り替え、様子を見る
6. 状況に応じてp=rejectを検討：ドメインの使い方に合わせて、より厳しいポリシーを検討する

レポートはXML形式のため、そのままでは読みにくい面があります。DMARCレポートを見やすく集計してくれる、専用のツールやサービスを使うと、作業がぐっと楽になります。

メールを送らないドメインの設定

メールをまったく送らないドメイン（ウェブサイト専用のドメインなど）も、なりすましに悪用される可能性があります。そうしたドメインには、次のような設定をしておくのが一般的です。

example.com.         IN  TXT  "v=spf1 -all"
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject"

「このドメインからメールが送られることはない」と宣言しておくことで、なりすましメールを、受信側で排除してもらいやすくなります。

【2026年5月】DMARCの仕様が更新されました

DMARCは、2015年に公開された、初代の仕様（RFC 7489）に基づいて広く使われてきましたが、2026年5月に、IETFによる新しい仕様が公開されました。RFC 9989、RFC 9990、RFC 9991の3つに分かれ、初代の仕様に置き換わるものとなっています。

主な変更点

• 従来の「参考情報（Informational）」から、標準化過程の仕様（Proposed Standard）に位置づけが変わった
• 仕様が、本体（RFC 9989）、集計レポート（RFC 9990）、失敗レポート（RFC 9991）の3つに分割された
• 新しいタグとして、存在しないサブドメイン用のnp、テスト用のt、公開サフィックス用のpsdが追加された
• 従来のタグのうち、pct、rf、riが廃止された
• 組織ドメインを判定する方法が、公開サフィックスリストによる方法から、DNSを順にたどる方法（ツリーウォーク）に変わった
• p=rejectの扱いについて、ガイダンスが見直された

既存のレコードは、そのまま使える

「DMARC 2.0」といった新しいバージョンができたわけではなく、レコードの先頭は、これまでどおりv=DMARC1のままです。すでにDMARCを設定している場合でも、直ちに書き換えが必要になるわけではありません。廃止されたタグ（pctなど）が記述されていても、無視されるだけで、レコード自体が無効になることはありません。新しくレコードを作る場合は、廃止されたタグを入れないようにするとよいでしょう。

p=rejectの考え方が変わった点

新しい仕様では、p=rejectについて、次のような整理がされています。

• pの値は、ドメイン所有者からの「意思表示」であり、受信側は、それを判断材料の1つとして、最終的な扱いを決める
• 受信側は、p=rejectだけを理由に、機械的に受信を拒否してはならず、他の情報とあわせて判断する。ほかの判断材料がない場合は、p=quarantineとして扱う
• 従業員や顧客が普通のメールボックスとして使うような、汎用的なメール用のドメインでは、p=rejectを使わないよう推奨される

これは、メーリングリストなどを経由すると、SPFやDKIMが壊れて、正当なメールでもDMARCに失敗してしまうケースがあるためです。一方、通知メールや請求書メールなど、人が直接メールを書かない、送信専用のドメインでは、p=rejectが適切な場合も引き続きあります。ドメインの使われ方に応じて、ポリシーを使い分ける考え方が重要です。

新しい仕様の詳細は、RFC 9989の本文で確認できます。運用中のドメインに、影響のある変更点がないか、時間のあるときに確認しておくとよいでしょう。

なぜ今、DMARCが求められているのか

大手メールサービスの要件

2024年2月から、GoogleとYahoo!が、大量にメールを送る送信者（目安として、1日あたり5,000通以上）に対して、SPF・DKIM・DMARCの設定を必須としました。また、Microsoftも、Outlook.com、Hotmail、Live.comなどの個人向けサービスについて、同様の要件を、2025年5月から適用しています。

要件を満たしていないと、メールが迷惑メール扱いになったり、受信を拒否されたりする可能性があります。なお、最低限求められるDMARCのポリシーは、p=noneです。ただし、1日5,000通未満の送信者でも、これらの認証を設定しておくことは、到達率の観点から推奨されています。

日本国内の動き

日本では、2023年2月に、経済産業省、警察庁、総務省が、クレジットカード会社などに対して、DMARCの導入をはじめとするフィッシング対策の強化を要請しました。利用者向けに公開しているすべてのドメインで、DMARCを導入することなどが求められており、企業のフィッシング対策として、DMARCの重要性は、国内でも高まっています。

DMARCレコードの確認方法

コマンドで確認する

Mac・Linuxではdigコマンド、Windowsではnslookupコマンドで確認できます。

dig _dmarc.example.com TXT +short

nslookup -type=TXT _dmarc.example.com

設定されていれば、次のような結果が表示されます。

"v=DMARC1; p=none; rua=mailto:[email protected]"

ドメインチェッカーなどのWebツールで確認する

ブラウザ上でドメイン名を入力するだけで、DMARCレコードの有無や内容、記述ミスがないかを確認できる、Webツールもあります。コマンド操作が不要なため、初心者の方でも、手軽に現在の設定を把握できます。

よくあるトラブルと対処法

DMARCレコードが認識されない

次の点を確認しましょう。

• ホスト名が、_dmarcになっているか（dmarcや_dmarc.example.com.example.comのような、ミスがないか）
• タイプが、TXTになっているか
• 値の先頭が、v=DMARC1になっているか
• タグの区切りが、セミコロン（;）になっているか
• DMARCレコードが、1つのドメインに複数登録されていないか（複数あると、正しく処理されない原因になる）

正当なメールがDMARCに失敗する

メール配信サービスや、外部のシステムから送信している場合に、アライメントが取れていないことが、主な原因です。次の点を確認します。

• 外部サービスが、自社ドメインでDKIM署名を行う設定になっているか
• SPFレコードに、外部サービスの送信元が含まれているか
• 転送やメーリングリストを経由して、SPFやDKIMが壊れていないか

レポートが届かない

ruaのアドレスが正しく入力されているか、レポートの送信先アドレスのメールボックスに、容量の空きがあるか、迷惑メールとして扱われていないかを、確認してください。また、レポートは、受信側から、通常は1日に1回程度まとめて送られるため、設定した直後には、届かないこともあります。

変更が反映されない

DNSの変更は、キャッシュの影響で、反映までに時間がかかることがあります。TTLの時間が経過してから、再度確認しましょう。

よくある質問

DMARCは必ず設定しないといけませんか？

法律上の義務ではありませんが、大量にメールを送る送信者にとっては、GoogleやYahoo!、Microsoftの要件として、実質的に必須となっています。それ以外の場合でも、なりすまし対策や、メールの到達率向上のために、設定しておくことが推奨されます。

p=noneのままで問題ありませんか？

最初のステップとしては、問題ありません。ただし、p=noneは、なりすましメールを止める効果はなく、監視のみの設定です。なりすましを実際に減らしたい場合は、レポートを確認しながら、quarantineやrejectへの移行を検討しましょう。

SPFやDKIMを設定していなくても、DMARCは使えますか？

使えません。DMARCは、SPFまたはDKIMの認証結果を利用する仕組みです。少なくともどちらか一方、できれば両方を、先に設定しておく必要があります。

DMARCを設定すると、迷惑メールが減りますか？

DMARCが直接防ぐのは、「自分のドメインを騙ったなりすましメール」です。自分の受信箱に届く迷惑メールが、直接減るわけではありません。ただし、多くの企業がDMARCを導入することで、なりすましメールが、受信側で排除されやすい環境が整っていきます。

まとめ

DMARCについて、要点を整理します。

• DMARCは、メールの送信元ドメインの偽装を検出し、失敗時の扱い方とレポートを、ドメイン所有者が指定できる仕組みである
• SPFまたはDKIMで認証され、かつ、「From」のドメインと一致（アライメント）していれば、DMARCは合格となる
• 設定は、ホスト名_dmarcのTXTレコードで行い、ポリシーはnone、quarantine、rejectから選ぶ
• まずはp=noneとレポート（rua）から始め、送信元を洗い出したうえで、段階的に厳しくする
• 2026年5月にDMARCの仕様が更新されたが、v=DMARC1のまま、既存のレコードは引き続き使える
• 大手メールサービスの要件や、国内でのフィッシング対策の流れを受けて、DMARCの重要性は高まっている
• 設定後は、dig・nslookup・ドメインチェッカーなどで、登録内容を確認する

DMARCは、設定して終わりではなく、レポートを確認しながら、少しずつ運用を改善していく仕組みです。まずは、p=noneで現状を把握するところから、始めてみてください。ドメインの現在の設定を確認したいときは、ドメインチェッカーなどのツールも、ぜひ活用してください。

参考情報

• RFC 9989（DMARCの仕様）：https://www.rfc-editor.org/rfc/rfc9989.html
• 総務省「クレジットカード会社等に対するフィッシング対策強化の要請」：https://www.soumu.go.jp/menu_news/s-news/01kiban18_01000184.html
• 経済産業省「クレジットカード会社等に対するフィッシング対策の強化を要請しました」：https://www.meti.go.jp/press/2022/02/20230201001/20230201001.html
• Microsoft Community Hub「Outlook’s New Requirements for High‐Volume Senders」：https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730