Reverse DNS (PTR) and Email Authentication: What It Does and Does Not Do

DKIM

Introduction

A PTR record maps a sending server's IP address back to a hostname, and that hostname must resolve forward to the same IP. Gmail and Yahoo require this forward-confirmed reverse DNS from all senders. It is not part of SPF, DKIM or DMARC, though: a correct PTR record does not make DMARC pass, and a missing one does not make it fail.

PTR matters most for clients that run their own mail servers or relays. For mail sent through Microsoft 365, Google Workspace or an email service provider, the provider owns the IPs and the PTR records. This article explains what reverse DNS checks, who can change it, how to test it and how it relates to the authentication an MSP manages. For the protocol background, see the DMARC guide.

Key takeaways

• Reverse DNS turns an IP address into a hostname; forward-confirmed reverse DNS means that hostname resolves back to the same IP.
• Google and Yahoo list valid forward and reverse DNS as a requirement for all senders, not only bulk senders.
• PTR records live in the IP owner's zone, so they are set by the ISP, hosting or cloud provider, not in the client's domain DNS.
• DMARC never looks at PTR. It uses SPF and DKIM results aligned with the From domain.
• The SPF ptr mechanism is discouraged by RFC 7208 and should not be published.

What is a PTR record?

A PTR record is the reverse of an A record. An A record says which IP address a hostname has; a PTR record, published under the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones, says which hostname an IP address belongs to.

For a sending server at 203.0.113.25, the pair looks like this:

25.113.0.203.in-addr.arpa.  PTR  mail.example.com.
mail.example.com.           A    203.0.113.25

When the PTR hostname resolves back to the same IP, the result is called forward-confirmed reverse DNS. That match is what mailbox providers check.

Do Gmail and Yahoo require reverse DNS?

Yes, for every sender. Google's email sender guidelines list valid forward and reverse DNS among the requirements for all senders, and again for those sending 5,000 or more messages a day. Google states that the sending IP must have a PTR record resolving to a hostname, that hostname must have an A or AAAA record pointing back to the sending IP, and the two must match.

Yahoo's sender best practices also list valid forward and reverse DNS for sending IPs as a requirement for all senders. When Gmail refuses mail for this reason, its SMTP error reference uses 550 5.7.25 or 451 4.7.23; for IPv6 it also describes a 550 5.7.1 message about PTR records and authentication. Gmail bounce codes explained maps each code to a fix.

Does reverse DNS affect DMARC?

No. DMARC passes when SPF or DKIM passes for a domain aligned with the From address, as defined in RFC 9989. The PTR record of the sending IP is not part of that evaluation, and DMARC aggregate reports do not include a PTR result.

The two checks answer different questions:

So a server can have perfect reverse DNS and still fail DMARC, and a message can pass DMARC from an IP whose PTR is generic. Providers check both independently, which is why a missing PTR can cause rejections even on a domain at p=reject with everything aligned.

Who sets the PTR record for a sending IP?

Whoever owns the IP address. Reverse DNS zones are delegated with IP address blocks, so the client's domain DNS host cannot publish a PTR for an IP it does not own. That splits clients into two groups:

• Mail sent through a cloud platform or ESP (Microsoft 365, Google Workspace, marketing and transactional services): the provider owns the IPs and maintains their PTR records. There is nothing for the client to set.
• Mail sent from the client's own server or relay (on-premises Exchange, a hosted SMTP relay, a VPS, a multifunction printer sending directly, a line-of-business application): the PTR must be requested from the ISP or set in the hosting or cloud provider's console for that IP.

Most cloud providers let you set reverse DNS on a static or reserved public IP from their own console; some require the matching A record to exist first. Dynamic or shared consumer IP addresses usually cannot get a custom PTR at all, which is one reason not to send mail directly from them.

How do you check reverse DNS for a mail server?

Look up the PTR for the sending IP, then look up the A record of the hostname it returns, and compare:

$ dig +short -x 203.0.113.25
mail.example.com.
$ dig +short A mail.example.com
203.0.113.25

If the first command returns nothing, there is no PTR. If the second returns a different IP, the forward and reverse records do not match. Our DNS lookup tool can run both queries without a command line.

To find which IP actually sends, read the Received: headers of a delivered message or the source IPs in DMARC aggregate reports. How to read email headers shows where the connecting IP appears.

What does "reverse DNS does not match SMTP banner" mean?

It means the hostname a mail server announces in its SMTP greeting or EHLO command differs from the hostname in its PTR record. Many test tools raise this as a warning. It is a consistency check rather than a rule in the SMTP standard, but a server whose PTR, EHLO name and A record all agree is easier for receivers to trust and easier for you to troubleshoot.

On a self-managed server, set the server's announced hostname to the same fully qualified name as the PTR, for example mail.example.com, and make sure that name has an A record pointing to the sending IP.

Should SPF use the ptr mechanism?

No. RFC 7208, Section 5.5, describes ptr as slow and unreliable and says it should not be published. It also costs DNS lookups against the 10-lookup limit. Authorise sending servers with ip4:, ip6:, a or include: instead, and remove ptr if an old record still contains it. SPF record best practices covers the alternatives.

What should an MSP check per client?

Add reverse DNS to the sender inventory for every system that sends from an IP the client controls. For each one:

1. Identify the sending IP from headers or aggregate reports.
2. Check PTR and forward match with the two lookups above.
3. Check the EHLO hostname matches the PTR on self-managed servers.
4. Confirm SPF authorises the IP with ip4:, ip6: or a, not ptr.
5. Prefer relaying through the client's mail platform for devices and applications that cannot get proper reverse DNS, so they send from IPs the provider maintains.

Systems sending through Microsoft 365, Google Workspace or an ESP can be marked "PTR managed by provider" and left alone. DMARC client discovery explains how to find the self-managed senders in the first place.

FAQ

Do I need a PTR record if I use Microsoft 365 or Google Workspace?

No action is needed. Mail sent through those platforms leaves from the provider's IP addresses, and the provider maintains their reverse DNS. You still need SPF, DKIM and DMARC on your own domain.

Can I add a PTR record in my domain's DNS?

Not for an IP you do not own. PTR records sit in the reverse zone of the IP block, which the ISP, hosting provider or cloud provider controls. Ask them, or use their console, to set it.

Does a missing PTR record make DMARC fail?

No. DMARC only evaluates SPF and DKIM alignment with the From domain. But Gmail and Yahoo require valid reverse DNS separately, so mail from an IP without it can be rejected even when DMARC passes.

Does the PTR hostname have to be in my own domain?

Google's guidance is to set reverse DNS records that point to your domain, and the hostname must resolve back to the sending IP. A hostname in your own domain also makes logs and headers easier to read.

What PTR record does an IPv6 sending server need?

The same match, published in the ip6.arpa zone, with an AAAA record for the hostname. Google specifically mentions PTR problems as a reason for rejecting mail sent over IPv6, so check IPv6 sending paths as carefully as IPv4.

Final thoughts

Reverse DNS is infrastructure hygiene, not authentication. It tells receivers that an IP belongs to a named, accountable mail server, and Gmail and Yahoo expect it from everyone. Get it right for the few systems that send from IPs the client controls, then spend the rest of the effort where DMARC actually looks: SPF and DKIM aligned with the From domain.