PTR records and reverse DNS for email: setup and checks

Every receiver runs the same opening check on every connection: who is this IP, really? A reverse DNS (PTR) lookup is the cheapest way to ask. If your IP doesn't answer, or answers with generic nonsense, you've failed a vibes check before you sent a single byte of message.

For the broader infrastructure picture, use the reputation hub and keep PTR evidence alongside blocklists, provider dashboards, and domain-monitoring checks.

What a PTR record looks like

PTR records live in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zone. The IP is reversed and concatenated with the zone suffix. For 203.0.113.42 the PTR query is 42.113.0.203.in-addr.arpa.

Forward-confirmed reverse DNS (FCrDNS)

Receivers don't just check that a PTR exists — they check that the hostname it returns also resolves back to the original IP via an A or AAAA lookup. This is FCrDNS, and it's the actual gate. A mismatch is treated the same as no PTR at all.

# Step 1: PTR lookup
dig +short -x 203.0.113.42
# Returns: mail.example.com.

# Step 2: Forward lookup of the result
dig +short A mail.example.com
# Should return: 203.0.113.42

# If both match, FCrDNS passes.

Who sets the PTR

PTR for IPv6

Most major receivers — Gmail in particular — actively require PTR for IPv6 senders, often more strictly than for IPv4. The format is verbose: each hex digit reversed and dot-separated, ending in ip6.arpa. Most providers expose a friendly UI; you rarely write the raw record.

HELO/EHLO matching

The hostname your MTA announces in HELO/EHLO should match the PTR. Most filtering engines treat a HELO-PTR mismatch as another negative signal. Configure your MTA's myhostname (Postfix), dkimprovidername (Exim), or equivalent to match exactly.

# PTR for 203.0.113.42 returns mail.example.com
myhostname = mail.example.com
smtp_helo_name = mail.example.com

Verifying

1. Run dig +short -x <your-ip>. Expect a hostname on a domain you control.
2. Run dig +short A <returned-hostname>. Expect your IP back.
3. Send a test through WillItInbox — the report's infrastructure category breaks PTR results out individually.
4. Watch the message header — most receivers add an X-Originating-IP or Received: ... helo=... line that reveals what they thought of you.

Additional guidance: Reverse DNS (PTR) Records for Email: Setup, Checks, and Fixes

A PTR record (reverse DNS) maps an IP address back to a hostname — the opposite of an A record — and mailbox providers require it for inbound email. If your sending IP has no PTR record, or the PTR name doesn't resolve back to the same IP (a check called forward-confirmed reverse DNS, or FCrDNS), Gmail rejects your mail outright with 550 5.7.25 and many corporate filters junk it silently. The fix: set the PTR through whoever owns the IP — your hosting provider or ESP — and make it match your HELO hostname.

This post covers what PTR actually is, why it's the most common invisible rejection cause for self-hosted senders, and exactly how to verify and fix it.

What is a PTR record, and how is it different from an A record?

Regular DNS works forward: an A record maps mail.acmebilling.com → 203.0.113.44. Reverse DNS works backward: a PTR record (pointer record) maps 203.0.113.44 → mail.acmebilling.com.

The mechanics are slightly odd. Reverse records live in a special zone where the IP address is written backwards:

# Forward DNS (normal A record) — lives in your acmebilling.com zone
mail.acmebilling.com.   300  IN  A      203.0.113.44

# Reverse DNS (PTR record) — lives in the 113.0.203.in-addr.arpa zone
44.113.0.203.in-addr.arpa.  300  IN  PTR  mail.acmebilling.com.

For IPv6 the same idea uses ip6.arpa with the address nibble-reversed — much uglier, same principle.

Why do receivers care? Because anyone can claim any hostname in their SMTP greeting, but only the IP's owner can set its PTR. A botnet box at a random residential IP can say EHLO mail.acmebilling.com, but it can't make that IP's PTR record say it. The PTR is a weak-but-cheap ownership signal, and providers have treated it as table stakes for over a decade. It's one of the first things spam filters check, and missing PTR is one of the classic answers to why emails land in spam from freshly provisioned servers.

What is FCrDNS and why is one-sided PTR not enough?

Setting a PTR alone isn't sufficient. Providers verify forward-confirmed reverse DNS (FCrDNS) — a two-way check:

1. Look up the PTR of the connecting IP: 203.0.113.44 → mail.acmebilling.com
2. Look up the A record of that hostname: mail.acmebilling.com → must return 203.0.113.44

Both directions must agree. Common failure modes:

