業務メールが届かない理由は認証にある。SPF・DKIM・DMARCと整合を分けて整える

編集部の実務提案

認証は3つの別々の約束である

SPFは、ドメインの代わりにメールを送ってよいサーバーの一覧をDNSに公開する仕組みである。受信側は送信元IPアドレスとその一覧を照合し、許可されていないサーバーからの送信を見分ける。DKIMは、メールに電子署名を付け、送信途中で本文やヘッダーが改ざんされていないことと、署名したドメインを証明する。DMARCは、この2つの結果を踏まえ、認証に失敗したメールをどう扱うかを受信側へ指示するポリシーであり、結果のレポートを受け取る仕組みでもある。

3つは役割が違う。SPFとDKIMは「証明」の仕組み、DMARCは「失敗時にどうするか」と「結果を誰に知らせるか」の仕組みである。SPFだけ入れて安心する、DKIMの鍵を作ったがローテーションを忘れる、DMARCレコードはあるがポリシーが監視用のnoneのまま、といった中途半端な状態は珍しくない。届かない問題の切り分けでは、まず3つのうちどれが欠けているか、どれが古いままかを分けて確認する。

Googleのガイドラインでは、DKIM鍵は最低1024ビット、2048ビットが推奨とされる。鍵長のような地味な項目も、監査や移行の時点で効いてくる。認証設定は一度きりの作業ではなく、証明書や鍵と同様に棚卸しと更新の対象として扱うべき資産である。

実務では、認証の不備は「届くメールもある」形で現れる。受信側のポリシー次第で、同じ送信でも届いたり迷惑メールに入ったりする。だからこそ、再現性の低い報告に振り回されず、認証の状態そのものを点検する順序が要る。

混同しやすいのは、認証と暗号化、そして到達率の関係である。SPF・DKIM・DMARCが担うのは送信元の証明であり、通信の暗号化（TLS）や、本文の内容の良し悪しとは別の層の問題だ。認証が完全でも、宛先リストが古ければ迷惑メール率は上がるし、逆に本文が丁寧でも認証がなければ拒否される。障害の切り分けでは、層を混ぜないことが近道になる。受信側の応答コード、認証結果、迷惑メール率という別々の証跡を、それぞれの層の責任で見る習慣をつけたい。

なお、ガイドラインが求めるのは認証だけではない。簡単な登録解除の仕組み、ワンクリック登録解除、暗号化された接続での送信、受信者の同意に基づく宛先管理など、送信行為全体の健全さが到達率を左右する。認証は入口であり、入口を通った後の送信の質が、次の配信判定に跳ね返る。だからこそ、認証の整備と同時に、宛先リストの取得経路と同意の記録を見直すことが、届く状態を持続させる条件になる。

出典：[1]

編集部の実務提案

認証が通っても整合が崩れればDMARCは失敗する

見落とされやすいのが整合（アライメント）である。DMARCでは、メールヘッダーのFromドメインが、SPFで認証されたドメイン、またはDKIM署名のドメインと一致している必要がある。送信自体が正規のサーバーから行われ、SPFもDKIMも単体では合格していても、FromとずれていればDMARCは失敗する。

典型例は委託先の送信サービスである。SaaSのデフォルト設定では、エンベロープの送信元やDKIM署名がベンダーのドメインになりがちで、自社ドメインのFromとは一致しない。利用者から見れば自社名義のメールなのに、認証の観点では別人のメールとして扱われる。GoogleのDMARC設定ガイドも、第三者サービスを使う場合は送信元ドメインの一致やSPFレコードへの送信サーバーの追加を確認するよう求めている。

整合には厳密（strict）と緩和（relaxed）があり、緩和ではサブドメインの一致まで許容される。既定は緩和だが、サブドメインを自社で管理していない場合や、別組織が運用するサブドメインがある場合は、厳密化を検討する価値がある。どちらを選ぶかはセキュリティの好みではなく、ドメインの管理実態に合わせて決める項目である。

