SPF、DKIM、DMARCが機能しなくなった？原因の見つけ方

2年間問題なく通っていた認証が、ある火曜日に、エラーメッセージもなく、心当たりのある変更もないまま失敗することがあります。メールはサーバーから出ていきますが、迷惑メールフォルダーに入るか、まだ開いていないレポートの中でDMARCの失敗として記録されるか、あるいはまったく届きません。このガイドでは、動いていたSPF、DKIM、DMARCが壊れる主な原因、いくつかのDNSルックアップで数分のうちに原因を突き止める方法、そして次の退行（リグレッション）をバウンス率より先に知る方法を説明します。

結論#

動いていた認証が失敗し始めたら、DNSの何かが変わったか、送信元の何かが変わったかのどちらかです。次の順に確認してください。DNSホストやネームサーバーを最近変更したか、SPFレコードはちょうど1つか、失敗したメールのDKIMセレクターはいまも鍵を返すか、_dmarcにあるDMARCレコードはちょうど1つか、新しい送信ツールがあなたのドメインを名乗って送信し始めていないか。 この5つの問いで、ほとんどの退行は説明できます。まず、失敗したメールのAuthentication-Resultsヘッダーを読んでください。SPF、DKIM、DMARCのどれが、どのドメインについて失敗したのかがわかります。メールヘッダー解析でそれらの判定を確認でき、SPF、DKIM、DMARCチェッカーでは、いまDNSがどう答えているかを確認できます。

まず失敗したメールを読む#

どのプロトコルが壊れたのかを推測してはいけません。失敗したメールの完全なヘッダーを開き、受信サーバーが追加したAuthentication-Resultsの行を探してください。

Authentication-Results: mx.receiver.example;
  spf=fail smtp.mailfrom=bounce.example.com;
  dkim=fail header.d=example.com header.s=mail;
  dmarc=fail header.from=example.com

重要な点は3つです。spf=とdkim=は、どのチェックが失敗したかを示します。header.sは使われたDKIMセレクターで、問い合わせるべきDNS名が正確にわかります。そしてsmtp.mailfromやheader.dは、各チェックが評価したドメインを示します。Fromヘッダーのドメインとは別のドメインについてSPFが通っている場合に、これが重要になります。

次に、コマンドラインからレコードを問い合わせます。macOSとLinuxで使えます。

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com

mailは、ヘッダーのセレクターに置き換えてください。わからない場合は、DKIMセレクターの見つけ方で手順を説明しています。問い合わせても何も返ってこなければ、レコードはなくなっています。何か返ってきた場合は、注意して読んでください。レコードが存在していても壊れていることがあり、それについては次のセクションで説明します。

原因1：DNS移行でレコードが欠落または破損した#

新しいDNSホスト、新しいレジストラ、新しいウェブサイトプラットフォームへの移行は、最もよくあるきっかけです。インポートツールは、理解できるもの（通常はA、CNAME、MXレコード）をコピーし、TXTレコードは黙ってスキップしたり書き換えたりします。症状は、SPFがない、DMARCがない、あるいはDKIMセレクターが名前解決できなくなるといったもので、すべて移行した日から始まります。

移行のたびに、次の3点を確認してください。ネームサーバーが想定どおりの場所を指していること、すべての認証レコードが新しいホストにあること、そして長いTXT値が欠けずに移っていることです。壊れやすいのは長いDKIMキーで、ホストによっては途中で切り詰めたり余分なスペースを加えたりします。切れた鍵は、レコードが「存在」していても検証に失敗します（長い鍵を分割する理由）。ホストごとの扱いは、CloudflareとRoute 53のプロバイダー別ガイドで紹介しています。メール側から見た同じ落とし穴は、メールプロバイダーの切り替えで説明しています。

原因2：SPFレコードまたはDMARCレコードが2つある#

ドメインが公開できるSPFレコードは1つだけ、DMARCレコードも1つだけです。新しいツールのセットアップ画面に「このTXTレコードを追加してください」とあり、最初のレコードを編集する代わりに、2つ目のv=spf1のエントリを追加してしまうと、静かに壊れます。

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

このように2つのレコードがあると、受信側はSPFに対して恒久的なエラーを返し、記載されているツールからのメールも含め、すべてのメールでSPFが失敗します。解決策は、両方のincludeを~allの前に置いた1つのレコードに統合することです。同じルールが_dmarcにも当てはまり、DMARCレコードが2つあると、受信側は両方を無視します。統合するときは、ルックアップの予算にも注意してください。include:を追加するたびにDNSルックアップを消費し、上限は10回です。数え方は、SPFのDNSルックアップが多すぎる場合で説明しています。

原因3：DKIMキーがローテーション、移動、または削除された#

DKIMは、秘密鍵で各メールに署名し、公開鍵をselector._domainkey.yourdomain.comに公開します。送信元がそのセレクターで署名しているのに、DNSレコードが消えると、すべてのメールがDKIMで失敗します。

起こり方はいくつかあります。プロバイダーが新しいセレクターに切り替えたとき、古いレコードを早く片付けすぎた。誰かが、DNSの整理中に「使っていない」_domainkeyのエントリを削除した。プロバイダーが管理する鍵を指すCNAMEが、プロバイダーによる変更やサービスの解約で名前解決できなくなった。あるいは、鍵が失効された場合で、これは空のp=の値として公開されます。

