バウンスメールとは何か？

バウンスメールは受信先から届くとは限らない ― 誰が作り、どこに届くのか

2026年11月3日作成
著者: 竹洞 陽一郎

結論 ― 受信先に拒否されたメールのバウンスメールは、送信側のメールサーバーが作ります

バウンスメールとは、送信したメールが宛先に配送できなかったことを、送信者に知らせる通知メールです。
仕様上の名称は「配送不能通知（non-delivery notification）」で、形式はDSN（Delivery Status Notification、配送状態通知）としてRFC 3464で定められています。
バウンスメールは、受信先のメールサーバーから返ってくるものだと考えられがちです。

しかし、受信先のメールサーバーがSMTPのやり取りの中でメールを拒否した場合、バウンスメールを作っているのは、受信先ではなく送信側のメールサーバーです。
受信先が返すのは、拒否を示すSMTPの応答コードと応答テキストだけで、送信側のメールサーバーがそれを書き写して、送信者に通知します。
受信先がバウンスメールを作るのは、いったんメールを受け入れた後に配送できなかった場合です。

どちらの場合も、通知は、ヘッダーFromのアドレスではなく、SMTPのMAIL FROM（エンベロープ送信者、受信したメールのReturn-Pathヘッダー）のアドレスに届きます。
そのため、メール配信サービスなど、MAIL FROMに他社のドメインを使う送信元から送ったメールのバウンスは、ドメイン所有者の手元には届きません。
配送の失敗に気付くには、バウンスメールだけでは不十分で、DMARCの集計レポートで送信元ごとの認証結果を確認することが欠かせません。

DMARCのポリシーがp=quarantineの場合、不合格になったメールは受信側で隔離や迷惑メールへの振り分けにされ、バウンスメールは届きません。
送信者は、メールが相手の受信箱に入っていないことに気付けません。
だからこそ、MailDataは、DMARCのポリシーをp=rejectまで進めることを勧めています。

1. バウンスメールの定義

要点: 「バウンスメール」は慣用的な呼び方で、仕様上は配送不能通知（non-delivery notification）です。形式はRFC 3464のDSNとして定められています。

バウンスメール（bounce）は、宛先に配送できなかったメールが、送信者に「跳ね返される」ことから付いた呼び方です。
エラーメール、不達メール、NDR（Non-Delivery Report）とも呼ばれます。
SMTPの仕様であるRFC 5321では、「undeliverable mail」notification、non-delivery notificationと書かれています。
RFC 5321自身も、配送不能通知を返すことを「bounced」と表現しています。
（RFC 5321 Section 6.2）

SMTPサーバーが、メールの中継を引き受けた後に、宛先が誤っていることや、その他の理由で配送できないことが分かった場合は、配送不能通知を作成し、送信者に送らなければなりません（MUST）。
通知の形式には、RFC 3461やRFC 3464など、ほかの標準で定められた形式を使うべきです（SHOULD）。
（RFC 5321 Section 3.6.3）
RFC 3464は、配送の結果を知らせるメッセージの形式を、DSN（Delivery Status Notification）として定めています。
（RFC 3464 Section 2）

配送不能通知（non-delivery notification）

配送できなかったことを知らせる通知です。
一般に「バウンスメール」と呼ばれるのは、これです。

DSN（Delivery Status Notification、配送状態通知）

配送の結果を知らせる通知の形式です。
配送できなかった場合だけでなく、配送が遅れている場合や、配送が完了した場合の通知にも使われます。
（RFC 3464 Section 2.3.3）

MAIL FROM（エンベロープ送信者）

SMTPのMAIL FROMコマンドで指定されるアドレスです。
RFC 5321ではreverse-path（逆経路）と呼ばれ、配送不能通知の宛先になります。
受信したメールでは、Return-Pathヘッダーとして記録されます。

ヘッダーFrom

メールソフトに差出人として表示される、メッセージのFromヘッダーのアドレスです。
DMARCが保護の対象にするのは、このドメインです。
配送不能通知は、このアドレスには送られません。

2. バウンスメールを作っているのは誰か ― 2つのタイミング

要点: SMTPのやり取りの中で受信側が拒否した場合は、受信先ではなく送信側のMTA（SMTPクライアント）が通知を作ります。受信側がメールを受け入れた後に配送できなかった場合は、受信側のMTAが通知を作ります。

A. SMTPのやり取りの中で拒否された場合

受信側のSMTPサーバーが、RCPT TOやDATAの後に5yz（恒久的な失敗）の応答コードを返した場合、受信側はそのメールの責任を引き受けていません。
DATAの後に5yzを返したSMTPサーバーは、そのメッセージの配送を試みてはなりません（MUST NOT）。
メッセージの責任は、送信側のSMTPクライアントに残ります。
（RFC 5321 Section 4.2.5）
そのため、配送不能通知を作るのは、送信側のMTAです。
送信側のMTAが、受信側の応答コードと応答テキストを通知に記載して、送信者に返します。

