請求書が迷惑メールに入る理由 — 香港の小売ブランドのためのSPF・DKIM・DMARC解説

結論から言うと: 「気づいたら届かなくなっている」メールは、ほぼ例外なく認証の「アライメント（整合性）」チェックに失敗したメールです。サードパーティのプラットフォームが自社ドメイン名義で注文確認や請求書を送り始めるなら、そのプラットフォームはSPFで許可され、なおかつ自社ドメインにアライメントしたDKIM署名を持たなければなりません。ツールを受信箱に接続することと、DNSに接続することはまったく別の作業であり、このギャップこそが企業メールが忽然と消える最も一般的な原因です。

なぜ注文確認メールが突然届かなくなったのか

香港の消費財ブランドを想像してください——中規模のホームウェア・ライフスタイル小売業者で、従業員は20〜60名、自社サイトと複数のECモールで販売しています。このブランドがカスタマーサポートを新しいサードパーティのサポートプラットフォームに切り替えました。導入は順調に進みます。チケットは正しくルーティングされ、担当者は新しい受信箱を気に入り、運用チームの誰もこれを「メールのプロジェクト」だとは考えません。彼らの目には、これはあくまで「ヘルプデスクのプロジェクト」だからです。

1週間もしないうちに、苦情が届き始めます。ある顧客が注文確認メールがどこにあるのか電話で問い合わせてきます。別の顧客は請求書が届かず、すでに2回も再送を依頼したと言います。物流パートナーは、出荷通知メールが迷惑メールフォルダに入っていたと言及します。これらは一見、一つのインシデントには見えません。最初の数日は、運用マネージャーもそう扱います——こちらはフィルターの気まぐれ、あちらは顧客の入力ミス、という具合に。

しかしこれは偶然でも、迷惑メールフィルターのランダムな挙動でもありません。新しいプラットフォームは、注文確認・請求書・出荷通知といったトランザクションメールを、ブランド自身のドメインを差出人アドレスにして送信します。それが顧客の目に正当なものとして映るための方法だからです。それを技術的に成立させるには、どんな送信者とも同様に、そのプラットフォームがドメインから「信頼」されている必要があります——SPFに記載されているか、DKIMで署名しているか、理想的には両方であり、さらに重要なのは、それが顧客が実際に目にするメッセージのドメインと「アライメント（整合）」していることです。プラットフォームを切り替えた際、誰もDNSに触れていません。なぜならサポートプラットフォームの導入は、表面上はDNSの変更には見えないからです。この記事が扱うのは、まさにこのギャップ——新しい送信者が追加されたのに、ドメインの認証設定には一度も追加されなかったという状態——についてです。

この記事は、「請求書は届いていますか」という問い合わせの山を前にしながら、プラットフォームのベンダーからは「連携は正常に機能している」と言われているECまたは運用マネージャーのために書かれています。プラットフォーム側から見れば、それは事実です。メールは送信されています。その後どうなるかはDNSの問題であり、DNSは誰の担当にも割り当てられていない部分なのです。

3つのレコードと、実際にすべてを左右するたった一つの言葉——アライメント

SPF、DKIM、DMARCについてのほとんどの解説は、「これら3つが必要です」と述べ、それぞれが何であるかを説明したところで終わってしまい、実際にあなたの注文確認メールが届くかどうかを左右する部分を飛ばしています。その部分こそが「アライメント」です。3つのレコードをそれぞれ個別に正しく設定していても、アライメントが誤っていれば、メールはやはり失敗します。

SPF（Sender Policy Framework） は、あなたのドメインのDNS TXTレコードで、どのメールサーバーがあなたの名義でメールを送信してよいかを列挙するものです。これが照合するのは非常に具体的な一点——エンベロープ送信者、いわゆるReturn-PathまたはMAIL FROMアドレスと呼ばれる、メール配送の過程で使われる技術的なフィールドです。ここは正確に理解しておく価値があります。ほとんどの解説が見落としている点だからです。SPFは顧客が受信箱で目にするアドレスを照合しているわけではありません。 顧客が決して目にすることのない、背後のアドレスを照合しているのです。メッセージはSPFを問題なく通過しながら、顧客に見える差出人アドレスのドメインについて、SPFが一切言及していないということが起こり得ます。

