DMARCは、_dmarc.<your domain> に置くTXTレコードです。From ヘッダーに自社ドメインを使っていながら、アライメントの取れたSPFにもDKIMにも合格しなかったメールを受信側がどう扱うか、そしてレポートをどこに送るかを指定します。p=none はレポートを求めるだけです。p=quarantine はそうしたメールを疑わしいものとして扱うよう、p=reject は受け取りを拒否するよう、受信側に求めます。

Gmail、Yahoo、Microsoft は一括送信者の p=none を認めているため、多くのドメインは p=none を公開したところで止まり、なりすましを報告させるだけで、ブロックはしていません。2026年4月に引用された Red Sift の分析では、7,330万ドメインのうち、何らかのDMARCポリシーを設定していたのは14.9%、p=reject を適用していたのは2.5%でした。同じくDMARCベンダーの EasyDMARC は、DMARCを導入している Fortune 500 企業の62.7%が p=reject を使っているのに対し、Inc. 5000 企業では15.2%にとどまると2025年に報告しています。

ここでは、業務用メール、1〜2つのESP、ヘルプデスク、請求ツールから送信しているドメインを想定し、p=reject までの30日間の計画をレコードごとに紹介します。30日という期間は、送信用のサブドメインに向いています。従業員が日常のメールに使うドメインには、もっと時間が必要です。

この記事のポイント

• 1日目に v=DMARC1; p=none; rua=mailto:... を公開します。rua がなければ、受信側は集約レポートを送ってはいけないことになっています。
• 正規の送信元はすべて、From ドメインとアライメントの取れたSPFかDKIMに合格する必要があります。ほとんどのツールでは、自社ドメインでDKIM署名するということです。
• SPFでDNSルックアップを伴う項目は、ネストされた include も含めて10個以内に抑えます。超えると、すべてのメールが permerror になります。
• 15日目に p=quarantine、22日目に p=reject に移行します。どちらも、問題のないレポートが1週間続いてからにしましょう。従業員が日常のメールに使うドメインについては、RFC 9989 は最初の2つの段階にそれぞれ1か月かけるよう求めています。
• RFC 9989（2026年5月）は、pct を廃止扱い（historic）にしました。pct=10、pct=50 と段階的に上げるやり方は使わないでください。
• BIMIには、組織ドメインでの p=quarantine または p=reject、sp=none を使わないこと、SVG Tiny PS形式のロゴ、そして Gmail の場合はVMCかCMCが必要です。

2026年にDMARCで変わったこと

2026年5月、IETFは、2015年の Informational（情報提供）文書であるRFC 7489 をDMARCbisに置き換えました。DMARCbisは、RFC 9091 も廃止する Proposed Standard（標準化提案）のRFC 9989 と、集約レポートを定めるRFC 9990 からなります。ここで重要な変更は3つです。

• pct は廃止扱い（historic）に。付録A.6には、pct は「指定された値が0か100でない限り、たいてい正確には適用されていなかった」とあります。
• pct=0 に代わる t=y。受信側は、設定したポリシーより1段階弱い処理を適用するため、p=reject; t=y は quarantine として機能します。テスト用のスイッチです。
• 新しい np。DNSに存在しないサブドメインを対象とするタグで、古い受信側はこれを無視することになっています。

また、組織ドメインを判定する方法も、パブリックサフィックスリストからDNSツリーウォークに変わりました。

DMARCを支える3つのレコード

DMARCに合格するのは、SPFかDKIMが合格し、かつ合格したドメインが From ドメインとアライメントしている場合です。アライメントの取れた合格が1つあれば十分です。

SPFとルックアップ10回の上限

SPFは、エンベロープ（MAIL FROM またはリターンパス）のドメインについて、送信を許可するサーバーを指定します。DMARCが使う識別子はこれだけで、HELOは使いません。RFC 7208 の4.6.4節は、DNSルックアップを伴う項目（include、a、mx、ptr、exists、redirect）を、ネストされたすべての include を含めて10個までに制限しています。ip4、ip6、all は数に入りません。上限を超えると、結果は permerror になります。同じ節では、「void lookup」（結果が空になるルックアップ）も2回までしか認めていません。たいていは、もう存在しないホスト名への include が原因です。

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

これだけで、各ベンダーがネストしている分を数える前に、すでに4回のルックアップを使っています。dig +short TXT <name> でチェーンをたどり、ひとつずつ解決して確かめましょう。10回以内に収めるには、使っていないツールを外すか、bounce.example.com のような専用のリターンパス用サブドメインを各ESPに割り当てます。サブドメインごとに、10回の枠が別に確保されます。Microsoft のSPF設定ガイドは、DKIMとDMARCも運用しているドメインでは、-all で終えることを推奨しています。

