2026年7月6日

DKIMを整えてDMARCをp=rejectへ移行する方法｜送信元の洗い出しから段階移行・戻し方まで

DNS・名前解決

「p=reject」はDKIMではなくDMARCのポリシーですが、reject に安全に移れるかどうかを決めるのは、実質的にDKIMの整備状況です。転送やメーリングリストを経由するとSPFは通らなくなりやすく、最後まで頼りになるのは、送信ドメインと一致する（アラインした）DKIM署名だからです。この記事では、DKIMを軸に送信元を洗い出して署名を整え、DMARCを p=none から p=quarantine、p=reject へ段階的に移す手順と、問題が出たときの戻し方を説明します。

用語の整理：DKIMの「p=」とDMARCの「p=」は別物

検索で混乱しやすい点を先に整理します。

**DKIMレコードの p=**：公開鍵そのものです。selector._domainkey.example.com のTXTレコードに v=DKIM1; k=rsa; p=MIIBIjAN... のように書かれます。ここを空（p=）にすると「この鍵は失効した」という意味になり、その鍵で署名したメールはDKIMで失敗します。
**DMARCレコードの p=**：認証に失敗したメールを受信側にどう扱ってほしいかの方針です。_dmarc.example.com のTXTレコードに p=none・p=quarantine・p=reject のいずれかを書きます。

この記事で「p=rejectへ移行する」と言うときは、後者のDMARCのポリシーを指します。DKIMレコードの p= を書き換える作業ではないので、取り違えて鍵を消さないよう注意してください。

なぜDKIMが鍵になるのか

DMARCは、SPFかDKIMのどちらか一方が「通過」し、かつそのドメインが差出人（Fromヘッダー）のドメインと一致していれば合格とします。SPFだけで合格している送信元は、次のような場面で不合格に変わります。

受信者が別のアドレスへ自動転送している（転送先から見ると、送信元IPが転送サーバーになる）。
配信サービスが、エンベロープの送信者（Return-Path）に自社のドメインを使っている（SPFは通っても差出人ドメインと一致しない）。

DKIMの署名は、本文やヘッダーが書き換えられない限り転送後も検証できます。そのため、reject に進む前に「すべての送信元が、差出人ドメインと一致する d= でDKIM署名している」状態を作ることが、もっとも効果のある準備になります。

手順1：p=none と集計レポートで送信元を洗い出す

まだDMARCを公開していない場合は、監視だけを行う p=none で始め、集計レポート（rua）を受け取ります。

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

レポートは受信事業者ごとにXMLで届きます。見るのは、送信元IPごとの次の項目です。

<row>
  <source_ip>192.0.2.10</source_ip>
  <count>120</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</row>
<auth_results>
  <dkim><domain>sender-service.example</domain><selector>s1</selector><result>pass</result></dkim>
  <spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>

この例では、DKIM署名自体は通っていますが、署名ドメインが配信サービスのもの（sender-service.example）なので、DMARCとしてのDKIM評価（policy_evaluated の dkim）は fail です。現在はSPFで合格していますが、転送されれば不合格になる送信元です。こうした送信元を一覧にしていきます。

レポートは数週間分を集めると、月次の請求メールや年に数回のキャンペーン配信など、たまにしか送らない送信元も拾いやすくなります。XMLをそのまま読むのは大変なので、レポートを集計するサービスやツールを使うのが現実的です。

手順2：送信元ごとにDKIMを差出人ドメインで署名させる

一覧にした送信元ごとに、DKIMの署名ドメイン（d=）を自社ドメインにする設定を行います。

メール配信サービス・SMTP送信サービス：多くのサービスに「独自ドメイン認証」「ドメイン認証」といった機能があり、指示されたCNAMEまたはTXTレコードをDNSに追加すると、自社ドメインで署名されるようになります。項目名はサービスごとに違うので、各サービスのドキュメントで確認してください。
自社運用のメールサーバー：OpenDKIMなどで署名を設定します。鍵は2048ビットのRSAが一般的です。
WordPress：WordPress本体はDKIM署名を行いません。SMTPプラグイン（WP Mail SMTP、FluentSMTP など）で外部の送信サービスにつなぎ、その送信サービス側で自社ドメインのDKIMを設定します。差出人アドレスがサイトのドメインと一致しているかも確認します。