受信先から届いたように見える理由

Aの場合のバウンスメールは、送信側のMTAが作って送信者に届けたものですが、受信先から返ってきたように見えます。
これは、バウンスメールの中に、受信先のMTAの名前と、受信先が返した応答がそのまま書き写されているからです。
4章の例で、どのMTAが何をしたかは、次のように読み取れます。

Reporting-MTA（例：mta.example.com）

バウンスメールを作ったMTAです。
Aの場合は、送信者側のメールサーバーです。

Remote-MTA（例：mx.example.net）

配送を試みた相手、つまり受信先のMTAです。
受信先は、このMTAで拒否の応答を返しただけで、バウンスメールは作っていません。

Diagnostic-Code（例：smtp; 550 5.1.1 ... User unknown）

受信先のMTAが返した応答コードと応答テキストを、Reporting-MTAが書き写したものです。

From（例：MAILER-DAEMON@mta.example.com）

バウンスメールの差出人は、通常、バウンスメールを作ったMTAのアドレスです。
差出人のドメインが自社のメールサーバーやメールサービスのものであれば、バウンスメールを作ったのは送信側です。

受信したバウンスメールのReceivedヘッダーをたどると、送信側のメールサーバーの中で作られ、受信先を経由していないことも確認できます。
ただし、MTAによってはDSN形式を使わず、バウンスメールの差出人や本文の書き方も異なります。

B. 受け入れた後に配送できなかった場合

受信側のSMTPサーバーが、DATAに対して「250 OK」を返した時点で、メッセージの配送または中継の責任を引き受けます。
受け入れた後に配送に失敗した場合、受信側のSMTPサーバーは通知メッセージを作成して送らなければなりません（MUST）。
この通知は、空のreverse-path（<>）で送らなければならず（MUST）、宛先はエンベロープのreturn path（Return-Pathヘッダー）のアドレスでなければなりません（MUST）。
（RFC 5321 Section 6.1）
受け入れた後の配送失敗は、中継先や転送先で拒否された場合や、受け入れた時点では宛先をすべて確認できなかった場合に起こります。

一時的な失敗と遅延通知

一時的な失敗（4yz）の場合、送信側のMTAはメールをキューに入れ、間隔を空けて再送します。
RFC 5321は、再送の間隔を一般に少なくとも30分（SHOULD）、再送をあきらめるまでの時間を一般に少なくとも4〜5日としています。
（RFC 5321 Section 4.5.4.1）
再送をあきらめた時点で、配送不能通知が送信者に返されます。
再送の途中で、配送が遅れていることを知らせる通知（DSNのActionがdelayed）を送るMTAもあります。
遅延通知を送るかどうか、いつ送るかは、MTAの実装と設定によって異なります。

3. バウンスメールが届く宛先 ― MAIL FROMとReturn-Path

要点: バウンスメールは、MAIL FROM（Return-Path）のアドレスに届きます。バウンスメール自体は空のMAIL FROMで送られ、バウンスメールに対するバウンスは送られません。

通知の宛先はMAIL FROMのアドレス

最終配送を行うSMTPサーバーは、MAIL FROMのreverse-pathを、Return-Pathヘッダーとしてメッセージの先頭に記録します。
RFC 5321は、Return-Pathの主な目的を、配送不能などの通知の宛先を指定することだと説明しています。
また、エラーの通知を専用のメールボックスに届けるために、Return-Pathのアドレスが実際の送信者と異なる場合があるとも説明しています。
（RFC 5321 Section 4.4）

メール配信サービスやメーリングリストは、この仕組みを使って、バウンスを自社のシステムで受け取ります。
例えば、ヘッダーFromがinfo@example.comでも、MAIL FROMが配信サービスのドメインのアドレスであれば、バウンスメールは配信サービスに届きます。
宛先ごとに異なるMAIL FROMのアドレスを使い、どの宛先がバウンスしたかを自動で判別する方法も、配信サービスで広く使われています。
この方法はVERP（Variable Envelope Return Path）と呼ばれますが、RFCで定められたものではありません。

バウンスメールは空のMAIL FROMで送られる

配送不能通知などの通知メッセージは、空のreverse-path（MAIL FROM:<>）で送られます。
（RFC 5321 Section 4.5.5）
これは、通知のループを防ぐためです。
空のreverse-pathで送られたメールが配送できなかった場合、SMTPサーバーは通知を送ってはなりません（MUST NOT）。
（RFC 5321 Section 6.1）
自動応答などの仕組みも、空のreverse-pathのメッセージに返信すべきではありません（SHOULD NOT）。
（RFC 5321 Section 4.5.5）

空のMAIL FROMとSPF

MAIL FROMが空の場合、SPFは、ローカル部を「postmaster」、ドメイン部をHELOのドメインとしたアドレスを、MAIL FROMの識別子として評価します。
（RFC 7208 Section 2.4）
DMARCも、MAIL FROMが空の場合のSPFドメインとして、この定義を使います。
（RFC 9989 Section 3.2.4）
バウンスメールを送信するMTAのHELOのドメインにも、SPFレコードを公開しておいてください。