DKIM（DomainKeys Identified Mail） は、送信メッセージに付加される暗号署名で、あなたのDNSの特定の場所に公開された公開鍵と照合されます——「セレクタ」とドメイン名を組み合わせた場所であり、たとえば yourbrand.com 上でセレクタ s1 を使って行われた署名は、s1._domainkey.yourbrand.com というDNSレコードと照合されます。この署名は、メッセージが送信中に改ざんされていないこと、そして対応する秘密鍵を保持する側が実際に送信したことを証明します。重要なのは、DKIM署名が「誰の手柄になるか」——署名内の d= の値——は、署名者がどのドメイン名義で署名するかを自由に選べるという点です。これも可視の差出人アドレスと一致している必要はありません。サードパーティのプラットフォームは、自分自身のドメインで自分自身の送信メールに、技術的には完全に有効なDKIM署名を付けることができますが、その署名はあなたのブランドとは何の関係もありません。

だからこそ、上記の両方が個別には正しくても、メールはやはり失敗し得るのです。DMARC（Domain-based Message Authentication, Reporting and Conformance） は、このギャップを埋めるためのレコードです。DMARCは新しい認証方式を導入するわけではなく、SPFとDKIMの結果を受け取り、もう一段階の照合を行います——実際に通過したドメイン（SPFのReturn-Pathドメイン、またはDKIMの d= ドメイン）が、顧客が実際に目にする差出人アドレスのドメインと一致するか、あるいは合理的に一致すると言えるか、という照合です。この照合は識別子アライメント（identifier alignment）と呼ばれ、DMARCレコードは2通りの方法でこれを要求できます。リラックスアライメント（relaxed alignment、一般的なデフォルト）は組織ドメインのレベルでの一致を認めるため、mail.yourbrand.com は yourbrand.com とアライメントします。厳格アライメント（strict alignment）は両者の完全修飾ドメイン名が完全に一致することを要求します。SPFが通過しアライメントしているか、DKIMが通過しアライメントしていれば、メッセージはDMARCを通過します——どちらか一方で十分ですが、少なくとも一方は「単に有効」ではなく、実際に「アライメントしている」必要があります。

端的に言えば、あなたのブランドは教科書通りに正しいSPFとDKIMを両方持ちながら、それでもDMARCに完全に失敗し得るのです。なぜなら、それぞれのチェックを実際に通過したドメインが「あなたの」ドメインではなく「プラットフォームの」ドメインだったからです。これはまさに上記のシナリオで起きている失敗の形であり、繰り返す価値があります。急いで書かれた解説の多くが見落とす部分だからです。レコードそのものはゴールではありません。顧客が目にする差出人ドメインへのアライメントこそがゴールであり、レコードは単なる手段にすぎないのです。

サードパーティの送信者を追加すると、実際にどう配信性が壊れるのか

新しいプラットフォームが登場する前のDNSの状態を想像してください。Microsoft 365またはGoogle Workspaceが導入時に正しく設定されていれば、通常は正常に機能するSPFレコードがあり、主要な送信ドメインでDKIMが有効化されており、導入担当者が十分に注意深かった場合は、すでにDMARCレコードが公開されている——それも強制適用のポリシーになっている可能性さえあります。これは近年、例外というよりむしろ賢明なデフォルトになりつつあるからです。通常の社員のメールは問題なく認証を通過し、誰もそれについて改めて考えることはありません。

そこにサポートプラットフォームが導入され、ブランド名義で注文確認や請求書を送信するよう設定されます。汎用的なプラットフォームのドメインから届いたことが見えるメールよりも、ブランド自身から届いたように見えるメールの方が、コンバージョン率も信頼性も高いからです。プラットフォームの送信メールサーバーは、ブランドのSPFレコードに一度も追加されていません。プラットフォームは自分自身のメールにDKIM署名をするかもしれませんが、それは自分自身の d= ドメインであり、ブランドのドメインではありません——ブランドがこのプラットフォームのためにDKIM鍵ペアを生成して引き渡したことは一度もないからです。顧客が目にする差出人アドレスは orders@yourbrand.com です。SPFもDKIMも、yourbrand.com にアライメントする結果を生み出しません。DMARCは失敗します。

