DMARCレコードとは？書き方・設定例・確認方法をRFC 9989（最新仕様）で解説

Q: DMARCレコードはどう確認しますか？

dig +short TXT _dmarc.ドメイン名 で公開内容を確認できます。Gmailで受信したメールの「メッセージのソースを表示」で DMARC: PASS になっているかも確認します。

結論（DMARCレコード）

DMARCレコードとは、_dmarc.ドメイン名のTXTレコードに v=DMARC1 で始まる形で公開する設定です。メールの差出人（Fromヘッダー）のドメインが本物かをSPFとDKIMの結果で判定し、偽物だった場合の扱い（none／quarantine／reject）をドメインの持ち主が宣言する仕組みです。現行仕様は2026年5月のRFC 9989です。From偽装に対処できる標準的な仕組みで、集計レポートで自ドメインを名乗るメールの状況も把握できます。まずp=noneとruaで監視から始めます。

この記事のポイント

DMARCは、SPFまたはDKIMで認証されたドメインがFromドメインと一致（アライン）していればpassになります。
2026年5月、DMARCはRFC 9989として標準化トラックになり、RFC 7489とRFC 9091を廃止しました。
v=DMARC1 は必ず先頭に書き、値は大文字のDMARC1のみ。誤るとレコード全体が無視されます。
_dmarcに複数のDMARCレコードがあると、すべて破棄されDMARCがないのと同じになります。
セキュリティAIチェッカーは、MXがあるドメインに適用されるDMARCレコードが1件あれば○、なければ×（重み3）と判定します。

診断項目名	DMARCレコード
項目ID	`dns.dmarc`
分類	DNS・メールのなりすまし対策
重大度・配点の重み	重要（high）　重み 3
関連する標準・ガイドライン	RFC 9989（DMARC、2026年5月公開、RFC 7489・RFC 9091 を廃止）、RFC 9990 / RFC 9991（DMARC レポート）、RFC 7208（SPF）、政府機関等の対策基準策定のためのガイドライン（令和7年度版、令和8年10月1日一部改定）基本対策事項 6.2.2(1)-3、迷惑メール対策推進協議会「送信ドメイン認証技術 DMARC導入ガイドライン」（2024年7月9日）、Google「メール送信者のガイドライン」

DMARCレコードとは

DMARCレコードとは、メールの「差出人（From ヘッダー）」に表示されるドメインが本物かどうかを SPF と DKIM の結果を使って判定し、偽物だった場合に受信側にどう扱ってほしいか（何もしない／隔離／拒否）をドメインの持ち主が宣言するための DNS レコードです。宣言は _dmarc.ドメイン名 の TXT レコードで公開します。

_dmarc.city.example.lg.jp.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@city.example.lg.jp"

SPF や DKIM だけでは、攻撃者が自分のドメインで認証を通しつつ From だけ自治体名にする偽装を止められません。DMARC はこの「見た目の差出人」の偽装に対処できる唯一の標準的な仕組みであり、さらに受信側から集計レポートを受け取ることで、自分のドメインを名乗るメールが世界でどれだけ送られているかを把握できます。

この診断項目は、メール受信設定があるドメインに DMARC レコードが正しく1件公開されているかを確認します。

DMARC の判定の仕組み

DMARC では、次のどちらかを満たすと pass になります。

SPF が pass し、その SPF で認証されたドメイン（エンベロープ送信者）が From ドメインと一致（アライン）している。
DKIM 署名が検証に成功し、その署名ドメイン（d=）が From ドメインと一致している。

一致の厳しさは aspf / adkim タグで relaxed（組織ドメインが同じならよい、既定）か strict（完全一致）かを選べます。

DMARCの最新仕様 RFC 9989 の要点

2026年5月、DMARC は RFC 9989 として標準化トラック（Proposed Standard）になり、情報提供（Informational）RFC であった RFC 7489 と実験的 RFC の RFC 9091 を廃止しました。集計レポートは RFC 9990、失敗レポートは RFC 9991 に分離されています。レコードに関する主な規定は次のとおりです。

