SPF・DKIM・DMARC崩壊で顧客メールが届かない

2026年6月22日(月)

SPF・DKIM・DMARCはDNSと送信基盤（ESP）の両方にまたがって初めて成立するため、ドメイン移管時に片方だけ更新すると認証が崩壊し、パスワードリセットや請求書メールが迷惑メール判定・受信拒否される。買い手は移管前後の到達性検証を、売り手は認証設定の台帳化とレピュテーションの開示を行うべきだ。

移管の翌朝、サポート窓口に問い合わせが殺到していた。「パスワードリセットのメールが届かない」「登録確認メールが来ない」「請求書が送られてこない」。サービス自体は正常に動いている。メールも送信処理は成功している。送信ログには「送信完了」と記録されている。それでも顧客の受信箱には届いていない。届いていたとしても、すべて迷惑メールフォルダに直行していた。原因は、DNS移管のときにSPF・DKIM・DMARCのレコードが引き継がれなかったことだった。

メールは「送れば届く」ものだと思われがちだが、2026年の現実はその逆だ。送信ドメイン認証（SPF・DKIM・DMARC）が正しく設定されていないメールは、GmailやMicrosoft 365をはじめとする主要メールプロバイダーによって、迷惑メール判定されるか、受信そのものを拒否される。そして、これらの認証設定はすべてDNSのTXTレコードと送信基盤（ESP）の設定に分散して存在しており、M&Aのインフラ移管で最も引き継ぎ漏れを起こしやすい領域の一つだ。

本稿では、SPF・DKIM・DMARCがなぜ事業の生命線なのか、移管時に何が崩壊するのか、ドメイン認証とESPの棚卸し手順、そしてメール到達性（デリバラビリティ）をバリュエーションと移行計画にどう織り込むかを、現場目線で整理する。

1. メール認証が事業の生命線である理由

1-1. トランザクションメールが止まると事業が止まる

多くのサービスは、メールを通じて顧客と接続している。パスワードリセット、新規登録の確認、二要素認証コード、購入確認、請求書、配送通知、重要なお知らせ ── これらのトランザクションメールは、サービスの利用そのものに不可欠だ。パスワードリセットメールが届かなければ、ユーザーはログインできなくなり、サポートに問い合わせが殺到する。

これらが迷惑メール判定や受信拒否で届かなくなると、サービスは「動いているのに使えない」状態に陥る。顧客は離脱し、サポートコストは跳ね上がり、ブランドへの信頼が損なわれる。メール到達性は、サービスの可用性と同等の事業基盤であり、それが崩壊すれば事業も連鎖的に崩れる。

1-2. マーケティング・督促メールの全滅という二次被害

トランザクションメールに加え、マーケティングメール（ニュースレター、キャンペーン）や督促メール（決済失敗時の再通知）も認証崩壊の影響を受ける。マーケティングメールが全件迷惑メール判定されれば、リード獲得とリテンションのチャネルが断たれる。督促メールが届かなければ、決済失敗からの回収ができず解約に直結する。

さらに悪いのは、認証に失敗したメールを送り続けると、送信ドメインのレピュテーション（評判）そのものが悪化することだ。一度レピュテーションが地に落ちると、認証を直しても到達性が回復するまで時間がかかる。認証崩壊は一過性の事故ではなく、ドメインの信頼資産を毀損する持続的なダメージになる。

2. SPF・DKIM・DMARCはどこに存在するか

2-1. SPF ── 「どのサーバーが送信を許可されているか」

SPF（Sender Policy Framework）は、「このドメインから送信してよいのはどのサーバー（IP/ホスト）か」をDNSのTXTレコードで宣言する仕組みだ。利用しているESP（SendGrid、Amazon SES、Postmark、Mailgun等）や自社メールサーバーを `include` で列挙する。受信側は、メールの送信元IPがSPFに含まれているかを検証する。