確認方法は簡単です。失敗したメールのheader.sからセレクターを取り出し、selector._domainkey.yourdomain.comを問い合わせて、実際の鍵データを持つp=の値があることを確認します。送信元が新しいセレクターに移ったためにセレクターが違っていたなら、プロバイダーから案内された新しいレコードを公開してください。正しく行うローテーションでは、古い鍵と新しい鍵の期間を重ねます。この点は、セレクターのガイドで説明しています。

原因4：新しい送信元があなたのドメインで送信し始めた#

レコードに問題はなく、送信元のほうが変わったこともあります。チームがCRM、ヘルプデスク、請求ツール、ニュースレタープラットフォームを有効にすると、それぞれがFromアドレスにあなたのドメインを使って送信を始めます。そのサービスをSPFに追加せず、DKIMキーも設定していなければ、そのメールはSPFのアライメントで失敗し、何も通らないこともあり、DMARCレポートに失敗として現れます。

DNSは変わっていないので、DNSを見ても気づけません。実際に誰が送信しているかを見ることで気づきます。それこそがDMARC集計レポートの役割で、成功率の低い新しい送信元が現れるのが、その兆候です。そうした送信元ごとに、きちんと認証する（SPFには適切な場合にincludeを加え、さらに重要なのは、お使いのドメインでのDKIM署名）か、あなたの名義での送信をやめさせてください。

原因5：関連レコードの期限切れや変更#

認証の内側ではなく、その隣で起きる失敗もいくつかあります。

• CNAMEの参照先が変わった。 多くのプロバイダーは、レコードを自社のホスト名に向けるよう求めます。プロバイダーがそれを廃止したり、あなたがCNAMEを削除したりすると、鍵やリターンパスのドメインが名前解決できなくなります。
• MXホストがアドレスを失った。 送信側の認証は完璧でも、MXに指定されたホストにAレコードもAAAAレコードもないため、あなたのドメイン宛てのメールがバウンスし始めます。
• MTA-STSのポリシーとDNSがずれた。 _mta-stsのTXTレコードはまだありますが、HTTPSのポリシーファイルに現在のMXホストが載っていない、あるいはメールサーバーの証明書が期限切れです。enforceモードのポリシーを保持している送信側はメールを延期または拒否し、キャッシュされたポリシーのない送信側は単に平文の配信にフォールバックするため、影響はまだらになります。MTA-STSとTLS-RPTを参照してください。
• DMARCが厳格化された。 誰かがp=noneからquarantineまたはrejectに切り替えました。認証されていないツールや転送メールなど、以前からあった失敗が、今度は配信に影響するようになります。失敗は新しいものではなく、その結果が新しいのです。

次の退行を早期に発見する#

これらのほとんどは、バウンスが1通も出る前に、DNSだけで検出できます。壊れた状態が、レコードの欠落や形式の誤りだからです。例外は、MTA-STSのポリシーファイルのように、DNSレコードの背後にあるものです。緊急度の高い順に、次の点を確認してください。

1. MXがあり、すべてのホストが名前解決できる。
2. SPFレコードがちょうど1つで、構文が有効で、ルックアップが10回以下。
3. 頼りにしているDKIMセレクターのすべてが、p=の値を持つ鍵を返す。
4. DMARCレコードがちょうど1つで、ポリシーが有効で、rua=アドレスがある。

DNSを変更するたびに、これを手作業で実行することができますし、そうすべきです。手作業のチェックの弱点は、気にしている退行が、誰も見ていないときに起こることです。ドメイン診断の監視は、対象のすべてのドメインでこれらのチェックを1日1回繰り返し、問題が発生したときと、解消したときにメールでお知らせします。問題コードは、このリストに対応しています。SPFの欠落または複数公開、SPFのルックアップ上限超過、レコードを公開していないSPFのinclude、鍵のない、または失効した、設定済みのDKIMセレクター、DMARCの欠落または無効、そしてMXの問題です。ハブとなる記事のメールドメイン診断の監視では、より広い全体像と、チェックの頻度を説明しています。

知っておくとよい点が2つあります。監視するDKIMセレクターは、あなたが指定します。欠落したセレクターは、名前を指定したものについてしか報告できないからです。また、DNSのタイムアウトは、アラートではなく「チェックできませんでした」になるので、不安定なリゾルバーのせいで起こされることはありません。

監視では見つけられないもの#

DNSの監視が読み取るのは、公開DNSだけです。新しいCRMがあなたの名義で送信し始めたこと、有効なSPFレコードに送信元が漏れていること、プロバイダーがあなたが登録していない鍵をローテーションしたことは、わかりません。実際に誰があなたの名義で送信しているかはDMARC集計レポートが、実際のメールがどう認証されるかはメール到達性テストが示します。限界の全体は、ドメイン診断の監視ガイドにまとめています。

認証が通っていることは、あなたのメールがあなたのものだという証明であって、リストが送る価値のあるものだという証明ではありません。リスト自体を確認する準備ができたら、無料プランの料金ページにある100クレジットで、フル検証を実行できます。レコードが正しくても、その背後に健全なリストが必要です。