• PTR missing entirely → instant rejection at Gmail, heavy spam scoring elsewhere.
• PTR exists but is generic → 44.113.0.203.static.hostingco.com or pool-203-0-113-44.isp.net. Technically passes FCrDNS, but spam filters treat dynamic-looking names as a negative signal because that's what residential botnet IPs look like.
• PTR points to a hostname that doesn't resolve back → FCrDNS fails; as bad as no PTR at Gmail.
• PTR points to a shared hosting name unrelated to you → server47.webhost.com. FCrDNS passes, but there's a mismatch with your HELO and your domain identity (more on that below).

Verify your own IP right now:

# Step 1: reverse lookup — what does the IP claim to be?
dig -x 203.0.113.44 +short
# → mail.acmebilling.com.

# Step 2: forward confirmation — does that name resolve back?
dig mail.acmebilling.com A +short
# → 203.0.113.44   ✓ FCrDNS passes

# Equivalent with nslookup
nslookup 203.0.113.44

If step 1 returns nothing, or step 2 returns a different IP, you've found your problem.

What does the Gmail 550 5.7.25 rejection look like?

Since Gmail moved to permanent rejections for authentication and infrastructure failures (the 5.7.26 authentication rejections began in November 2025; PTR enforcement has been strict even longer), a missing or unconfirmed PTR produces a hard bounce like this:

550-5.7.25 [203.0.113.44] The IP address sending this message does not
550-5.7.25 have a PTR record setup, or the corresponding forward DNS entry
550-5.7.25 does not point to the sending IP. As a policy, Gmail does not accept
550-5.7.25 messages from IPs with missing PTR records. Please visit
550 5.7.25 https://support.google.com/mail/answer/81126 for more information.

Note the final code: 550, a permanent failure. Your MTA will not retry this — the message bounces immediately. This trips up senders who are used to infrastructure issues producing soft failures; a PTR problem at Gmail is not something that resolves itself with queue retries. (If you're seeing 550 5.7.26 instead, that's the authentication variant — different fix, covered in our Gmail 550 5.7.26 error guide.)

Microsoft's equivalent typically arrives as 550 5.7.1 with text about reverse DNS, and many corporate gateways (Proofpoint, Barracuda, generic SpamAssassin setups with RDNS_NONE) score missing PTR heavily even when they don't reject. For decoding the rest of the numeric zoo, see our SMTP error codes explainer.

Why can't you set the PTR in your own DNS zone?

This is the number-one confusion, so let's be blunt: the PTR record is controlled by whoever owns the IP address, not whoever owns the domain.

Your DNS provider (Cloudflare, Route 53, GoDaddy) hosts the zone for acmebilling.com. The reverse zone 113.0.203.in-addr.arpa belongs to the network that was allocated 203.0.113.0/24 — your hosting company, cloud provider, or ISP. Setting a PTR "record" in your own DNS zone does nothing, because resolvers never query your zone for reverse lookups.

Where to actually set it:

• AWS EC2: Request a reverse DNS entry for your Elastic IP via the AWS support form (or the ModifyAddressAttribute API / console for Elastic IPs). They validate that forward DNS already points at the IP.
• Google Cloud: Create a PTR record on the VM's external IP in Cloud DNS (GCP exposes the reverse zone to you for their IPs).
• Azure: Set the ReverseFqdn on the public IP resource.
• Hetzner / OVH / DigitalOcean / Vultr / Linode: A "rDNS" field in the server/networking panel. Usually instant.
• Bare metal / colo / ISP: Open a ticket with the provider. For larger allocations (a /24 or bigger), they can delegate the whole reverse zone to your nameservers with NS records — then you do manage PTR yourself.
• cPanel/shared hosting: Ask the host; you typically can't set PTR on shared IPs at all.

Order of operations matters: set the A record first, wait for it to propagate, then request the PTR. Providers verify the forward mapping before they'll create the reverse one, and you need both for FCrDNS anyway.

How should the PTR align with your HELO/EHLO hostname?

Three names show up when your server talks to a receiving MX, and filters compare them:

1. The PTR of your connecting IP — e.g., mail.acmebilling.com
2. The hostname your server announces in EHLO/HELO — configured in your MTA
3. Your From/envelope domains — acmebilling.com

They don't need to be identical, but the first two should match exactly, and the third should be plausibly related. Postfix example:

# /etc/postfix/main.cf
myhostname = mail.acmebilling.com
smtp_helo_name = $myhostname

