DMARCはp=noneから始める、一気にrejectで正規メールを落とさない

|著者: QUASA編集チーム|2 分で読めます
DMARCはp=noneから始める、一気にrejectで正規メールを落とさない

独自ドメインのDMARCは、正規の送信元でSPF・DKIMを確認し、GoogleのDMARC設定手順が勧めるように、集計レポートを受け取れるp=noneのTXTレコードから始める。最初からp=rejectを指定すると、認証設定が漏れていた正規メールまで拒否されるおそれがある。

レポートで自社の送信経路を把握し、DMARCに失敗する正規メールを修正してからp=quarantineへ進む。p=rejectは、外部配信サービスや転送、メーリングリストを通るメールへの影響も見て判断する。ポリシーを強める前に変更前のレコード値を保存しておけば、不達が生じたときに戻しやすい。

自社ドメインで送る経路を先に洗い出す

普段使うメールサービスに加え、問い合わせフォーム、請求通知、予約確認、メール配信サービスなど、差出人のFromに自社ドメインを使う仕組みを列挙する。各経路について利用部署、外部事業者、Fromアドレス、送信頻度を対応付ける。月次通知のように送信間隔が長いメールも、この段階で一覧に入れる。

DMARCに合格するには、SPFまたはDKIMの認証に合格し、その認証で使われたドメインがFromドメインと整合する必要がある。外部サービスのドメインでDKIMに合格していても、自社のFromドメインと整合しなければ、その署名だけではDMARCに合格しない。SPFレコードへ外部サービスの送信元を追加するだけで解決したと判断せず、サービスが自社ドメインでDKIM署名できるか、整合するエンベロープ送信者ドメインを使えるか確認する。

設定を変えた経路から試験メールを送り、受信したメールの認証結果を見る。確認するのは「SPFがpass」「DKIMがpass」という表示だけではなく、どちらの認証ドメインがFromと整合してDMARCを通したかだ。管理画面でドメインが認証済みと表示されても、実際に送ったメールのFromや送信経路が異なれば、同じ結果になるとは限らない。

p=noneとruaをDNSのTXTレコードに設定する

集計レポートを受け取る専用のメールボックスを用意し、DNSの「_dmarc.example.com」にTXTレコードを登録する。次はexample.comを自社ドメインと仮定した例であり、実際にはドメイン名とレポートの受信先を置き換える。

v=DMARC1; p=none; rua=mailto:[email protected]

vはDMARCレコードの形式、pはDMARCに失敗したメールについて受信側へ伝える処理方針を示す。p=noneはDMARCによる隔離や拒否を求めず、認証状況を観測する指定だ。ruaには集計レポートの送付先を記す。個人の受信箱ではなく、継続して管理できる宛先を使うと、担当者の異動後も報告を追いやすい。

DNS事業者によっては、入力したホスト名に自社ドメインを自動で付ける。管理画面へ「_dmarc」と入力するのか、完全な名前を入力するのかを確認し、公開後に意図した名前でTXTレコードを取得できるか調べる。すでにDMARCレコードがある場合は新しいものを並べて追加せず、既存の値とレポートの運用状況を確認して更新する。

p=noneであっても、受信側の通常の迷惑メール判定まで無効になるわけではない。また、レポートが届くことと、送信した個々のメールが受信箱に届いたことは別の情報だ。認証結果はレポートで、重要な通知の到達は実際の配送状況でも確かめる。

レポートから失敗した正規メールを見つける

集計レポートでは、Fromドメインを使った送信元、SPF・DKIMの結果、DMARCの判定を送信経路ごとに見比べる。自社の一覧にある経路が失敗していれば、認証ドメインの不整合や署名漏れを優先して調べる。一覧にない送信元も直ちになりすましと決めず、利用部署や委託先に照会してから分類する。

外部サービスの送信が失敗している場合は、まずFromとDKIM署名のドメイン、エンベロープ送信者のドメインを確認する。自社ドメインに整合するDKIM署名を設定できるなら、その経路から再送して結果を見る。SPF側で整合させる場合も、実際のエンベロープ送信者とSPFに登録した送信元の両方を確かめる必要がある。

