DMARCとは？SPF・DKIMとの違い、仕組みとレコードの書き方【RFC 9989対応】

DMARC（ディーマーク）は、メールの差出人欄（From）に表示されるドメインと、SPF・DKIMの認証結果を突き合わせ、認証に失敗したメールをどう扱ってほしいかを受信側に伝える仕組みです。あわせて、そのドメインを名乗るメールの認証結果を集計レポートで受け取れます。2026年5月にはDMARCの仕様がRFC 9989として改訂され、使えるタグや組織ドメインの判定方法が変わりました。この記事では、SPF・DKIMとの違い、受信側の判定の流れ、レコードの書き方、実在ドメインのレコードの読み方、レポートの見方、ポリシーの選び方を順に説明します。

まとめ｜DMARCの要点

• DMARCは「Fromのドメイン」と「SPFまたはDKIMで認証されたドメイン」が一致するか（アライメント）を見る。どちらか一方が一致して認証に通ればDMARCはpass。
• SPFは送信元IPを、DKIMは電子署名を検証するが、どちらも単独ではFromの表示を守れない。DMARCはその穴を埋め、失敗時の扱い（none／quarantine／reject）とレポート先を宣言する。
• レコードは _dmarc.ドメイン名 のTXTに1本だけ公開する。2本あると両方とも無視される。
• 2026年5月のRFC 9989で、pct・rf・ri が廃止され、np・psd・t が加わった。組織ドメインの判定は公開サフィックスリストからDNSツリーウォークに変わった。
• Gmailは1日5,000件を超える送信者にDMARC（p=none で可）を求めている。防御効果が出るのはquarantine以上だが、メーリングリストへ投稿する利用者を抱えるドメインはrejectを公開すべきでないとRFC 9989は書いている。

DMARCとは｜読み方と、SPF・DKIMだけでは防げないもの

DMARCは Domain-based Message Authentication, Reporting, and Conformance の略で、「ディーマーク」と読みます。メールの受信者が目にするのはFromヘッダのアドレスですが、SPFもDKIMも、このFromのドメインを直接は検証していません。

• SPFが調べるのは、SMTPの封筒の差出人（Return-Path、RFC5321.MailFrom）のドメインです。攻撃者は自分で取得したドメインでSPFを通し、Fromだけを銀行のドメインにできます。
• DKIMが調べるのは署名の d= に書かれたドメインです。署名は正しくても、d= が攻撃者のドメインならFromの詐称は止まりません。

DMARCはこの2つの結果を「Fromのドメインと一致しているか」という一点で束ね、一致しないメールの扱いをドメイン所有者が宣言できるようにします。従来の仕様RFC 7489は、IETFの作業部会を経ずに出された情報提供（Informational）の文書でした。2026年5月のRFC 9989は標準化過程（Standards Track）の文書で、RFC 7489を置き換えています。集計レポートはRFC 9990、失敗レポートはRFC 9991に分かれました。

SPF・DKIM・DMARCの違い｜3つの送信ドメイン認証の役割

DMARCはSPFとDKIMの結果を使うため、単独では動きません。3つの違いを先に表で示します。

SPF：送信元IPと許可リストの照合

SPFは、Return-Pathのドメインに公開された v=spf1 のレコードに、送信元サーバーのIPアドレスが含まれるかを確かめます。include・a・mx・ptr・exists・redirect はDNS参照を伴い、その合計はRFC 7208の4.6.4節で、評価中に現れるこれらの項目を合計10個までと定めています（include先の評価も含みます）。メール配信サービスを足すたびに include が増え、上限を超えるとSPFはエラー（permerror）になり、SPF経由のDMARC passも失われます。レコードの書き方はSPFとは？メール認証の仕組み・SPFレコードの書き方と設定の判断基準を解説で扱っています。

DKIM：署名ドメインd=とセレクタによる公開鍵の取得

DKIMでは、送信側のサーバーがメールに次のような署名ヘッダを付けます。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2026;
    h=from:to:subject:date:message-id; bh=...; b=...