切り分けの実務では、実際の受信メールヘッダーを1通取り、From、Return-Path、DKIM署名ドメインの3つを並べて見るのが早い。3つがどうずれているかが見えれば、直すべきが送信設定か、DNSか、ベンダー側のカスタムドメイン設定かは自ずと決まる。

ドメイン戦略にも影響する。通知用にサブドメインを分ける運用は、評判の分離には有効だが、整合の設定とレポートの受け口がドメインごとに増える。分けるなら、どのサブドメインがどのシステムの送信に使われ、DMARCポリシーを個別に持つのか、継承させるのかを設計に含める。特にspタグでサブドメイン向けのポリシーを別に定義できることは、移行期の保険として覚えておくとよい。場当たりに増やしたサブドメインは、棚卸し漏れの温床になる。

実務の落とし穴として、テスト送信では合格するのに本番の一部だけ失敗するケースがある。たとえば、通常の通知は自社サーバー経由だが、エラー時の再送だけ別経路を通る、添付ファイル付きだけ外部サービスを使う、といった例外経路である。例外経路は棚卸しとテストの両方から漏れやすい。経路の分岐条件そのものを洗い出し、分岐ごとに1通ずつ実メールヘッダーで確認する手順を、受け入れテストに組み込んでおきたい。

出典：[2][1]

編集部の実務提案

送信元の棚卸しが先、DNSの編集は後

認証整備で最初にやるべきはDNSの編集ではなく、自社ドメインでメールを送っている送信元の棚卸しである。自社のメールサーバー、請求システム、CRM、マーケティングツール、監視アラート、問い合わせフォーム。部門ごとに契約したSaaSが、それぞれ別々に自社ドメインで送信していることは珍しくない。

棚卸しでは送信元ごとに、送信サーバー、エンベロープのドメイン、DKIM署名の有無と鍵の管理者、月間の送信量を記録する。これがないままSPFレコードを編集すると、正規の送信を認証失敗にする事故が起きる。SPFのincludeを積み上げすぎてDNS参照回数の上限に触れる問題も、棚卸しなしの場当たり的な追加から生まれる。

DMARCの集計レポートは、棚卸しの答え合わせにも使える。レポートには、自社ドメインを名乗って送信したサーバーと認証結果が並ぶ。把握していなかった送信元がレポートに現れたら、それはシャドーITの発見でもある。棚卸し表とレポートを突き合わせる運用を最初から設計しておくと、認証整備は一過性のプロジェクトで終わらない。

責任分界も表に含める。各送信元の認証設定を変更できるのは誰か、ベンダー側の設定変更に必要な手続きは何か。障害時に「DNSは情シス、送信サービスは現場部門」という空白地帯で止まらないよう、変更権限の所在を棚卸しの段階で確定させる。

棚卸しの実務で効くのは、請求書や契約書といった経理の記録と突き合わせる方法である。技術部門の把握していないSaaSでも、支払いには必ず痕跡がある。情シス、経理、各部門の管理者で年に一度でも棚卸しの場を持つと、利用実態と支払いの差分から未把握の送信元が見えてくる。技術的な探索ツールと台帳の両輪で進めるのが確実である。

出典：[2]

編集部の実務提案

DMARCポリシーは監視から拒否へ段階的に強める

DMARCのポリシーには、none（何もしない・監視）、quarantine（迷惑メールとして隔離）、reject（拒否）の3段階がある。Googleのガイドは、開始時はnoneで認証の実態を把握し、学びながらquarantineやrejectへ移す段階的な展開を推奨している。いきなりrejectにすると、未把握の正規送信まで止めてしまうためである。

pctタグでポリシーの適用割合を絞ることもできる。小さい割合から始め、認証が通る送信の割合が上がるにつれて100%へ寄せていく。段階移行の判断材料はレポートであり、「失敗している送信が何か」を特定できない間はポリシーを強めない、という順序を守る。

