送信した電子メールがなんらかのエラーで戻ってくる事をバウンスと表現します。 下記の図は、送信した電子メールが受信者のメールボックスに配送されるまでの間で バウンスが発生しうる可能性のあるタイミングを示すものです。
バウンスが発生するタイミングは大きく分けて三つ、 1. SMTP接続前と2. SMTPセッション中と 3. 転送時(送信先サーバー以降での)です。これらのいずれかで エラーが発生すると、送信メールのReturn-Path: ヘッダーにあるメールアドレスにバウンスメールが送られてきます。
初出: 2010年12月 bouncehammer.jp/ja/when-does-email-bounce
図の1はSMTP接続以前の段階で発生するエラーです。おおむねバウンス全体の5%前後 が、送信先サーバーに接続できないエラーであり、次のような原因が大半を占めます。
接続エラーで発生する実際のバウンスメールを Sisimaiが解析すると、 一定期間内に配送できずに差し戻されたものは Expired に、 宛先メールアドレスのドメインが存在しない場合は HostUnknown に、 宛先メールアドレスのドメインがNullMXの場合は NotAccept に、 それぞれバウンス理由が決定されます。
SMTP接続以前の段階で発生したエラーによるバウンスメールは、 図の送信サーバーであるsender.example.jpが生成します。
宛先メールアドレスのドメイン部分(@の右側)の権威あるDNSコンテンツサーバに異常がある、 というのが最も多いのですが、 自分のメールサーバが参照しているDNSサーバが機能していない 可能性もあります。 そのような理由で戻ってきたバウンスメールをSisimaiが解析した場合、 バウンス理由はNetworkError になります。
多くは相手側メールサーバがダウンしている、相手側ネットワークのFirewallが SMTP接続を阻んでいる、というケースです。
しかし自分のネットワーク側のFirewallが外部へのSMTP接続を阻んでいる 可能性もあります。接続プロバイダによって行われるOP25B(Outbound Port 25 Blocking)は 自分のネットワーク側が外部へのSMTP接続を制限している為に接続できないケースに該当します。
いずれにせよネットワークの回復まで再試行され、時間切れで差し戻されたものの バウンス理由はSisimaiの解析によって Expired と判定されます。
送信先メールアドレスのドメインが存在しない場合、またはAもMXも設定されていない場合、 Sisimaiはバウンス理由を HostUnknown (Hard Bounce) に決定しますので、なるべく早めに当該メールアドレスを送信者リストから除外してください。 稀な例としては、第三者がそのドメインを取得して全ての宛先メールアドレスを受け取ってしまうように メールサーバーを設定していると、メールマガジン冒頭に書いた購読者の名前とメールアドレスで 意図しない名寄せに加担してしまう危険があります。
図の2は送信先メールサーバにSMTP接続が確立した後のSMTPセッション中に発生するエラーに よってバウンスします。割合はバウンス全体の25%前後です
数年前までは発生するバウンスのほとんどがSMTPセッション中に発生するものでしたが、 2024年2月から段階的に開始されたGmailと米国Yahoo!の送信者向けガイドライン準拠要請によって、 ドメイン認証関連のエラーを筆頭に転送メールが引き起こすバウンスが大半を占めるように なりました。
このケースで発生したバウンスメールをSisimaiが解析すると、 UserUnknown や、 MailboxFull や、 MesgTooBig など 宛先メールアドレスやメールボックスに関連したバウンス理由と判断されます。
また近年では徹底したドメイン認証が求められることによる AuthFailure や、 送信元IPアドレスまたは送信元ドメインの評判(レピュテーションと呼ばれる)に起因した BadReputation に加え、送信元IPアドレスの適切な逆引きを求める RequirePTR や、 メールヘッダーのRFC5322準拠違反があったことを示す NotCompliantRFC といったバウンス理由も増えています。
SMTPセッション中に発生したエラーによるバウンスメールも1. SMTP接続前 と同様に、図の送信サーバーであるsender.example.jpが生成します。
組織のメールアドレス宛に来たメールを、スマートフォンで受信通知を得るために GmailやOutlookなどに転送しているケースは多くあることでしょう。 2024年2月から段階的に開始されたGmailと米国Yahoo!の送信者向けガイドライン準拠要請によって、 転送メールはこれまでよりも多くのバウンスを生む要因となりました。 ここ数年の観測では、転送時のエラーによるバウンスの割合は全体の70%程度にまで上昇 しています。
具体的には、図のmx.example.comで受信したメールを転送する際に、 SPFがHard Failとなったり、転送時にSubject: ヘッダーや本文の部分的な書き換え(これはメーリングリストで起こることが殆ど)によって DKIM署名が検証失敗したりして、ドメイン認証の失敗によるバウンスとなります。
このケースで発生するバウンスメールは、上述の1. SMTP接続前や 2. SMTPセッション中と異なり、mx.example.com が生成し、Return-Path:に書かれたメールアドレスに送られます。
転送時に発生したドメイン認証エラーによるバウンスメールをSisimaiが解析すると バウンス理由は AuthFailure とります。転送元サーバー(mx.example.com)がARCに対応していれば、 転送前の時点で「うちが受信した段階ではSPFもDKIMもDMARCも全てOKでしたよ」という 技術的に検証可能な事実の記録としてARC関連ヘッダーが追加され、転送先も受け取ってくれると 期待できるでしょう。
あるいは、転送元サーバー(mx.example.com)のIPアドレスが 低いレピュテーションであることで接続を拒否された場合、バウンス理由は BadReputation に決定されます。
近年はDMARCやDKIMを筆頭にドメイン認証関係のエラーが目立つようになってきましたが、 転送先メールアドレスが無くなっていることによる UserUnknown や、転送先メールボックスを放置していることによる MailboxFull もまだまだ発生しています。
いずれのバウンス理由にせよ、ある程度の量を配信しているのであれば、メール転送時 にエラーとなる宛先メールアドレスも、配信対象から除外することを検討すべきでしょう。