4. バウンスメールの構造と読み方

要点: DSN形式のバウンスメールは、人が読む説明、機械が読む配送状態、元のメッセージの3つの部分でできています。原因の特定には、機械が読む部分のStatusとDiagnostic-Codeを確認します。

DSNの3つの部分

DSNは、最上位のContent-Typeがmultipart/reportで、report-typeパラメーターがdelivery-statusのMIMEメッセージです。
（RFC 3464 Section 2、RFC 6522）

1. 人が読むための説明（text/plainなど）
2. 機械が読むための配送状態（message/delivery-status）
3. 元のメッセージ、またはそのヘッダー部分（返送する場合）

バウンスメールの例

宛先のメールボックスが存在せず、受信側にSMTPのやり取りの中で拒否された場合の、DSNの例です。
このバウンスメールは、送信側のMTA（mta.example.com）が作ったもので、受信側のMTA（mx.example.net）は拒否の応答を返しただけです。
ドメインとホスト名は説明用の例です。

Return-Path: <>
From: Mail Delivery Subsystem <MAILER-DAEMON@mta.example.com>
To: bounce@example.com
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
    boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/plain; charset=us-ascii

This is the mail system at host mta.example.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--BOUNDARY
Content-Type: message/delivery-status

Reporting-MTA: dns; mta.example.com

Final-Recipient: rfc822; nosuchuser@example.net
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.net
Diagnostic-Code: smtp; 550 5.1.1 <nosuchuser@example.net>: Recipient address rejected: User unknown

--BOUNDARY
Content-Type: text/rfc822-headers

(元のメッセージのヘッダー)
--BOUNDARY--

主なフィールドの意味

Final-Recipient

この配送状態が対象とする宛先のアドレスです。
（RFC 3464 Section 2.3.2）

Action

配送の結果です。
failed（配送できなかった）、delayed（まだ配送できていない）、delivered（配送した）、relayed（DSNに対応していない先へ中継した）、expanded（配送後に複数の宛先へ展開した）のいずれかです。
バウンスメールでは、通常failedです。
（RFC 3464 Section 2.3.3）

Status

転送手段に依存しない状態コードで、RFC 3463の拡張ステータスコード（例：5.1.1）が入ります。
（RFC 3464 Section 2.3.4）

Remote-MTA

配送を試みた相手のMTAです。
相手のMTAが関与していない場合は、記載してはなりません（MUST NOT）。
（RFC 3464 Section 2.3.5）

Diagnostic-Code

相手のMTAが実際に返した応答コードと応答テキストです。
Remote-MTAがない場合は、通知を作ったMTA（Reporting-MTA）自身が付けた診断コードです。
（RFC 3464 Section 2.3.6）

原因の特定には、StatusとDiagnostic-Codeを確認してください。
Diagnostic-Codeの応答テキストは受信側の実装によって異なり、拒否の理由が具体的に書かれている場合も、書かれていない場合もあります。
なお、DSN形式ではない独自の形式で通知を返すMTAもあります。

5. ハードバウンスとソフトバウンス

要点: 「ハードバウンス」「ソフトバウンス」は業界の慣用語です。仕様上は、SMTPの応答コードと拡張ステータスコードの先頭の数字が、5なら恒久的な失敗、4なら一時的な失敗を表します。

応答コードの先頭の数字

「ハードバウンス」「ソフトバウンス」は、メール配信の業界で使われている呼び方で、RFCで定義された用語ではありません。
一般に、ハードバウンスは恒久的な失敗、ソフトバウンスは一時的な失敗を指します。
仕様上の区別は、SMTPの応答コード（RFC 5321）と、拡張ステータスコード（RFC 3463）の先頭の数字です。

（RFC 5321 Section 4.2.1、RFC 3463 Section 2）

拡張ステータスコードの読み方

拡張ステータスコードは「クラス.サブジェクト.詳細」の3つの数字でできています。
1つ目の数字（クラス）は成功か失敗か、2つ目（サブジェクト）は問題のおおよその原因、3つ目（詳細）は具体的なエラーの状態を表します。
（RFC 3463 Section 2）
バウンスメールでよく見かけるコードは、次のとおりです。

（RFC 3463 Section 3）
Xには、クラスの数字（4または5）が入ります。
拡張ステータスコードの一覧は、IANAの「Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry」に登録されています。

仕様の区分と実装の応答は一致しないことがあります

RFC 3463は、X.2.2（Mailbox full）を持続的な一時的失敗（4.2.2）として使うべきだとしています。
（RFC 3463 Section 3.3）
しかし、受信側の実装によっては、メールボックスの容量超過を552 5.2.2のように恒久的な失敗として返すことがあります。
バウンスの種類を機械的に判定する場合は、クラスの数字だけでなく、サブジェクトと詳細の数字、Diagnostic-Codeの応答テキストもあわせて確認してください。