v タグはタグ一覧の最初に置かなければならず、値は DMARC1 のみ（大文字小文字を区別）。最初にない、欠けている、値が違う場合はレコード全体を無視しなければならない（4.7節）。
p タグは RECOMMENDED。p が欠けている、または値が不正な場合、有効な rua があれば p=none として扱い、rua もなければ受信側は DMARC の処理を行わない（4.10.1節）。
1つの問い合わせ先から複数の DMARC レコードが返った場合は、すべて破棄する（4.10節）。
対象ドメインにレコードがない場合は、DNS の階層を上へたどる「DNS ツリーウォーク」（問い合わせは最大8回）で組織ドメインのポリシーを探す。従来の Public Suffix List に頼る方法を置き換えたもので、psd タグでたどる範囲を制御できる。
sp（既存サブドメイン）と np（存在しないサブドメイン）で、サブドメイン向けの方針を別に指定できる。
pct、rf、ri タグは廃止され、np、psd、t（t=y でテストモード）が追加された（付録 C.5）。

DMARCレコードの書き方（主なタグ）

タグ	意味	例
`v`	バージョン。必ず先頭	`v=DMARC1`
`p`	認証に失敗したメールへの方針（none / quarantine / reject）	`p=quarantine`
`sp`	既存サブドメインへの方針。省略時は `p` と同じ	`sp=reject`
`np`	存在しないサブドメインへの方針。省略時は `sp`、それもなければ `p`	`np=reject`
`rua`	集計レポートの送信先URI（集計レポートを送る受信側は `mailto:` に必ず対応）	`rua=mailto:dmarc@example.jp`
`ruf`	失敗レポートの送信先（対応しない受信側も多い）	`ruf=mailto:...`
`adkim` / `aspf`	DKIM / SPF のアラインメントの厳しさ（r=relaxed、s=strict）	`adkim=s`
`t`	`y` でテストモード。受信側は方針を1段階弱めて適用	`t=y`

タグはセミコロンで区切り、区切りの前後に空白を入れてもかまいません。p の値をどこまで強めるべきかは「DMARC強制ポリシー」、rua の設定は「DMARC集計レポート送信先」で詳しく解説しています。このページは DMARC レコードが正しく存在するかに絞って解説します。

DMARCレコードはなぜ必要か（国内の位置付け）

政府機関等の対策基準策定のためのガイドライン（令和7年度版）は、基本対策事項 6.2.2(1)-3 で DMARC による送信側・受信側の対策と、ポリシーへの p=quarantine または p=reject の設定を求めています（令和8年6月12日の一部改定で強化）。やむを得ず p=none とする場合も期間を可能な限り短くし、解説では1年以内に全メールへ quarantine または reject を設定することが望ましいとしています。地方公共団体に直接適用される基準ではありませんが、自治体の情報セキュリティポリシーを検討する際の有力な参照先です。

2023年2月1日には経済産業省・警察庁・総務省がクレジットカード会社等に DMARC 導入を含むフィッシング対策の強化を要請しました。また Google は1日5,000件以上を送る送信者に DMARC（p=none でも可）を求めています。迷惑メール対策推進協議会も2024年7月9日に「送信ドメイン認証技術 DMARC導入ガイドライン」を公表しています。

DMARCレコードについてよくある誤解

「SPF と DKIM があれば DMARC は不要」：From の偽装は DMARC でしか判定・宣言できません。SPF の公開状況は「SPFレコード」で確認します。
「DMARC を入れると正規メールが届かなくなる」：p=none は受信側に処理を求めず、レポートを受け取るだけです。まず監視から始められます。
「_dmarc に2件書いておけば安全」：複数ある場合は全部破棄され、DMARC がないのと同じになります。

セキュリティAIチェッカーを利用する

DMARCレコードの診断基準（セキュリティAIチェッカー）

取得対象と方法