SPFとDKIMが少なくとも48時間は安定して認証できていることを確認してからDMARCを有効化する、という前提もガイドに明記されている。認証の土台が揺れている状態でポリシーだけ先行させると、届かない問題の原因が認証なのかポリシーなのか切り分けられなくなる。

最終形はrejectである。なりすましメールを受信側で確実に落とせる状態にして初めて、DMARCは「届けるための仕組み」から「自社ドメインを守る仕組み」になる。段階を飛ばさず、しかしnoneに留まり続けもしない。各段階の滞在期間と移行条件を先に決めておくことが、プロジェクトを前に進める。

段階移行では「いつ次へ進むか」の判定を数値で持っておくと揉めない。たとえば、正規送信の認証成功率がレポート上で安定して高いこと、失敗行に未知の送信元が残っていないことを移行条件とし、2週間分のレポートで確認する、といった具合である。逆に、キャンペーンや請求サイクルの繁忙期とポリシー変更を重ねない配慮も要る。到達率に影響する変更は、影響が見えやすい時期にこそ避けるのが定石だ。

移行の順序を決める材料として、送信の重要度も加えたい。請求や契約に関わるメールと、キャンペーン性のメールでは、失敗したときの影響が違う。重要度の高い送信から先に整合と監視を固め、割合を絞ったポリシー適用の対象も重要な送信から広げる。逆に、停止しても業務影響の小さい送信は、実験的な設定変更の検証に使いやすい。全送信を一括で扱わず、重要度でキューを分ける発想が、段階移行のリスクを下げる。

出典：[2][1]

編集部の実務提案

レポートと迷惑メール率を継続監視する

DMARCの集計レポート（rua）は、認証の健康状態を継続的に見るための窓である。Googleは専用のグループやメールボックスで受け取ることを推奨する。大きな組織では1日に数百から数千件のレポートが届くため、個人の受信箱に流す設計は破綻する。集計ツールに流し、失敗の送信元と割合で見る運用が現実的である。

もう一つの継続指標が迷惑メール率である。GoogleはPostmaster Toolsで報告される迷惑メール率を0.3%未満に保ち、0.1%以下を目指すよう求めている。率が上がるのは、認証とは別の問題、たとえば宛先リストの鮮度や送信頻度の急変を示すことが多い。認証の監視と到達率の監視は別のダッシュボードで見るべきだが、障害時には突き合わせて判断する。

認証エラーにも注意する。未認証のメールは5.7.26のようなエラーで拒否される場合がある。送信ログにこのコードが増えたら、受信側ポリシーの変更か、自社側の設定変更のどちらかが起きている。エラーメッセージをコードで集計し、通常時の水準を把握しておくと異常検知が早くなる。

監視の目的は、届かないという報告を受ける前に、認証の崩れを自社で先に知ることである。新規SaaSの導入、DNSの変更、送信量の急増といった変化点のたびにレポートを確認する手順を、変更管理の中に組み込んでおく。

レポートの読み方にも定型がある。見るべきは失敗の絶対数ではなく、送信元ごとの内訳と、正規送信に占める失敗の割合である。特定のSaaSだけ失敗率が高いならベンダー設定の問題、特定の受信ドメインだけ失敗するなら受信側の転送やメーリングリストの影響が疑われる。転送されるとSPFが崩れることは仕様上起こり得るため、失敗イコール不正ではない。内訳を見ずに件数だけで判断しないことが、誤ったポリシー強化を防ぐ。

監視の受け手が決まっていないレポートは、届いても読まれない。レポートの確認を週次の定例に組み込む、失敗の閾値を超えたら担当へ通知する、四半期ごとに棚卸し表と突き合わせる、といった具体的なリズムを決めて初めて、監視は機能になる。あわせて、主要な受信先である大手プロバイダのガイドライン変更を追う担当も決めておく。要件は予告なくは変わらないが、見ていない変更は突然の変更と同じである。