その次に何が起きるかは、ブランドのDNSにすでに存在しているDMARCポリシーに完全に左右されます——だからこそ、DMARCという言葉を聞いたことすらない運用マネージャーが、この後始末をする羽目になるのです。ドメインが p=reject を公開していれば、受信メールサーバーはメッセージを完全に拒否します。送信側には、プラットフォームが表示できる形でのバウンス通知は一切届かず、注文確認メールは顧客の受信箱にとってはそもそも存在しなかったことになります。ドメインが p=quarantine を公開していれば、メッセージは通常、受信者の迷惑メールフォルダに配信されます——これが「迷惑メールフォルダで見つけた」という報告と「まったく届いていない」という報告が混在する理由です。両者は同じ根本的な失敗が、隔離ポリシーの扱いがわずかに異なる受信システムに落ちているだけなのです。ドメインが p=none を公開している、あるいはDMARCレコード自体が存在しない場合、メッセージが配信される可能性は高くなりますが、その代わりドメインは「誰かがブランド名義で未認証のメールを送る」ことに対する保護をまったく持たないことになります——これは別の問題であり、本記事の対象外です。後述する別の記事のテーマです。

正しい修正方法は、正確に2つだけです。「プラットフォームに自社ドメインを使わせない」ことで配信性を解決しようとするのは、ブランド化された送信者アドレスを放棄することであり、通常はビジネスが望む結果ではありません。ブランド化されたアドレスを維持しながら認証を通過させる2つの修正方法は次の通りです。

サードパーティの送信者を修正する2つの方法と、それぞれに必要なこと

• プラットフォームをSPFに追加する。 プラットフォームのドキュメントには、まさにこの目的のための include: 値が公開されているはずです——include:mail.platformname.com のようなものです。これをSPFレコードに追加することで、プラットフォームのサーバーがあなたのエンベロープドメインを使用することを許可します。これは変更としては小さい方ですが、DMARCの「どちらか一方」のうちSPF側だけを解決するにすぎません——DKIMには何の効果もなく、さらにSPFの10回のDNSルックアップ上限（後述）に一歩近づくことになります。すでに複数の送信者をincludeしている場合は特に注意が必要です。
• プラットフォームに、あなたのドメインにアライメントしたDKIM署名で送信させる。 これはより強固な修正方法です。なぜならDKIMのアライメントは、メールが転送された後も有効であり、SPFの弱点であるメールが辿ったネットワーク経路を受信サーバーが信頼しているかどうかにも依存しないからです。これを正しく行うには、通常あなたのドメイン用にDKIM鍵ペアを生成し、公開鍵をプラットフォームが指定するセレクタの下、_domainkey.yourbrand.com の下に公開し、秘密鍵をプラットフォームに渡して署名させる必要があります——今日、多くのSaaS型送信者ではより一般的で、かつミスの起きにくいパターンとして、生の鍵ではなくプラットフォームが提供するCNAMEレコードを設定するだけで自動的に行われることも多くなっています。

両方を行うのは過剰ではなく、むしろ普通のことです。DMARCがどちらか一方の通過だけを必要とするからこそ、両方を設定しておけば、片方の仕組みに一時的な問題が起きても、それだけでメールが止まることはありません。普通ではなく、修正とも言えないのは、プラットフォームをSPFに追加しただけで終わりにし、「SPFとDKIMはだいたい同じようなものだろう」と思い込んでしまうことです。両者はまったく異なるものを照合しており、それぞれ独立して誤り得ますし、DMARCのアライメントチェックも両者に対して別々に評価されます。

ツールを買わずに、DMARCレポートは実際に何を教えてくれるのか

DMARCの rua タグ——DMARCのDNSレコードに記載するメールアドレス——は、受信メールサーバーに対して、あなたのドメイン名義を名乗るメールについて、何が通過し、何が失敗し、どこから送られたかを毎日集計したレポートを送るよう要求します。これらは通常、圧縮されたXML添付ファイルとして届き、専用の監視サービスを導入する前でも、単発のインシデントであれば手作業で読み解くことは十分に可能です。