多くのESPは、デフォルトでESP自身のリターンパス用ドメインを使います。これはあなたのドメインとアライメントしません。カスタムのリターンパスを設定するか、DKIMに頼りましょう。

DKIM：2048ビットの鍵、セレクター、ローテーション

DKIMは、ドメイン d= とセレクター s= を使って各メッセージに署名し、受信側は <selector>._domainkey.<d domain> から鍵を取得します。d=vendor-mail.example で署名するツールは、DKIMには合格しても、DMARCには不合格になります。

RFC 8301 は、署名者は少なくとも1024ビットのRSA鍵を使わなければならず、2048ビットを使うべきだとしています。Google の送信者ガイドラインも、個人の Gmail アカウント宛てについて同じことを求めています。2048ビットの鍵はTXT文字列の上限である255文字を超えるため、1つのレコードの中で、引用符で囲んだ複数の文字列に分けて登録します。ほとんどのDNSホスティングでは、この分割を自動で行ってくれます。

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

送信システムごとに専用のセレクターを割り当て、名前は決して使い回さないでください。s202610 のように日付を使うと、履歴が読みやすくなります。M3AAWGの鍵のローテーションに関するベストプラクティスは、少なくとも6か月ごとにローテーションするよう勧めています。

1. 新しいセレクターを公開し、反映されるのを待ちます。
2. 署名を新しい鍵に切り替えます。
3. 配送途中のメールも検証できるよう、古い公開鍵を7〜30日間DNSに残します。
4. 古いセレクターは、p= を空にして無効化します。削除はしないでください。

アライメント：relaxed か strict か

RFC 9989 は2つのモードを定めています。

RFC 9989 は、「ほぼすべてのドメイン所有者が、relaxed のアライメントで十分だと判断している」と述べています。aspf と adkim は指定しないでおきましょう。SPFのアライメントを strict にすると、サブドメインに置く一般的なリターンパスが機能しなくなります。

30日間の計画

各段階のレコード。問題のないレポートが1週間続いてから、次の段階に進みます。

2週目に、誰にも修正できない送信元が見つかったら、p=none のままにしておきましょう。自社の請求書のメールを拒否してしまうのは、ポリシーの適用が遅れるより悪い事態です。

1〜7日目：レポート付きで p=none を公開する

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

レポートは gzip で圧縮されたXMLで、受信側ごとに少なくとも1日1通届きます。そのため rua の宛先は、人ではなくレポート解析サービスにしましょう。アドレスが別の組織ドメインにある場合、RFC 9990 では、example.com._report._dmarc.<report domain> で許可されていない限り、受信側はそのアドレスを無視します。レポート解析サービスであれば、このレコードはサービス側が公開しています。自社の別ドメインを宛先にする場合は、自分で追加してください。

公開するDMARCレコードは、必ず1つだけにします。設定ウィザードのせいで _dmarc.example.com に v=DMARC1 のレコードが2つ残っていると、受信側は両方とも破棄します。

ruf は設定しなくてかまいません。RFC 9989 によると、プライバシーを重視する受信側は、失敗レポートの内容を大幅に伏せるか、そもそも送りません。また、Microsoft の送信量の多い送信者向けの発表にあるFAQでは、rua のレポートは送るものの、ruf を送る予定はないとしています。

集約レポートの読み方

RFC 9990 は、ポリシードメインごとに1つずつ、「毎日（またはそれ以上の頻度で）」送られるXMLレポートについて説明しています。以下は、そのサンプルをもとにしたレコードの例です。

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

policy_evaluated の dkim と spf はアライメントの結果で、disposition は受信側が実際に行った処理です。auth_results には、生の認証結果とそのドメインが入っています。この例では、どちらも vendor.example で合格しているため、アライメントはどちらも不合格です。つまり、ベンダーがあなたの名前で送信しているのに、あなたのドメインで署名していない状態です。そのベンダーのカスタムDKIMかドメイン認証を有効にしましょう。

1〜7日目：不明な送信元を見つける

source_ip、envelope_from、DKIMの domain と selector の組み合わせでグループ化し、count で並べ替えてから、次のように分類します。

IPの送信元を特定するには、dig -x 192.0.2.123 +short を実行し、セレクターも確認します。セレクターにはベンダー名が入っていることがよくあります。そのうえで、経理、サポート、営業の各チームに、会社の名前で何がメールを送っているかを確認しましょう。請求、ヘルプデスク、カレンダーの招待、オフィスのスキャナーなどです。

