DMARCとは？なりすましメールを防ぐ仕組みと設定方法をわかりやすく解説
DMARCの基本的な意味から、SPF・DKIMとの関係、レコードの書き方、ポリシーの選び方、導入の進め方、2026年5月に行われた仕様の更新、確認方法、よくあるトラブルまでを、初心者の方にもわかりやすく解説
目次
- DMARCとは
- なぜDMARCが必要なのか
- SPF・DKIM・DMARCの関係
- DMARCの仕組み
- アライメント（一致）とは
- DMARCレコードの書き方
- 主なタグの意味
- ポリシーの種類（none・quarantine・reject）
- DMARCの導入手順
- メールを送らないドメインの設定
- 【2026年5月】DMARCの仕様が更新されました
- 主な変更点
- 既存のレコードは、そのまま使える
- p=rejectの考え方が変わった点
- なぜ今、DMARCが求められているのか
- 大手メールサービスの要件
- 日本国内の動き
- DMARCレコードの確認方法
- コマンドで確認する
- ドメインチェッカーなどのWebツールで確認する
- よくあるトラブルと対処法
- DMARCレコードが認識されない
- 正当なメールがDMARCに失敗する
- レポートが届かない
- 変更が反映されない
- よくある質問
- DMARCは必ず設定しないといけませんか？
- p=noneのままで問題ありませんか？
- SPFやDKIMを設定していなくても、DMARCは使えますか？
- 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による検証は、次の流れで行われます。
- 送信者が、ドメイン「example.com」から、メールを送信する
- 受信側のメールサーバーが、メールを受け取り、SPFとDKIMの検証を行う
- 受信側のメールサーバーが、「From」に書かれたドメイン（example.com）のDMARCレコードを、DNSに問い合わせて取得する
- SPFまたはDKIMのどちらかが「成功」し、かつ、その認証されたドメインが、「From」のドメインと一致（アライメント）していれば、DMARCは「合格」となる
- どちらも条件を満たさなければ、DMARCは「不合格」となり、DMARCレコードに書かれたポリシーを、判断材料の1つとして、受信側がメールを処理する
- 受信側は、集計した認証結果を、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の導入手順
いきなり厳しいポリシーを設定すると、正当なメールまで届かなくなるおそれがあります。次のように、段階的に進めましょう。
- 送信元の洗い出し：自社ドメインでメールを送っているすべてのサービス（メールサーバー、メルマガ配信サービス、問い合わせフォーム、業務システムなど）を、リストアップする
- SPFとDKIMの設定：それぞれの送信元について、SPFとDKIMを正しく設定する
p=noneでDMARCを開始：ruaを指定して、まずは監視だけを行う- レポートの確認：数週間程度レポートを集め、認証に失敗している正当な送信元がないかを確認し、あれば設定を修正する
p=quarantineへ移行：問題がなくなったら、隔離のポリシーに切り替え、様子を見る- 状況に応じて
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 +shortnslookup -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