PTRレコードを設定して dig -x でも引けるのに、送ったメールが「PTRレコードが無い」「逆引きが一致しない」と拒否される場合は、逆引きそのものではなく、受信側が見ている条件とのずれが原因です。多いのは、実際にはIPv6で送信していてIPv6側の逆引きが無い、逆引きのホスト名を正引きすると同じIPに戻らない、送信に使われているIPが想定と違う、の3つです。この記事では、エラーメッセージとメールヘッダーから受信側が見たIPを特定し、原因を多い順に確かめて直す手順を説明します。DNS側でPTRがまったく引けない場合の切り分けは、別の記事で扱っています。
エラーメッセージから送信元IPを読み取る
最初に、受信側がどのIPからの接続を問題にしているのかを確認します。手がかりは、送信サーバーのログと、送信者に戻ってくるエラーメール（バウンス）です。
Postfix なら、メールのログに受信側の応答がそのまま残ります。
# Debian/Ubuntu 系の例（環境によりログの場所は異なる）
sudo grep -E "status=(bounced|deferred)" /var/log/mail.log | tail -n 20
# systemd-journald だけで管理している環境
sudo journalctl -u postfix --since "1 hour ago" | grep -E "bounced|deferred"Gmail 宛てで逆引きが原因の場合は、5.7.25 を含む応答とともに、接続元IPがかっこ書きで示されることがあります。そこに表示されたのがIPv6アドレスなら、IPv6で送信しています。応答の文面やコードは受信側の事業者ごとに異なり、変わることもあります（2026年10月現在）。
テスト用のアドレスに届いたメールがあれば、ヘッダーの Received: の行でも確認できます。受信側のサーバーが記録した行に、接続してきたIPが書かれています。
原因1：IPv6で送信しているのに、IPv6の逆引きが無い
もっとも多い原因です。サーバーにIPv6アドレスが付いていると、Postfix などのメールサーバーは、相手のMXにAAAAレコードがあればIPv6で接続することがあります。IPv4にだけPTRを設定していると、IPv6で送った分だけ拒否されます。
直し方は2つあります。
- IPv6のアドレスにもPTRを設定し、そのホスト名にAAAAレコードを用意する
- 当面IPv6で送信しないように設定する
後者の場合、Postfix では main.cf で次のどちらかを使います。
# 送信時はIPv4を優先する（受信やほかの通信はIPv6のまま）
smtp_address_preference = ipv4
# Postfix 全体でIPv4だけを使う（IPv6での受信もやめる）
inet_protocols = ipv4sudo postfix check
sudo systemctl restart postfix # inet_protocols を変えた場合は reload ではなく restartIPv6を使い続けるのであれば、前者のほうが根本的な対応です。
原因2：正引きと逆引きが一致していない
受信側の多くは、接続元IPの逆引きで得たホスト名を、さらに正引きして同じIPに戻るか（FCrDNS）を確かめます。PTRがあっても、そのホスト名のAレコードが別のIPを指している、またはAレコード自体が無いと、不一致として扱われます。
# IPv4
ip=203.0.113.25
name=$(dig -x "$ip" +short)
echo "PTR: $name"
dig +short "$name" A
# IPv6
ip6=2001:db8::25
name6=$(dig -x "$ip6" +short)
echo "PTR: $name6"
dig +short "$name6" AAAA最後の行の結果に元のIPが含まれていれば一致です。含まれていなければ、PTRのホスト名に合わせてA（またはAAAA）レコードを追加・修正します。PTRのホスト名を、CDNやロードバランサーに向けたCNAMEの名前にしている場合も、正引きの結果が送信サーバーのIPにならないので一致しません。メール送信用には、送信サーバーのIPだけを指すホスト名を用意します。
原因3：送信に使われているIPが想定と違う
PTRを設定したIPと、メールが出ていくIPが違うケースです。次のような構成で起こります。
- サーバーに複数のIPがあり、送信には別のIPが使われている
- NATやクラウドのゲートウェイを通っていて、外から見えるIPがサーバーのIPと異なる
- 別の中継サーバー（スマートホストや外部の送信サービス）を経由している
送信元IPを固定したい場合、Postfix では smtp_bind_address（IPv4）と smtp_bind_address6（IPv6）で、送信に使うアドレスを指定できます。
smtp_bind_address = 203.0.113.25
smtp_bind_address6 = 2001:db8::25外部の送信サービスを中継に使っているなら、受信側から見える接続元はそのサービスのIPです。この場合、自分のサーバーのPTRは評価に関係しないため、送信サービス側の案内に沿ってSPFやDKIMを設定します。
原因4：IPv6の逆引きの書き方の誤り
IPv6のPTRを自前のゾーンで書く場合、ip6.arpa の名前はアドレスを省略せずに展開し、16進数1桁ずつ逆順に並べます。:: の省略を展開し忘れると、桁がずれた別の名前になります。手で書かずに、ツールで名前を作ると誤りを防げます。
# Python の標準ライブラリで逆引き名を作る
python3 -c "import ipaddress; print(ipaddress.ip_address('2001:db8::25').reverse_pointer)"
# 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa事業者の管理画面で設定する場合でも、IPv4の欄とIPv6の欄を取り違えていないか、割り当てられた範囲の中の正しいアドレスに設定したかを確認します。
原因5：PTRが複数ある、または汎用的なホスト名のまま
1つのIPに複数のPTRがあると、受信側がどれを使うかが定まらず、一致の確認に失敗することがあります。メールを送るIPのPTRは1つにします。
また、事業者が自動で付けたIPアドレスを含むホスト名のままだと、受信側によっては個人向け回線などの動的なアドレスと判断し、評価を下げることがあります。mail.example.com のように、自分のドメインの名前に変えておきます。
あわせて、メールサーバーが名乗るホスト名（HELO・EHLO）も逆引きの名前にそろえます。Postfix では myhostname で設定します。
修正後の確認
修正したら、テスト用のアドレスに送り、ログで受信側の応答が status=sent になることを確かめます。拒否された直後は、送信側のキューに残ったメールが再送を待っている場合があります。postqueue -p でキューを確認し、修正後に postqueue -f で再送を試せます。
逆引きが正しくなっても、受信側では SPF・DKIM・DMARC による送信ドメインの認証も見られています。逆引きの修正と並行して、これらの設定も確認しておくと、迷惑メール扱いの原因を一度に減らせます。設定を変える前には、main.cf のバックアップを取っておきます。
まとめ
- エラーメッセージとログから、受信側が問題にしている接続元IP（IPv4かIPv6か）を特定する
- IPv6で送信しているなら、IPv6にもPTRとAAAAを用意するか、
smtp_address_preference = ipv4で当面IPv4を優先する - 逆引きのホスト名を正引きして、同じIPに戻るか（FCrDNS）を確かめる
- 送信に使われるIPが想定どおりか確認し、必要なら
smtp_bind_addressで固定する - PTRは1つにし、自分のドメインのホスト名にする。HELO名もそろえる