Skip to content
correct.email
Mail infrastructure

Reverse DNS (PTR) for mail servers

How reverse DNS and forward-confirmed reverse DNS work for mail servers, who sets the PTR record, what Gmail requires, and how to fix HELO and IPv6 problems.

By Exmoor Software7 min read

When your server connects to deliver a message, the receiving server sees only its IP address. Reverse DNS turns that address back into a name, and many receivers — Gmail among them — expect the name to exist and to point back to the same address.

This matters if you run your own sending server: a mail server on a VPS, an on-premises Exchange or Postfix, an application server that delivers mail directly. If you send through Google Workspace, Microsoft 365 or an email service provider, they take care of reverse DNS for their own IP addresses.

How reverse DNS works

Reverse lookups use special DNS zones. For IPv4 it is in-addr.arpa, with the four parts of the address in reverse order (RFC 1035, section 3.5). The record that holds the name is a PTR record:

25.2.0.192.in-addr.arpa.  3600  IN  PTR  mail.example.com.

That is the reverse entry for 192.0.2.25. For IPv6 the zone is ip6.arpa, and the name is built from every hexadecimal digit (nibble) of the full address, in reverse order (RFC 3596, section 2.5). For 2001:db8::25:

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.

You rarely have to write these names by hand: dig -x and the reverse DNS lookup build them for you.

Who controls the PTR record

Not you — or at least not through your domain’s DNS. The reverse zone of an address belongs to whoever holds the address block: your hosting or cloud provider, or your ISP. A PTR record added to the example.com zone does nothing.

To set it:

  • Hosting and cloud providers usually have a “reverse DNS” or “PTR” field in the settings of the server or IP address, or set the record on request through support. Create the A/AAAA record for the name first, so the pair is complete as soon as the PTR appears.
  • Your own address block — the reverse zone is delegated to you, and you publish PTR records there like any other records. Blocks smaller than a /24 can be delegated with the CNAME technique described in RFC 2317.
  • Residential and dynamic connections usually come with a fixed, generic name you can’t change. Don’t send mail directly from them; use a relay instead.

Forward-confirmed reverse DNS (FCrDNS)

Anyone who controls an IP block can make its PTR records say anything — including mail.bank.example. That’s why receivers don’t trust the PTR name alone and check it in both directions:

  1. Look up the PTR record of the connecting IP → mail.example.com.
  2. Look up the A (or AAAA) records of that name.
  3. The address list must contain the original IP.

If step 3 succeeds, the name is forward-confirmed: the owner of the domain agrees that this server carries its name. From a terminal:

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

On Windows, use Resolve-DnsName 192.0.2.25 and then Resolve-DnsName mail.example.com.

The chain typically breaks because the server moved to a new IP and only one direction was updated, or because the PTR name has no A record at all. The PTR target should also be a name with its own A/AAAA record, not an alias: RFC 1912 says PTR records must point back to a valid A record, not a name defined by a CNAME.

What Gmail requires

Google’s email sender guidelines list reverse DNS among the requirements for all senders, not only bulk senders: sending domains or IPs must have valid forward and reverse DNS records. The infrastructure section spells it out:

  • the public IP address of the sending server must have a PTR record that resolves to a host name;
  • that host name must have an A (IPv4) or AAAA (IPv6) record that resolves to the same IP address;
  • the PTR records should point to your domain.

Google puts the key rule in one sentence: “The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.” Other mailbox providers publish their own requirements; see Sender requirements of Gmail, Yahoo and Outlook.

Keep the HELO name consistent

At the start of each SMTP session the sending server introduces itself with EHLO (or the older HELO) and a name. RFC 5321 requires this to be, where possible, the server’s primary host name — a fully qualified name that resolves to an address — and otherwise an address literal such as [192.0.2.25].

A receiving server may check whether the EHLO name matches the connecting IP, but RFC 5321 forbids rejecting a message on that basis alone. Receivers do use it in other ways, though:

  • SPF can be checked for the HELO name (RFC 7208, section 2.3 recommends it), and for bounces, which have an empty envelope sender, SPF uses the HELO name as the sender domain.
  • A name like localhost, an internal server01.local or a name that doesn’t resolve is an obvious sign of a misconfigured server.

The simplest setup uses one name in all three places: the PTR record, the A/AAAA record and the EHLO greeting. In Postfix, the EHLO name comes from myhostname. Publish an SPF record for that host name too:

mail.example.com.            IN  A    192.0.2.25
mail.example.com.            IN  TXT  "v=spf1 a -all"
25.2.0.192.in-addr.arpa.     IN  PTR  mail.example.com.

Avoid generic-looking names

Providers often give every address a default name derived from the IP, such as 203-0-113-25.static.hosting.example or host-203-0-113-25.pool.isp.example. Such a name may even pass forward confirmation, but it doesn’t point to your domain as Google recommends, and it looks like the names given to end-user connections. Spam filters may treat it that way.

Choose a plain, descriptive name in your own domain — mail.example.com, smtp1.example.com — set it as the PTR, and create the matching A/AAAA record.

IPv6 specifics

IPv6 is where reverse DNS breaks most often, because it is easy to forget:

  • Your server may send over IPv6 without you noticing. If it has an IPv6 address and the receiving MX has an AAAA record, the connection may well use IPv6. Then the IPv6 address needs its own PTR and AAAA records — a correct IPv4 setup doesn’t help. Gmail reports the problem with an error such as 550 5.7.1 This message does not meet IPv6 sending guidelines regarding PTR records and authentication.
  • The source address must be the one you configured. A server can have several IPv6 addresses, some of them generated automatically. Bind the mail server to a fixed address (in Postfix, smtp_bind_address6) and set the PTR for exactly that one.
  • No IPv6 PTR available? Configure the mail server to send over IPv4 only (in Postfix, inet_protocols = ipv4) until you can get one.
  • Don’t forget SPF. The IPv6 address must be authorized as well, for example with ip6:2001:db8::25.

Every sending IP needs its own PTR

Each address your mail can leave from needs a PTR record and a matching forward record — RFC 1912 makes the same point for hosts with several addresses. DNS allows more than one PTR record per address, but a single name is the easiest to keep consistent with the A record and the EHLO name.

How to check

  1. Find the address your mail actually leaves from. Send a message to an external mailbox, open the original and look at the topmost Received header added by the receiving server. It shows the connecting IP, usually the name the receiver found for it and the EHLO name your server used. The email header analyzer lays this out for each hop.
  2. Run the reverse DNS lookup on that IP. It shows the PTR name and whether the forward lookup of that name returns the same address.
  3. Repeat for IPv6 if your server has an IPv6 address.

Fixing common problems

SymptomLikely causeFix
No PTR recordThe provider sets none by defaultSet the PTR in the provider’s panel or ask its support
PTR exists, forward lookup doesn’t return the IPThe A/AAAA record is missing or points elsewhereAdd or correct the A/AAAA record for the PTR name
Works over IPv4, Gmail rejects over IPv6No PTR for the IPv6 addressSet the IPv6 PTR and AAAA, or send over IPv4 only
PTR looks like 203-0-113-25.pool…Provider’s default nameSet a name in your own domain
PTR added, nothing changedRecord added in your own domain’s zoneOnly the IP owner’s reverse zone counts
EHLO shows localhost or an internal nameServer host name not setSet the mail server’s host name to the PTR name

After any change, remember that resolvers may keep the old answer until the record’s TTL expires.

References