観測期間は、主要な送信経路が一巡する長さで決める。日常の社員メールが見えても、月次の請求通知や不定期の障害連絡がまだ現れていないなら、厳しいポリシーへ進む判断には早い。レポートは多くの受信側から集まるため、送信元を整理できる形で解析し、送信量の多さだけで重要度を決めない。

quarantineへ進む際はpctを保証と考えない

正規の送信経路で目立つDMARC失敗を解消したら、p=quarantineを検討する。Googleの段階導入手順は、p=noneで少なくとも1週間レポートを確認し、少量からquarantineを試す例としてpct=5を示している。quarantineを求めると、失敗したメールは受信側で迷惑メールとして扱われ得るため、変更後はレポートと受信者への配送状況を併せて見る。

旧来のpctは、DMARCに失敗したメールの一部に指定したポリシーを適用するためのタグだった。旧方式に対応する受信先を想定して運用するなら、pct=5から25、100へ増やすのは仮の段階例になる。ただし、数値を上げるたびに正規メールの失敗や迷惑メール振り分けを確認し、割合を安全性の保証として扱わない。

一方、RFC 9989はpctを旧仕様のタグに分類し、中間値は受信側で正確に適用されないことが多かったと説明している。Googleの例は段階導入を考える手掛かりにはなるが、pct=5なら影響が必ず5％に収まるとは見込めない。現在の仕様に沿って進める場合はpctに依存せず、p=noneで送信経路を直したうえでp=quarantineへ変更し、その後の認証結果と配送を観測する。

ポリシーを変えるときは同じDMARCレコードのpの値を更新し、ruaの受信先を維持する。変更前の値、変更時刻、観測した送信経路を記録しておけば、レポートに新たな失敗が現れたときに原因を絞りやすい。quarantine中に正規メールの振り分けが増えるなら、rejectへ進む前にその経路を修正する。

rejectは転送とメーリングリストも見て判断する

p=rejectは、DMARCに失敗したメールを拒否するよう受信側に求める指定だ。正規の送信経路が整い、quarantine中のレポートと実際の配送で問題が見つからなかった場合に検討する。example.comを使う条件付きのレコード例は、v=DMARC1; p=reject; rua=mailto:[email protected]となる。これは受信側への処理方針であり、すべての受信側が同一の結果を返す保証ではない。

転送されたメールは、転送先サーバーのIPアドレスが元の送信ドメインのSPFに含まれず、SPFで失敗することがある。DKIM署名が有効なままでFromドメインと整合すればDMARCに合格できるが、メーリングリストによる本文の変更などで署名が無効になる経路もある。社員が外部のメーリングリストへ投稿するドメインでは、この間接的な配送経路を含めて影響を調べ、必要ならquarantineを維持する。

新しい配信サービスを追加した後も、送信元の一覧と認証結果は更新する。既存サービスの送信方式や差出人の設定が変われば、以前は合格していたメールが失敗する可能性がある。rejectへ移した後もruaのレポートを受け続け、頻度の低い通知を含めて失敗の増減を追う。

正規メールに影響が出たら、保存した値へ戻す

切り戻しの判断材料は、把握している正規の送信元でDMARC失敗が増えたこと、重要な通知の不達、移行後の迷惑メール振り分けや拒否の発生だ。該当メールの認証結果と送信経路を確認し、直前のDNS変更と時間が重なるか調べる。迷惑メール判定にはDMARC以外の要因もあるため、振り分けだけで原因を断定しない。

quarantineへ移した直後なら保存したp=noneの値へ、rejectへ移した直後なら検証済みのquarantineまたはp=noneの値へ戻す。切り戻しは配送への影響を抑えるための処置であり、送信元の認証不備そのものは残る。問題の経路を修正し、試験メールと集計レポートで認証結果を確かめてから、ポリシーを再び強める。

関連記事：

共有:

関連記事

ニュースレターを購読

Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。

0