移管でこのTXTレコードが消えると、すべての送信元が「許可されていない」と判定される。また、SPFには「1つのドメインにつきDNSルックアップ10回まで」という制約があり、複数ESPを併用してincludeが増えすぎると上限超過でSPF全体が無効化される。移管時にはSPFレコードの内容だけでなく、ルックアップ回数の上限にも注意が必要だ。

2-2. DKIM ── 「署名鍵」というドメインとESPにまたがる資産

DKIM（DomainKeys Identified Mail）は、送信メールに電子署名を付け、受信側が公開鍵で検証する仕組みだ。公開鍵はDNSのTXTレコード（セレクタ._domainkey.ドメイン）に置かれ、秘密鍵は送信基盤（ESP）側に保持される。つまりDKIMは、DNSとESPの両方にまたがって初めて成立する。

移管でDNS側の公開鍵レコードが消えれば署名検証が失敗する。逆に、ESPアカウントを移管・変更すればセレクタと鍵が変わり、DNS側も更新が必要になる。DKIMは「DNSだけ」「ESPだけ」のどちらか一方の移管では必ず壊れる、最も連動性の高い設定だ。セレクタの一覧と、どのESPがどのセレクタを使っているかを正確に棚卸しする必要がある。

2-3. DMARC ── 「認証失敗時にどうするか」のポリシー

DMARC（Domain-based Message Authentication, Reporting and Conformance）は、SPF/DKIMの認証が失敗したメールをどう扱うか（none=何もしない / quarantine=隔離 / reject=拒否）を宣言し、認証結果のレポートを受け取る仕組みだ。`p=reject` を設定しているドメインで、移管後にSPF/DKIMが揃わない（アラインメントが取れない）と、自社の正規メールが自社のDMARCポリシーによって受信拒否される。

これは特に皮肉な事故だ。セキュリティを高めるために `p=reject` を設定していた事業ほど、移管時の認証崩壊で自らのメールを締め出してしまう。移管時は、DMARCポリシーを一時的に緩める（p=none/quarantineにする）か、SPF/DKIMのアラインメントを完全に揃えてから切り替える、という順序設計が不可欠だ。

3. ESPアカウントとレピュテーションの引き継ぎ

3-1. ESPアカウントの名義と送信IPの移管

メール送信を担うESPのアカウントが、旧オーナーの名義のままだと、課金・設定・送信ドメイン設定がすべて旧オーナーに紐づく。ESPアカウントを移管または新規契約する場合、DKIMセレクタの再設定、送信ドメインの再認証、SPFのinclude更新が連動して発生する。

専用IP（dedicated IP）で送信している事業の場合、IPのレピュテーションは時間をかけて積み上げたものだ。ESPを変えて新しいIPになれば、レピュテーションはゼロからのウォームアップが必要になり、その間は到達性が一時的に低下する。ESP移管は「アカウントを移す」だけでなく、「積み上げたレピュテーション資産をどう引き継ぐか」という問題を含む。

3-2. デリバラビリティ指標という見えない資産

送信ドメインとIPのレピュテーション、過去の到達率・苦情率・バウンス率は、財務諸表に載らないが事業の到達性を支える資産だ。これらが良好な事業は、メールがインボックスに届く確率が高く、コンバージョンとリテンションを支えている。レピュテーションが毀損された状態では、同じメールを送っても届かない。

DDでは、ESPのダッシュボードから過去のデリバラビリティ指標（到達率、開封率の前提となるインボックス配置率、スパム苦情率、バウンス率）を取得し、ドメインのレピュテーションが健全かを確認する。レピュテーションが既に毀損されている事業は、メールチャネルの実効性が見かけより低く、これもバリュエーションの論点になる。

4. 棚卸しと移行の実務手順

4-1. 全送信ドメイン・サブドメインの認証レコード棚卸し

