Reverse DNS and Email

How reverse DNS works

The forward DNS chain maps hostnames to IPs: mail.example.com → 203.0.113.45. Reverse DNS maps IPs to hostnames: 203.0.113.45 → mail.example.com. The reverse mapping uses a special DNS zone (in-addr.arpa for IPv4, ip6.arpa for IPv6) where each IP has a PTR record.

The lookup process:

1. Receiver wants to know who's connecting from 203.0.113.45.
2. Receiver queries 45.113.0.203.in-addr.arpa for a PTR record.
3. If a PTR exists, it returns a hostname (say, mail.example.com).
4. Receiver may then forward-resolve that hostname to confirm it points back at 203.0.113.45.

Forward-Confirmed Reverse DNS

FCrDNS is the two-step check:

1. IP → PTR → hostname.
2. Hostname → A/AAAA → IP.
3. Compare original IP to resolved IP. If they match, FCrDNS passes.

Most mail receivers run this check. Failures fall into categories:

• No PTR. The IP has no reverse record. Score down heavily.
• Generic PTR. Something like c-203-113-0-45.cable-isp.net looking like a residential or dynamic IP. Score down.
• PTR doesn't forward-resolve. The hostname has no A record. Score down.
• PTR forward-resolves to a different IP. Score down.

Why this is hard for spammers

To set up a PTR, you need cooperation from the IP block owner. Spammers using compromised home machines, hijacked cloud instances, or stolen IPs typically can't set arbitrary PTRs. The PTR check is therefore a coarse but effective filter: legitimate operators set their PTRs; spammers usually can't. Mail providers exploit this asymmetry.

How to set a PTR record

The PTR for an IP is controlled by whoever owns the IP block:

The hostname to put in PTR

For a mail server, the PTR should match the hostname your server uses in its SMTP EHLO greeting and in HELO logging. Reasonable conventions:

• Dedicated mail server: mail.example.com or mx1.example.com.
• Multiple servers: mta01.example.com, mta02.example.com — sequential.
• Outbound vs inbound: can use the same name; some operators separate out.example.com and in.example.com.

The forward A record for the chosen hostname must point at the IP. The IP's PTR must point at the hostname. Both must match.

IPv6 PTR

IPv6 PTR records live in ip6.arpa. The hostname for the PTR is the IPv6 address written with each nibble reversed and separated by dots. Example: address 2001:db8::1 has PTR at 1.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.

Most cloud providers automate this; you just set the human-readable hostname and they generate the in-addr/ip6.arpa entries. Mail receivers check IPv6 PTRs the same way they check IPv4.

When PTR mismatch is unavoidable

Some scenarios where strict PTR alignment is hard:

• Hosting providers with shared IPs. The PTR matches the provider's hostname, not yours. Mail from that IP is implicitly delegated to the provider's reputation.
• Behind a NAT. The outbound IP isn't yours; PTR follows the NAT operator's setup.
• Multi-region cloud with anycast. One name, many IPs. Each IP needs its own PTR; the forward record may be different per region.

For most production mail, use an SMTP provider (SendGrid, Mailgun, AWS SES, Postmark) that has proper PTRs configured on their sending IPs. You inherit their reputation and don't manage PTRs directly.

Diagnosing PTR issues

From a Linux/macOS terminal:

dig -x 203.0.113.45 +short            # forward lookup of PTR
dig mail.example.com +short            # forward A lookup
host 203.0.113.45                      # combined check

Several online tools (MXToolbox, dnschecker.org) check PTR records. For deliverability investigations, mail-tester.com simulates a full receiver-side check and reports PTR specifically.

What PTR is not

• Not authentication. SPF, DKIM, DMARC do authentication. PTR is one input to reputation.
• Not a security boundary. Setting a PTR doesn't restrict who can send from that IP.
• Not the only deliverability factor. IP reputation, sending volume, complaint rate, and content all matter too. PTR is necessary but not sufficient.

Frequently Asked Questions

Why does email care about reverse DNS?

Because PTR records are an inexpensive proof that the IP and the claimed sender are coordinated. Spammers using compromised hosts or stolen IPs typically can't set arbitrary PTR records; legitimate mail servers can. Receivers use this as a coarse but effective spam signal — IPs with no PTR or a generic-looking PTR get scored down.

What is FCrDNS?

Forward-Confirmed Reverse DNS — the check that both directions match. The receiver looks up the sending IP's PTR record to get a hostname, then looks up that hostname to get an IP, and confirms the result matches the original sending IP. If either direction fails or they don't match, FCrDNS fails.

Who controls the PTR record?

The owner of the IP block, not the user of the IP. For consumer ISPs that means the ISP — typically you cannot set arbitrary PTRs on a residential connection. For business internet with a static IP, the ISP can usually set a PTR on request. For cloud-hosted services, the cloud provider lets you set the PTR through the console or API. For dedicated hosting, the hosting provider sets it via control panel or support ticket.

What if my ISP won't set a PTR record?

Then you probably can't run a production mail server on that connection. Many ISPs explicitly block port 25 outbound from residential connections and don't allow custom PTRs, specifically to discourage open mail servers. The practical alternative is to relay through an outbound SMTP service (your ISP's smarthost, or a transactional email provider like SendGrid, Mailgun, AWS SES) that has proper PTRs configured on its sending IPs.

Does PTR need to match the EHLO/HELO hostname?

Yes, it should. Some receivers compare the PTR-derived hostname to the hostname the sending server announces in its EHLO greeting. Mismatch is a spam signal. Best practice: the sending IP's PTR points at the same hostname the mail server uses in EHLO, and that hostname's forward A/AAAA record points back at the IP.