Reverse DNS and PTR records for email: what receivers check and who controls it

What a PTR record is

Ordinary DNS maps a name to an address: mail.example.com resolves to 203.0.113.25. Reverse DNS goes the other way. The PTR record for 203.0.113.25 lives in a special zone—25.113.0.203.in-addr.arpa for IPv4—and returns a hostname. IPv6 addresses use the ip6.arpa zone in the same way.

Forward-confirmed reverse DNS means the two directions agree: the PTR names a hostname, and that hostname’s forward record returns the original IP. RFC 1912, an informational guide to common DNS errors, puts it plainly: make sure your PTR and A records match, because a mismatch can cost you Internet services much as if you were not in DNS at all. [1]

Why receivers check it

Reverse DNS is a cheap accountability signal. Residential connections and compromised machines often have generic or missing PTR records, while deliberately operated mail servers have deliberate ones. A valid record proves nothing about whether mail is wanted, but its absence suggests nobody is running the server as a mail system.

Google requires every sender to Gmail to have valid forward and reverse DNS records for its sending domains or IPs, and Yahoo requires the same for sending IPs. Gmail’s published errors show the consequence: 550 5.7.25 blocks a message when the sending IP lacks a PTR record or the forward DNS entry does not reference the sending IP, and 451 4.7.23 defers mail for the same mismatch. [2][3][4]

The SMTP standard is more cautious than current practice. RFC 5321 lets a server check whether the name a client gives in EHLO corresponds to its IP address, but says the server must not refuse a message on that basis alone. Mailbox providers now rely on the broader forward-and-reverse DNS requirement instead, so treat a missing or mismatched PTR as a delivery failure waiting to happen. [5]

Who controls the record

You cannot publish a working PTR record in your domain’s own DNS zone. Reverse zones are delegated to whoever holds the IP address block—usually a cloud provider, hosting company, or email service—so the record is set through that operator’s console, API, or support process.

That changes the checklist depending on how you send:

• Workspace mailboxes such as Google Workspace or Microsoft 365: the provider operates the sending servers and their reverse DNS; you authenticate your domain with SPF, DKIM, and DMARC.
• A sending provider on shared IPs: the provider owns the PTR, which names its hostname rather than yours. That is normal, because DMARC alignment comes from SPF and DKIM, not from reverse DNS.
• A dedicated IP from a provider: ask whether the PTR can name a hostname on your domain, who changes it, and whether the matching forward record is published.
• A self-hosted server on a cloud IP: you request the PTR from the cloud provider, often after it approves outbound port 25, and publish the matching A or AAAA record yourself.

Keep the EHLO name consistent

When a server connects, it introduces itself with EHLO, whose argument should be its fully qualified domain name. The cleanest configuration uses one hostname in three places: the EHLO greeting, the PTR record for the sending IP, and that hostname’s A or AAAA record pointing back to the same IP. [5]

Mismatches usually appear after a change: a server moves to a new IP, a hostname is renamed, or a container sends with a default name such as localhost. None of these is exotic, and all are easy to catch with a test message before real traffic.

How to check it

Check from a public resolver rather than inside your own network, where split-horizon DNS can show a record the rest of the world cannot see. Then confirm with a delivered message; the receiving server’s Received header is the evidence that matters.

• Find the sending IP in the Received headers of a delivered test message, not in the DNS records you expect to be used.
• Run dig -x 203.0.113.25 +short, or nslookup 203.0.113.25, to read the PTR hostname.
• Run dig mail.example.com A +short, or AAAA for IPv6, and confirm it returns the same IP.
• Compare that hostname with the EHLO name recorded in the Received header added by the receiving server.
• Repeat for every sending IP, including IPv6 addresses if the server can send over IPv6.

Common mistakes

Most PTR problems come from changes rather than initial setup. Recheck after migrations, IP reassignments, and provider changes, not only on the first day.

• Adding a PTR-style record to the domain’s own zone, where no receiver will ever look.
• Leaving a provider’s generic PTR on a dedicated IP that announces a different EHLO name.
• Pointing the PTR at a hostname with no forward record, or one that resolves to a different IP.
• Forgetting IPv6: a server with IPv6 connectivity may send over it, and that address needs its own matching records.
• Assuming a correct PTR fixes reputation. It removes one reason for rejection; it does not make unwanted mail welcome.

How Actually Agentic handles reverse DNS

Customers never manage sending servers or IPs. Mission Inbox operates the mailbox, server, and IP layer behind Actually Agentic, and the control plane pins each campaign to exact provider resources. Before warm-up, it verifies forward DNS and PTR alignment along with SPF, DKIM, DMARC, MX, and return-path records, and DNS and IP checks must pass again before a person approves launch. [6][7]

If a check fails, the campaign waits rather than sending around the problem. Actually Agentic is prelaunch, and a correct PTR record, like every other check here, reduces risk without guaranteeing inbox placement. [8]