KoltrixReverse DNS for mail servers: PTR, FCrDNS and HELO
Receivers expect a sending IP to have a PTR record that resolves back to the same IP and a sane HELO name. Configure all three and verify them.
On this page(9 sections)
- The three names involved
- Why receivers care
- Who controls the PTR record
- Setting it up for your own server
- 1. Choose a hostname
- 2. Create the forward record
- 3. Set the PTR records
- 4. Configure the EHLO name
- 5. Make sure the TLS certificate matches
- Verifying with dig
- IPv6 deserves special care
- Common mistakes
- Checklist
- Key takeaways
Before a receiving server even looks at SPF or DKIM, it often checks something more basic: does the IP address that just connected have a sensible name? Missing or mismatched reverse DNS is one of the oldest spam signals there is, and Gmail and Yahoo both list valid forward and reverse DNS as a requirement for all senders.
The three names involved
When your server connects to deliver mail, three related identities are in play:
- The PTR record. Reverse DNS maps the connecting IP to a hostname, through a PTR record in the
in-addr.arpa(IPv4) orip6.arpa(IPv6) zone. - The forward record. That hostname should resolve back, through an A or AAAA record, to the same IP. When both directions agree, it is called forward-confirmed reverse DNS, or FCrDNS.
- The HELO/EHLO name. At the start of the SMTP session, your server announces a hostname with the
EHLOcommand. Receivers compare it with the other two.
A consistent setup looks like this:
| Item | Value |
|---|---|
| Sending IP | 192.0.2.25 |
| PTR for 192.0.2.25 | mail1.example.com |
| A record for mail1.example.com | 192.0.2.25 |
| EHLO name | mail1.example.com |
Why receivers care
Spam from compromised home computers and short-lived cloud instances historically came from IPs with no PTR record, or with generic names like host-192-0-2-25.isp.example. Legitimate mail servers are operated deliberately, by someone who configured their names. Receivers use reverse DNS as a cheap first filter:
- No PTR at all is treated as highly suspicious and can cause outright rejection at some receivers.
- A PTR that does not resolve back (failed FCrDNS) is a weaker but still negative signal.
- A generic, ISP-assigned-looking PTR suggests a residential or dynamic address.
- An EHLO name that is not a real hostname, such as
localhostor a bare word, reflects poorly on the sender.
Gmail's sender guidelines state that sending domains or IPs must have valid forward and reverse DNS records. Yahoo's sender best practices say senders should have a valid forward and reverse DNS record for their sending IPs. Both apply this to all senders, not just bulk senders.
Who controls the PTR record
This is where people get stuck. You do not control the PTR record through your domain's DNS. Reverse zones belong to whoever owns the IP address block:
- On a cloud provider, you usually set reverse DNS through the provider's console or API for the specific IP. Many providers require that the forward record already points at the IP before they allow the PTR.
- With a hosting company or data center, you request it through their support or panel.
- With an email service provider, their sending IPs already have PTR records under their domain. You do not need to do anything, and you cannot change them unless you have dedicated IPs and the provider offers custom reverse DNS.
Setting it up for your own server
1. Choose a hostname
Pick a dedicated name such as mail1.example.com or out1.example.com. Avoid reusing your web server's name if the two roles might move separately.
2. Create the forward record
mail1.example.com. A 192.0.2.25
mail1.example.com. AAAA 2001:db8::253. Set the PTR records
Through your provider, set the reverse record for each IP:
25.2.0.192.in-addr.arpa. PTR mail1.example.com.For IPv6, the reverse name is the address written as nibbles in reverse order under ip6.arpa; your provider's console usually builds it for you.
4. Configure the EHLO name
Set your mail server to announce the same hostname. In Postfix, that is myhostname; other servers have an equivalent setting.
5. Make sure the TLS certificate matches
If your server offers STARTTLS when sending, a certificate for the same hostname avoids mismatches that some receivers log, although opportunistic TLS between servers rarely enforces it.
Verifying with dig
dig +short -x 192.0.2.25 # expect: mail1.example.com.
dig +short A mail1.example.com # expect: 192.0.2.25
dig +short -x 2001:db8::25 # IPv6 reverse lookupBoth directions must agree. To check the EHLO name, connect to a test receiver you control, or look at the Received header your message gets at a mailbox you own; it typically records both the EHLO name and the reverse DNS name the receiver found, for example:
Received: from mail1.example.com (mail1.example.com [192.0.2.25])The first name is what your server said in EHLO; the name in parentheses is what the receiver resolved. Mismatches are easy to spot there.
IPv6 deserves special care
If your server has an IPv6 address and the receiver supports IPv6, delivery may happen over IPv6 even if you configured everything carefully for IPv4. Large providers apply stricter checks to IPv6 senders, and missing reverse DNS on IPv6 is a common cause of rejections that appear only for some messages. Either configure PTR records for every IPv6 address you send from, or configure your mail server to send over IPv4 only.
Common mistakes
- Setting PTR to the bare domain, such as
example.com. It works technically, but a dedicated mail hostname is clearer and easier to manage across several IPs. - Multiple PTR records for one IP. This is allowed in DNS but confuses receivers; use exactly one.
- Forgetting the forward record after a DNS migration, which breaks FCrDNS silently.
- EHLO with an internal name, like
ip-10-0-0-5.internal, leaking from a cloud default. - Sending from a new IP before setting PTR, which hands receivers a bad first impression.
Checklist
- Every sending IP, IPv4 and IPv6, has exactly one PTR record.
- Each PTR hostname resolves back to the same IP.
- The EHLO name matches the PTR hostname.
- The hostname is a real, dedicated name under a domain you control.
- Received headers on a test message show matching names.
Key takeaways
- Receivers expect the connecting IP to have a PTR record, the PTR name to resolve back to that IP, and the EHLO name to match.
- Gmail and Yahoo list valid forward and reverse DNS as a requirement for all senders.
- PTR records are controlled by whoever owns the IP block, usually set through your cloud or hosting provider.
- Check IPv6 as carefully as IPv4, or disable IPv6 sending.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
