Email Security9 min readUpdated

How to Set Up a PTR Record for a Mail Server

Mail from an IP with no reverse DNS, or with a PTR that does not resolve back, is rejected by many receivers before the message is even read. Getting it right takes three matching names: the PTR, the forward record and the server's own HELO.

Rahul KumarEditor

When your server connects to deliver mail, the receiving server looks up the PTR record for your IP address. If there is none, if it points to a name that does not resolve back to the same IP, or if it looks like a home broadband address, many receivers reject the connection with a 5xx error. Gmail requires a valid PTR from every sender. This guide sets it up end to end and checks it the way receivers do.

Three names that have to agreeA healthy setup has the PTR (IP → name), the forward record (name → same IP) and the server's HELO/EHLO name all pointing at the same hostname, such as mail.example.com. The first two together are forward-confirmed reverse DNS (FCrDNS). For background, see What Is Reverse DNS?

Step 1 — Find the IP Address Mail Actually Leaves From

This is not always the address you think. A server with several addresses, a NAT gateway or an IPv6 address can send from a different one than the A record you use for SSH. Find it from the source:

  • From a delivered message. Send a message to an outside mailbox and read the first Received: header added by the receiver — it shows the connecting IP. Paste the headers into the Email Header Analyzer to pull it out.
  • From the server. List the addresses the server holds, IPv4 and IPv6:
bash
# Every global address on the machine ip -4 addr show scope global ip -6 addr show scope global # The source address the kernel would use to reach the internet ip route get 8.8.8.8 ip -6 route get 2001:4860:4860::8888
Do not forget IPv6If the server has a global IPv6 address, Postfix and Exim will use it to reach receivers that support IPv6 — including Gmail and Outlook. An IPv4 PTR alone is not enough; the IPv6 address needs one too, or outgoing mail must be limited to IPv4 (Step 5).

Step 2 — Choose the Hostname

The PTR name identifies the server. Pick one that:

  • Is a fully qualified name under a domain you control, such as mail.example.com or mx1.example.com.
  • Looks specific, not generic. Names like 203-0-113-25.static.provider.net or anything containing dynamic, dsl or pool are scored as residential by spam filters.
  • Is unique to this server. Two sending servers get two names (mail1, mail2), each with its own address.

It does not have to match the domain you send mail for. One server can send for many domains; those are authenticated by SPF, DKIM and DMARC, not by the PTR.

Step 3 — Create the Forward Record First

In your domain's DNS, add an A record (and an AAAA record for IPv6) for the hostname, pointing at the sending address. Several providers refuse to set a PTR until this exists.

text
mail.example.com. 3600 IN A 203.0.113.25 mail.example.com. 3600 IN AAAA 2001:db8:4d2::25
bash
dig +short A mail.example.com dig +short AAAA mail.example.com

Step 4 — Set the PTR With Whoever Owns the IP

The reverse zone belongs to the owner of the address block, so this happens in your provider's console, not your DNS host. Where to find it at common providers:

ProviderWhere to set reverse DNS
AWS EC2Needs an Elastic IP. EC2 console → Elastic IPs → select the address → Actions → Update reverse DNS. The forward record must already resolve to the Elastic IP. AWS also blocks port 25 by default; request removal of the email sending limit.
Google CloudEdit the VM → network interface → external IP → Public DNS PTR record. Google requires the domain to be verified as yours first.
AzureSet the reverse FQDN on the public IP resource, e.g. az network public-ip update -g RG -n IP --reverse-fqdn mail.example.com. The name must resolve forward to that IP.
DigitalOceanThe PTR follows the Droplet's name. Rename the Droplet to the full hostname (mail.example.com) and both the IPv4 and IPv6 PTRs update.
HetznerCloud console → server → Networking → edit reverse DNS beside each IP. Dedicated servers: Robot → IPs.
Akamai (Linode)Linode → Network tab → the IP's menu → Edit RDNS. The forward record must exist first.
VultrServer → Settings → IPv4 / IPv6 → reverse DNS field.
Office or business ISPAsk support to set the PTR for your static IP. Dynamic and residential addresses usually cannot have one — send through a relay instead.
If you own the IP blockIf you hold your own allocation (a /24 or larger), your regional registry delegates the reverse zone to your nameservers and you add PTR records there like any other record. For blocks smaller than a /24, your upstream provider can delegate them to you using RFC 2317 classless delegation (CNAMEs into a zone you host).