6. バックスキャッター ― 偽装された送信元への返送

要点: 受信側が受け入れた後にバウンスを返すと、MAIL FROMを偽装されたメールのバウンスが、無関係な第三者に届きます。これをバックスキャッターと呼びます。

SMTPは、配送不能通知に使うreverse-pathの検証を扱っていません。
（RFC 5321 Section 3.6.2）
そのため、攻撃者がMAIL FROMに他人のアドレスを指定して送ったメールを、受信側が受け入れた後にバウンスすると、そのバウンスメールは、メールを送っていない第三者に届きます。
このような、偽装された送信元に返される配送不能通知を、バックスキャッター（backscatter）と呼びます。

RFC 5321は、悪意のある内容を含むために拒否したメッセージについては、受信側が通知が有用に届くと確信できる場合を除き、拒否の通知を送るべきではない（SHOULD NOT）としています。
（RFC 5321 Section 6.2）
RFC 9989も、DMARCでメッセージを拒否する場合は、DSNを生成するより、SMTPのやり取りの中で拒否するほうが望ましいとしています。
不正なメッセージに対してDSNを生成すると、MAIL FROMのアドレスに迷惑な失敗通知が返されることになるからです。
（RFC 9989 Section 7.2）

バックスキャッターは、受信側の設定の不備による迷惑な副作用であるだけでなく、自社のアドレスを偽装して自社を迷惑メールの送信者に見せかけるジョージョブや、バウンスに迷惑メールの本文を載せて届ける反射型の迷惑メールにも悪用されます。
問い合わせフォームの自動返信も、入力された第三者のアドレスに応答を返すという点で、同じ構造で悪用されます。
悪用の手口、DMARCで防げる被害と防げない被害、対策は、バックスキャッターとは何か？で解説しています。

7. DMARCとバウンスメールの関係

要点: DMARCのp=rejectで拒否されたメールのバウンスは、MAIL FROMのアドレスに届きます。MAIL FROMが配信サービスのドメインの場合、ドメイン所有者はバウンスに気付けません。

p=rejectによる拒否とバウンス

DMARCのポリシーがp=rejectのドメインからのメールがDMARCで不合格になった場合、受信側はSMTPのやり取りの中で拒否することがあります。
RFC 9989は、この拒否の方法として、DATAコマンドに5xyの応答コードを返す「full rejection」を挙げ、その場合はSMTPクライアントが配送失敗の通知を作る責任を負うとしています。
（RFC 9989 Section 7.2）
RFC 9989は、拒否の理由が分かるように、応答テキストに「DMARC」という語を含める例として、次の応答を示しています。

550 5.7.1 Email rejected per DMARC policy for example.com

もう1つの方法として、2xyの応答を返して受け入れたように見せ、メッセージを破棄する「silent discard」も挙げられています。
この場合、バウンスメールは返されません。
どちらの方法をとるかは、受信側の実装と設定によって異なります。
また、RFC 9989は、受信側がp=rejectのポリシーだけを理由にメッセージを拒否してはならない（MUST NOT）としているため、DMARCで不合格になったメールが必ず拒否されるわけではありません。
（RFC 9989 Section 7.4、Section 8）

ドメイン所有者がバウンスに気付けない場合

バウンスメールはMAIL FROMのアドレスに届くため、ヘッダーFromのドメインの所有者に届くとは限りません。
例えば、メール配信サービスからinfo@example.comをヘッダーFromにして送ったメールが、SPFとDKIMのアライメントの不備でDMARCに不合格になり、拒否されたとします。
MAIL FROMが配信サービスのドメインのアドレスであれば、バウンスメールは配信サービスに届き、example.comの管理者には届きません。
これは、RFC 5321の通知の宛先の規定から導かれる帰結です。

このような送信元の不備は、DMARCの集計レポートで、送信元ごとのSPFとDKIMの認証結果とアライメントを確認すると見つけられます。
自分が送ったメールのバウンスを受け取る方法は、8章で解説します。
MAIL FROMを自社ドメインに合わせると、バウンスの受け取り先とSPFのアライメントの両方を自社で管理できます。
設定方法は、メール配信事業者向けReturn-Path一致のやり方と、Amazon SESでSPFのDMARCアライメントを一致させるカスタムMAIL FROMドメインの設定方法で解説しています。

SPFの-allによる早期拒否

受信側がSPFのfailをMAIL FROMの段階で拒否する場合、そのメールはDATAに進まず、DMARCは評価されません。
この場合もバウンスメールはMAIL FROMのアドレスに返されますが、その受信側に拒否されたメールは、DMARCの集計レポートには現れません。
（RFC 9989 Section 7.1）
詳しくは、SPFは-allにすべき理由 ― ~allとの違いとDMARC運用での注意点で解説しています。

8. DMARCで不合格になったメールに気付くために、バウンスを受け取る