棚卸しの第一歩は、メール送信に使っている全ドメイン・サブドメインの洗い出しだ。メインドメインだけでなく、トランザクションメール用サブドメイン（mail.example.com等）、マーケティング用サブドメイン、督促用など、用途別にサブドメインを分けている事業は多い。それぞれにSPF・DKIM・DMARCが設定されている。

各ドメインについて、現行のSPFレコード（includeの一覧）、DKIMセレクタと公開鍵、DMARCポリシーとレポート送信先を取得し、台帳化する。用途別サブドメインの一つでも認証設定を取りこぼすと、その用途のメールだけが移管後に全滅する。

4-2. 移行の順序設計 ── 「届くことを確認してから切り替える」

移行時は、新環境からのメールがSPF/DKIM/DMARCすべてをパスし、主要プロバイダー（Gmail、Microsoft 365等）のインボックスに届くことを、本番切り替え前にテスト送信で確認する。DMARCポリシーが厳格な場合は、一時的にp=noneやquarantineに緩め、認証が安定してから元に戻す。

切り替え後はDMARCの集約レポート（RUA）を監視し、認証失敗が発生していないかを継続確認する。「送信処理が成功した」ことと「受信箱に届いた」ことは全く別であり、後者を検証せずに移行を完了とみなしてはならない。検証手順を移行計画に明記し、クロージング後の表明保証事項に含めることが望ましい。

5. バリュエーションとチェックリスト

5-1. メールチャネル依存度と認証の堅牢性を評価する

バリュエーションでは、事業がメールチャネルにどれだけ依存しているかと、その認証基盤がどれだけ堅牢かを評価する。トランザクションメールがサービス利用の中核を成し、かつ認証設定が文書化され、DMARCがreject運用で安定し、レピュテーションが健全な事業は、メール基盤が資産として機能している。

逆に、メール依存度が高いのに認証が場当たり的で、誰がESPを管理しているかも不明で、DMARCがnoneのまま放置されている事業は、移管時の崩壊リスクとなりすまし被害リスクの両方を抱えている。メール認証の堅牢性は、事業の到達性とセキュリティの両面を映す指標であり、技術DDの評価項目に含めるべきだ。

5-2. 買い手・売り手のチェックリスト

買い手は、①全送信ドメイン/サブドメインのSPF・DKIM・DMARC設定、②ESPアカウントの名義と利用状況、③DKIMセレクタとESPの対応関係、④DMARCポリシーと集約レポートの運用状況、⑤デリバラビリティ指標とレピュテーション、⑥移行時の認証維持計画、を確認する。

売り手は、認証レコードを台帳化し、DMARCをreject運用で安定させ、ESPアカウントを法人名義で整理し、デリバラビリティ指標を開示できる状態にしておく。「メールが確実に届く事業」であることを実証できる売り手は、買い手の到達性に対する不安を解消し、メールチャネルを資産として評価させられる。メール認証の棚卸しは、見えない顧客連絡網を可視化する作業だ。

結論：メールは「送れた」ではなく「届いた」で初めて価値を持つ

送信ログの「送信完了」は、メールが受信箱に届いたことを意味しない。SPF・DKIM・DMARCという見えない三層の認証が揃って初めて、メールは顧客の目に触れる。これらの設定はDNSとESPに分散し、財務諸表にもシステム構成図にも現れないが、崩壊した瞬間にパスワードリセットを止め、請求書を迷惑メールに沈め、督促を解約に変え、ドメインの信頼資産を蝕む。

M&Aにおけるメール認証の棚卸しは、事業と顧客をつなぐ見えない連絡網を可視化し、確実に引き継ぐ作業だ。売り手にとっては認証の堅牢性が事業価値を守り、買い手にとっては移管時の崩壊リスクを見極める論点になる。技術的DDの本質は、こうした「送れているように見えて届いていない」領域を検証可能な手順に翻訳することにある。メール認証は、最も地味で最も顧客に近い、その最前線だ。