転送メールやメーリングリストのメールは、修正しようのない形で失敗します。Google の送信者向けのよくある質問でも、こうしたメールにはアライメントを求めていないので、その解決を待つ必要はありません。

8〜14日目：すべての正規の送信元を修正する

count の多いものから順に対応します。

1. 業務用メール（Google Workspace、Microsoft 365）：管理コンソールでDKIMを有効にし、選べる場合は2048ビットにします。プロバイダーの include がSPFに入っていることも確認します。
2. ESPとマーケティングツール：自社の d= で署名されるようにドメイン認証を設定し、可能ならカスタムのリターンパスも設定します。
3. ヘルプデスク、請求、CRM：ESPと同じです。自社ドメインで署名できないツールには、そのツールが署名できるサブドメインか、ツール自身のドメインを使わせます。
4. 使っていないツール：その include とセレクターを削除します。

最後に、SPFのルックアップ数を数え直しましょう。

15日目：p=quarantine

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

quarantine は、通常は迷惑メールフォルダーへの振り分けを意味します。disposition が quarantine になっている正規の送信元がないか注意しましょう。予行演習をしたい場合は、p=quarantine; t=y とすると、RFC 9989 に対応した受信側には none を適用するよう求めることになります。ただし、このRFCは公開から数か月しかたっておらず、まだすべての受信側が t に対応しているわけではありません。

22日目：p=reject

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"

p=reject に従う受信側は、認証に失敗したメールをSMTPセッションの中で拒否します。ただしRFC 9989 は、判断の根拠がポリシーしかない場合には quarantine にするよう受信側に求めているため、一部は迷惑メールフォルダーに入ります。

同じRFCは、p=reject のドメインは「SPFだけに頼ってはならない（MUST NOT rely solely on SPF）」とし、DKIMで署名しなければならないと定めています。転送でSPFは壊れても、DKIMは壊れないからです。先に、すべての送信元でアライメントの取れたDKIMを確認しておきましょう。

rua はずっと残しておきましょう。来四半期に導入される新しいツールは、サポートへの問い合わせより先に、レポートに現れるはずです。

計画を延ばすべきとき

RFC 9989 の7.4節は、ユーザーがメーリングリストに投稿するドメインは p=reject を公開すべきではない（SHOULD NOT）としています。公開する場合も、まず p=none で「少なくとも1か月」、p=quarantine で「同じくらいの期間」を過ごすべきだとしています。多くの企業のルートドメインがこれに当てはまるため、そうしたドメインでは最初の2つの段階にそれぞれ1か月かけましょう。ESPだけが使うサブドメインにはメーリングリストのトラフィックがないので、30日のペースのままで問題ありません。

サブドメインのポリシー：sp= と np=

p は、そのドメインとサブドメインに適用されます。sp は存在するサブドメインについて、np は存在しないサブドメインについて、p の設定を上書きします。独自のレコードを持つサブドメインではそのレコードが使われ、RFC 9989 ではそこでの sp は無視されます。

mail.example.com のような送信専用のサブドメインを1つのESPだけが使っていて、SPFとDKIMが認証済みなら、初日から p=reject を公開できます。ルートドメインに p=none; sp=reject を設定すると、メインのドメインの作業を終えるまでの間サブドメインを守れますが、BIMIは使えなくなります。

メールを送らないパークドメインでは、Microsoft のSPFガイドに従って v=spf1 -all を公開し、さらに _dmarc に v=DMARC1; p=reject; を公開しましょう。

30日目以降：BIMI

BIMIに対応した受信トレイでは、認証済みのメールの横にブランドのロゴが表示されます。

BIMIのドラフトは第14版（2026年5月）で、いまもRFC 7489 を前提に書かれた Internet-Draft です。pct が出てくるのはそのためです。pct は指定せず、t=y も設定しないでください。

組織ドメインについてのルールには、サブドメインから送信している場合も引っかかります。mail.example.com が p=reject でも、example.com が p=none なら、受信側はロゴを表示してはいけません。ルートドメインでも、この計画を最後までやり遂げる必要があります。

BIMI Group のSVGガイダンスは、単色の背景の中央に配置した正方形のロゴで、32KB未満にすることを推奨しています。Google は2024年9月にCMCへの対応を追加しました。BIMI Group の実装ガイドに沿ったレコードは次のとおりです。

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

商標登録には数か月かかるので、VMCを取得するなら今すぐ準備を始めましょう。

Gmail、Yahoo、Microsoft の要件

3社とも、ポリシーの適用までは求めていません。求めているのは、DMARCレコードとアライメントだけです。