各レポートの中で最も重要なフィールドは source_ip で、実際にメッセージを送信したサーバーがどれかを示します——この項目のおかげで、失敗しているメールのかなりの割合が、怪しい送信元ではなく、サポートプラットフォームが保有するIPブロックから来ていることがわかります。その隣にある count は、同じIPから同じ結果で送られたメッセージ数を示します。これによって「プラットフォームが時々失敗しているようだ」という漠然とした話が、「プラットフォームは先週4,000通送信し、そのうち3,850通がアライメントに失敗した」という具体的な結論に変わります。次に policy_evaluated があり、あなたのドメインのポリシーが、その特定のメッセージについて受信側に何をするよう指示したかが記録されています——disposition（正常配信は none、迷惑メールへの振り分けは quarantine、完全拒否は reject）と、そのメッセージの dkim および spf の評価結果です。最後に auth_results があり、DKIMとSPFそれぞれについて、実際に照合されたドメインと通過したかどうかが示されます——ここでこそ、DKIMが platformname.com に対しては通過している一方で、あなた自身のドメインのアライメントは失敗していることを直接確認でき、これが「原因はレコードの誤りではなくサードパーティ送信者である」ことを示す最も明確な証拠になります。

注目すべき3つの数字は、順に次の通りです。特定の source_ip からの総送信量、そのうち意図した結果とは異なる disposition になっている割合、そして失敗しているメカニズムについて auth_results が示すドメインが、自分たちが認識している送信者かどうか。もし認識している送信者であれば、サードパーティ送信者の問題を発見したことになります。もし認識していないのであれば、それはまったく別の、より深刻な話——あなたが一度も送っていないのに、あなたのドメイン名義を騙るメールが送られている——を発見したことになるかもしれません。

DMARCポリシーはどこまで厳しくすべきか——いきなりrejectにすると何が問題になるのか

DMARCの p= タグは3つの値を取り、これらはオン・オフのスイッチではなく、意図的に設計された段階を成しています。p=none は、受信側に失敗したメッセージに対して特別な処置を取らないよう求めますが、レポートは引き続き送るよう求めます——これは観察段階であり、長年運用されていてDMARCポリシーが一度もチェックされたことのないドメインを含め、すべてのドメインがここから始めるべきです。p=quarantine は、受信側に失敗したメッセージを疑わしいものとして扱う——通常は受信箱ではなく迷惑メールフォルダに振り分ける——よう求めます。p=reject は、受信側にメッセージを完全に拒否するよう求めます。pct タグを使えば、これらの処置を失敗メールの全体にではなく、指定した割合にだけ適用できます。これが「一斉切り替え」ではなく「段階的な移行」を可能にする仕組みです。

未知の送信者が存在するドメインが、いきなり p=reject に飛びつくべきでない理由は、まさに本記事の冒頭のシナリオを逆方向に走らせたものです。サポートプラットフォーム(あるいは請求書ツール、マーケティングの送信者、納品書をメール送信するERP)がまだ正しく認証されていない状態でrejectに切り替えても、何も解決しません——既存の失敗を完全かつ即座なものにするだけで、どの送信者が最初に壊れたのかを把握する手がかりも失われます。実際に機能する順序は次の通りです。まずレポート送信先を指定した p=none を公開し、月末処理、マーケティング配信、日常的な注文量を含む一連の業務サイクル全体を読み解けるだけの期間、レポートを読み続け、すべての正当な送信者が認証済みかつアライメント済みとして表示されるまで待つこと。次に、できれば低めの pct から始めて p=quarantine に移行し、レポートがきれいな状態を維持しながら比率を上げていくこと。そして最後にようやく p=reject に移行することです。この観察段階を飛ばすことは、ドメインを「保護」しているつもりで、自分自身の手で障害を作り出すことに等しいのです。

SPF・DKIM・DMARCが技術的に整っていても、他に何が配信性を静かに損なうのか

3つのレコードのアライメント問題を解決することは、最も一般的な原因を取り除いただけであり、唯一の原因を取り除いたわけではありません。この規模の企業でよく見られる、隣接するいくつかの問題について、はっきりと述べておく価値があります。

共有送信IP——比較的低価格なトランザクションメールの追加オプションや、一部のヘルプデスクプラットフォームの送信メールでよく見られます——は、あなたの配信性が、そのIPを共有する他の顧客によって部分的に左右されることを意味します。もし他の誰かが送ったメールがそのIPをフラグ付けされる原因になれば、あなた自身のドメイン設定には何の落ち度もないのに、正当な注文確認メールが同じレピュテーション被害に巻き込まれる可能性があります。