出典：[1][2]

編集部の実務提案

委託先の送信は契約と設定の両方で管理する

業務メールの多くは委託先から送られる。送信プラットフォーム、決済通知、配送通知、外部のサポートデスク。委託先が自社ドメインで送る以上、その認証設定は自社の到達率とブランド保護に直結する。契約や利用開始のチェックリストに、SPFへの組み込み方法、DKIMのカスタムドメイン署名の可否、鍵の所有者を明記しておく。

特にDKIMは、ベンダーの共用ドメインで署名される設定のままだと整合が取れない。自社ドメインで署名できるプランや設定があるかを導入前に確認し、鍵の生成とDNS公開の手順をどちらが行うか決める。退職や規格変更で鍵を差し替える場面も想定し、鍵ローテーションの手順と予備鍵の持ち方を取り決める。

解約時の扱いも忘れがちである。委託先をやめたら、SPFレコードからその送信元を外し、DKIMセレクタを無効化する。残された認証の許可は、なりすましに使われ得る入口になる。棚卸し表に「廃止時の削除手順」まで書いておくと、オフボーディングの漏れが減る。

委託先の障害や仕様変更で認証が崩れることもある。到達率の異常を委託先のせいにする前に自社のレポートで事実を確認し、逆に委託先へ問い合わせる際はレポートの該当行を示せる状態にしておく。証跡を持ったコミュニケーションが、切り分けの時間を短くする。

セキュリティ部門との連携も押さえたい。自社ドメインを騙るフィッシングが観測されたとき、DMARCのrejectポリシーとレポートは、被害範囲の把握と対外説明の根拠になる。認証整備を「メールの届き」の文脈だけで進めると、情シスや運用部門の仕事に見えるが、実際にはブランド防衛とインシデント対応の基盤でもある。関係部門を巻き込む材料として、レポートに現れたなりすましの実績は強い。

出典：[2]

編集部の実務提案

届く状態を監査可能な形で残す

最後に、認証の状態を監査可能な形で残す。どのドメインとサブドメインに、どのSPFレコード、DKIMセレクタ、DMARCポリシーが設定されているか。変更履歴と変更理由、ポリシー段階の移行日と判断に使ったレポートの期間。これらが残っていれば、移行や監査、担当者交代のたびに現状を再調査しなくて済む。

一括送信の基準も変わり続けている。Googleは1日5,000通以上をGmail宛に送る送信者に、SPF・DKIM・DMARCの全設定、ワンクリック登録解除、迷惑メール率の管理を求めた。要件は段階的に広がる前提で、自社の送信量が基準未満でも、大量送信者向けの要件を先取りしておく方が移行は楽である。

確認観点をまとめると、証明（SPF・DKIMが正しく設定され鍵が適切か）、整合（Fromと一致しているか）、範囲（棚卸しに漏れた送信元はないか）、強度（ポリシーは段階計画どおり進んでいるか）、監視（レポートと率を誰が見ているか）の5つになる。この5つを別々に点検できる状態が、「設定した」ではなく「運用している」状態である。

メールは最も古く、最も業務に近い通知経路である。届かない問題を本文の書き方の問題として扱う前に、認証という土台を点検する。その順序が、問い合わせと遅延を減らす最短路になる。

記録の残し方として有効なのは、DNSのゾーンファイルやレコード設定のエクスポートを、変更のたびに台帳へ添付することである。誰が、いつ、何を、なぜ変えたかが復元できれば、障害時に「直前の変更へ戻す」という判断が速くなる。あわせて、認証チェックを定期実行する小さな仕組み、たとえば主要ドメインのSPF・DKIM・DMARCの有無とポリシーを週次で確認するスクリプトを用意しておくと、意図しない失効や削除の早期発見につながる。

出典：[1]