Reverse DNS (PTR records) for mail servers

Reverse DNS maps an IP address back to a host name through a PTR record. For a mail server, the PTR name should resolve forward to the same IP again; this round trip is called forward-confirmed reverse DNS (FCrDNS). Gmail and Yahoo require it from every sender, Outlook.com asks for valid reverse DNS, and Gmail may defer or refuse mail from an IP that fails it. The PTR record is set by whoever controls the IP address, usually your hosting provider or email service provider, not in your own domain's DNS zone.

What a PTR record is

Forward DNS answers "which IP has this name?" with an A record (IPv4) or AAAA record (IPv6). Reverse DNS answers the opposite question with a PTR record, which RFC 1035, section 3.3.12, defines as a simple pointer to another domain name.

The pointer lives under special domains built from the address itself. For IPv4, RFC 1035, section 3.5, puts the data in the in-addr.arpa domain, with the four octets of the address in reverse order. For IPv6, RFC 3596, section 2.5, uses the ip6.arpa domain: the address is written out as 32 hexadecimal digits (nibbles), and they are reversed one by one. For the documentation addresses 192.0.2.25 and 2001:db8::25 the records look like this:

25.2.0.192.in-addr.arpa.  IN PTR  mail.example.com.
5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR  mail.example.com.

mail.example.com.  IN A     192.0.2.25
mail.example.com.  IN AAAA  2001:db8::25

RFC 1035, section 3.5, explains that the reversed order lets reverse zones be delegated along network boundaries. That is why you cannot add a PTR record for your server to example.com: it belongs in the zone of whoever holds the address block.

Forward-confirmed reverse DNS

Whoever controls a reverse zone can point a PTR record at any name, even one they do not own, so a PTR alone proves little. Receivers check the round trip: look up the PTR name of the connecting IP, look up that name's A or AAAA record, and expect the original IP in the answer. Google's email sender guidelines describe exactly these two lookups, and RFC 1912, section 2.1, gives the same advice for any host: PTR and A records should match.

Why receivers check it

A matching PTR and forward record shows that someone deliberately named and runs the server. M3AAWG describes the goal of its reverse DNS rules as transparency of ownership: a receiver or an abuse desk should be able to tell who is responsible for an IP. The large mailbox providers all ask for it:

Sources: Google, Yahoo sender best practices, Outlook.com postmaster policies, Exchange Online NDR reference. For the rest of each provider's rules, see Gmail and Yahoo sender requirements and Outlook sender requirements.

The standards leave this to local policy. RFC 5321, section 4.1.4, forbids refusing a message only because the EHLO name does not match the client's IP, but a reverse DNS policy is a different test: RFC 7372, section 3.3, defines X.7.25, "reverse DNS validation failed", for servers whose local policy requires it.

Choosing a good PTR name

The industry group M3AAWG gives the most concrete naming rules, in section 2.6 of its Sender Best Common Practices (version 4.0, August 2026):

• Name the responsible party. On a shared IP, that is the email service provider's domain. On a dedicated IP it is normally the customer's domain, or an entity-specific name under the provider such as entity.cust.esp.example, so a reader can tell who sends.
• Look like a server, not a pool. A name like server03.espname.com is fine; one like pool-dhcp-456.espname.com looks like dynamic address space. Yahoo makes the same point: the PTR should reflect your domain and should not look like a dynamically assigned address. Google's guidelines likewise ask for reverse DNS records that point to your domain.
• One PTR per IP, matching the primary forward name exactly.
• One registered domain. Use server1.espname.com and server2.espname.com, not a string of look-alike domains.

M3AAWG also recommends that the domain used in the PTR and HELO names can receive mail (it has an MX record) and accepts the postmaster and abuse addresses, so receivers can reach the operator.

If your server runs on an IP from a cloud or hosting provider, any default PTR name it carries belongs to the provider and says nothing about you. Replace it with a name in your own domain before you send.

The HELO/EHLO name

A sending server introduces itself with the EHLO (or older HELO) command. RFC 5321, section 4.1.1.1, says the argument is the client's fully qualified domain name when one is available, and section 2.3.5 requires that name to be a primary host name, one that resolves to an address record. An address literal is allowed only when the host has no name.

The EHLO name, PTR name and forward record should agree. M3AAWG's rules:

• The HELO name must be a resolvable host name. An IP literal in brackets is acceptable only between your own internal servers.
• On a dedicated IP, the HELO name must match the primary forward DNS name exactly.
• On a shared IP or behind NAT, it must match at least at the registered-domain level: a HELO of server01.brand1.espname.com fits an IP whose primary name is in espname.com.

The HELO name also matters for SPF. RFC 7208, section 2.3, recommends that receivers check the HELO identity as well as MAIL FROM, and section 2.4 falls back to it for bounces, which have an empty MAIL FROM. Check your HELO host name's SPF record with the SPF checker, and stay under the SPF lookup limit. Do not use the SPF ptr mechanism: RFC 7208, section 5.5, says it should not be published.

Who sets the PTR record

The holder of the IP address controls its reverse zone, so the steps depend on how you send:

• Shared IPs at an email service provider. The provider sets the PTR to a name in its own domain; you have nothing to do. Your domain is authenticated through SPF, DKIM and DMARC instead.
• Dedicated IPs at an email service provider. Ask which PTR name the provider uses. M3AAWG recommends an entity-specific name, and a PTR pointing to your own domain when you bring your own IP range. A new dedicated IP also needs warm-up.
• Your own server at a cloud or hosting provider. Set the PTR in the provider's control panel or through its support, and add the matching A or AAAA record in your own zone.
• A home or office connection. The PTR belongs to your ISP. Outlook.com says connections from dynamic IP space may be refused, so send through your mail provider's relay instead.

When an IP or host name changes, update the PTR, the forward record and the EHLO name together.

IPv6 needs its own PTR

A server with both IPv4 and IPv6 may deliver over IPv6 without you noticing. Each IPv6 address needs its own PTR record under ip6.arpa and its own AAAA record; the IPv4 setup does not cover it. Google's sender guidelines say an IPv6 authorization error can mean the PTR record is not set up for IPv6, and ask you to confirm that your email service provider uses an IPv6 PTR record. Microsoft 365 refuses IPv6 mail from an address without reverse DNS, and M3AAWG treats its IPv4 rules as the minimum for IPv6. If you cannot set an IPv6 PTR, send over IPv4 only.

How to check your setup

Find the sending IP in a bounce or in the Received: headers of a message you sent, then run the round trip:

dig -x 192.0.2.25 +short
dig mail.example.com A +short
dig mail.example.com AAAA +short
nslookup 192.0.2.25

Per the BIND 9 manual, dig -x builds the in-addr.arpa or ip6.arpa name for you and asks for the PTR record; +short prints only the answer. On Windows, nslookup returns the host name for an IP address. Google's sender guidelines also link a browser-based dig tool.

Check three things: there is exactly one PTR name, its forward record contains the same IP, and the name your server sends in EHLO is the same name or at least in the same domain.

Gmail errors that point to reverse DNS

Google's SMTP error reference ties four replies to PTR problems:

Retries of the 4xx deferrals keep failing until DNS is fixed. None of these codes is about the recipient: keep the address and fix the server.

Questions

Does the PTR name have to match my From: domain?

Not exactly. Google asks for reverse DNS that points to your domain and Yahoo for a name that reflects it, but on shared IPs M3AAWG has the PTR name the provider, which is the responsible party there. What ties mail to your From: domain is DMARC alignment through SPF or DKIM; see moving DMARC from none to reject.

Can an IP have more than one PTR record?

DNS allows it, but M3AAWG asks for exactly one reverse DNS name per sending IP, matching the primary forward name. Keep one, and use that name in EHLO.

Does a correct PTR record get my mail into the inbox?

No. It removes one reason for a refusal. Placement still depends on authentication, complaints, bounces and the reputation of your IP and domain.

Try it

Check the SPF record of your sending domain or HELO host name with the SPF checker. Once the server side is fixed, run your list through bulk email verification so that your first sends do not add hard bounces.

Related

• Bounce code 550 5.7.25: mail refused for missing or mismatched reverse DNS.
• Bounce code 421 4.7.0: temporary policy deferrals, including missing PTR records.
• Glossary: SMTP and sender reputation.
• The DNS tools: SPF, DKIM, DMARC and BIMI checkers.

Related guides

• Gmail and Yahoo sender requirements
• Outlook.com requirements for high-volume senders
• Email warm-up for new IPs and domains
• The SPF 10-lookup limit explained
• Moving DMARC from p=none to p=reject
• All guides

Sources

• Google: Email sender guidelines: the forward and reverse DNS requirement, the PTR round trip, IPv6 PTR errors.
• Google: Gmail SMTP errors and codes: 421 4.7.0, 451 4.7.23, 550 5.7.25 and 550 5.7.1 texts.
• Yahoo: Sender best practices: forward and reverse DNS requirement, non-generic PTR names.
• Outlook.com Postmaster: Policies, practices and guidelines: valid reverse DNS, dynamic IP space.
• Microsoft Learn: Email nondelivery reports and SMTP errors in Exchange Online: 5.7.25 for IPv6 senders without reverse DNS.
• M3AAWG: Sender Best Common Practices, version 4.0: section 2.6 on forward DNS, reverse DNS, HELO names, IPv6 and dedicated IPs.
• RFC 1035, Domain Names: Implementation and Specification: sections 3.3.12 (PTR) and 3.5 (in-addr.arpa).
• RFC 3596, DNS Extensions to Support IP Version 6: section 2.5 (ip6.arpa).
• RFC 1912, Common DNS Operational and Configuration Errors: section 2.1 on matching PTR and A records.
• RFC 5321, Simple Mail Transfer Protocol: sections 2.3.5, 4.1.1.1 and 4.1.4 on the EHLO name.
• RFC 7372, Email Authentication Status Codes: section 3.3, X.7.25.
• RFC 7208, Sender Policy Framework: sections 2.3, 2.4 and 5.5 on the HELO identity and the ptr mechanism.
• ISC: BIND 9 manual pages: dig -x and +short.
• Microsoft Learn: nslookup: reverse lookups with an IP address.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.