要点: 自分が送ったメールが受信側のDMARCで不合格になり、SMTPのやり取りの中で拒否されると、送信側のメールサーバーがバウンスメールを作ります。このバウンスを受け取るには、MAIL FROMを自分で受信できるアドレスにし、送信の経路にバウンスを作るメールサーバーを置く必要があります。ただし、受信側が拒否しない場合はバウンスが発生しないため、DMARCの集計レポートとあわせて使ってください。

バウンスを受け取るための2つの条件

受信側がDMARCの不合格を理由にSMTPのやり取りの中で拒否した場合、バウンスメールを作るのは送信側のメールサーバーです。
（RFC 9989 Section 7.2、RFC 5321 Section 4.2.5）
バウンスメールのDiagnostic-Codeには、受信側が返した応答コードと応答テキストが書き写されるので、DMARCによる拒否かどうかを確認できます。
このバウンスを受け取るには、次の2つの条件を満たす必要があります。

1. MAIL FROM（Return-Path）が、自分で受信して確認できるアドレスになっていること
2. 送信の経路に、拒否の応答を受け取ってバウンスメールを作るメールサーバーがあること

送信方法ごとのバウンスの届き先

DMARCで不合格になるメールは、Google WorkspaceやMicrosoft 365から直接送ったメールより、メール配信サービス、業務システム、複合機など、それ以外の送信元から送ったメールに多く見られます。
これは、MailDataがDMARCの集計レポートを分析してきた経験によるもので、統計として集計した数値ではありません。
こうした送信元は、上の表のとおり、バウンスがドメイン所有者に届きにくい送信元でもあります。

メール配信サービスから送る場合

メール配信サービスでReturn-Path（MAIL FROM）を自社のサブドメインに合わせても、そのサブドメインのMXレコードは、通常、配信サービスのサーバーを指しています。
そのため、Return-Pathを自社のドメインに合わせても、バウンスメールを受け取って処理するのは配信サービスのままです。
配信サービスに届いたバウンスの内容は、配信サービスの次のような機能で確認してください。

• 管理画面のバウンスログ
• バウンスをシステムに通知するWebhookやAPI
• バウンスを指定したアドレスへ転送する機能

例えば、Amazon SESには、バウンスの通知を、送信時に指定したアドレスへメールで転送する機能があります。
詳しくは、Amazon SESでSPFのDMARCアライメントを一致させるカスタムMAIL FROMドメインの設定方法の4章で解説しています。
どの機能があるかは配信サービスによって異なるので、各サービスのドキュメントで確認してください。

受信側の実装 ― Microsoft 365とGmail

受信側がDMARCの不合格をどう扱うかは、受信側の実装と設定によって異なります。
送信側は、受信側の設定を変えられません。
主な受信サービスの公式ドキュメントでは、次のように説明されています。

Microsoft 365

受信側の組織のフィッシング対策ポリシーで「Honor DMARC record policy when the message is detected as spoof」が有効な場合、送信元のDMARCがp=rejectで不合格になったメールは、SMTPのやり取りの中で550 5.7.1で拒否されます。
（Microsoft Learn「Set up DMARC to validate the From address domain in Microsoft 365」）
この設定の既定値は有効で、p=rejectの場合の既定の動作は「Reject the message」です。
p=quarantineの場合の既定の動作は「Quarantine the message」で、拒否されないためバウンスは発生しません。
（Microsoft Learn「Recommended email and collaboration threat policy settings for cloud organizations」）

Gmail

SPFやDKIMで認証されないメッセージは、迷惑メールとされるか、5.7.26のエラーで拒否される可能性があると説明されています。
（Gmail Help「Email sender guidelines」）
どの場合に拒否され、どの場合に迷惑メールとされるかは、公開されているドキュメントでは確認できませんでした。

バウンスが発生しない場合

次の場合は、受信側が拒否の応答を返さないため、送信側のメールサーバーはバウンスメールを作りません。

• 受信側が、DMARCで不合格のメールを拒否せず、迷惑メールフォルダーへの振り分けや隔離にした場合
• 受信側が、2xyの応答で受け入れたように見せて破棄した場合（RFC 9989 Section 7.2の「silent discard」）
• 受信側が、ドメイン所有者のDMARCのポリシーを適用しない設定にしている場合
• DKIMの検証などでDNSの一時エラー（temperror）が起きた場合

DMARCの検証に必要なDNSの問い合わせが、一時的または恒久的なDNSエラーで完了しなかった場合、そのメッセージはDMARCで合格とも不合格ともみなせず、ドメイン所有者のポリシーは適用できません。
（RFC 9989 Section 5.3.6）
受信側がDMARCのポリシーを適用できないために配送を延期する場合は、4xyの応答を返すのが望ましいとされています。
（RFC 9989 Section 7.2）
4xyで延期されたメールは送信側のメールサーバーが再送するので、再送で届けばバウンスは発生しません。
また、DKIMがtemperrorでも、SPFが合格してアラインしていれば、DMARCは合格になります。
（RFC 9989 Section 5.3.5）