受信側は s=（セレクタ）と d=（署名ドメイン）から mail2026._domainkey.example.com のTXTを引き、そこに公開された鍵で署名を検証します。セレクタを分ければ、配信サービスごとに別の鍵を置けます。鍵が公開されているかは dig +short txt mail2026._domainkey.example.com で確かめられ、v=DKIM1; k=rsa; p=… が返れば公開済み、p= が空なら鍵は失効扱いです。鍵の長さはRFC 8301が「RSAは1024ビット以上必須、2048ビット以上を推奨」と定め、rsa-sha1での署名を禁じています。Gmailも1,024ビット以上を必須、2,048ビットを推奨としています。DKIMの署名は、転送の途中で本文と署名対象のヘッダ（件名など）が書き換えられなければ有効なまま残るため、DMARCを転送に強くしたいならDKIMのアライメントを必ず通しておきます。

DMARC：Fromとのアライメント・処理方針・レポート

DMARCが担うのは、Fromのドメインと認証済みドメインの一致の判定、一致しなかったメールの扱いの宣言（p=）、受信側からのレポートの受け取り（rua=・ruf=）です。SPFとDKIMが「誰が送ったか」を確かめ、DMARCがその結果を表示上の差出人に結び付けます。

DMARCの仕組み｜受信側の判定フローとアライメント

RFC 9989の5.3節は、受信側の処理を次の順に定めています。

1. FromヘッダからAuthor Domain（表示上の差出人ドメイン）を取り出す。
2. DNSツリーウォークでDMARCレコードを探す。見つからなければDMARCは適用しない。
3. SPFとDKIMの結果から、passした認証済みドメインを集める。
4. そのドメインとFromのドメインのアライメントを確かめる。
5. SPFかDKIMのどちらか1つでもアライメントが取れて通っていればpass、なければfail。
6. failなら、宣言されたポリシーを踏まえて扱いを決める。
7. 結果を保存し、rua があれば集計レポートを送る。

最後の扱いは受信側の判断です。RFC 9989の5.4節は「メールの最終的な扱いは常に受信側のローカルポリシー」と書いています。さらに7.4節は、送信側が p=reject を公開していることだけを根拠に受信を拒否してはならない（MUST NOT）とし、送信傾向や内容の分析といった他の材料が無ければ、quarantineとして扱わなければならない（MUST）と定めました。DMARCは受信側への依頼であって、命令ではありません。

アライメントのrelaxedとstrict

アライメントの判定には、組織ドメインが同じなら一致とみなすrelaxed（既定）と、完全一致だけを認めるstrictがあり、DKIMは adkim、SPFは aspf で切り替えます。

3行目は、メール配信サービスの共用ドメインがReturn-Pathに入っている典型例です。SPFは通っていてもアライメントが取れないので、配信サービス側で独自ドメインのDKIM署名（d=example.com）を有効にしないとDMARCは通りません。

組織ドメイン判定の変更：PSLからDNSツリーウォークへの移行

relaxedの「組織ドメインが同じ」をどう決めるかは、RFC 7489では公開サフィックスリスト（PSL）頼みで、どのリストを使うかは受信側任せでした。RFC 9989では、ドメインの左端のラベルを削って上位ドメインへたどりながら _dmarc のレコードを問い合わせる「DNSツリーウォーク」に置き換わりました。問い合わせは最大8回に抑えられています。新しく加わった psd= タグは、このツリーウォークでどこを組織ドメインとみなすかの手がかりになります。古い実装の受信側はPSLで判定し続けるため、両者の結論が食い違う余地があります。RFC 9989の付録C.3は、strictアライメントを使い、メールで使うすべての差出人ドメインに明示的にレコードを置けば、この食い違いは完全に避けられると書いています。

DMARCレコードの書き方｜タグ一覧とRFC 9989での変更

DMARCレコードは _dmarc.example.com のTXTとして公開します。観測から始めるときの例は次のとおりです。

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

RFC 9989の4.7節に載るタグは次のとおりです。

書くときに押さえる規則は次のとおりです。