Step 5 — Make the Server's HELO Name Match

The server introduces itself with EHLO (or HELO) at the start of every connection. Receivers compare that name with the PTR, and a mismatch — or a bare name like localhost — is another spam signal. Set the mail server's hostname to the PTR name:

bash
# Postfix — /etc/postfix/main.cf myhostname = mail.example.com # smtp_helo_name defaults to $myhostname, so EHLO now matches. # Only if IPv6 has no PTR yet: send over IPv4 until it does inet_protocols = ipv4 sudo postfix check && sudo systemctl reload postfix
text
# Exim — /etc/exim4/exim4.conf.template (or update-exim4.conf.conf on Debian) primary_hostname = mail.example.com # The smtp transport's helo_data defaults to $primary_hostname.

If the server sends from more than one address, give each one its own PTR and forward record, and make sure the EHLO name used on each matches that address's PTR.

Step 6 — Verify Forward-Confirmed Reverse DNS

Check the round trip exactly as a receiver would — IP to name, then name back to IP:

bash
dig +short -x 203.0.113.25 # mail.example.com. dig +short A mail.example.com # 203.0.113.25 ← must be the same IP # Same for IPv6 dig +short -x 2001:db8:4d2::25 dig +short AAAA mail.example.com # Ask a public resolver to rule out a stale local cache dig +short -x 203.0.113.25 @1.1.1.1

The PTR Lookup does both halves in one step and shows who owns the address. Then run the server through the SMTP Test to see the banner and EHLO name it presents.

Confirm the PTR and the forward matchEnter your sending IP to see its PTR record and whether that name resolves back to the same address.
Check a PTR record

Step 7 — Check the Rest of the Sending Setup

Reverse DNS is one of several checks a receiver runs. With it fixed, confirm the others:

Email Health checks all of these for a domain in one report.

Common Problems

  • PTR set in your own DNS zone. A record at 25.113.0.203.in-addr.arpa in your domain's zone is never queried. It has to be set by the IP owner.
  • PTR set, forward record missing or different. FCrDNS fails. This often happens after a migration, when the A record moved but the old PTR stayed.
  • Only IPv4 fixed. Mail to IPv6-capable receivers still leaves from an address with no PTR and is rejected.
  • Provider default left in place. A generic name like ec2-203-0-113-25.compute-1.amazonaws.com passes FCrDNS but looks like a throwaway cloud host to many filters.
  • Wrong IP. The PTR was set on the server's main address while mail leaves through a NAT gateway or a second interface. Check Step 1 again.

Frequently Asked Questions

1. Where do I set a PTR record?

With whoever owns the IP address, not with your domain's DNS host. For a cloud server that is the cloud provider's console or API; for a dedicated server it is the hosting company; for an office connection it is the ISP. Adding a PTR record in your own domain's zone does nothing, because resolvers look it up under in-addr.arpa or ip6.arpa, which your provider controls.

2. Does the PTR hostname have to match my email domain?

No. Receivers check that the PTR exists, that it resolves back to the same IP (forward-confirmed reverse DNS), and that it is not a generic ISP-style name. mail.example.net can send for example.com, and one server can send for many domains. The domain your messages claim is checked by SPF, DKIM and DMARC instead.

3. Do I need a PTR record for IPv6 too?

Yes, if the server can send over IPv6. Mail servers prefer IPv6 when both ends support it, and Gmail rejects IPv6 mail from addresses without a valid PTR record. Either set PTR records for every IPv6 address the server may send from, or restrict outgoing mail to IPv4 (in Postfix, inet_protocols = ipv4) until you do.

4. How long does a new PTR record take to work?

Usually minutes. The provider publishes it in its reverse zone straight away, and resolvers that had cached the old answer — or the lack of one — pick it up when that cache expires, typically within an hour. If dig -x against a public resolver still shows the old name after a few hours, the change did not save at the provider.

5. Can one IP address have several PTR records?

DNS allows it, but do not do it on a mail server. Receivers usually check only one of the names, and which one they get varies, so the forward-confirmation can pass on one attempt and fail on the next. Give each sending IP exactly one PTR record that names the server.

6. Will a correct PTR record get me out of spam folders?

It removes one reason for rejection, which is often the difference between mail being refused and being accepted. Inbox placement then depends on SPF, DKIM and DMARC, the IP's reputation and blocklist status, and the content. Check those next with Email Health and the Blacklist Checker.