SPFのルックアップ上限超過は、本記事が説明している問題のスローモーション版であり、直接確認する価値があります。SPFの評価は、include、a、mx、ptr、exists、redirect の各メカニズムを合算して10回のDNSルックアップに制限されています——マーケティングプラットフォーム、ECプラットフォーム、サポートプラットフォーム、会計システム、配送通知サービスなどを何年もかけて少しずつ追加してきたドメインは、気づかないうちにこの上限を超えてしまうことがあります。その時点でSPFチェック全体が恒久的なエラーを返すようになり、最新の送信者だけでなく、レコードに記載されているすべての送信者に対する保護が事実上失われます。

Return-Pathの欠落または誤設定——これはSPFが実際に照合する技術的なアドレスであり、顧客が見る差出人アドレスとは別のものです——は、誰も意図していないドメインに対してSPFが評価を行う原因になり得ます。特に、あるプラットフォームがあなたのために管理しているサブドメイン経由で送信しており、そのサブドメイン自体のSPFの状態をあなたのチームが一度も確認していない場合に起こりがちです。

そしてフィッシングのように見えるコンテンツは、認証とはまったく無関係に、送信パターンの異常さ、見慣れないリンク短縮サービス、あるいは受信サーバーのコンテンツフィルターに引っかかる文言によって、SPF・DKIM・DMARCがすべて問題なく通過していても配信を抑制することがあります。認証とコンテンツフィルタリングは別々のシステムであり、同じメッセージについてそれぞれ独立した判断を下しているからです。

これは結局、誰が恒久的に責任を持つべきなのか

責任分担として最も明快で、次にプラットフォームを切り替えたときにも耐えられる方法は、DNSはあなたのもの、プラットフォームは向こうのもの、そして日常の監視は、日々Microsoft 365やGoogle Workspaceのテナントを管理している側が担う、というものです。プラットフォームの役割は、自分のドキュメントの中で、どのSPF includeの値、あるいはどのDKIM CNAMEレコードが必要かを明記することです。あなたの役割——あるいはあなたのITプロバイダーの役割——は、実際にそのDNS変更を行い、正しく伝播・解決されていることを確認し、その連携を「完了」と見なす前に、DMARCレポート上でそのプラットフォームのメールが認証済みかつアライメント済みとして表示されていることを確認することです。「ベンダーが設定済みだと言っていた」ことをプロセスの終点とし、独立したDNSの確認を行わないことこそが、新しい送信者を追加するたびにこの失敗が繰り返される理由なのです。

香港のブランドが新しい送信者にどう対応しているか、3つのパターン

• 誰も担当しておらず、問題が起きたときにしかDNSを触らない。 プラットフォームが稼働を始め、メールが送信されるようになり、顧客からの苦情があって初めて、誰かがSPFやDMARCについて知ることになります。これは、サポートプラットフォームの導入を「メールのプロジェクト」ではなく「ヘルプデスクのプロジェクト」として扱うことの、いわばデフォルトの結果であり、まさに本記事のシナリオに登場するブランドが置かれている立場です。
• DNSは導入時に一度だけ確認され、その後は誰も見ていない。 多くの場合、当初Microsoft 365テナントを構築した人が、新しいプラットフォームのSPF includeを追加してそれで完了とみなします。これは明らかなケースは防げますが、「ドリフト」は見逃します——プラットフォームが送信インフラを変更する、誰も読んでいないDMARCレポートが実は別の無関係な送信者の失敗を示していた、あるいはツールが1年かけて次々と追加されるうちにルックアップ上限にじわじわ近づいていく、といったことです。
• DNS変更は管理されたプロセスを経て行われ、DMARCレポートは実際に読まれている。 すべての新しい送信者は、稼働開始前にレポートと照らし合わせて認証・検証され、SPFレコードは定期的にルックアップ上限に対してチェックされ、DMARCポリシーは意図的に——none、次にquarantine、最後にreject——段階的に引き上げられます。一度設定されたきりの状態のまま放置されることはありません。3つのパターンのうち、顧客より先に2つ目の失敗した送信者を発見できるのは、これだけです。

