A PTR record is the reverse of an address lookup. Given an IP address, it returns a hostname. Mail servers use it to answer a basic question about anyone connecting to them: does this machine have a name, and does that name check out?
How is a PTR record different from the records I publish?
It lives in a zone you probably do not control.
Your DKIM, DMARC and MX records sit in your own domain's DNS, where you have authority. A PTR record sits in the reverse zone for an IP address block, and authority over that follows the address rather than the domain. Whoever was allocated the range delegates it, which means your hosting provider or your sending platform, not you.
This is why the answer to "how do I add a PTR record for my email" is usually "you ask, or you already have one". You cannot publish it yourself unless you own the addresses.
What exactly is required?
That the lookup works in both directions and agrees with itself.
Google states the requirement on its sender guidelines and repeats the constraint twice, which is a fair indication of how often it is met halfway:
The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname. This is called a reverse DNS lookup. The same hostname must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server. This is called a forward DNS lookup.
and again, as a callout of its own:
Important: The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.
So there are three things, not one: the IP resolves to a name, the name resolves to an address, and that address is the one you are sending from. A PTR record pointing at a hostname that no longer resolves is a failure, and so is one pointing at a hostname that resolves to a different machine.
The advice is older than the email requirements built on it. RFC 1912, which catalogues common DNS mistakes, gave the rule and the reason:
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all.
It also names a trap that still catches people: "PTR records must point back to a valid A record, not a alias defined by a CNAME."
Is it actually enforced?
Yes, and at the lowest tier of requirements rather than only for bulk senders.
Google's requirements for all senders include valid forward and reverse DNS, alongside authentication and TLS. It is not on the bulk-sender list, it is on the list that applies to everybody. The Gmail and Yahoo requirements covers the two tiers.
Google also reports it as a specific delivery error in Postmaster Tools, where "Bad or missing PTR record" appears beside entries like "IP is in one or more public RBLs". If you have a domain in Postmaster Tools and mail is failing, that dashboard will name this cause rather than leave you guessing.
Spamhaus makes the same point from the receiving side, listing among its practices for keeping an IP reputable: "ensure that your hostname and your HELO match, and that your reverse DNS (PTR record) is defined and pointing to the same hostname."
Do I need to do anything about it?
Almost certainly not, and knowing why saves an afternoon.
| How you send | Who owns the PTR record |
|---|---|
| Through a sending platform's shared IPs | The platform. Already configured, and not visible to you |
| On a dedicated IP from a platform | The platform, which announces the address |
| Your own mail server on your own IP | You, through whoever allocated the address block |
Only the third row is work. In the first two the record exists and matches, because a sending platform whose reverse DNS did not match would fail Google's baseline requirement for every customer at once.
The reason to understand it anyway is diagnosis. If you are told your mail is failing on reverse DNS and you send through a platform, the fault is not something you can fix in your own DNS, and looking for it there wastes the time you should spend opening a support case. If you run your own server, this is one of the first things to check when a new IP behaves badly, alongside whether it is on a blocklist.