バウンスで気付けるもの、気付けないもの

DMARCで不合格になったメールのバウンスを受け取るには、MAIL FROMを自社で受信できるアドレス、つまり、通常は自社のドメインのアドレスにする必要があります。
しかし、MAIL FROMを自社のドメインにしてSPFがpassすれば、SPFのアライメントが一致してDMARCは合格し、メールは届きます。
バウンスを受け取れる設定にすると、そもそも不合格にならないという、相反する関係があります。

ただし、MAIL FROMが自社のドメインでも、DMARCが合格するとは限りません。
DMARCでSPFの識別子として使われるのは、SPFで検証済み（pass）のMAIL FROMのドメインだけです。
（RFC 9989 Section 3.2.4）
MAIL FROMが自社のドメインのまま、SPFが不合格になる次のような場合は、DMARCで不合格になったときのバウンスが自社に届きます。

• 複合機、社内の業務システム、オンプレミスのメールサーバーなどが、MAIL FROMに自社のドメインのアドレスを使い、SPFレコードに登録されていないIPアドレスから送信している場合（SPFへの登録漏れ）
• メールが転送され、転送の途中でSPFが不合格になり、DKIMの署名も内容の改変で検証できなくなった場合

転送の場合は、メールを受け入れた転送元のサーバーが、転送先に拒否された後でバウンスメールを作り、元のMAIL FROMのアドレスに返します。
（RFC 5321 Section 6.1）
なお、転送元のサーバーが、SRS（Sender Rewriting Scheme）などの方法でMAIL FROMを自分のドメインのアドレスに書き換えている場合は、転送先でのSPFは転送元のドメインで評価され、バウンスもいったん転送元のサーバーに届きます。
SRSは、元のMAIL FROMのアドレスを書き換え後のアドレスに符号化しておき、転送元に届いたバウンスを元の送信者に戻せるようにする方法ですが、RFCで定められた仕組みではありません。
RFC 9989も、中継するサーバーがMAIL FROMを書き換えない限り、転送されたメールはSPFで不合格になる可能性が高いと説明しています。
（RFC 9989 Section 7.4）
相反する関係がそのまま当てはまるのは、メール配信サービスなど、MAIL FROMに他社のドメインを使う送信元です。
不合格の間はバウンスが配信サービスに届き、Return-Pathを自社のドメインに合わせると合格するので、ドメイン所有者がバウンスで不合格に気付く機会はありません。

バウンスで気付けるのは、主に自社のドメインをMAIL FROMに使う送信元の不備と、転送による不合格です。
他社のドメインをMAIL FROMに使う送信元の不備は、DMARCの集計レポートでしか気付けません。

バウンスだけでは、DMARCで不合格になったすべてのメールには気付けません

バウンスメールが届くのは、受信側がSMTPのやり取りの中で拒否した場合だけです。
迷惑メールフォルダーへの振り分けや隔離にされたメールは、バウンスでは分かりません。
1通ごとの不合格を知らせる失敗レポート（ruf）も、主な受信サービスでは送られていません。
Gmailはrufタグに対応しておらず、Microsoft 365もrufのアドレスがあっても失敗レポートを送らないと説明しています。
（Google Workspace Admin Help「Set up DMARC」、Microsoft Learn「Set up DMARC to validate the From address domain in Microsoft 365」）
DMARCで不合格になったメールを送信元ごとに把握するには、バウンスとあわせて、DMARCの集計レポート（rua）で、SPFとDKIMの結果、アライメント、受信側が適用した処理（disposition）を確認してください。

結論 ― p=quarantineでは届いていないことに気付けないため、p=rejectを勧めます

DMARCのポリシーをp=quarantineにすると、DMARCで不合格になったメールは、受信側で隔離されるか迷惑メールフォルダーに振り分けられます。
受信側は拒否の応答を返さないので、送信側のメールサーバーはバウンスメールを作りません。
例えば、Microsoft 365の既定の設定では、p=quarantineで不合格になったメールは隔離されます。
（Microsoft Learn「Recommended email and collaboration threat policy settings for cloud organizations」）
その結果、送信者は、自分のメールが相手の受信箱に入っていないことに気付けません。

p=rejectにすると、受信側がDMARCのポリシーを適用する場合、不合格になったメールはSMTPのやり取りの中で拒否されます。
MAIL FROMが自社のドメインのアドレスであれば、送信側のメールサーバーが作ったバウンスメールが届き、届かなかったことに気付けます。
同時に、自社のドメインを名乗るなりすましメールも、受信箱に届く前に拒否されます。
だからこそ、MailDataは、DMARCのポリシーをp=quarantineで止めず、p=rejectまで進めることを勧めています。

