@btinternet.com（BTインターネット）宛てに送ったメールだけが返送され、他の宛先には届く――そんなときは受信側の迷惑メールポリシーで拒否されている可能性が高いです。エラー554（2.1.2.2）の実務的な切り分けと対処をまとめます。
@btinternet.com 宛てだけ届かない症状を整理する
今回のポイントは「@btinternet.com に送ったメールだけが届かず、他ドメイン（Gmail、Outlook.com、社内など）には送れる」という点です。送信元側の障害（送信サーバーダウン等）であれば宛先全体で失敗しがちですが、特定プロバイダーだけで弾かれる場合は、受信側が定める迷惑メール対策（ポリシー）に引っかかっているケースが多いです。
返ってきた 「554 Message rejected for policy reasons (2.1.2.2)」 は、受信側が「恒久的に拒否（Permanent failure）」として扱っていることを示す典型的な文言です。つまり、同じ状態で再送しても改善しにくく、原因の特定と修正（または解除依頼）が必要になります。括弧内の (2.1.2.2) は、SMTPの標準的な返信コードというよりも「受信側の内部コード（分類番号）」として付いていることが多く、バウンス全文を見ないと具体的な判定理由が読み解けない場合があります。
| 見えている事実 | 示唆される原因の方向性 | 優先して確認すること |
|---|---|---|
| @btinternet.com 宛てだけ失敗 | 受信側ポリシー（ISP固有の判定）に該当 | バウンス全文、認証、レピュテーション |
| SMTP 554 / policy reasons | スパム判定、認証失敗、送信元評価の低下など | SPF/DKIM/DMARC、IP・ドメイン評価、送信挙動 |
| 他宛先は送れる | 送信サーバーの基本動作は正常の可能性が高い | 特定の宛先だけが嫌がる条件を探す |
まず押さえる：SMTP 554「policy reasons」の意味
SMTP 554 は、受信側が「そのメールを受け取らない」と判断したときに返すことがある拒否応答です。特に “policy reasons” は「受信側の規約・迷惑メール対策の基準に抵触した」というニュアンスで、原因は1つに限りません。
| カテゴリ | 典型的な中身 | このケースでの優先度 |
|---|---|---|
| 認証（SPF/DKIM/DMARC） | PASSしていない、整合が取れていない、署名が壊れている | 最優先 |
| 送信元評価（レピュテーション） | IP/ドメインが低評価、過去の苦情率、スパム履歴、RBL掲載 | 最優先 |
| 技術要件（MTA品質） | 逆引きDNS未整備、HELO不正、IPv6の不備、TLS問題 | 高 |
| 内容・挙動（コンテンツ/送信量） | URL過多、危険添付、HTMLが雑、大量送信、再送連打 | 中〜高 |
| 宛先側の事情 | 相手側のルール/フィルタ強化、受信ボックス満杯、独自ブロック | 中 |
最短で原因に近づく切り分けの全体像
メール到達性（Deliverability）は「設定・送信経路・内容・評判」の掛け算です。順番を間違えると遠回りになります。以下の流れで進めると、原因を潰し込みやすくなります。
| 手順 | 目的 | アウトプット |
|---|---|---|
| バウンスメール全文を保存 | 拒否理由の手がかりを確保 | 拒否した受信サーバー名、診断コード、拒否された送信IP |
| SPF/DKIM/DMARC を点検 | 「正規の送信者」だと証明 | 認証がPASSし、DMARC整合（alignment）が取れる状態 |
| 送信元IP/ドメインの評価を確認 | ブラックリスト・低評価の有無を把握 | 該当があれば解除申請、送信量・内容の見直し |
| 送信サーバーの基本品質を確認 | ISPが嫌う技術的欠陥を除去 | 逆引きDNS、HELO、TLS、時刻、IPv6 などの整合 |
| 送信内容・送信挙動を見直す | フィルタに刺さる要素を削る | 件名/本文/URL/添付/大量送信/エラー率の改善 |
| btinternet 側へ解除依頼 | ISP側ブロックの解除・原因共有 | 必要情報を添えた問い合わせ（バウンス全文が鍵） |
まず必須：バウンスメール（エラーメール）全文を確保する
一次切り分けで最も重要なのが、バウンスメール全文（ヘッダーを含む）の確保です。件名や短いエラー文だけだと、推測が混ざってしまい、対策が外れやすくなります。
バウンス全文で見るべきポイント
| 項目 | どこに出ることが多いか | 何が分かるか |
|---|---|---|
| Remote-MTA / Reporting-MTA | DSN（配達状況通知）のヘッダー | 拒否した相手サーバー（btinternet側）の実体 |
| Diagnostic-Code | 本文のエラー詳細 | policy reasons 以外の補足（認証失敗、レート制限等） |
| Received 行（複数） | メールヘッダー | 実際に接続した送信IP、経由した中継（どの基盤で送ったか） |
| Final-Recipient | DSN本文 | 拒否された宛先アドレス（切り分け対象の特定） |
| Message-ID | メールヘッダー | 送信ログ/メッセージ追跡と突合するキー |
| 日時（タイムゾーン込み） | ヘッダー/本文 | 発生開始時期、再現性、ISP側変更の疑いの切り分け |
バウンス全文は、社内の分析だけでなく、btinternet 側へ解除依頼を出す際にも「これがないと調査できない」と言われることが多い資料です。個人情報が含まれる場合は、宛先や本文をマスクしても構いませんが、診断コードと送信IPに関わる行は残すのがコツです。
最低限ここだけは残したい行の例
実際のバウンスは環境で異なりますが、次のような要素が含まれていれば切り分けが進みます（例示のために簡略化しています）。
Diagnostic-Code: smtp; 554 Message rejected for policy reasons (2.1.2.2) Remote-MTA: dns; mx.bt.example Final-Recipient: rfc822; [email protected] Received: from mail.example.jp (203.0.113.10) ...
原因の王道：SPF・DKIM・DMARC を「到達性の観点」で見直す
「policy reasons」で拒否される典型は、受信側が なりすましの可能性 を強く疑うケースです。SPF/DKIM/DMARC が未設定、または設定していても実運用の送信経路とズレていると、宛先によっては一気に弾かれます。
SPF：送信経路の漏れ・二重登録・失敗判定に注意
SPF は「このドメインを名乗るメールは、どの送信元から送ってよいか」を DNS に宣言する仕組みです。落とし穴は主に3つあります。
- 送信元が複数あるのにSPFに反映されていない（MAツール、Webフォーム、システム通知、別SMTPなど）
- SPFレコードが複数存在する（TXTが2本以上）
- 参照回数（DNS lookup）が増えすぎて評価できない（includeの盛りすぎ）
| よくあるSPFのつまずき | 起きやすい状況 | 対処の方向性 |
|---|---|---|
| SPFが複数存在する | 過去の設定が残った、DNS運用が複数部署 | 1レコードに統合（includeやip4/ip6を整理） |
| 送信サービスがSPFに含まれていない | Microsoft 365と別SMTP、Webフォーム送信を併用 | 実際の送信元を洗い出してSPFへ追加 |
| ~all（SoftFail）で固定されている | とりあえず通したい運用 | 送信経路を整えてから -all に近づける（段階的に） |
| DNS参照回数（10回）超過 | includeが多い、外部サービスを盛りすぎ | 不要include削減、サブドメイン分割、送信経路統一 |
特に「自社ドメインで送っているつもりでも、実は別の中継（SMTPリレー、MAツール、Webサーバー）から出ている」ケースは頻発します。バウンスの Received 行や送信システムのログから、本当に外に出ているIPを確定させてください。
DKIM：署名が付いているか／検証に失敗していないか
DKIM は送信側がメールに電子署名を付け、受信側が DNS 上の公開鍵で検証する仕組みです。SPF は転送や中継で評価が変わりやすい一方、DKIM は本文やヘッダーが改変されない限り残りやすいため、到達性の要になります。
- 送信メールのヘッダーに DKIM-Signature が付いているか
- DNS に登録した selector（例：
selector1._domainkey）が正しいか - 送信経路の途中で本文が書き換わって DKIM が壊れていないか（フッター挿入、メールゲートウェイ等）
社内のセキュリティゲートウェイやマーケティングツールが本文末尾に文言を足す運用だと DKIM が破損し、受信側によっては「なりすまし扱い」で拒否されることがあります。もし心当たりがあれば、改変箇所を見直すか、改変後に再署名できる設計に寄せるのが有効です。
DMARC：FromドメインとSPF/DKIMの「整合（alignment）」が鍵
DMARC は「From: に書かれたドメイン」と「SPFまたはDKIMで認証できたドメイン」が整合しているかをチェックします。ここがズレると、SPFもDKIMも一見設定されているのに DMARC が FAIL し、受信側が厳しめに拒否することがあります。
| DMARCで見られる点 | 例 | 失敗しやすいパターン |
|---|---|---|
| Fromドメイン | From: [email protected] | 表示上のFromだけ整っている |
| SPFの認証対象（MAIL FROM/Return-Path） | Return-Path: [email protected] | 外部配信サービスのドメインになっている |
| DKIM d= | d=example.jp | d=が別ドメインで署名されている |
| 整合（alignment） | FromとSPF/DKIMが同一（または許容範囲） | Fromだけ自社、認証は別ドメインで不一致 |
DMARC レコード自体の例は次のようになります（運用段階に応じて変えます）。
- 様子見・レポート収集：
v=DMARC1; p=none; rua=mailto:[email protected] - 隔離を推奨：
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected] - 拒否を推奨：
v=DMARC1; p=reject; rua=mailto:[email protected]
もし自社ドメインが p=reject なのに、実運用の送信がDMARC整合していない場合、宛先（btinternetを含む）が DMARC に従って拒否する可能性があります。ここは「緩める」よりも、まずは Fromと認証の整合を取ることが先決です（送信経路を揃える、外部配信のカスタムドメイン/署名設定を正す、改変でDKIMが壊れないようにする等）。
送信元IP・ドメインのレピュテーションを確認する
特定ISPだけで拒否されるケースでは、送信元の評価（レピュテーション）が宛先ごとに異なることが原因になることがあります。受信側は独自のスパム判定・ブラックリスト参照・過去の苦情率などを使い、送信元の信用度を点数化しています。
実務での確認ポイント
- 送信に使っている グローバルIP が変わっていないか（NAT配下の場合は特に）
- 複数の送信経路があり、一部のIPだけが悪化していないか
- 過去の大量配信、誤配信、ウイルス感染端末などで 急に送信量が増えた履歴がないか
- バウンス率が高い状態で送り続けていないか（存在しないアドレスへの送信が多い等）
ブラックリストに載っているかどうかは、RBL（Realtime Blackhole List）を横断チェックできるサービスや、主要リストの確認ページで調べられます。もし掲載が見つかった場合は、原因の改善→解除申請の順が基本です。解除だけ先にしても、再掲載されるとさらに厳しく見られます。
「設定は合っているはず」でも落ちる：送信サーバーの基本品質チェック
SPF/DKIM/DMARC が揃っていても、送信サーバーの作法が悪いと ISP 側でポリシー拒否されることがあります。特にオンプレミス（自社管理MTA）やVPSでの送信は要注意です。
| チェック項目 | なぜ重要か | 目安 |
|---|---|---|
| 逆引きDNS（PTR） | 「正規のサーバー」らしさの基本 | 送信IP→FQDNが引け、A/AAAAと整合している |
| SMTPバナー/HELO(EHLO) | 雑なホスト名はスパム扱いされやすい | 実在するFQDN、PTRと矛盾しない |
| 時刻同期（NTP） | 署名検証やログ解析に影響 | 大きくズレない（数分以上のズレは避ける） |
| TLS設定 | 暗号化必須の受信側もある | STARTTLSが有効、古い暗号のみは避ける |
| IPv6送信 | IPv6のrDNS未整備で落ちることがある | 使うならIPv6もPTR整備、不要なら止める |
btinternet 宛てだけ落ちる場合でも、実際には「他社は許容してくれるが、btinternet はここを厳密に見ている」だけ、ということが起こります。送信側の品質を上げるほど、こうした相性問題が減ります。
送信内容と送信挙動の見直し：迷惑メール判定を避ける実務のコツ
同じIP・同じ認証でも、メールの内容や送信のしかたで判定が変わります。特に次の条件が重なると、特定ISPで弾かれることがあります。
内容（コンテンツ）で引っかかりやすい例
- 短い本文にURLが多い、短縮URLを使っている
- 添付ファイル（危険判定されやすい形式、パスワード付きZIPなど）がある
- 件名が過度に煽り文句、記号だらけ、同じ件名の大量送信
- HTMLメールの作りが荒い（画像だけ、外部画像だらけ、text/plainが無い等）
挙動（ふるまい）で引っかかりやすい例
- 短時間に大量送信する（新IP/新ドメインは特に）
- バウンスが多いのに送り続ける
- 受信者からの迷惑メール報告が増えている
- 過去に同一宛先へ繰り返し失敗し、再送を連打している
まずは切り分けとして、テキストのみの短いメール（URLなし・添付なし）を @btinternet.com 宛てに送って結果を比べてください。これで届くなら「内容が原因」、届かないなら「認証/評判/経路が原因」の線が強くなります。切り分けは「最小構成で通るか」を見ると、最短で答えに近づけます。
Microsoft 365 / Exchange Online 利用時に追加で見るべきポイント
Microsoft 365（Exchange Online）を使っている場合でも、送信経路の作り方によっては SPF/DKIM/DMARC が崩れたり、送信元IPが想定外になったりします。管理者が見落としやすい箇所をまとめます。
メッセージ追跡で「どこで失敗したか」を確定する
- 管理センターのメッセージ追跡で、該当メールが「送信済み」になっているか
- コネクタ経由（オンプレ中継、サードパーティ中継）になっていないか
- 送信後にルールで書き換え（差出人変更、フッター挿入）が入っていないか
送信方式が混在していないか（M365でありがちな混線）
| 方式 | 見え方 | 起きがちな到達性トラブル | 対策の方向性 |
|---|---|---|---|
| Exchange Online から直接送信 | Microsoftの送信基盤IP | 基本は安定。ただしドメイン認証が未整備だと弾かれる | SPF/DKIM/DMARCを正しく整える |
| オンプレ/社内機器からSMTPリレー | 自社グローバルIP（NAT） | rDNSや評判が弱く、ISPで弾かれやすい | rDNS整備、送信量管理、必要なら中継を統一 |
| MAツール/フォーム送信 | ツール事業者の送信IP/ドメイン | From整合が崩れる、Return-Pathが別になりDMARC失敗 | カスタムドメイン設定、DKIM対応、整合を取る |
「普段はMicrosoft 365から送るが、一部システム通知だけ別サーバーから送っている」といった構成は、btinternet のような厳しめのISPで問題が表面化しやすいです。送信経路が複数あるなら、まずは 問題のメールがどの経路で出ているか を確定してください。
btinternet 側にブロック解除を依頼する際の実務テンプレ
認証・レピュテーション・技術要件を見直しても改善しない場合、btinternet 側のブロック（送信元IPの拒否、ドメイン単位の遮断など）が残っている可能性があります。公式のサポート窓口／postmaster 相当の問い合わせ先を確認し、必要情報を添えて連絡します。
問い合わせに入れると効果が高い情報
- 送信元ドメイン（例：example.jp）
- 送信元IPアドレス（複数なら全て）
- 送信日時（タイムゾーン含む）
- 宛先（@btinternet.com の具体的アドレスはマスク可）
- バウンスメール全文（ヘッダー含む）
- 実施した対策（SPF/DKIM/DMARCの整備、rDNSの整備など）
英文での依頼文サンプル（コピペ用）
Subject: Request for delisting / delivery issue to btinternet.com (SMTP 554 policy reasons 2.1.2.2) Hello Postmaster Team, We are experiencing delivery failures only when sending to @btinternet.com recipients. Other domains receive our emails successfully. Error returned: "554 Message rejected for policy reasons (2.1.2.2)" Sender domain: example.jp Sending IP address: 203.0.113.10 Date/Time (with timezone): 2025-12-14 10:00 JST We have verified and corrected our email authentication: * SPF: PASS * DKIM: PASS * DMARC: aligned and PASS Could you please advise the reason for the block and/or remove any blocklisting for our IP/domain? Full bounce message is attached below (headers included). Thank you.
ポイントは「他ドメインには届く」「btinternet 宛てだけ拒否」「エラー文」「送信元IP」「バウンス全文」を揃えることです。受信側が追加情報（ログ提出、追加テスト）を求めることもあるため、やり取りの履歴は保管しておくと再発時に役立ちます。
一時的な回避策（業務を止めないための現実的な選択肢）
原因特定と解除には時間がかかる場合があります。重要な連絡があるときは、暫定運用も用意しておくと安心です。
- 相手に代替連絡先（別メール、フォーム、チャット、電話）を確認する
- 社内の別ドメイン／別送信基盤からテスト送信し、問題が「ドメイン要因」か「IP要因」かを切り分ける
- 個別連絡は件数を絞って送る（再送連打は避ける）
- 送信基盤を一本化し、認証とレピュテーションを集中管理する
再発防止：到達性を継続的に守る運用
一度でも「特定ISPで拒否」が起きると、同じ構成のままでは再発しやすいです。次の運用を仕組みにすると、問題の早期発見と予防につながります。
- DMARCレポート（rua）を受け取り、未知の送信元がないか定期確認する
- バウンス率・苦情率・送信量を監視し、急増をアラート化する
- 新しい送信IP/ドメインはウォームアップ（段階的増量）を行う
- システム通知・MA配信・担当者メールなど送信経路を棚卸しし、SPF/DKIM/DMARC整合を保つ
よくある質問
なぜ btinternet.com 宛てだけブロックされるのですか？
受信側ISPは独自の迷惑メール対策を持ち、判定基準（認証の厳しさ、IP評価、コンテンツ判定、送信量の閾値など）が異なります。他社が許容する軽微な不備でも、btinternet 側では拒否されることがあります。
SPF/DKIM/DMARC を設定したのに改善しません
設定が存在することと、実際の送信メールでPASSしていることは別です。バウンスの Received 行や送信メールのヘッダーで、どの経路・どのドメインで認証されているかを確認し、Fromと整合しているか（DMARC alignment）までチェックしてください。
解除依頼はどのタイミングで出すべきですか？
最低限、(1)バウンス全文の確保、(2)SPF/DKIM/DMARCと送信サーバー品質の見直し、(3)送信元IP/ドメイン評価の確認、まで終えてからが効率的です。改善前に依頼しても「設定を直してから再申請してほしい」となることがあります。
まとめ：554（2.1.2.2）を解消するための実務チェックリスト
| チェック | 完了目安 | メモ |
|---|---|---|
| バウンスメール全文（ヘッダー含む）を保存 | ☐ | 拒否した相手と送信IPを特定 |
| SPFが1本化され、送信経路が全て含まれている | ☐ | 併用サービスの漏れに注意 |
| DKIM署名が付与され、検証に失敗していない | ☐ | 途中改変（フッター等）で壊れやすい |
| DMARCがPASSし、Fromと認証ドメインが整合 | ☐ | Return-Pathとd=のズレを確認 |
| 送信元IP/ドメインの評判（RBL等）を確認 | ☐ | 原因改善→解除申請が基本 |
| 逆引きDNS、HELO、TLS、IPv6など基本品質を確認 | ☐ | ISPごとに厳しさが違う |
| 内容（URL/添付/HTML）と送信挙動（大量送信）を見直し | ☐ | テキスト短文で切り分けすると早い |
| btinternet側へ解除依頼（必要情報を添付） | ☐ | バウンス全文が最重要 |
コメント