最終URLのホスト名から先頭の www. を除いた「メールドメイン」について、Google Public DNS の DNS over HTTPS（https://dns.google/resolve）で MX と _dmarc.メールドメイン の TXT を問い合わせます（通信エラー・非2xx応答時は待機を挟み、合計3回まで試行）。
MX が1件以上あり、Null MX（0 .）でない場合に「メール受信設定あり」とします。
_dmarc の TXT のうち、先頭が v=DMARC1（= の前後の空白を許容し、その後が ; または末尾。DMARC1 は大文字のみ）のものを DMARC レコードとして数えます。
メール受信設定があり、メールドメインに該当レコードが0件のときは、RFC 9989 4.10節のツリーウォークにならい、親ドメインの _dmarc を上位へ順に最大7件問い合わせます。レコードが1件だけある親のうち最も上位のもの（psd=n があればそこで打ち切り、psd=y があればその1階層下を優先）を、適用されるレコードとします。
適用されるレコードが、有効な p（none / quarantine / reject）または mailto: の rua を持つ場合に「DMARC あり」とします。

判定条件

判定	条件	得点への影響
○ 問題なし（pass）	メール受信設定があり、メールドメイン自身または親ドメインに、適用される DMARC レコードが1件ある	重み3 × 1.00
× 要改善（fail）	メール受信設定があり、適用されるレコードがない、メールドメインに2件以上ある（受信側で破棄されるため）、または `p` も `rua` もない	重み3 × 0
対象外（na）	MX がない、Null MX のみ、または `_dmarc` の DNS 照会に失敗	採点から除外

ポリシーの強さ（p=quarantine / reject）は「DMARC強制ポリシー」、集計レポート送信先は「DMARC集計レポート送信先」で別に評価します。この2項目は、有効な p または rua を持つ適用レコードがある場合にだけ判定されます（MX がなく本項目が対象外でも、メールドメイン自身に有効なレコードが1件あれば判定されます）。この項目に「△ 要確認（warn）」はありません。

自治体ドメインでの判定例

`_dmarc` の TXT	判定
`v=DMARC1; p=reject; rua=mailto:dmarc@city.example.lg.jp`	○ 問題なし
`v=DMARC1; p=none;`	○ 問題なし（存在の判定。ポリシーは別項目で△）
レコードなし	× 要改善
`v=DMARC1; p=none` と `v=DMARC1; p=reject` の2件	× 要改善（複数レコード）
`p=reject; v=DMARC1`（v が先頭にない）	× 要改善
`v=dmarc1; p=reject`（値が小文字）	× 要改善
`v=DMARC1` のみ（p も rua もない）	× 要改善
`kankou.city.example.lg.jp` に MX があり、`_dmarc` は親の `city.example.lg.jp` にだけある	○ 問題なし（親のレコードを適用）
MX がない Web 専用ドメイン	対象外

診断の限界

親ドメインのレコードを適用して「○ 問題なし」になった場合、根拠欄にその親ドメイン名が表示されます。旧仕様（RFC 7489）のままの受信側は Public Suffix List で組織ドメインを決めるため、結果が異なることがあります（RFC 9989 付録 C.3）。メールに使うドメインには _dmarc を明示的に公開するのが確実です。
メールドメイン自身に DMARC レコードが2件以上ある場合は、親ドメインをたどらず「× 要改善」とします。
親ドメインへの問い合わせは jp などの上位ドメインにも及びますが、公開 DNS の参照だけで対象サイトへの負荷はありません。
DKIM の設定は外部から網羅的に確認できないため評価していません。
URL のホストが IP アドレスの場合、DNS・メール保護の各項目は判定されず、結果にも出力されません。
MX の照会に失敗した場合は「メール受信設定なし」と同じ対象外になります。結果に疑問があるときは dig などで手元から再確認してください。

DMARCレコードがないとどんなリスクがあるか

From 偽装メールが届く：DMARC がないと、受信側は自治体名を名乗る偽メールを拒否する根拠を持てません。税・給付金・選挙・防災・ワクチン接種など、住民が開封しやすい件名のフィッシングに悪用されます。
被害の把握ができない：集計レポートがなければ、自団体のドメインがなりすましに使われていることに気付けません。
正規メールの不達：主要メールサービスは大量送信者に DMARC を求めており、防災メールや電子申請の通知などを大量に送る場合、到達率に影響します。

DMARCレコードの設定方法と確認方法

1. 前提をそろえる