Brocentはここで何をしているのか、詐欺対策とはどう違うのか

密接に関連する別の記事との違いを、はっきりさせておく価値があります。両方ともSPF・DKIM・DMARCについて扱っていますが、同じ問題を扱っているわけではないからです。香港の卸売業者があわや取引先支払い詐欺に遭いかけた事例を扱った記事は、逆方向の話です。メールがあなたの会社に届き、本物の取引先から来たように見せかけて、別の銀行口座への支払いを求めてくるというものです。あの記事におけるSPF・DKIM・DMARCの議論は、これらのレコードが、誰かがあなたに対して送信者になりすますことをどこまで防げるか、そしてどこで防げないかについてのものです。一方、この記事が扱っているのは、あなた自身が追加した送信者が正しく認証されなかったために、あなた自身の外向けメールがあなた自身の顧客に届かなくなっている、という問題です。同じ3つのDNSレコード、同じ根底のメカニズムでありながら、方向は逆で、対処法も異なります。

BrocentのマネージドITクラウドサービスは、Microsoft 365側をまさに直接カバーしています。Exchange OnlineをSPF・DKIM・DMARC設定込みで導入・運用し、あわせてMicrosoft Defender for Microsoft 365によるセーフリンク、セーフ添付ファイル、迷惑メール対策を有効化します。標準的な導入プロセスにおける「ID設定」のステップには、サードパーティの送信者がこのギャップを露呈させるまで放置するのではなく、初日からドメインのSPFとDMARCを設定することが含まれています。認証レコード側ではなく、なりすまし検知・アンチフィッシング側のニーズがある企業には、マネージドメールセキュリティが該当します。Microsoft 365やGoogle Workspace環境の前段に、アンチフィッシング・ビジネスメール詐欺検知、ランサムウェア・マルウェア対策、隔離管理を重ねるサービスです。両方ともここで関係してきますが、理由は異なります。クラウドサービス側は、そもそも自社の認証を最初から正しく設定するためのもの。メールセキュリティ側は、メールが逆方向から来ることを心配し始めたときに関係してくるものであり、それはこの記事ではなく、上でリンクした記事のテーマです。

どちらのサービスも、実際にそのプラットフォームのドキュメントを誰かが読み、要求されているDNS変更を行わない限り、特定のサードパーティプラットフォームを自動的に認証してくれるわけではありません。このステップは常にその送信者固有のものであり、汎用的なマネージドサービスがこれを代替することはありません。マネージドな関係によって変わるのは、その後実際に誰かがDMARCレポートを継続して見ているかどうか、そしてSPFレコードが静かにルックアップ上限に達する前に監査されるかどうかです。

よくある質問

以前は問題なく届いていたメールが、なぜ突然届かなくなったのですか？

ほぼ常に、ドメインから外に出ていく仕組みに新しい送信者——サポートプラットフォーム、マーケティングツール、請求書発行システムなど——が追加されたのに、SPFやDKIMの側が対応する変更をされなかったためです。Microsoft 365やGoogle Workspaceから直接送られる、ドメインの既存のメールは以前とまったく同じように認証を通過し続けます。失敗するのは新しい送信者のメールだけであり、これが問題が完全な障害ではなく、断続的なものに見える理由です。

プラットフォームをSPFレコードに追加するだけで十分ですか？

役には立ちますが、それはDMARCがチェックしている内容の半分にすぎません。SPFが通過しアライメントしていることは、DMARCを満たす一つの方法であり、DKIMが通過しアライメントしていることはもう一つの方法です。プラットフォームをSPFだけに追加すると、その送信者に関してSPFが機能し続けること——メールが辿るネットワーク経路を含めて——に完全に依存することになり、万が一それがうまくいかなかった場合に頼れるDKIM署名がありません。より堅牢な修正方法は、両方を設定することです。

DKIMのアライメントとは具体的に何を指しますか？

