要旨
本番サーバーから外部宛てメールの到達性が不安定になった。表面的には配送ログが status=sent を返していたが、受信側での扱いが不安定で一部不達も観測。原因は、名乗り（HELO/EHLO）と逆引き（PTR）の不整合およびIPv6 接続失敗の連発が重なり、第三者のスパム対策リスト（以下「第三者リスト」）の CSS に一時登録されたことである。設定の是正と監視強化により解決した。
背景
本番サーバーからの通知・レポートメールが届かないとの報告。対照として、開発サーバーは同様の宛先へ問題なく配信できていた。配送ログには成功が記録されている一方で、到達性に差がある点が異常のサインである。
- ログ上は status=sent だが、実際には受信側で迷惑扱い/遅延/稀に不達
- IPv6 宛て接続が Cannot assign requested address で頻発し、その後 IPv4 へフォールバック
なぜ問題が拡大したのか（第三者リストの影響）
受信側メールサービスは、リアルタイムのブロックリストを参照して送信元の信用度を判定する。CSS への一時登録は、即座の全面拒否ではないものの、スコアリング悪化・遅延・迷惑振り分けを誘発する。結果として「送ったのに届かない/遅い」という利用者体験に直結する。
調査（技術的要因の切り分け）
- 識別情報の不整合：本番サーバーの myhostname がドメイン名のままで、サーバー名と一致していなかった。
→ HELO/EHLO と PTR の不一致は到達性を大きく下げる。 - 逆引き設定の不備：逆引き（PTR）が実ホスト名と合致せず、FCrDNS が成立していなかった。
- IPv6 の失敗連発：IPv6 アドレスでの接続試行が失敗し続け、短時間に再試行を重ねる挙動が観測された。機械的には「怪しい」パターンに見える。
- 第三者リストの確認：CSS に一時登録されていることを確認。解除申請の要否を判断。
対処（設定の是正と申請）
1) 名乗りの統一
メールサーバーの myhostname を実ホスト名に修正。外向けの HELO/EHLO が FQDN となるように統一した。
# /etc/postfix/main.cf
myhostname = （本番サーバーのFQDN）
smtp_helo_name = （必要なら明示。未指定なら myhostname を使用）
2) 逆引き（PTR）の修正
ドメインの DNS 管理画面で、送信元IPに対する PTR を実ホスト名へ修正し、正引きと往復で一致するようにした（FCrDNS を成立）。
dig -x （送信元IP） +short # 逆引き → 実ホスト名.
dig （実ホスト名） +short # 正引き → 同じ送信元IP
3) IPv6 の扱いを見直し
運用上 IPv6 が必須ではなかったため、スタックを IPv4 のみへ限定。失敗ログの連発を止め、怪しい挙動のシグナルを消した。
inet_protocols = ipv4
# 反映
postfix reload
4) 認証レコードの整備
- SPF：送信元IPを正確に列挙済みであることを確認。
- DMARC：監視モード（p=none）で導入。rua は受信可能なアドレスを指定し、日次の集計レポートを取得。
- DKIM：次段で導入予定（鍵発行→公開鍵を DNS に掲載→署名付与→検証）。
5) 解除申請
第三者リストの窓口に対し、以下の要点で申請：
「固定IPである」「名乗りと逆引きを是正した」「スパム送信はしていない」。
その後、登録解除（反映には時間差あり）を確認。
検証（配送品質の再確認）
- 配送ログは一貫して status=sent。遅延が稀に見られても、相手側の処理待ちで説明可能。
- 逆引き・正引き・HELO の三点が整合し、外形的な信頼性が回復。
- DMARC レポートで第三者から見た判定傾向を可視化。
mailq # キュー滞留の有無
grep 'postfix/smtp' /var/log/postfix.log | tail -n 100
dig +short TXT _dmarc.（ドメイン）
得られた教訓
- アイデンティティの一貫性は最優先：HELO/EHLO・PTR・正引きの整合が崩れると、内容に問題がなくても到達性は落ちる。
- 不要なIPv6を無理に使わない：スタックの不安定さは「怪しい挙動」と見なされる。使うなら往来の疎通を確実に。
- 25番はサーバー間配送専用：エンドユーザーは 587/465 + SMTP-AUTH。出口・入口ともに最小化する。
- 可観測性を持つ：DMARC レポート、ログ監視、キュー監視で早期に異常を検知する。
- 段階的な強化：SPF → DKIM → DMARC（none→quarantine→reject）と段階を踏む。
運用チェックリスト（抜粋）
- 本番サーバーの myhostname は実ホスト名か
- 逆引き（PTR）⇄ 正引きで FCrDNS が成立しているか
- HELO/EHLO は FQDN か（ドメイン直書きや短縮名は不可）
- 25番の入口・出口はサーバー用途に限定されているか
- SPF が送信実態に合っているか（漏れ・過剰指定に注意）
- DMARC は導入済みか（まずは p=none で監視）
- DKIM 導入計画はあるか（鍵の保守・ローテーションを前提に）
付録：設定とコマンド例（抽象化）
Postfix（抜粋）
myhostname = （本番サーバーのFQDN）
inet_protocols = ipv4
smtpd_tls_security_level = may
smtp_tls_security_level = may
DNS（抜粋）
（ドメイン） IN TXT "v=spf1 ip4:（送信元IP） include:（必要なら） ~all"
# DMARC（_dmarc.ドメイン）
_dmarc.（ドメイン） IN TXT "v=DMARC1; p=none; rua=mailto:（受信可能なアドレス）"
動作テスト
swaks --from you@（ドメイン） --to you@（テスト宛先） --server （相手MTA）:25 --ehlo （本番サーバーのFQDN）
# RBLの参照挙動（空なら未登録）
dig +short （逆順IP）.zen.spamhaus.org @8.8.8.8
まとめ
配送品質は「コンテンツ」以前に「外形の信用」で大きく左右される。サーバーの名乗り・逆引き・プロトコル挙動を正しく整えることが、最短の到達性改善である。今回は基本に立ち返って整備した結果、第三者リストからの解除と安定配信を取り戻した。次は DKIM を導入し、DMARC のポリシーを段階的に強めていく。