ただし、p=rejectにしても、すべての不合格のメールが拒否されるわけではありません。
RFC 9989は、受信側がp=rejectのポリシーだけを理由に拒否してはならず（MUST NOT）、ほかの知見や分析がない場合は、p=quarantineとして扱わなければならない（MUST）としています。
（RFC 9989 Section 7.4）
p=quarantineとして扱われた場合は、p=rejectでもバウンスは発生しません。
また、MAIL FROMに他社のドメインを使う送信元のバウンスは、p=rejectでも自社には届きません。
バウンスは気付く手段の1つであり、DMARCの集計レポートの確認が欠かせないことは、p=rejectでも変わりません。

RFC 9989がp=rejectを公開するドメインに求めていること

RFC 9989は、p=rejectが、転送やメーリングリストなどの間接的なメールの流れと相互運用上の問題を起こしうるとして、次のように定めています。
（RFC 9989 Section 7.4）

• p=rejectを公開するドメインは、DMARCの合格をSPFだけに頼ってはならず（MUST NOT）、メッセージに有効なDKIM署名を付けなければなりません（MUST）。
  転送されたメールは、中継するサーバーがMAIL FROMを書き換えない限りSPFで不合格になる可能性が高い一方、DKIM署名は、通常、検証できる状態のまま残るためです。
• メーリングリストに投稿する可能性のある利用者がいるドメインは、p=rejectを公開すべきではありません（SHOULD NOT）。
  それでもp=rejectを公開する場合は、まずp=noneを少なくとも1か月、続いてp=quarantineを同じ期間公開し、集計レポートで処理の結果を比べて、影響を確認すべきです（SHOULD）。
  また、利用者がインターネット上のメーリングリストに投稿しないようにするか、メーリングリストへの参加が妨げられる可能性を利用者に知らせるべきです（SHOULD）。

一方で、RFC 9989は、p=rejectを公開する大手のメールサービスが現れてからの10年間で、メーリングリストのソフトウェアは、Fromヘッダーを書き換えてDMARCにアラインさせる回避策をすべて採用したとも記しています。

MailDataは、p=quarantineを経ずにp=rejectへ移行します

p=noneからp=quarantineを経てp=rejectに進む段階的な移行は、RFC 9989ではSHOULDです。
SHOULDは、特定の状況では従わない正当な理由がありうるものの、その影響を十分に理解し、慎重に検討したうえで別の方法を選ぶべき、という意味です。
（RFC 2119 Section 3）
段階的な移行の目的は、集計レポートで正規のメールへの影響を確認することです。

MailDataは、p=noneの期間に、集計レポートを分析して自社のドメインを使うすべての送信元を洗い出し、SPFとDKIMのアライメントを一致させたうえで、p=quarantineを経ずに直接p=rejectへ移行することを勧めています。
この記事で説明したとおり、p=quarantineの期間は、不合格になった正規のメールが隔離や迷惑メールへの振り分けにされても、送信者はバウンスで気付けません。
p=noneでも、集計レポートには、自社のドメインを使うすべての送信元について、SPFとDKIMの結果とアライメントが報告されるため、どの送信元が不合格になるかは、p=noneの期間に特定できます。
MailDataは、正規の送信元がすべてSPFとDKIMの両方でアラインしていることを集計レポートで確認してから、p=rejectに移行します。
RFC 9989がp=quarantineの期間を置く目的は処理の結果を比べて影響を確認することですが、不合格になる送信元そのものはp=noneの期間に分かるため、p=quarantineの期間がなくても、確認の目的は果たせます。
p=quarantineを経由しなければ、正規のメールが届いていないことに気付けない期間をなくせます。
送信元の洗い出しと整備をp=noneの期間に終えられることが、国内1,300ドメイン以上の導入を支援してきたMailDataの強みです。
移行の手順は、DMARCでp=rejectにするためのプロセスで解説しています。

9. バウンスメールを受け取ったときの対応

要点: StatusとDiagnostic-Codeから原因を切り分けます。宛先を配信リストから外すかどうかは、3桁の応答コードではなく、拡張ステータスコードで判断してください。DMARCなどのポリシーによる拒否で宛先を外すと、正規の宛先を失います。

対応の手順

1. バウンスメールのStatus（拡張ステータスコード）とDiagnostic-Code（受信側の応答）を確認します。
2. 次の表で、宛先の問題か、自社の送信の設定の問題かを判断します。
3. 元のメッセージのヘッダーが添付されている場合は、Authentication-Resultsヘッダーなどで、認証の結果を確認します。
4. 送信元ごとの認証結果を、DMARCの集計レポートで継続して確認します。

3桁の応答コードだけで判断しない

SMTPの応答コード550は、「mailbox unavailable」と定義されており、その例として、メールボックスが見つからない場合だけでなく、アクセスできない場合や、ポリシーによってコマンドが拒否された場合が挙げられています。
（RFC 5321 Section 4.2.3）
DMARCによる拒否も、550 5.7.1や550 5.7.26のように、550で返されます。
3桁の応答コードが5で始まるバウンスを、すべて「宛先不明」として配信リストから外す仕組みにしていると、自社のSPF、DKIM、DMARCの設定不備で拒否された正規の宛先まで、リストから消えてしまいます。
宛先を外すかどうかは、拡張ステータスコードの2つ目と3つ目の数字（サブジェクトと詳細）と、Diagnostic-Codeの応答テキストで判断してください。