出典：Google の送信者ガイドラインとよくある質問、Yahoo の送信者向けベストプラクティス、Microsoft の2025年4月の発表と5.7.515 のサポートページ。Microsoft は2025年5月5日に適用を開始しました。その前の4月29日の更新で、要件を満たさないメールへの対応が、迷惑メールフォルダーへの振り分けから拒否に変わっています。

Google のよくある質問には、SPFとDKIMの両方でのアライメントは「いずれ送信者の要件になる」とあります。2週目に、両方ともアライメントを取っておきましょう。配信停止や迷惑メール率については、エージェントがメールを送る場合にも変わらないことと到達率ガイドをご覧ください。

Brew の送信ドメインでのDMARC

Brew のドメイン設定では、次のレコードを求められます。

• DKIM：送信ドメイン配下の ._domainkey セレクターに置くTXTレコード。必須です。
• SPF：Brew のリターンパスである send.<your sending domain> に置くMXレコードとTXTレコード。必須です。
• DMARC：_dmarc.<your sending domain> に置くTXTレコード。任意ですが、推奨します。
• クリックトラッキング用のCNAME：独自のトラッキング用サブドメインを使う場合のみ。

SPFとDKIMが認証されればそのドメインから送信でき、Brew はそれに合わせたDMARCの値を提案します。

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

専用のサブドメインに p=reject が提案されるのは、Brew のSPFとDKIMが認証されるまで、そこから送信されるものが何もないからです。ルートドメインに p=none が提案されるのは、ほかのツールもそのドメインで送信している可能性が高いからです。その場合は、上の計画を実行しましょう。アライメントが relaxed のままなのは、send.<domain> のリターンパスが relaxed モードでしかアライメントしないためです。

Brew は、ドメインの追加時、認証時、そして再確認のたびに、公開中の _dmarc.<sending domain> レコードを読み取ります。結果は ドメイン に表示され、MCPの get_domain_health や GET /v1/domains/{domainId}/health でも確認できます。

• dmarc_missing：追加すべき正確なレコードを示す警告です。
• dmarc_invalid：同じ名前にDMARCレコードが2つある場合や、バージョンやポリシーが不正な場合、タグが重複している場合に表示されます。削除すべきレコードも示されます。
• 認証済み：有効なレコードがちょうど1つ見つかった状態です。

DNSの自動設定は、DMARCレコードがない場合にだけ書き込むため、レコードが重複することはありません。チェックは親ドメインではなく送信ドメインで行われるので、送信用のサブドメインにはそれぞれ専用のレコードを用意しましょう。ドキュメントで勧めているとおりトランザクションメールを分けている場合は、そのサブドメインにも必要です。レポートを読み、reject に移るタイミングを判断する場所は、rua の宛先にしたレポート解析サービスです。

よくある質問

quarantine に移行する前に、p=none をどのくらい続けるべきですか？

すべての正規の送信元がアライメントの取れたSPFかDKIMに合格していることを、丸1週間分のレポートで確認できるまでです。送信用のサブドメインなら、通常は1〜2週間です。従業員が日常のメールに使うドメインについては、RFC 9989 は少なくとも1か月を求めています。誰もレポートを読まないまま p=none を2年続けても、何の意味もありません。

DMARCの pct タグは非推奨になったのですか？

はい。RFC 9989 は pct を「historic（廃止扱い）」とし、確実に機能していた値だけを t に置き換えています。t=y は pct=0 と、t=n は pct=100 と同じ動作です。古い受信側はまだ pct を読み取るかもしれませんが、中間の値が一貫して適用されたことはないので、段階は丸ごと切り替えましょう。

p=reject にすると、転送したメールがブロックされますか？

単純な転送では、通常SPFは壊れてもDKIMは壊れないため、アライメントの取れたDKIMはそのまま合格します。件名やフッターを書き換えるメーリングリストではDKIMが壊れますが、その埋め合わせとして From ヘッダーを書き換えるリストもあります。すべての送信元でアライメントの取れたDKIMを使うことが、最善の対策です。

Gmail と Yahoo は p=reject を必須にしていますか？

いいえ。どちらも一括送信者にDMARCの公開を求めていますが、p=none で問題ありません。Outlook.com 宛てに1日5,000通を超えて送る送信者に対する Microsoft の要件も同じです。ポリシーの適用はなりすましを防ぎ、BIMIにも必要ですが、3社とも必須にはしていません。

BIMIにはVMCが必要ですか？

Gmail では、VMCかCMCのどちらかが必要です。VMCには登録商標が必要で、チェックマークが表示されます。CMCでは、チェックマークなしでロゴが表示されます。BIMI Group によると、Yahoo や Fastmail など一部のプロバイダーでは、証明書のない自己申告のロゴも表示されます。