With the PTR also set to mail.acmebilling.com, everything lines up: EHLO mail.acmebilling.com from 203.0.113.44, whose PTR says mail.acmebilling.com, whose A record says 203.0.113.44. Clean, consistent, boring — exactly what filters reward. (Same logic applies to which SMTP ports you use: submission on 587, relay on 25 — boring and correct.)

Common misalignment: the MTA announces its internal hostname (webapp-01.acme.internal) or the OS default (localhost.localdomain). SpamAssassin's HELO_DYNAMIC_IPADDR and friends exist precisely for this. Fix myhostname / the equivalent in Exim (primary_hostname) or your MTA of choice.

What about IPv6?

Gmail applies the same PTR requirement to IPv6 connections — and historically enforced it there first. If your server has both A and AAAA records, your MTA may connect over IPv6 without you realizing it. If the IPv6 address has no PTR, mail fails even though your IPv4 setup is perfect.

# Check both
dig -x 203.0.113.44 +short                    # IPv4
dig -x 2001:db8::44 +short                    # IPv6

Either set PTR on both address families or force your MTA to use IPv4 for outbound SMTP (in Postfix: inet_protocols = ipv4) until the IPv6 side is ready. Half-configured dual-stack is a sneaky source of "sometimes it bounces, sometimes it doesn't" — your server picks whichever address family it feels like per connection.

If you use an ESP, is PTR your problem?

Mostly no. If you send through SendGrid, Mailgun, SES, Postmark, or any established ESP, their outbound IPs already have proper PTR records and FCrDNS — it's their infrastructure, their responsibility. You should never see a 5.7.25 from an ESP's IP, and if you do, that's a ticket to them, not a DNS change for you.

PTR becomes your problem when you:

• Run your own mail server (Postfix, Exim, Exchange, Mailcow, iRedMail, Postal)
• Send from an app server or VPS directly (WordPress SMTP plugins relaying through the box, transactional scripts)
• Bought a dedicated IP from an ESP — some ESPs let you customize the PTR on dedicated IPs; aligning it with your domain is a small reputation win and worth doing
• Operate on-premises or colo infrastructure

That last-mile question — dedicated versus shared IPs and who controls what — interacts with PTR more than people expect; our domain reputation vs IP reputation piece covers which one filters weight more heavily now (domain, increasingly), but a missing PTR will sink you regardless of how good your domain reputation is.

Quick final check before you call it fixed: send a real message to a Gmail address and a Microsoft address, then read the Received-SPF/Authentication-Results headers — or shortcut the whole loop by sending one test through the deliverability tester, which checks PTR and FCrDNS as part of its DNS scoring category and tells you in seconds whether the receiving side sees what you think you published. If you're auditing a whole fleet of sending domains, the MX lookup tool helps you map which servers each domain actually sends and receives through, so you know which IPs need PTR coverage in the first place.

How long does a PTR change take to work?

Two clocks matter. First, the provider's own provisioning time: cloud consoles apply rDNS changes in minutes, while an ISP support ticket can take a business day. Second, DNS caching. PTR records carry a TTL (time to live), and receiving servers cache negative answers too — if Gmail's resolvers looked up your IP while it had no PTR, that "no record" answer is cached until the negative TTL expires. After your provider confirms the change, verify from an external resolver rather than your own server:

# Query Google's public resolver directly, bypassing your local cache
dig @8.8.8.8 -x 203.0.113.44 +short
dig @1.1.1.1 -x 203.0.113.44 +short

If both return your hostname, the world sees it — resend your queued mail. If they return nothing, the change hasn't propagated or wasn't actually applied at the reverse zone; go back to the provider with the dig output. One trap: some providers set the PTR but with a very long TTL on the old cached negative response (24 hours is common). In that case, waiting is the only fix, which is why you should configure PTR on day one when provisioning a sending server, not after the first wave of bounces. Getting this right early also matters for warmup — a new IP that starts life with greylisting-era delays and missing PTR digs a reputation hole that takes weeks to climb out of.

PTR and FCrDNS are also just one line item on the compliance checklist receivers run against you. Once your reverse DNS is solid, the sender compliance checker audits the rest — SPF, DKIM, DMARC alignment, and unsubscribe headers — so a green PTR isn't masking a red flag elsewhere.

The minimum healthy chain is one PTR hostname, a forward A or AAAA record returning the same IP, and an EHLO name consistent with that hostname. Use domain monitoring for recurring checks, the MX lookup for the receiving side of the route, and a deliverability test to see how the sender identity appears in the final report.