p=none から p=reject へ、自社のメールを失わずに進める
DMARC を段階的に導入する手順。まず集約レポートを読み、正規の送信元をすべて洗い出してアライメントを整え、pct 廃止後は t=y をブレーキに使い、最後に強制へ移す。
v=DMARC1; p=none を公開するのに一分もかかりません。p=reject を公開するのも同じくらいです。ただし同じ日の午後に両方やってしまうと、その後の一週間は「なぜ請求書もパスワード再設定も採用ツールの通知も届かなくなったのか」を説明して過ごすことになりかねません。
この二つのレコードの差は技術ではなく、棚卸しです。p=reject は、DMARC に失敗したメールを拒否するよう受信側へ求めるもので、すべての受信側が必ずその通りに扱う保証ではありません。たいていの組織は、記憶で列挙できる以上の場所から正規のメールを送っています。導入の手順とは、この要請を出す前に、その場所を全部見つけ出す作業のことです。
用語の土台がまだなら——アライメントとは何か、なぜ SPF が通るだけでは足りないのか——先にSPF・DKIM・DMARC はそれぞれ何をしているのかを読んでください。この記事はそのモデルを前提に、運用側の半分だけを扱います。
段階 0：観測用のレコードだけを公開し、他は何もしない
最初のレコードの役割は、受信側にレポートを送り始めてもらうことだけです。
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comp=none は DMARC による強制を求めません。受信側は通常のスパム・不正利用対策を引き続き適用できます。変わるのは、DMARC に対応する受信側が、あなたのドメインを使うメールについて集約レポートを送り始められることです。
このレポート宛先について、最初に押さえておきたいことが二つあります。どちらも失敗が静かに起きるからです。
レポート宛先が他ドメインなら、その相手側の許可が要ります。 you@dmarc-vendor.example に送るには、yourdomain.com._report._dmarc.dmarc-vendor.example に v=DMARC1 を含む TXT レコードが必要です。これがないと、仕様に沿ったレポート送信側はあなたのレポートを破棄します。そして「レポートが届かない」状態は「そもそも誰も送っていない」状態と見分けがつきません。DMARC のホスティング事業者は通常これを代わりに公開しますが、当然と思わず確認する価値があります。
集約レポートは XML で、通常は gzip 圧縮されています。 期間は通常 UTC の一日ですが、同じ受信側から複数来ることも、一通も来ないこともあります。小規模なドメインならメールボックスで十分ですが、量が増えれば解析する仕組みが要ります。いずれにせよ、誰も見ない宛先に流さないこと。この段階の意義はレポートそのものです。
レコードが有効か、レポート先が許可されているかは SPF/DMARC チェッカーで確認できます。タグ単位でレコードを読み、外部レポートの認可を個別に検証します。
あとは待ちます。日常的に人が使い、メーリングリストへ投稿する可能性があるドメインなら、RFC 9989 は p=none を少なくとも一か月続けるよう勧めています。専用の送信ドメインであっても、月次・四半期・年次の送信元がすべて現れるまで待ちます。低頻度の送信元がまだデータに現れていないうちに強制へ進むことが、まさに事故の起き方です。
段階 1：レポートを送信元の一覧に変える
集約レポートは送信元 IP ごとに、何通送られたか、SPF は通ったか、DKIM は通ったか、そして最も重要な点として——そのどちらかが From ドメインとアラインしていたかを教えてくれます。
作るのは一枚の表です。
| 送信元 | SPF アライン | DKIM アライン | 対応 |
|---|---|---|---|
| Google Workspace（社員メール） | あり | あり | 対応不要 |
| マーケティング基盤 | なし | なし | 両方を設定 |
| 請求システム | あり | なし | DKIM を追加 |
| ヘルプデスク | なし | なし | 設定する、またはサブドメインへ |
| 見覚えのない海外の IP | なし | なし | 強制の前に調査 |
毎回意外なのは、この表がどれだけ長くなるかです。給与システム、CI の通知、CRM、日程調整ツールが出す会議招待、2023 年に誰かが登録したアンケートツール——「あなたに代わって」送信する SaaS がすべてここに並びます。それこそが段階 0 で得られるものです。
自社のシステムではなく、純粋な転送である送信元もあります。受信者が自動転送を設定していると、転送サーバーは自分の IP から中継するため SPF が失敗します。それでも DKIM が生きていれば、DMARC は DKIM 側で通ります。SPF に頼るより DKIM のアライメントをあらゆる経路で整えるべき理由として、これは最も明快なものの一つです。
レポートにできないことも書いておきます。集約されているので、失敗した送信元は IP と件数であって、読めるメールではありません。特定の一通がなぜ失敗したかを知りたいときは、答えはそのヘッダーの中にあります。ソース形式で保存してメールヘッダー解析ツールにかけてください。どこを見るべきかはメールヘッダーの読み方で扱っています。
段階 2：正規の送信元すべてにアライメントを通す
一覧の各項目について、目標はアラインした成功を最低ひとつ確保することです。実務ではあらゆる経路で DKIM のアライメントを整えるのを優先します。転送に耐え、SPF の予算も消費しないからです。
事業者側での DKIM 設定は、たいてい事業者が鍵ペアを生成し、s1._domainkey.yourdomain.com のようなセレクターに公開する CNAME か TXT を渡してくる形です。決定的なのは、できあがる署名の d= の値です。これは事業者のドメインではなく、あなたのドメインでなければなりません。d=mailer-provider.com の署名は完璧に検証を通りますが、何ともアラインしません。ついでに鍵長も見ておきましょう。RFC 8301 は下限を 1024 ビットとし 2048 を推奨していますが、いまだに 1024 ビットの鍵を配る事業者もあります。チェッカーは見つけた鍵をすべて測定します。
SPF のアライメントには通常、SMTP のエンベロープ送信者があなたのドメインの下にあることが必要です。多くの事業者はまさにこのために「カスタムバウンスドメイン」や「カスタム Return-Path」の設定を用意しています。設定すれば SPF がアラインする可能性が生まれます。設定しなければエンベロープ送信者は事業者のバウンス用ドメインのままで、SPF はそちらで成功し、DMARC には何も寄与しません。配送済みのメールでは Return-Path だけで判断せず、smtp.mailfrom（空の reverse path なら smtp.helo）を確認します。
SPF を触るついでに上限も見ておきます。SPF が許すのは DNS 参照を伴う項が 10 個までで、include は再帰的に数えられ、事業者が一つ増えるごとに最低一つ増えます。超えると PermError が返り、DMARC はこれを SPF の失敗として扱います。しかも超過している間もレコードは正常に見えます。チェッカーは include ツリーを丸ごと展開し、参照を消費する項を上限と突き合わせて数えます。上限までの余裕を把握する最も現実的な方法です。この数値はメール単位の結果ではなく保守的な上限なので、10 を超えていたら「一部の送信経路が PermError になる」と読み、その経路を特定しに行ってください。
どうしてもアラインできない送信元は、サブドメインへ移します。ヘルプデスクなら notifications.yourdomain.com といった具合です。サブドメインのメールは sp（または np）で判定されるので、主ドメインでは厳格に強制しつつ、サブドメインは別のポリシーで運用できます。
段階 3：まず隔離、それから拒否
一覧が片付き、レポートが静かになったら一段上げます。まず隔離です。
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com隔離には拒否にない性質があります。取り返しがつくことです。失敗すべきでなかったメールは迷惑メールフォルダーに入り、受信者はまだそれを見つけて知らせることができます。拒否されたメールは消えてしまい、送信側に届いたバウンスがあなたに転送されるとは限りません。日常利用のメールドメインなら、隔離でも少なくとも一か月は様子を見て、レポートを読み続けます。
その後に：
v=DMARC1; p=reject; sp=reject; np=reject; adkim=r; aspf=r;
rua=mailto:dmarc-reports@yourdomain.comこのレコードが組織ドメインから継承される場合、sp=reject は既存のサブドメインを、np=reject はそもそも存在しないサブドメインを守ります。後者は攻撃者が好んで捏造するもので、捏造される理由は何にも縛られていないからです。np は意識して書く価値があります。コストはほぼゼロで、塞ぐのは実在する穴です。
導入時のブレーキは
pctではなくtです。 2026 年より前に DMARC を学んだなら、当時の定石はpct=20でポリシーを一部のメールにだけ適用することでした。RFC 9989 は 2026 年 5 月に RFC 7489 を廃止した際、pctを削除しました（rfとriも同様）。そして代替としてテストモードのタグtを挙げています。pctが残っているレコードもそのまま動きます——受信側は削除されたタグを無視するだけでレコードごと拒否はしません——が、挙動は二分します。現行仕様に従う受信側はすべてのメールに完全なポリシーを適用し、いまだpctを尊重する受信側は一部だけを対象にします。pctを安全マージンとして頼っているなら、そのマージンはもう思っているようには残っていません。
t=y の実際の挙動
t=y は現在のブレーキであり、「まだ強制しないでほしい」と読み違えられがちです。より正確には、公開したポリシーをそのまま適用しないよう受信側へ求めるものです。RFC 9989 では公開値より一段弱い結果が想定されますが、最終的な扱いは受信側が決めます。
| 公開した値 | t=y を付けたときの想定される扱い |
|---|---|
p=reject | quarantine |
p=quarantine | none |
p=none | none |
つまり p=reject; t=y は、最終的に望むポリシーを先に公開しつつ、想定される扱いを隔離にとどめる書き方です。慎重に切り替えたいときには実際に有用で、同時に落とし穴でもあります。一見 p=reject に見えるレコードが、誰かがタグを外すまで隔離を要請しているからです。リマインダーを設定しておきましょう。チェッカーは t=y を検出すると想定される扱いを別項目で示すので、弱められた結果は記憶に頼らず目で確認できます。
強制を始めたあとに見るもの
強制はレポート関係の終わりではありません。rua は恒久的に残します。 新しい SaaS があなたの名前で送信し始めたことや、事業者が DKIM 鍵を無断でローテーションしたことに気づけるのは、これがあるからです。
DMARC が壊れたように見えて実はそうではない状況を二つ挙げておきます。
メーリングリスト。 フッターを追記したり件名を書き換えたりするリストは DKIM 署名を無効にし、しかも自分の IP から中継するので SPF も失敗します。p=reject のもとでは、厳格な受信側を使う購読者にそれらのメールが届かなくなります。よく運用されているリストは From ヘッダーをリスト自身のドメインに書き換えて回避しますが、そうでないリストもあります。また、自分が見た結果を ARC で封印する中間者もいます。リストが手を加える前に認証を通っていたことを下流の受信側が知れるからです。ただしこれは受信側がその中間者を信頼している場合にしか効かないので、解決ではなく緩和です。いずれにせよ、これは強制に伴う既知のコストであって、あなた側の設定ミスではありません。
転送。 形は似ていますが結果は良好です。本文が手つかずである限り、アラインした DKIM は生き残り、DMARC も通ります。
チェックリスト
- 動作する
ruaを伴うp=noneを公開する。 宛先が他ドメインなら外部認可レコードを確認する。 - すべての送信元が現れるまで観測する。 日常利用のメールドメインなら、
p=noneで少なくとも一か月。 - レポートから送信元一覧を作る。 すべての送信元と、アラインした成功があるかどうか。
- 各送信元のアライメントを整える。
d=yourdomain.comの DKIM を優先。SPF の 10 回上限に注意。どうしても無理なものはサブドメインへ。 p=quarantineに移し、日常利用のメールドメインならさらに少なくとも一か月、レポートを読み続ける。p=rejectに移し、spとnpを明示する。- ブレーキが要るなら
t=yを使う。 一段弱まること、そして外し忘れないことを忘れずに。 ruaはずっと残す。
一連の流れは意図的に地味です。p=reject の公開そのものは少しも難しくありません。手間は一覧づくりにあり、その一覧が存在するのは、推測ではなく p=none で数週間レポートを読んだからです。できあがったレコードを確認するには——ポリシー、サブドメインと非存在サブドメインの扱い、アライメントの段階、その裏にある SPF の予算、そしてレポート宛先が認可されているか——ドメインを SPF/DMARC チェッカーに通してください。