メルマモ

この記事でわかること

オンプレミスのメールサーバーから送信する際に必要な逆引き(PTR)とAレコードの役割、設定手順、動作確認方法、よくある問題と対処法を初心者向けにわかりやすく解説します。

結論（要点）

結論：送信元IPに対して正しいPTR（逆引き）と、そのPTRが示すホスト名に対応するAレコードを揃えることが、受信側の信頼性を高め、配信失敗やスパム判定を減らします。

理由（なぜ必要か）

メール受信サーバーは送信元IPの逆引きを確認し、HELO/EHLO名やSPFと整合するかを見ます。整合しないと次のような問題が起きます。

配信拒否や遅延
スパムフォルダ振り分け
ブロックリスト登録のリスク上昇

例えると、郵便で差出人住所が不明瞭だと配達先が疑うのと同じです。

仕組み（初心者向け）

Aレコードとは

ドメイン名（例: mail.example.com）をIPv4アドレス（例: 203.0.113.45）に変換するDNSレコードです。

PTR（逆引き）とは

IPアドレスからドメイン名を返すレコード。IP側の名前空間（in-addr.arpa）に登録され、通常はIPアドレスの割当事業者（ISP/クラウド事業者）が管理します。

要求される整合性

推奨される基本ルール：

PTRが返すホスト名が存在し、そのホスト名に対応するAレコードが元のIPを返す（双方向の整合性）。
PTRのホスト名はメールサーバーのHELO/EHLO名と一致していることが望ましい。

実例でイメージ

例：IP 203.0.113.45 を使うメールサーバー

PTR: 45.113.0.203.in-addr.arpa. PTR mail.example.com.
A: mail.example.com. A 203.0.113.45
HELO/EHLO: mail.example.com

この状態だと受信側は整合性を確認でき、信頼性が高まります。

設定方法・実践手順

手順の概要（結論→理由→例→手順）

結論：IP割当元にPTRを作成依頼し、DNS側でAレコードを正しく設定する。理由：PTRはIP側が管理するため、DNSホスティングだけでは完結しないからです。

詳細手順

送信に使う固定IPv4アドレスを確認する（例: 203.0.113.45）。
メールサーバーのホスト名を決める（例: mail.example.com）。HELO/EHLOも同じ名前にする。
あなたが管理するDNSゾーンでAレコードを追加する。例：
```
mail.example.com. IN A 203.0.113.45
```
IPの割当元（ISP、クラウド、ホスティング）に連絡してPTRの設定を依頼する。依頼内容の例：
```
203.0.113.45 -> mail.example.com
```
多くの場合管理画面やサポートチケットで依頼可能です。
PTRの設定後、DNSの伝播を待つ（通常数分〜48時間）。
動作確認：以下のコマンドで確認します。
```
# 逆引き (PTR)確認
dig -x 203.0.113.45 +short
# Aレコード確認
dig +short mail.example.com
# SMTPでHELO確認
telnet 203.0.113.45 25
```
期待される結果は PTR が mail.example.com を返し、digでmail.example.comが同じIPを返すことです。
SPF/DKIMも同時に正しく設定する。SPFでは送信IPを許可し、DKIMで署名すると更に信頼性が上がります。

よくあるトラブルと対処法

PTRが設定できない（ISP管理）

原因：IPの逆引きはISPが管理。対応：ISPサポートにPTR設定を依頼するか、固定IPを移管しているか確認する。

PTRとAが一致しない

原因：PTRが返す名前とAが指すIPが不一致。対応：Aレコードを修正するかISPにPTRを変更してもらう。どちらかを合わせる。

複数PTRが設定されている

問題点：RFC的には1つが望ましい。複数あると受信側で不正扱いされる可能性。対応：ISPに不要なPTRを削除してもらう。

HELO名とPTRが違う

受信側で警告・拒否されることがある。対応：メールサーバーの設定でHELO名をPTRと一致させる。

テストで「no reverse」の表示

逆引きが未設定。対応：PTRをISPに依頼する。

他の技術との関係

SPF

SPFはどのIPがそのドメインから送信可能かを示します。PTRとは別だが、SPFで許可されたIPとPTRの整合が取れていると信頼性が高まります。

DKIM

DKIMはメールに署名を付ける仕組み。PTRは署名とは別だが、DKIMがあると配信成功率がさらに改善します。

DMARC

DMARCはSPF/DKIMの結果を基にポリシーを実行します。PTRはDMARC判定の直接要素ではないが、配信信頼度を補強します。

チェックリスト（導入時）

固定IPを確保しているか
メールサーバーのホスト名を決定しHELOに設定したか
Aレコードでホスト名がIPを指しているか
ISPにPTR設定を依頼したか
dig/host/nslookupで双方向確認が取れたか
SPF/DKIMを設定し、テスト送信でヘッダを確認したか

まとめ

オンプレメール送信で重要なのは、送信元IPの逆引き(PTR)とそれに対応するAレコードの双方向一致を作ることです。PTRは多くの場合ISP側で管理されるため、DNS設定だけで完結しません。HELO名、SPF、DKIMと合わせて整備すれば、配信成功率と受信側の信頼度が大きく向上します。

逆引き(PTR)とAレコード整備ガイド