SPF を1件に整理し、DKIM 署名を有効にします（Microsoft 365、Google Workspace、配信サービスそれぞれで設定）。From に自治体ドメインを使う全送信元が SPF または DKIM でアラインするようにします。

2. 監視モードで公開する

_dmarc.city.example.lg.jp.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@city.example.lg.jp"

外部の DMARC レポート解析サービスへ送る場合、RFC 9990 の外部宛先検証のため、受け手側ドメインに city.example.lg.jp._report._dmarc.受け手ドメイン の TXT（v=DMARC1）が必要です。

3. レポートを分析して段階的に強化する

数週間〜数か月、集計レポートで正規の送信元がすべて pass していることを確認し、p=quarantine、p=reject へ移行します（「DMARC強制ポリシー」を参照）。

4. メールを送らないドメイン

_dmarc.www.city.example.lg.jp.  IN  TXT  "v=DMARC1; p=reject;"

5. 確認方法

dig +short TXT _dmarc.city.example.lg.jp
curl -s 'https://dns.google/resolve?name=_dmarc.city.example.lg.jp&type=TXT'

Gmail で受信したメールの「メッセージのソースを表示」で DMARC: PASS を確認します。設定後はセキュリティAIチェッカーで再診断し、根拠欄に「DMARCレコードを確認しました」と表示されることを確かめてください。

メールを止めないための注意点

既存の _dmarc レコードがあるときは書き換えで対応し、2件目を追加しないでください。
v=DMARC1 を必ず先頭に書きます。順序を誤るとレコード全体が無視されます。
集計レポートは量が多くなるため、専用の受信アドレスや解析サービスを用意します。職員の個人メールボックスを宛先にしないでください。
いきなり p=reject にすると、DKIM 未設定の委託システムからの通知が届かなくなるおそれがあります。RFC 9989 7.4節は、p=reject を公開するドメインは SPF だけに頼らず有効な DKIM 署名を付けなければならない（MUST）としています。

よくある質問（FAQ）

SPFとDKIMがあればDMARCは不要ですか？

不要ではありません。SPFやDKIMだけでは、攻撃者が自分のドメインで認証を通しつつFromだけ自治体名にする偽装を止められません。Fromの偽装はDMARCでしか判定・宣言できません。

DMARCを入れると正規のメールが届かなくなりませんか？

p=none は受信側に特別な処理を求めず、レポートを受け取るだけなので、まず監視から始められます。正規の送信元がすべて認証できていることをレポートで確認してから、quarantine や reject へ段階的に強化します。

DMARCの現行仕様はRFC 7489ですか？

いいえ。2026年5月にRFC 9989が標準化トラック（Proposed Standard）として公開され、RFC 7489とRFC 9091を廃止しました。集計レポートはRFC 9990、失敗レポートはRFC 9991に分かれています。

_dmarc に2件レコードを書いておけば安全ですか？

逆効果です。1つの問い合わせ先から複数のDMARCレコードが返った場合、受信側はすべて破棄するため、DMARCがないのと同じになります。既存のレコードは書き換えで更新してください。

サブドメインに _dmarc がなくても親ドメインのDMARCは適用されますか？

RFC 9989では、対象ドメインにレコードがない場合にDNSの階層を上へたどる「DNSツリーウォーク」で組織ドメインのポリシーを探します。セキュリティAIチェッカーも親ドメインのレコードを適用して○と判定しますが、旧仕様の受信側では結果が異なることがあるため、メールに使うドメインには _dmarc を明示的に公開するのが確実です。

DMARCレコードはどう確認しますか？

dig +short TXT _dmarc.ドメイン名で公開内容を確認できます。Gmailで受信したメールの「メッセージのソースを表示」で DMARC: PASS になっているかも確認します。

国の基準ではDMARCはどう扱われていますか？

政府機関等の対策基準策定のためのガイドライン（令和7年度版）は、基本対策事項6.2.2(1)-3でDMARCによる対策とp=quarantineまたはp=rejectの設定を求めています。地方公共団体に直接適用される基準ではありませんが、自治体のセキュリティポリシーを検討する際の有力な参照先です。