運用していたメールサーバのメールがいきなりgmailに拒否される事態になりました。調査したところ、意外な盲点でしたが、ここまでたどり着くため調査したことを、備忘として残しています。
Gmailへの配送状況
送信エラーの内容
to=<piteki-test@gmail.com>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30562, relay=gmail-smtp-in.l.google.com. [64.233.189.26], dsn=5.0.0, stat=Service unavailable(Reason:550-5.7.26 This message does not have authentication information or fails to 550-5.7.26 pass authentication checks. To best protect our users from spam, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.26 information. x69-20020a638648000000b0037c9aff9416si5495604pgd.354 - gsmtp)googleのサイトを確認しても明確な解は書いておらず、スパムと認定されないようにいろいろセキュリティレベル上げてねーというような感じ。。。
切り分け
いろいろ確認したけど、意味のない情報は割愛・・・なので結論
Gmailへの配送エラー 原因と対応
はじめに記載しておくと、原因のパターンは複数考えられるため、当記事で解決に至るかどうかは環境次第です。悪しからず。。。
根本原因はSPFにありました。
fromドメインにはSPF(TXTレコード)が登録済で、送信元のメールサーバIP(例：2.2.2.2)はincludeされた中に含まれているのでなりすまし判定にはならない状態と思っていたのが根本的に確認する場所の検討違いだった。
piteki.com. 600 IN TXT "v=spf1 include:hoge1.jp include:hoge2.com ip4:1.1.1.1 ~all"
hoge2.com. 600 IN TXT "v=spf1 ip4:2.2.2.2 ~all"google側がどこまでSPFを確認しているのか不明ですが、別のドメインでSPF登録されていないメールサーバから送信したところ、送信できました。では、何故SPFが問題かというと、
includeしている中身が空になってしまってたから
hoge1.jpが知らない間にレコード引けなくなってしまってたんですね。。。それでエラーになっていたみたいです。該当のinclude部を無くしたら問題無くgmailに届くようになりました。
ということで会社で管理しているSPFは全部見直しですね。。。nslookupやdigで確認するのもいいですが、SPFに問題が無いかを確認するのにはコチラのサイトが便利です。最大文字列数などもチェックしてくれます。
コメント