設定後は、実際にテストメールを送り、受信したメールのヘッダーで確認します。

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounce.sender-service.example;
       dmarc=pass header.from=example.com

dkim=pass の header.i（または header.d）が差出人ドメインと一致していれば、その送信元はDKIMで合格できる状態です。DNSの反映を確認するには dig s1._domainkey.example.com TXT +short のようにセレクター名を付けて引きます。

手順3：p=quarantine へ進める

集計レポートで、正規の送信元がすべてアラインしたDKIMで合格するようになったら、p=quarantine に進めます。変更前に、現在のレコードの値を控え、TTLを短く（数分〜1時間程度）しておくと、問題が出たときにすぐ戻せます。

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

従来は pct= で適用する割合を少しずつ増やす方法が使われてきました。ただし、DMARCの改訂版（DMARCbis）では pct タグの扱いが見直されており、受信側がどの程度尊重するかも一様ではありません（2026年10月現在）。割合に頼るより、「quarantine の期間を十分に取り、レポートと迷惑メールフォルダへの振り分けの報告を確認する」という進め方のほうが確かです。

quarantine の期間中は、レポートの disposition が quarantine になっている行を毎週確認し、正規の送信元が含まれていないかを見ます。社内や取引先から「メールが迷惑メールに入る」という連絡が来たら、その送信元のDKIM設定に戻って確認します。

手順4：p=reject へ移り、サブドメインも決める

quarantine で数週間〜数か月運用し、正規のメールが不合格になっていないと判断できたら p=reject にします。

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

sp= はサブドメインのポリシーです。省略すると p= と同じ扱いになります。メールを送らないサブドメインが多いなら reject にしておくとなりすましに使われにくく、サブドメインから送っている送信元があるなら、そのサブドメインのDKIMも整えてから強めます。

reject になると、不合格のメールは受信側で受け取りを拒否され、送信者にエラーが返るか、届かないまま終わります。迷惑メールフォルダに入る quarantine と違い、受信者が自分で救い出すことはできないため、この段階に進む前の確認を丁寧に行ってください。

つまずきやすい点

メーリングリスト：件名にタグを付けたり本文に署名を追加したりするリストでは、DKIM署名が壊れます。リスト側が差出人を書き換える設定や、ARC（転送経路の認証結果を引き継ぐ仕組み）への対応状況を確認します。
鍵の入れ替え：鍵を交換するときは、新しいセレクターで新しい鍵を公開し、署名を切り替えてから古い鍵を消します。同じセレクターで鍵を差し替えると、配送途中のメールが検証に失敗します。
TXTレコードの長さ：2048ビットの公開鍵は1つの文字列の上限（255文字）を超えるため、複数の文字列に分けて登録します。DNS管理画面が自動で分割する場合もあります。
大量送信者向けの要件：Gmailなどは一定量以上を送る送信者にSPF・DKIM・DMARCの設定を求めていますが、求めているのはDMARCの公開とアラインメントで、reject への移行そのものは求めていません。要件の詳細は各社の案内で確認してください。

問題が出たときの戻し方

reject にした後で正規のメールが届かないと分かったら、まず p=quarantine か p=none に戻して被害を止め、そのうえで原因の送信元のDKIMを直します。TTLを短くしておけば、戻した設定は比較的早く行き渡ります。戻すときもレポートの受信は続け、原因を直してから改めて段階を踏みます。

まとめ

p=reject はDMARCのポリシー。DKIMレコードの p=（公開鍵）とは別物で、空にすると鍵の失効になる。
転送に強いのはDKIM。すべての送信元を、差出人ドメインと一致する d= で署名させることが reject への近道。
p=none の集計レポートで送信元を洗い出し、policy_evaluated の dkim が pass になるまで一つずつ直す。
quarantine で十分な期間様子を見てから reject へ。sp= でサブドメインの扱いも決める。
変更前に値を控え、TTLを短くしておき、問題が出たらすぐ緩める。