5.7.Xのバウンスで、宛先を配信リストから外さないでください

5.7.Xは、ポリシーによる拒否です。
DMARCで不合格になった場合も、このコードで拒否されます。
原因は宛先ではなく、自社の送信元のSPF、DKIM、DMARCの設定にあることが多く、宛先を外すと、正規の取引先や顧客のアドレスを失います。
バウンスを自動で処理する仕組みが、5.7.Xの宛先を自動で削除する設定になっていないかを確認してください。

拡張ステータスコードの意味は、RFC 3463とIANAの登録簿に基づきます。
（RFC 3463 Section 3）
宛先の扱いと自社が行うことは、MailDataが推奨する運用です。
メールボックスの容量超過は、RFC 3463では一時的な失敗として使うべきとされていますが、受信側によっては552 5.2.2のように恒久的な失敗として返されるため、すぐには外さない扱いにしています。
一時的な失敗を何回繰り返したら宛先を外すかについて、公的な基準は確認できていません。
メール配信サービスを使っている場合は、そのサービスの仕様に従ってください。

主な受信サービスのDMARCによる拒否のコード

DMARCで不合格になったメールが拒否されたときに返されるコードは、受信サービスによって異なります。
公式ドキュメントで確認できたものは、次のとおりです。

どちらも5.7.Xのポリシーによる拒否なので、上の表のとおり、宛先は配信リストから外さず、自社の送信元の設定を直してください。
Diagnostic-Codeの応答テキストに「DMARC」という語が含まれていれば、DMARCによる拒否だと判断できます。
RFC 9989も、拒否の理由が分かるように、応答テキストに「DMARC」という語を含める例を示しています。
（RFC 9989 Section 7.2）
ただし、応答テキストの書き方は受信側の実装によって異なり、拒否の理由が書かれていない場合もあります。

受信したメールのヘッダーは、メールヘッダ診断で確認できます。
DMARCの集計レポートは、MailData（PowerDMARC）で送信元ごとに集計して確認できます。

10. まとめ ― 確認チェックリスト

• バウンスの受け取り先: 自ドメインのメールを送るすべての送信元で、MAIL FROM（Return-Path）がどのアドレスになっていて、バウンスメールが誰に届くかを把握しているか？
• 配信サービスのバウンス: メール配信サービスから送っているメールのバウンスを、バウンスログ、Webhook、転送機能などで確認できるようにしているか？
• バウンスの確認: MAIL FROMのアドレスに届いたバウンスメールを、誰かが確認する運用になっているか？
• ステータスコード: バウンスメールのStatusとDiagnostic-Codeで、恒久的な失敗か一時的な失敗かを判断しているか？
• 宛先リスト: 5.1.1などの宛先不明のバウンスが返った宛先を、配信リストから外しているか？
• ポリシーによる拒否: 5.7.Xなどポリシーによる拒否で、宛先を配信リストから外さず、自社の送信元の設定を確認しているか？
• HELOのSPF: バウンスメールを送信するMTAのHELOのドメインに、SPFレコードを公開しているか？
• バックスキャッター: 自社の受信サーバーが、受け入れた後に偽装された送信元へバウンスを返す設定になっていないか？
• DMARCのポリシー: p=quarantineで止めず、正規の送信元のアライメントを一致させたうえで、p=rejectまで進めているか？
• DMARCの集計レポート: バウンスが自社に届かない送信元も含めて、送信元ごとのSPFとDKIMのアライメントを、集計レポートで確認しているか？

参考資料

• RFC 5321: Simple Mail Transfer Protocol（2008年10月。RFC 7504で更新）
• RFC 3461: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)（2003年1月。RFC 3798、RFC 3885、RFC 5337、RFC 6533、RFC 8098で更新）
• RFC 3463: Enhanced Mail System Status Codes（2003年1月。RFC 3886、RFC 4468、RFC 4865、RFC 4954、RFC 5248で更新）
• RFC 3464: An Extensible Message Format for Delivery Status Notifications（2003年1月。RFC 4865、RFC 5337、RFC 6533で更新）
• RFC 6522: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages（2012年1月。RFC 3462を廃止）
• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1（2014年4月。RFC 7372、RFC 8553、RFC 8616で更新）
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)（2026年5月。RFC 7489とRFC 9091を廃止）
• Microsoft Learn「Set up DMARC to validate the From address domain in Microsoft 365」
• Microsoft Learn「Recommended email and collaboration threat policy settings for cloud organizations」
• Gmail Help「Email sender guidelines」
• Google Workspace Admin Help「Set up DMARC」
• IANA: Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry