2026年10月9日

2026年10月9日

メールの配信失敗(バウンス)の対処方法:エラーコードの読み方と原因別の直し方

メールが相手に届かず「Undelivered Mail Returned to Sender」などの通知(バウンスメール)が戻ってきたら、まず通知の中のステータスコードを読むのが近道です。この記事では、バウンスメールのどこを見れば原因がわかるか、よくある原因を起こりやすい順に並べて、それぞれの確認方法と直し方を説明します。WordPress からの通知メールが戻ってくる場合の設定もあわせて扱います。

バウンスメールのどこを見るか

バウンスメールには、人間向けの説明文のほかに、機械向けの配送状況通知(DSN)が添付されています。見るべき項目は次の3つです。

  • Status: 5.1.1 のような3つの数字。先頭が 5 なら恒久的な失敗(ハードバウンス)、4 なら一時的な失敗(ソフトバウンス)です。
  • Diagnostic-Code: 相手のサーバーが返したエラー文。550 5.7.26 ... のように、SMTP の応答コードと理由が書かれています。原因を特定する手がかりの大半はここにあります。
  • Remote-MTA / Reporting-MTA: どのサーバーで止まったか。自分のサーバーで止まったのか、相手のサーバーに拒否されたのかを切り分けられます。

ハードバウンスは同じ内容で再送しても届きません。ソフトバウンスは送信側のサーバーがしばらく再試行するため、一定時間で解消することもありますが、何日も続くなら原因を探す必要があります。

原因と対処(起こりやすい順)

1. 宛先アドレスが存在しない(5.1.1 など)

550 5.1.1 User unknown や No such user は、宛先のつづり間違いか、相手がアドレスを廃止したケースです。もっとも多い原因です。

  • 確認: 宛先のドメイン部分とユーザー部分に誤字がないか。ドメイン自体がない場合は Host or domain name not found になります。
  • 対処: 正しいアドレスに直して送り直します。会員サイトやメルマガでは、ハードバウンスしたアドレスに送り続けると送信元の評価が下がるため、配信リストから外す運用にします。

2. 送信ドメイン認証の不備(5.7.26、5.7.1 など)

Gmail などは、SPF・DKIM・DMARC による送信ドメイン認証が通らないメールを拒否したり迷惑メールに振り分けたりします。2024年から Google と Yahoo は送信者向けの要件を強化しており、大量に送る送信者には DMARC の設定やワンクリック登録解除への対応も求めています(2026年10月現在)。最新の条件は各社の送信者ガイドラインで確認してください。

  • 確認: 自分宛て(Gmail など)にテストメールを送り、ヘッダーの Authentication-Results で spf=pass、dkim=pass、dmarc=pass になっているかを見ます。DNS の TXT レコードは次のように確認できます。
dig +short TXT example.com
dig +short TXT _dmarc.example.com
  • 対処: 送信に使っているサーバーや外部の配信サービスを SPF レコードに含め、DKIM 署名を有効にします。WordPress がレンタルサーバーの送信機能と外部 SMTP の両方からメールを出していて、片方だけが SPF に載っていない、という食い違いがよくあります。

3. 相手のメールボックスが満杯(5.2.2 / 4.2.2)

Mailbox full や quota exceeded は相手側の問題です。送信側でできることは少なく、時間を置いて再送するか、別の連絡手段を使います。何度も続くアドレスはリストから外す判断をします。

4. 送信元IPがブロックリストに載っている(5.7.1 など)

エラー文にブロックリストの名前や URL が含まれていれば、送信元 IP の評価が原因です。共用のレンタルサーバーでは、同じ IP を使う別の利用者の影響を受けることもあります。

  • 確認: エラー文に書かれたリストの公式サイトで IP を照会します。
  • 対処: 不正送信(乗っ取られたフォームやアカウント)がないかを先に調べ、原因を止めてから解除申請をします。原因が残ったまま解除しても再登録されます。

5. 送信量の制限・一時的な拒否(4.7.0、421 など)

短時間に大量に送ると、相手側から一時的に拒否されます。送信サーバーが再試行するので多くは自然に解消しますが、送信ペースを落とすのが根本的な対処です。

6. メッセージサイズの超過(5.3.4 など)

添付ファイルが相手の上限を超えている場合です。ファイルはダウンロードリンクで共有する形に切り替えます。

自分のサーバーのログで確かめる

自前の Postfix から送っている場合は、メールログで配送結果を追えます。Debian/Ubuntu では /var/log/mail.log、RHEL 系では /var/log/maillog が一般的です。

sudo grep "status=bounced" /var/log/mail.log | tail -n 20

status=bounced の行の dsn= と括弧内の説明が、相手のサーバーの応答です。status=deferred は再試行中で、キューに残っています。同じキューID(行頭の英数字)で検索すると、そのメールの受付から結果までを一続きで追えます。

WordPressから送るメールのバウンス対策

Return-Path(エンベロープ送信者)を整える

バウンスメールは、メールヘッダーの From ではなく、エンベロープ送信者(Return-Path)宛てに返ってきます。WordPress の既定ではサーバー側の値が使われ、www-data@ホスト名 のような誰も読まないアドレスになっていることがあります。その場合、バウンスが起きていても誰も気づけません。

外部 SMTP プラグインを使っているなら、プラグインの設定に Return-Path を From と揃える項目があるか確認してください(項目名や有無はプラグインとバージョンによって異なります)。コードで指定する場合は、子テーマの functions.php か mu-plugin に次のように書きます。

<?php
// wp-content/mu-plugins/mail-return-path.php
add_action( 'phpmailer_init', function ( $phpmailer ) {
    // バウンスを受け取れる、実在するアドレスを指定する
    $phpmailer->Sender = 'bounce@example.com';
} );

指定するアドレスは実際に受信でき、定期的に確認する人がいるものにします。また、このドメインの SPF に送信サーバーが含まれているかもあわせて確認してください。

送信そのものの失敗を記録する

WordPress には、wp_mail() の送信処理が失敗したときに呼ばれる wp_mail_failed アクションがあります。ただし、これは自サーバーから SMTP サーバーへの受け渡しに失敗したときに発火するもので、相手のサーバーから後で返ってくるバウンスは検知できません。両者は別物として扱ってください。

<?php
// wp-content/mu-plugins/mail-failure-log.php
add_action( 'wp_mail_failed', function ( WP_Error $error ) {
    $data    = (array) $error->get_error_data();
    $to      = isset( $data['to'] ) ? (array) $data['to'] : array();
    $domains = array();
    foreach ( $to as $addr ) {
        $at = strrpos( $addr, '@' );
        $domains[] = ( false === $at ) ? '(unknown)' : substr( $addr, $at + 1 );
    }
    // 本文やアドレス全体は記録せず、エラー内容と宛先ドメインだけ残す
    error_log( sprintf(
        '[wp_mail_failed] %s / to domains: %s',
        $error->get_error_message(),
        implode( ',', $domains )
    ) );
} );

ログにメール本文や宛先アドレスをそのまま残すと、個人情報をログファイルに溜め込むことになります。調査に必要な範囲だけを記録し、ログの保存期間も決めておくと安全です。

配信サービスのバウンス管理を使う

会員向けの一斉配信やメルマガでは、Amazon SES や SendGrid などの配信サービスが持つバウンス・苦情の通知機能や、配信停止リスト(サプレッションリスト)を使うと、ハードバウンスしたアドレスへの再送を自動で止められます。機能の名前や設定方法はサービスごとに異なるため、各サービスの公式ドキュメントに沿って設定してください。

まとめ

  • バウンスメールは Status の先頭の数字(5 は恒久、4 は一時)と Diagnostic-Code を最初に読む。
  • 多い原因は、宛先の誤り、送信ドメイン認証の不備、相手の容量超過、IP の評価、送信量制限の順。
  • 自前サーバーならメールログの status=bounced とキューIDで配送の流れを追う。
  • WordPress では Return-Path を受信可能なアドレスに揃え、wp_mail_failed は送信処理の失敗だけを拾うものと理解して使う。
  • ハードバウンスしたアドレスは配信リストから外し、送信元の評価を守る。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