• v=DMARC1 が先頭にないレコードは、全体が無視されます。
• 同じ名前にDMARCレコードが2本あると、両方とも捨てられます（4.10節）。SaaSの手順どおりに2本目を足すと、その名前のレコードは採用されません。ただし、上位ドメインのポリシーが適用される場合があります。
• RFC 9989では、構文が有効なレコードに p が無い場合は p=none として扱います。ただし旧仕様との互換性を保つため、新規設定では p を明記します。
• sp・np は組織ドメインのレコードに書いたときに効きます。サブドメイン（例：_dmarc.news.example.com）に置いたレコードの sp は無視されるので、サブドメインだけ扱いを変えたいなら、そのサブドメイン自身のレコードに p を書きます。
• レポート先が別ドメイン（例：解析サービスのアドレス）の場合、受け取る側が example.com._report._dmarc.受け取り側ドメイン に v=DMARC1 のTXTを置いていないと、レポートは送られません（RFC 9990）。解析サービスを使うなら、この許可レコードが用意されているかを確かめます。RFC 9990ではワイルドカードによる許可も認められているため、ドメイン別レコードの有無だけで判断しないでください。

廃止されたpct・rf・riと、代わりのt=y

RFC 9989の付録C.5で、pct（一部のメールにだけポリシーを適用する割合）、rf（失敗レポートの形式）、ri（集計レポートの間隔）が削除されました。付録A.6によると、pct は0と100（既定）以外の値が正確に適用されないことが多く、ずれ方も実装ごとにばらばらでした。一方で pct=0 は、メーリングリストなどの中継者がFromを書き換える合図として使われるようになり、移行判断の材料として役立っていました。その用途を引き継いだのが t=y で、「1段階弱いポリシーで扱ってほしい」という依頼になります（p=reject; t=y ならquarantine相当）。

ただし、古い仕様で動く受信側も残ります。GoogleのDMARC設定ヘルプは2026年10月時点でも、展開時に pct を入れることを勧め、BIMIを使うなら pct=100 にするよう求めています。既存レコードの pct=100 を急いで消す必要はありません。新しく書くレコードでは pct の割合に頼らず、quarantineやrejectへ上げる前のレポート観測で判断します。

実在ドメインのDMARCレコードを読む｜2026年10月28日のdig実測

公開されているレコードは誰でも確かめられます。2026年10月28日に dig +short txt _dmarc.ドメイン で取得した結果が次の表です（Windowsなら nslookup -type=TXT _dmarc.ドメイン）。

読み取れることは2つあります。1つ目は、会社のドメイン（google.com）はrejectでも、一般の利用者が使うフリーメールのドメイン（gmail.com・outlook.com）は本体を p=none にとどめている点です。RFC 9989の7.4節は、メーリングリストに投稿する利用者を抱えるドメインは p=reject を公開すべきでない（SHOULD NOT）としており、実測値はその考え方と合っています。2つ目は、outlook.comに廃止済みの pct=100 が残っている点です。pct=100 は全件適用の意味なので、古い実装の受信側でも新しい実装でも結果は変わりません。既存レコードに廃止タグがあっても、それだけで壊れるわけではありません。

DMARCの設定手順と確認方法

DNSに1行書く作業より先に、自社のどこからメールが出ているかを洗い出します。次の順で進めます。

1. 送信経路を洗い出す（社内メールサーバー、Google WorkspaceやMicrosoft 365、メール配信サービス、問い合わせフォーム、請求書や予約の通知を出す業務SaaS）。
2. SPFを公開するドメインごとにレコードを1本にまとめ、include先などの再帰評価も含め、DNS参照を伴う項目の評価数を合計10個以内に収める。
3. 各経路で、自社ドメインを d= にしたDKIM署名を有効にする。
4. p=none と rua を入れたDMARCレコードを公開する。
5. 集計レポートを1か月以上集め、正規の経路がすべてpassしているかを確かめる。
6. quarantineへ上げ、同じ期間観測してからrejectを判断する。

メールを送らないドメインやサブドメインは、観測を待たずに v=DMARC1; p=reject; を置けます。使っていないドメインの防御はパークドメインとは？意味・仕組みと危険性、なりすまし対策のDNS設定を解説で、SPFやMXとあわせて説明しています。DNSやメール経路の設定を外部の目で点検したい場合は、脆弱性診断・セキュリティ診断の範囲に含めて確認する方法もあります。

受信メールのヘッダによるDMARC認証結果の確認