DKIMのアライメントとは、有効なDKIM署名の「手柄」となるドメイン——署名ヘッダー内の d= の値——が、顧客が見る差出人ヘッダーのアドレスと一致していること、あるいはリラックスアライメントの場合は同じ組織ドメインを共有していることを指します。プラットフォームは自分自身のドメイン名義で、技術的には有効なDKIM署名を一日中付け続けることができますが、あなたのドメイン名義で署名しない限り、それらのどれ一つとしてあなたに対してDKIMアライメントしていることにはなりません。

この種のDNS変更は実際どのくらいの時間で反映されますか？

DNSレコード自体は、置き換える前のレコードに設定されていたTTL（生存時間）にもよりますが、通常は数分から数時間で伝播します。計画を立てる上でより安全な目安としては、変更が反映されていないと判断するまでに24〜48時間の余裕を見ておき、顧客の苦情が止まるかどうかだけで判断するのではなく、DNSルックアップで直接そのレコードを再確認することです。

DMARCポリシーをp=rejectに設定すべきですか？

最終的には、安全にそこへたどり着けるのであれば設定すべきです——ただし最初の一手としてではなく、認証がまだ済んでいない送信者が残っている間は避けるべきです。安全な順序は、none、次にquarantine、最後にrejectであり、DMARCレポートですべての正当な送信者が認証済みかつアライメント済みとして通過していることが確認できてから、次の段階に進みます。未確認の送信者が残っているドメインでいきなりrejectに切り替えると、まさにあなたが守ろうとしているそのメール自体を、気づかないうちに遮断してしまう恐れがあります。

専用のDMARC監視サービスは必要ですか、それとも自分たちでレポートを読めば十分ですか？

単発のインシデントに対してであれば、上述したように数件の集計XMLレポートを手作業で読むことは十分に実用的です。ただし、複数のサードパーティ送信者を抱え、p=reject への移行を見据えている継続的なドメインであれば、監視サービス、あるいは実際にスケジュールに沿ってレポートを確認しているマネージドプロバイダーの方が、不定期な手作業での確認よりもはるかに早く「ドリフト」——後から追加された送信者や、送信インフラをこっそり変更したプラットフォームなど——を発見できます。

これはMicrosoft 365だけの問題ですか、それとも他のプラットフォームでも起こりますか？

メインの受信箱プラットフォームが何であっても、仕組みはまったく同じです。SPF・DKIM・DMARCはインターネット標準であり、MicrosoftやGoogle固有の機能ではありません。本記事のシナリオは、Google Workspaceでも、その他どのメールプラットフォームでも、対応するDNS変更を行わずにサードパーティの送信者を追加すれば、まったく同じように発生します。

社内では誰が実際にDNSとこの設定の責任を持つべきですか？

責任は、その問題を引き起こしたプラットフォームにたまたま契約したマーケティング部門やECの運用部門ではなく、日々Microsoft 365やGoogle Workspaceのテナントを管理している側——社内IT、あるいはマネージドITプロバイダー——が持つべきです。プラットフォームのベンダーは何が必要かを教えてくれますが、それが正しく実施されたこと、そして今後さらに送信者が追加されていく中でも正しい状態を保ち続けていることを確認できるのは、ドメインのDNSを実際に管理している側だけです。

次にプラットフォームを切り替える前に、責任の所在をはっきりさせる

本記事のシナリオに登場するブランドには、セキュリティの問題もプラットフォームの問題もありませんでした——サポートプラットフォームは設計通りにまったく問題なく機能していました。あったのは責任のギャップです。製品導入と同時に行われるべきだったDNS変更が、両者が関連していることに誰も気づかないまま、実行されなかったのです。目の前の障害を直すには、DNS変更1回と数日間のレポート確認で足ります。このパターン自体を直すには、次のヘルプデスクプラットフォーム、マーケティングツール、あるいは請求書発行システムが静かに同じ失敗を繰り返す前に、新しい送信者が追加されるたびに誰が認証とアライメントを確認するのかを、一度きちんと決めておく必要があります。

最近プラットフォームやベンダーを切り替えた後にメールが届かなくなっているという問題を抱えている、あるいは次に何かを変更する前にDNSとDMARCレポートをきちんと確認しておきたいという場合は、私たちのチームにご相談ください。これがマネージドMicrosoft 365環境全体にどう組み込まれ、費用がどの程度になるのかを先に知りたい場合は、料金ページとユーザー単位のマネージドITプランで仕組みをご確認いただけます。