Reverse DNS (PTR) Records for Email: What They Are and How to Check

A PTR (pointer) record is the reverse of an A record: it maps an IP address back to a hostname. For email, the IP that sends your mail needs a PTR record, and the hostname it names must resolve back to that same IP. This round trip is called forward-confirmed reverse DNS, and Gmail and Yahoo both require it. Without it, mail is deferred, rejected or filtered.

You do not set PTR records in your own domain's DNS, and most senders never need to touch one. This guide covers how to check, what the major mailbox providers require, and who can change the record when it is wrong.

How reverse DNS works

A PTR record lives in a special reverse zone, named after the IP address written backwards. For IPv4, the four octets are reversed and in-addr.arpa is appended. The PTR for 209.85.220.41 is stored at 41.220.85.209.in-addr.arpa. IPv6 uses ip6.arpa and reverses every hex digit.

That naming is why you cannot add a PTR in your domain's DNS panel. The reverse zone belongs to whoever was allocated the IP block, and they delegate or manage it.

A single PTR lookup proves little, because anyone controlling a reverse zone can point it at any name, including yours. The check receivers care about goes both ways:

1. Reverse: look up the PTR for the connecting IP. You get a hostname.
2. Forward: look up the A (or AAAA) record of that hostname. It must include the original IP.

If both match, the IP has forward-confirmed reverse DNS (often written FCrDNS). This is older than any bulk-sender rule. RFC 1912, an informational guide to common DNS errors from 1996, already said: "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."

How to check yours with dig

Run dig -x on the sending IP, then look up the hostname it returns. Here is what we got on 7 October 2026 (UTC) for a few well-known sending IPs:

$ dig -x 209.85.220.41 +short
mail-sor-f41.google.com.
$ dig +short A mail-sor-f41.google.com
209.85.220.41

Sending IP	PTR	A record of that name	Forward-confirmed?
209.85.220.41 (Google)	mail-sor-f41.google.com	209.85.220.41	Yes
54.240.8.1 (Amazon SES)	a8-1.smtp-out.amazonses.com	54.240.8.1	Yes
198.2.128.1 (Mandrill)	mail128-1.atl41.mandrillapp.com	198.2.128.1	Yes
Our office broadband IP	none	n/a	No

The pattern is consistent: every mainstream sending service publishes a matching pair, and the residential connection publishes nothing.

To find the IP that actually sent a message, open the full headers of a message you received and read the top Received: line added by your own provider. Our guide to reading email headers shows which line to trust. If you prefer not to use the command line, Google's Admin Toolbox Dig has a PTR lookup.

What Gmail and Yahoo require

Both providers list valid forward and reverse DNS as a requirement for every sender, not only bulk senders.

Google's Email sender guidelines state: "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname." It continues: "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." Google's FAQ ties failures to specific codes, 4.7.23 and 5.7.25, which the Gmail and Yahoo requirements comparison lists alongside the other enforcement codes.

Yahoo's Sender Requirements say to "Have a valid forward and reverse DNS record for your sending IPs," and go further on what the name should look like: "Publish valid, meaningful, non-generic reverse DNS (PTR) records for all of your sending IPs," "Reverse DNS should reflect your domain name in some way," and "Do not use a reverse DNS that looks like a dynamically-assigned IP instead of a static mail server."

What a failure looks like

Yahoo refused our test connection at the first envelope command because the IP had no forward-confirmed reverse DNS. On 7 October 2026 we opened an SMTP session to Yahoo's inbound server from an office broadband connection with no PTR record, sending no message. The server greeted us normally, then answered MAIL FROM with:

550 5.7.25 Forward-confirmed reverse DNS failed

It closed the connection before we could name a recipient. Yahoo's public error codes page does not list this text, so treat that line as what we observed rather than documented behaviour. It matches Yahoo's written requirement and uses the same 5.7.25 enhanced code Google associates with PTR failures.

Spamhaus treats it as a reputation signal too. Its CSS blocklist page tells listed senders to "check all technical settings for correctness" first, and says "SMTP servers should be configured with correct forward and reverse DNS and HELO/EHLO values." See how blocklist removal works if you have already been listed.

Does the PTR have to match the EHLO name?

It should, but the standard does not let a server reject mail for a mismatch on that basis alone. RFC 5321, section 4.1.4, says an SMTP client must, if possible, give its primary host name in EHLO. It then says a server "MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis."

In practice, receivers use the EHLO name, the PTR and the forward lookup together as reputation signals, and the provider requirements above concern the PTR itself. The simplest configuration avoids the question: one hostname, such as mail.example.com, that is the PTR of the IP, has an A record pointing at the IP, and is the name the server announces in EHLO.

Who can change your PTR record

Whoever owns the sending IP controls its PTR, so the fix depends on how you send.

How you send	Who owns the IP	What you do
Google Workspace, Microsoft 365, Outlook.com, Gmail	The mailbox provider	Nothing. Their IPs already have FCrDNS
An ESP on a shared IP (Mailchimp, SendGrid, SES shared pool)	The ESP	Nothing. The PTR names the ESP, which is expected
An ESP on a dedicated IP	The ESP	Some ESPs let you set a branded hostname; follow their setup steps
Your own server at a cloud or VPS host	The host	Set reverse DNS in the host's control panel, or ask support
Your own server on business broadband	The ISP	Ask the ISP; many won't on dynamic or consumer ranges

Some dedicated IPs at SendGrid, for example, carry PTR records naming the customer's own domain rather than SendGrid's, which is what Yahoo's "reflect your domain name in some way" looks like in practice.

On a VPS, set the A record for your chosen hostname first, then set the PTR to that hostname in the provider's panel. Some providers will not accept a PTR whose name does not already resolve to the IP. Keep in mind that many cloud providers block outbound port 25 by default, so a correct PTR does not mean you can send; see which cloud providers block port 25.

Common PTR mistakes

Most reverse DNS failures come from one of five setups.

• No PTR at all. Typical of residential and many small business connections. Don't send direct-to-MX from these; relay through your provider or an ESP.
• A generic PTR. Names like 203-0-113-25.static.isp.example resolve, but look exactly like what Yahoo calls "a dynamically-assigned IP". Ask for a name under your own domain.
• A PTR that does not resolve forward. The PTR says mail.example.com, but that name has no A record, or points somewhere else after a migration.
• A PTR pointing at a CNAME. RFC 1912 says "PTR records must point back to a valid A record, not a alias defined by a CNAME."
• Only the first IP named. If the server sends from several IPs, or from IPv6 as well as IPv4, every address needs its own matching pair. RFC 1912 says the same for multi-homed hosts.

The short version

1. A PTR maps your sending IP to a hostname; that hostname must resolve back to the same IP.
2. Gmail and Yahoo require it for all senders. Yahoo also wants a non-generic name that reflects your domain.
3. Check with dig -x <ip> +short, then dig +short A <hostname>.
4. You change it through whoever owns the IP, not in your domain's DNS.
5. If you send through Google, Microsoft or an ESP, this is already handled. Spend the time on SPF, DKIM and DMARC instead, which you can check with the deliverability audit.