Reverse DNS and PTR records for mail servers

Reverse DNS is the oldest and simplest check a receiving mail server makes about you. Before it looks at SPF, DKIM or content, it can ask: does this IP address have a name, and does that name point back to this IP? If the answer is no, Gmail and Yahoo say you're not meeting their sender requirements. This guide explains what to set, who can set it, and how to check it.

What is a PTR record?

Normal DNS turns a name into an address. Reverse DNS turns an address back into a name, using a PTR record.

For IPv4, RFC 1035 section 3.5 puts the address's octets in reverse order under in-addr.arpa. Its example: data for 10.2.0.52 "is located at domain name 52.0.2.10.IN-ADDR.ARPA". For IPv6, RFC 3596 uses each hexadecimal digit (nibble), reversed, under ip6.arpa.

; Forward (in example.com's zone, which you control)
mail.example.com.           A     198.51.100.25

; Reverse (in the IP owner's zone)
25.100.51.198.in-addr.arpa. PTR   mail.example.com.

The two records live in different places. You control the forward record in your domain's DNS. The reverse record lives in a zone delegated to whoever owns the IP block.

What is forward-confirmed reverse DNS (FCrDNS)?

A PTR record on its own proves nothing, because anyone who controls an IP block can point it at any name. Receivers close the loop by checking the name's forward record too:

1. Look up the PTR for the connecting IP and get a hostname.
2. Look up that hostname's A (IPv4) or AAAA (IPv6) record.
3. Check that the original IP is in the answer.

If it is, the IP has forward-confirmed reverse DNS. RFC 8601 calls this check iprev, and you may see iprev=pass in Authentication-Results headers. RFC 8601 defines permerror as "no PTR data are published for the connecting IP address". It also notes iprev isn't strong authentication; receivers use it as a hygiene and reputation signal.

RFC 1912 has said since 1996 that "Failure to have matching PTR and A records can cause loss of Internet services".

Why do Gmail, Yahoo and Microsoft care?

Because legitimate mail servers almost always have stable, named addresses, while hijacked home computers and throwaway servers often don't.

• Gmail. Google's sender guidelines apply to everyone who sends to Gmail, not just bulk senders. They say: "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname. 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."
• Yahoo. Yahoo's Sender Best Practices list "Have a valid forward and reverse DNS record for your sending IPs" for all senders.
• Microsoft. Microsoft documents that the IPs Microsoft 365 sends from "have forward-confirmed reverse DNS records", and that some recipient servers use PTR lookups for validation.
• M3AAWG. The Sender Best Common Practices (version 4.0, August 2026) say the sending IP "must have reverse DNS", that there "must be only one reverse DNS name configured per IP address", and that it must match the server's primary forward name. It adds: "This is now a requirement for direct mail sent to major mailbox providers."
• Blocklists. Spamhaus's CSS page says SMTP servers "should be configured with correct forward and reverse DNS and HELO/EHLO values". Missing or mismatched reverse DNS can contribute to a listing; see how to get off an email blacklist.

Who sets the PTR record?

Whoever owns the IP address. RFC 1035 explains that the reversed format exists so reverse zones can be delegated along network boundaries, which means they follow address ownership, not domain ownership.

Create the matching A or AAAA record first, so the pair is complete the moment the PTR is published.

What should the PTR name be?

Follow M3AAWG's rules and you'll satisfy every major receiver:

1. Pick one primary hostname per sending IP, such as mail.example.com. M3AAWG says there must be only one PTR name per IP.
2. Make the forward record match exactly. mail.example.com must resolve to the same IP the PTR is on.
3. Make it identify the responsible party. On a dedicated server, use your own domain. On shared IPs, the provider's name is normal. Our guide to shared vs dedicated IPs explains the difference.
4. Make it look like a server, not a pool. M3AAWG's example: server03.espname.com, not pool-dhcp-456.espname.com.
5. Use the same name for HELO/EHLO. RFC 5321 requires the EHLO name to be a fully qualified domain name that resolves to an address, or an address literal. M3AAWG says the HELO must exactly match the primary forward name on dedicated IPs.

Generic vs proper PTR names

Spamhaus also lists localhost.localdomain, a bare mail and Windows default names such as WIN-XYZPDQ01 as common HELO misconfigurations.

How do you check your PTR record?

1. Find your sending IP. Send a message to an outside mailbox and open its headers in the Email Header Analyzer. The first external Received line shows the IP. If you use a hosted platform, that IP belongs to the platform.
2. Look up the PTR. Use the PTR Lookup, or from a terminal run dig -x 198.51.100.25 +short (Linux and macOS) or nslookup 198.51.100.25 (Windows).
3. Look up the forward record. Run dig mail.example.com A +short (or AAAA for IPv6) and confirm the same IP comes back.
4. Check the HELO name. On your own server, check the configured hostname your mail software announces and confirm it matches.
5. Read the receiver's verdict. Receivers that record the check show it as iprev=pass (or fail) in the Authentication-Results header.
6. Test IPv6 separately. If your server has an IPv6 address and sends over it, it needs its own PTR and AAAA pair. Gmail returns "550-5.7.1: Message does not meet IPv6 sending guidelines regarding PTR records and authentication" when it doesn't (our 550 5.7.1 page covers the other reasons servers send that code). A missing or mismatched PTR on IPv4 typically shows up as 550 5.7.25, reverse DNS validation failed.

PTR changes can take time to show, because resolvers cache the old answer until its TTL expires.

Common PTR problems and fixes

Next steps

1. Check every IP that sends mail as your domain with the PTR Lookup, including printers, scanners and web apps.
2. Fix any missing or mismatched records with your host or ISP.
3. Check those IPs against the Blacklist Checker, and confirm your domain's SPF, DKIM and DMARC with the Email Health Check.
4. Review the Gmail, Yahoo and Microsoft bulk sender requirements if you send in volume.

If you'd rather not manage a sending IP yourself, send through an outbound relay instead. iBlockSpam's outbound relay is one option, with DKIM signing and 500 messages per month included.

Browse more guides on running email day to day.