公開したレコードが効いているかは、実際に届いたメールのヘッダで判断します。受信側は判定結果を Authentication-Results ヘッダに書き込みます。

Authentication-Results: mx.example.net;
    dkim=pass header.d=example.com header.s=mail2026;
    spf=pass smtp.mailfrom=bounce.example.com;
    dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Gmailならメールの「メッセージのソースを表示」で、SPF・DKIM・DMARCそれぞれのPASS／FAILが冒頭にまとめて表示されます。Outlookではメッセージのインターネットヘッダーを開き、同じ Authentication-Results を探します。dmarc=fail のときは、同じヘッダの header.d（記載がなければ認証に通ったDKIM署名の d=）と smtp.mailfrom をFromのドメインと比べると、どちらのアライメントが外れたかが分かります。

DMARCレポート（rua・ruf）の読み方

rua に届く集計レポートは、受信側ごとに1日単位などでまとめたXMLです。RFC 9990の付録Bの例を短くすると、中身は次の形をしています。

<policy_published>
  <domain>example.com</domain><p>quarantine</p><sp>none</sp>
  <discovery_method>treewalk</discovery_method>
</policy_published>
<record>
  <row>
    <source_ip>192.0.2.123</source_ip><count>123</count>
    <policy_evaluated><disposition>pass</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
  <auth_results><dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim></auth_results>
</record>

1つの record が「この送信元IPから、このFromドメインで、何通届き、どう判定されたか」を表します。見る順番は次のとおりです。

• source_ip と count：自社の把握している送信経路のIPか。知らないIPから大量に来ていれば、なりすましか、棚卸しから漏れた正規の経路。
• policy_evaluated の dkim・spf：アライメントを含めた結果。上の例はSPFが外れてもDKIMで通っており、転送経由でよく見る形。
• disposition：受信側が実際に取った扱い。RFC 9990では none・pass・quarantine・reject の4値で、pass はポリシーを強制している状態でDMARCに通ったことを表す。
• auth_results の selector：RFC 9990でDKIMのセレクタの記載が必須になった。どの配信サービスの鍵で署名されたかを特定できる。

ruf の失敗レポートはRFC 9991で定義され、個々のメールの情報を含みます。RFC 9989の10.2節が指摘するように特定の利用者の情報が入り得るため、送らない受信側もあります。運用の中心は集計レポートになります。

none・quarantine・rejectの選び方と、rejectにしないほうがよい場面

p=none は観測専用です。RFC 9989の5.4節は、p=none を見つけた受信側は既存のメール処理を変えてはならない（MUST NOT）と定めています。DMARCを理由に扱いが変わることはなく、なりすましメールを止めるのは受信側の通常の迷惑メール対策だけになります。防御として効くのはquarantine（疑わしいメールとして迷惑メールフォルダなどへ）とreject（受け取り拒否の依頼）です。

それでも、すべてのドメインがrejectを目指すべきではありません。RFC 9989の7.4節は次の2点をはっきり書いています。

• p=reject を公開するドメインは、DMARCのpassをSPFだけに頼ってはならず（MUST NOT）、有効なDKIM署名を付けなければならない。転送でSPFは崩れるためです。
• メーリングリストに投稿する利用者を抱えるドメインは p=reject を公開すべきでない（SHOULD NOT）。どうしても公開するなら、p=none を少なくとも1か月、続けて p=quarantine を同じ期間公開し、レポートで影響を比べてから上げる。

取引先や顧客に通知メールを送るだけの業務ドメインや送信専用のサブドメインは、正規の全経路でアライメントしたDKIMが通ることをレポートで確かめたうえで、rejectまで上げるべきです。一方、社員が外部のメーリングリストや学会・業界団体のリストに日常的に投稿しているドメインは、quarantineで止めるか、投稿用のアドレスを別ドメインに分けてから検討します。日本企業の設定状況とrejectへの移行手順はDMARCのquarantineとrejectの違い｜日経225企業の設定率69.8%とドメイン保護率18.5%で、数値つきで解説しています。

Gmail・Yahoo・Microsoftの送信者要件と国内の動き

大手メールサービスの送信者要件により、大量に送る企業にとってDMARCは事実上の前提条件になりました。

