メールが無言で消える恐怖。SPFレコードのせいやった説
メールが無言で消える恐怖。SPFレコードのせいやった説
発端：送ったはずのメールが届いてない
ある日、仕事関係のメールを送ったんよ。Gmailのアプリから、自社ドメイン（@example-corp.co.jp）のアカウントで。SMTPサーバーもポートもちゃんと設定してある。いつも通り。
「送信しました」って出た。よし。
...数日後。
「あのメール届いてないんですけど」
は？
送信済みフォルダ見た。ある。確かに送った。
Returned Mailは？来てない。エラーも何もない。
送ったつもりのメールが、無言で消えてる。
これ、いつからや？多分去年の11月くらいから？でも正直わからん。だってエラー出ないから。送ったつもりのメールが何通消えたのか、誰に届いてないのか、全く把握できない。
郵便事故は起きてるのに、調査するのは人間。気づいた時にはもう遅い。
こわない？
とりあえず調べてみた
「Gmail 送信 届かない」とかでググってみたら、どうもSPFとかいう認証の話が出てきた。
SPFって何？
調べたところ、こういうことらしい。
メールって、送信元ドメインのDNSに「うちからメールを送る可能性のあるサーバーはこれです」というホワイトリストを登録しておく仕組みがある。これがSPF（Sender Policy Framework）。
メールサーバーはこれを照合して、リストにないサーバーから来たメールは「怪しい」と判定する。
最近GmailやOutlookがこのチェックを厳しくしていて、設定が合っていないと迷惑メール扱いされたり、エラーも返さず無言で破棄されたりするケースが増えているらしい。
無言で破棄て。こわ。
現状を確認してみる
SPFレコードはDNSのTXTレコードに書いてある。以下のコマンドで確認できる。
nslookup -type=txt example-corp.co.jp
結果：
v=spf1 ip4:198.51.100.10 include:spf.mailservice.example.jp ~all
ふむ。ip4:198.51.100.10 が許可されてるIPアドレスらしい。
じゃあ実際にメール送ってるサーバーのIPは？
nslookup mail.example-corp.co.jp
結果：198.51.100.20
あれ、違うやん。
SPFには 198.51.100.10 って書いてあるのに、実際のサーバーは 198.51.100.20。
これが原因か...！
SPF認証の流れを理解する
ここでちょっと整理。受信側のメールサーバーは何をやってるのか。
-
user@example-corp.co.jpからメールが来た。接続元IPは198.51.100.20 - 「
example-corp.co.jpのSPFレコードどうなってる？」とDNSに問い合わせ - 「
ip4:198.51.100.10だけ許可」と返ってくる - 実際に来たのは
198.51.100.20→ 「許可リストにないな、怪しい」
こうやって弾かれてたわけや。
なんでエラー返してくれないの？
これ、めっちゃ思うやん。「弾いたなら言えや」と。
でも理由があるらしい。
1. スパマーに情報を与えたくない
「SPF失敗で弾いた」って返すと、スパマーに「ここはSPFチェックしてるな、じゃあ回避策考えよう」ってヒントを与えてしまう。
2. バックスキャッター問題
なりすましメールにエラー返すと、なりすまされた側にエラーメールが届く。スパマーが user@example-corp.co.jp を騙って大量送信したら、全然関係ない人に大量のエラーメールが届くことになる。それ自体が迷惑メールになっちゃう。
3. 単純にコスト
GmailやOutlookは毎日何億通も処理してる。いちいちエラーメール生成して返送するのも負荷になる。
結果として「無言で消える」が一番楽、ということになってしまってる。送る側からすると迷惑な話やけど。
誰が判断してるかもわからん
さらに厄介なのは、どこで弾かれたかもわからんこと。
- 送信側のSMTPサーバーが送信前に弾いたのか
- 途中の中継サーバーが落としたのか
- 受信側のSMTPサーバーが拒否したのか
- 受信側のスパムフィルターが迷惑メール行きにしたのか
- 受信側がサイレントに破棄したのか
全部ブラックボックス。ログも見れないし、エラーも返ってこない。
「送りました」「届いてません」「え？」ってなって、どこで消えたかも誰が判断したかもわからない。メールの闇。
対策：SPFレコードを直す
原因がわかったので、対策。DNSのTXTレコードを修正する。
修正前
v=spf1 ip4:198.51.100.10 include:spf.mailservice.example.jp ~all
修正後
v=spf1 a:mail.example-corp.co.jp include:spf.mailservice.example.jp ~all
何が変わった？
ip4:198.51.100.10 を a:mail.example-corp.co.jp に変えた。
これ、IPアドレスを直接書くんじゃなくて、ホスト名で指定してる。受信側は mail.example-corp.co.jp のIPアドレスをDNSで引いてきて照合する。
メリットは、将来サーバーのIPが変わっても自動で追従してくれること。IPベタ書きだと、サーバー移転とかでIP変わるたびにSPFも直さなあかん。忘れたらまた同じ問題が起きる。
SPFの書き方まとめ
ついでに調べたので、SPFレコードの書き方をまとめとく。
| 記法 | 意味 |
|---|---|
ip4:xxx.xxx.xxx.xxx |
そのIPv4アドレスを許可 |
ip6:xxxx:xxxx:... |
そのIPv6アドレスを許可 |
a:ホスト名 |
そのホスト名のIPアドレスを許可（DNS引いてくる） |
include:ドメイン |
そのドメインのSPF設定を丸ごと参照（外部サービス使う時に便利） |
~all |
上記以外は怪しいとマーク（ソフトフェイル：最終判断は受信側に任せる） |
-all |
上記以外は拒否してOK（ハードフェイル） |
複数のメールサーバーがある場合は、スペース区切りで並べればOK。
v=spf1 a:mail1.example.jp a:mail2.example.jp include:spf.external.jp ~all
ちなみに：ウェブメールとSPFは別の話
うちはHordeっていうウェブメールを使ってるんやけど、「Hordeで設定するのかな？」と最初思った。
でも違った。Hordeはウェブメールの画面部分（フロントエンド）であって、SPFはその裏で動いてるSMTPサーバーのIPをDNSに登録する話。設定するのはDNS（ドメインのプロバイダ）の方。
まとめ
- メールが無言で消えるのは、SPFレコードと実サーバーのIPが一致してない可能性がある
-
nslookup -type=txt ドメイン名でSPFレコードを確認できる - IPベタ書きより
a:ホスト名で指定した方が、IP変更に追従できて楽 - エラーが返ってこないのはスパム対策の都合。送る側からすると迷惑やけど仕方ない
- いつから壊れてたかわからない、何通消えたかわからない、これが一番怖い
メールって枯れた技術やと思ってたけど、認証周りは最近どんどん厳しくなってるらしい。SPF以外にもDKIMとかDMARCとかあるみたいやけど、それはまた別の話。
とりあえず、送ったはずのメールが届いてないという謎現象に遭遇したら、SPFを疑ってみてもええかもしれん。
Discussion