自前のメールサーバーからGmailなどへメールを送信するとき、「PTRレコード（逆引きDNS）は必要なのか？」と疑問に思うことがあります。
SPF・DKIM・DMARCを設定しているから、PTRレコードまでは必要ないと思うかもしれません。
しかし現在のGmailのメール送信者ガイドラインでは、Gmailへメールを送信するすべての送信者について、送信元ドメインまたはIPアドレスに有効な正引き・逆引きDNSレコードを設定することが要件になっています。
PTRレコードがない、または逆引きしたホスト名を正引きしても元の送信IPアドレスへ戻らない場合、メールのレート制限や拒否につながる可能性があります。
PTRレコードとは？
PTR（Pointer）レコードは、IPアドレスからホスト名を調べるために使用するDNSレコードです。
通常のAレコードでは、次のようにホスト名からIPアドレスを調べます。
mail.example.com
↓
203.0.113.10これを「正引き」と呼びます。
PTRレコードでは反対方向に検索します。
203.0.113.10
↓
mail.example.comこれが「逆引き」です。
メールサーバーでは正引きと逆引きの整合性が重要
Googleのメール送信者ガイドラインでは、送信SMTPサーバーのパブリックIPアドレスについてPTRレコードが必要とされています。
さらに、PTRレコードから返されたホスト名にはAレコードまたはAAAAレコードがあり、それを正引きすると元の送信IPアドレスへ戻る必要があります。
例えば次のような状態です。
送信メールサーバー
203.0.113.10
↓ PTR
mail.example.com
↓ A
203.0.113.10逆引きで取得したホスト名をもう一度正引きすると、同じ送信元IPアドレスへ戻ります。
PTRレコードがないとGmailではどうなる？
GoogleはPTRレコードが存在しない、または正引きとの整合性が取れていない送信元に対するエラーコードも公開しています。
代表的なものに次があります。
4.7.23送信元IPアドレスにPTRレコードがない、またはPTRレコードの正引きDNSエントリが送信元IPアドレスと一致していない場合に、レート制限の対象となることがあります。
さらに、
5.7.25では、PTRレコードがない、または正引きDNSが送信元IPアドレスを参照していないことを理由にメールがブロックされる場合があります。
つまりPTRレコードは、単なる「あった方がよい設定」ではなく、現在のGmailでは送信者要件の一つです。
PTRレコードがあれば迷惑メールにならない？
いいえ。
PTRレコードを正しく設定しただけで、メールが必ず受信トレイへ届くわけではありません。
Googleはメール送信者に対してPTR以外にも、
- SPFまたはDKIM
- TLSによるメール送信
- RFC 5322に準拠したメール形式
- 低い迷惑メール率の維持
- 送信元IPやドメインのレピュテーション
などを求めています。
また、Gmailへ1日5,000件を超えて送信する送信者には、SPFとDKIMの両方に加えてDMARCなど追加要件があります。
そのため、
PTR OK
SPF OK
DKIM OK
DMARC OKだから必ず迷惑メールにならない、というわけではありません。
SPF・DKIM・DMARCとPTRは何が違う？
PTRはSPF・DKIM・DMARCの代わりになる仕組みではありません。
それぞれ確認している内容が異なります。
- PTR：送信元IPアドレスとホスト名のDNS上の対応を確認
- SPF：そのIPアドレスがドメインからメールを送信してよいか確認
- DKIM：電子署名を使ってメールの送信元や改ざんの有無を確認
- DMARC：SPF/DKIMとFromドメインの整合性を利用して認証ポリシーを適用
メール配送を安定させるには、これらを組み合わせて考える必要があります。
SPF・DKIM・DMARCがpassでも迷惑メールになることがある
実際のメールヘッダーを確認すると、
spf=pass
dkim=pass
dmarc=passとなっていても、受信側の迷惑メール判定はそれだけで決まるわけではありません。
メールの認証結果だけでなく、送信元IP・ドメインの評価、メールの内容、送信量、ユーザーからの迷惑メール報告など、さまざまな要素が影響します。
そのため「SPF/DKIM/DMARCが全部passなのに迷惑メールになる」という場合でも、PTRや送信元IPの状態を確認する価値があります。
PTRレコードをdigで確認する
LinuxやmacOSでは、digコマンドで逆引きを確認できます。
dig -x 203.0.113.10正常にPTRが設定されていれば、ホスト名が返ります。
例えば、
203.0.113.10
↓
mail.example.comのような結果になったとします。
次にそのホスト名を正引きします。
dig mail.example.comここで、
mail.example.com
↓
203.0.113.10と元のIPアドレスへ戻るか確認します。
nslookupでも確認できる
Windowsではnslookupでも確認できます。
nslookup 203.0.113.10PTRレコードからホスト名が取得できたら、そのホスト名を正引きします。
nslookup mail.example.com正引き結果がメール送信時に使用しているグローバルIPアドレスと一致しているか確認します。
どのIPアドレスのPTRを確認すればいい？
ここで注意したいのが、社内メールサーバー自身のプライベートIPアドレスではありません。
確認したいのは、インターネット上の受信メールサーバーから見える最終的な送信元グローバルIPアドレスです。
例えば、
業務システム
↓
Postfix
↓
FortiMail
↓
NAT / Firewall
↓
インターネット
↓
Gmailという構成なら、GmailへSMTP接続している最終的な送信元IPを確認します。
受信したメールのヘッダーにあるReceived:やReceived-SPF:なども、実際の送信経路を確認する手掛かりになります。
PTRレコードはどこで設定する？
PTRレコードは通常のドメインDNSレコードとは管理方法が異なる場合があります。
AレコードやMXレコードは自分が管理するDNSサーバーで設定できても、グローバルIPアドレスのPTRレコードは、そのIPアドレスを管理しているISP、データセンター、クラウド事業者などで設定することがあります。
そのためDNS管理画面にPTRの設定項目が見つからない場合は、グローバルIPアドレスを提供している事業者へ確認します。
PTRにはどんなホスト名を設定する？
例えば送信メールサーバーとして、
mail.example.comを使用するなら、次のように正引き・逆引きが一致する構成が分かりやすいでしょう。
203.0.113.10
↓ PTR
mail.example.com
↓ A
203.0.113.10重要なのは、PTRで返されたホスト名を正引きした結果が、実際の送信元IPアドレスと一致していることです。
メールが迷惑メールになるときの確認項目
自前のメールサーバーから送信したメールがGmailなどで迷惑メールになった場合は、PTRだけを見るのではなく、次の項目をまとめて確認します。
- 送信元グローバルIPにPTRがあるか
- PTRで返るホスト名を正引きすると元のIPへ戻るか
- SPFがpassしているか
- DKIMがpassしているか
- DMARCがpassしているか
- 送信元IPがブロックリストに掲載されていないか
- 送信元IPやドメインのレピュテーションに問題がないか
- 迷惑メール報告率が高くなっていないか
Gmailの場合はGoogle Postmaster Toolsを利用すると、送信ドメインやIPに関する情報を調査する手掛かりになります。
まとめ
メールサーバーからGmailなどへメールを送信する場合、PTRレコードは重要です。
特にGmailでは、現在のメール送信者ガイドラインで有効な正引き・逆引きDNSレコードが送信者要件になっています。
確認するポイントは、
送信元IP
↓ PTR
ホスト名
↓ A / AAAA
元の送信元IPという関係が成立していることです。
ただし、PTRを設定すれば迷惑メール問題がすべて解決するわけではありません。
PTR・SPF・DKIM・DMARC・送信レピュテーションなどをまとめて確認することが、メール配送トラブルを調査するときには重要です。
コメント