最初に確定させる三つの軸
調査を始める前に症状の範囲を確定する。ここを飛ばすと関係のない設定を触ることになる。確認するのは宛先の範囲、エラーの有無、発生時期の三つ。
宛先の範囲は「全宛先で届かない」のか「特定ドメイン宛だけ届かない」のかを分ける。全宛先で失敗するなら自社側のDNSや送信サーバの問題が濃い。特定ドメイン宛だけなら、その受信側のフィルタ判定や送信元IPの評価を疑う。エラーの有無では、送信者にバウンスメール(配信不能通知)が返るのか、無音のまま相手の迷惑メールフォルダに入るのかを区別する。バウンスが返るなら次章、無音ならヘッダ確認の章から始める。発生時期は「いつから」に加えて「直前に何を変えたか」を必ず聞く。DNSの移管、メールサーバの移行、新しいSaaSの導入、ドメイン登録情報の更新が引き金になっている例は多い。
バウンスメールのステータスコードを読む
バウンスメールには、受信側サーバが返した応答がそのまま含まれている。本文の日本語説明ではなく、Diagnostic-Code 行と Status 行を見る。
先頭が5で始まるコードは恒久エラーで、再送しても結果は変わらない。4で始まるコードは一時エラーで、送信サーバは自動で再試行する。代表的なものを挙げると、5.1.1 は宛先アドレスが存在しない、5.7.1 は受信側のポリシーによる拒否、5.2.2 は相手のメールボックス容量超過、4.7.0 系はレート制限やグレイリスティングによる一時的な拒否を意味する。Gmail宛では、送信ドメイン認証が要件を満たさない場合に 5.7.26 を伴うメッセージが返る。
ここで分岐する。5.1.1 や 5.2.2 なら原因は相手側のアドレスやメールボックスにあり、自社のドメイン設定は無関係なので調査を打ち切ってよい。5.7.x が返っているなら送信ドメイン認証かレピュテーションの問題なので次章へ進む。4.x.x が数時間続いて最終的に失敗するなら、短時間の大量送信や同時接続数を疑い、あわせてブロックリストの章も確認する。バウンス自体が一切返らない場合は受信はされている。判定の問題なので、次章のヘッダ確認が出発点になる。
受信側のヘッダで SPF・DKIM・DMARC の判定を見る
自分が管理する外部のメールアドレス(自社ドメインとは別のフリーメールなど)に、実際の業務メールと同じ経路でテスト送信する。届いたメールでソース表示の機能を開き、Authentication-Results ヘッダを探す。受信側が下した判定がここに記録されている。
三つの仕組みを短く説明する。SPFは「そのIPアドレスからこのドメインのメールを送ってよいか」をDNSで宣言する仕組み。DKIMは送信時に電子署名を付け、受信側が公開鍵で検証する仕組み。DMARCはSPFとDKIMの結果を受けて、認証に失敗したメールをどう扱うかをドメイン所有者が指示する仕組みで、レポートの受け取りも指定できる。
判定の読み方はこうなる。spf=pass かつ dkim=pass かつ dmarc=pass なら認証は問題ない。迷惑メール判定の原因は本文の内容、送信頻度、IPの評価など別の要素にある。ブロックリストの章へ進む。spf=fail または softfail なら送信元IPがSPFレコードに含まれていない。dkim=none なら署名そのものが付いていない。いずれも次章のDNS確認へ進む。
見落としやすいのがDMARCのアライメントだ。SPFは封筒の差出人にあたる Return-Path のドメインを検証するが、受信者が画面で見るのは From ヘッダのドメインで、この二つは別物になり得る。メール配信SaaS経由では Return-Path がSaaS側のドメインになることが多く、その場合はSPFが pass でもDMARCは fail になる。spf=pass なのに dmarc=fail と出ていたら、この不一致を疑う。対処はSaaS側でカスタムのReturn-Pathドメインを設定するか、自社ドメインでDKIM署名を行うかのどちらかになる。
自ドメインのDNSレコードを確認する
権威DNSに問い合わせて、実際に公開されている値を確認する。管理画面の表示ではなく、外から見える値を見ることが重要になる。
dig +short TXT example.jp
dig +short TXT selector1._domainkey.example.jp
dig +short TXT _dmarc.example.jp
dig +short MX example.jpSPFで頻出する不具合は三つある。第一に、v=spf1 で始まるTXTレコードが二つ以上あると仕様上の違反となり、受信側は検証に失敗する。ドメイン全体で一つにまとめる。第二に、include の入れ子で発生するDNS参照回数が10回を超えると同じく失敗する。使っていないSaaSの include を消して回数を減らす。第三に、末尾を ?all や +all にしていると事実上どのIPも許可することになり、SPFが機能しない。運用が固まるまでは ~all、確信が持てたら -all を使う。
DKIMはセレクタ名を間違えると何も返らない。実際に送ったメールの DKIM-Signature ヘッダにある s= の値がセレクタなので、それを使って引く。DMARCは _dmarc のホスト名に v=DMARC1; p=none; rua=mailto:[email protected] のような形で置く。まだ設定していなければ、まずこの p=none の状態で置いてレポートを集める段階から始める。
あわせて送信元IPの逆引き(PTRレコード)も確認する。逆引きが設定されていない、あるいはSMTPのHELO/EHLOで名乗るホスト名と食い違っている場合、それだけで拒否する受信サーバがある。逆引きは自社ではなく回線事業者やクラウド事業者側で設定するため、依頼が必要になることが多い。
ここで修正した場合は、DNSのTTLが切れるまで結果が変わらない。数分から数時間待ってから再度テスト送信し、Authentication-Results が変わったかを見る。改善しないならレピュテーションの問題が残っている。
IPレピュテーションとブロックリストを確認する
認証がすべて pass でも、送信元IPやドメインの評価が低ければ迷惑メールフォルダに入る。まず主要な事業者が提供する送信者向けの管理ツールを見る。GoogleはPostmaster Toolsで自ドメインの迷惑メール報告率や認証成功率を、MicrosoftはSNDSでIP単位の状況を公開している。いずれも事前にドメインやIPの所有確認が必要なので、障害が起きる前に登録しておくと調査が速くなる。ブロックリストへの掲載はSpamhausなどの照会ページで確認できる。
掲載されていた場合、解除申請の前に原因を止める。よくある原因は、社内端末のマルウェア感染による大量送信、乗っ取られたメールアカウントからの送信、Webフォームやお問い合わせ機能を踏み台にした転送、認証設定の不備によるオープンリレーだ。原因を残したまま解除しても再掲載される。共有IPのメール配信SaaSを使っている場合、他の利用者の送信品質に影響を受けることがある。この場合は自社で対処できないため、SaaS事業者への問い合わせか専用IPへの切り替えを検討する。
執筆時点では、GmailとYahoo!が一定量以上を送る送信者に対して送信ドメイン認証、ワンクリックでの配信停止、迷惑メール報告率の上限といった要件を課している。要件は改定されるため、Gmailのメール送信者のガイドラインなど各社の公式ページで最新の内容を確認してほしい。
見落とされがちな送信経路を棚卸しする
ここまでで直らない場合、調べていた経路と実際に問題が起きている経路が違う可能性が高い。組織のメールは一つのサーバからだけ出ているとは限らない。
洗い出す対象は、通常のメールサーバやMicrosoft 365・Google Workspaceのようなグループウェア、請求書や通知を送る業務システム、メール配信SaaSやマーケティングツール、CRM、スキャンした書類を送る複合機、サーバの監視ツールやCI、Webサイトのお問い合わせフォームだ。これらのうち、自社ドメインを From に使っているものすべてがSPFレコードとDKIM署名の対象になる。
典型的な症状の出方はこうだ。日常のやり取りは問題ないのに、システムからの自動通知だけが届かない。この場合、そのシステムの送信元IPがSPFに入っていないか、DKIM署名が設定されていない。SaaS側の管理画面には送信ドメイン認証の設定項目があり、指定されたCNAMEやTXTレコードを自社DNSに追加する手順になっていることが多い。DMARCの集計レポート(rua)を受け取っていれば、どのIPが自社ドメインを名乗って送信し、認証に失敗しているかが一覧で分かる。棚卸しの精度はレポートを見るのが最も高い。
それでも直らないときの二つの手
受信側の管理者に問い合わせる場合は、相手が調査できる情報をそろえて渡す。必要なのは、送信した日時(タイムゾーンを明記)、送信元と宛先のアドレス、Message-ID、送信元IPアドレス、バウンスメールがあればその全文、そして受信側のログに残っている拒否理由だ。「メールが届きません」だけでは受信側も探せない。自社のメールが誤判定されていると伝えたうえで、判定理由の確認と、必要なら許可リストへの登録を依頼する。
もう一つは送信ドメイン認証の段階的な導入だ。DMARCをいきなり p=reject にすると、設定漏れのある正規メールまで確実に消える。p=none でレポートを収集し、自社ドメインを使うすべての経路が認証を通ることを確認してから、p=quarantine に上げ、pct で適用割合を段階的に増やし、最後に p=reject へ移す。経路の数にもよるが、数週間から数か月をかけて進める作業になる。
次に着手する順番
いま何をすべきかは、テスト送信の Authentication-Results がどう出たかで決まる。dkim=none ならDKIM署名の設定が最優先で、これは受信側の判定に最も効き、転送されても壊れない。spf=fail なら送信経路の棚卸しとSPFレコードの修正が先。すべて pass なのに迷惑メールに入るなら、設定ではなく送信内容と送信頻度、そしてIPの評価が問題なので、Postmaster ToolsやSNDSへの登録から始める。
そして、DMARCを p=none で置いてレポートを受け取る設定だけは、今困っていなくても先に済ませておく。次に同じ症状が出たとき、切り分けにかかる時間が大きく変わる。国内の技術動向はJPAAWG、法令面は総務省の迷惑メール対策のページが一次情報にあたる。