Gmailのメール送信者のガイドラインは2段構えです。すべての送信者にSPFまたはDKIMを求め、1日5,000件を超える送信者にはSPFとDKIMの両方、DMARCの公開、FromのドメインとSPFまたはDKIMのドメインの一致を求めます。認証されていないメールは迷惑メールに分類されるか、5.7.26エラーで拒否されることがあると明記しています。5,000件未満の送信者もSPFかDKIMは必須なので、「小規模だから関係ない」とはなりません。GmailのFAQによると、大量送信者は、同じ主ドメインから個人のGmailアカウント宛てに24時間で5,000件近く以上を送る送信者で、サブドメインからの送信も主ドメインの分として合算され、一度大量送信者に分類されると分類は続きます。2025年11月からは、要件を満たさないメールへの対応（一時的な拒否と恒久的な拒否を含む）を強めると告知しています。

米国Yahooの送信者向けベストプラクティスも、大量送信者にSPFとDKIM、少なくとも p=none のDMARCの公開とDMARCのpassを求めています。Yahooは大量送信者の通数の閾値を公表しないとしています。

Microsoftは2025年4月2日の発表で、hotmail.com・live.com・outlook.comの個人向けアドレスに1日5,000通を超えて送るドメインへ、SPF・DKIMの合格と、最低 p=none でSPFかDKIMのどちらかと一致するDMARCを求めました。当初は迷惑メールフォルダへ振り分ける予定でしたが、4月29日の更新で、満たさないメールは「550; 5.7.515」で拒否する方針に変わっています。法人向けのExchange Onlineではなく、個人向けサービスが対象です。

国内では、フィッシング対策協議会のガイドライン2026年度版がDMARCを p=reject まで上げることを推奨に加えました。改訂の中身と移行手順はフィッシング対策ガイドライン2026年度版のDMARC要件｜p=reject推奨の中身とnoneからの移行手順にまとめています。

よくある質問

DMARCを設定しないとどうなりますか？

自社ドメインを名乗るなりすましメールを、受信側が判断する材料が減ります。加えて、Gmailに1日5,000件を超えて送る場合はDMARCの公開が要件なので、未設定だと迷惑メール扱いや拒否の対象になり得ます。5,000件未満でも、Gmail宛てにはSPFかDKIMの設定が必要です。

SPFとDKIMを設定していればDMARCは不要ですか？

不要ではありません。SPFはReturn-Pathのドメイン、DKIMは署名の d= のドメインを検証するだけで、受信者が見るFromのドメインとは結び付きません。Fromとの一致を確かめ、失敗時の扱いとレポート先を宣言するのはDMARCだけです。

p=noneのままでも意味はありますか？

なりすましを止める効果はありません。RFC 9989は、p=noneでは受信側の処理を変えないよう定めています。意味があるのは、集計レポートで自社の送信経路となりすましの実態を把握できることと、Gmailなどの送信者要件を満たせることです。

DMARCが普及しない理由は何ですか？

レコード自体は1行でも、正規の送信経路をすべて洗い出してSPFとDKIMを通すまでが大仕事だからです。部署ごとに契約したメール配信サービスや業務SaaSが漏れていると、quarantineやrejectに上げた時点で自社の正規メールが届かなくなります。このため、送信経路の確認が終わるまでは p=none で観測を続ける必要があり、強制ポリシーへ上げるまでに時間がかかります。

DMARCの導入に費用はかかりますか？

DNSにTXTレコードを追加するだけなので、仕様上の費用はかかりません。費用が出やすいのは、集計レポートのXMLを可視化する解析サービスと、配信サービス側で独自ドメインのDKIM署名を有効にするための上位プランです。

関連記事

• SPFとは？メール認証の仕組み・SPFレコードの書き方と設定の判断基準を解説
• DMARCのquarantineとrejectの違い｜日経225企業の設定率69.8%とドメイン保護率18.5%
• フィッシング対策ガイドライン2026年度版のDMARC要件｜p=reject推奨の中身とnoneからの移行手順
• BIMIとは？Exchange Online・Outlookの対応状況とMicrosoft 365環境での設定手順
• フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策を解説