rDNS/PTR Missing: The Boring DNS Fix That Saves Email Deliverability

What rDNS/PTR actually is (and why mail cares)

DNS normally answers: “What IP is mail.example.com?” That’s forward DNS (A/AAAA records). Reverse DNS answers the opposite: “What name belongs to 203.0.113.10?” That’s a PTR record stored under a special reverse-mapping zone (in-addr.arpa for IPv4 and ip6.arpa for IPv6).

For email, that reverse mapping becomes a cheap signal: “Is this IP’s operator competent enough to set basic DNS correctly, and does the claimed hostname look consistent with the rest of the identity?” Receivers don’t need rDNS to deliver a packet. They use it to decide whether to trust a sender enough to place the message in inbox-land rather than spam-purgatory.

The core deliverability expectation: coherence

Receivers typically like these to line up:

• The SMTP server’s connecting IP has a PTR that resolves to a hostname, e.g. mail01.example.com.
• That hostname has an A/AAAA record that resolves back to the same connecting IP (forward-confirmed reverse DNS, often abbreviated FCrDNS).
• The SMTP greeting name (HELO/EHLO) matches (or at least belongs to the same domain family as) that hostname.
• SPF/DKIM/DMARC align with the envelope-from and/or header-from domains (not strictly rDNS, but rDNS problems tend to correlate with “the rest is also messy”).

Notice what’s not in that list: “The PTR must match the From: domain.” That’s a common misunderstanding. You can send mail as @example.com from a host named smtp-out.provider.net—it’s done constantly by legitimate senders. But if you run your own infrastructure, aligning these signals is cheaper than debugging why Outlook is sulking today.

One practical rule: if you operate the IP, you should be able to set the PTR. If you don’t control the IP (shared hosting, consumer ISP, dynamic address), you are not running a production outbound mail server; you’re running an experiment.

Short joke #1: Reverse DNS is like labeling your office door. People can still enter the building without it, but they’ll assume you’re the intern and route you to the spam folder.

How receiving systems use rDNS (real behavior, not folklore)

Different receivers weigh rDNS differently, and they don’t publish the exact math. But rDNS shows up in three places that matter operationally:

1) Hard rejects and policy gates

Some organizations (especially in regulated industries) configure inbound gateways to reject SMTP connections that lack a PTR or have a generic-looking PTR. The logic is blunt: “If you can’t be bothered to set rDNS, you’re not serious.” It’s crude, but it’s easy to explain to auditors.

Many big consumer providers are more nuanced: missing PTR alone may not be an instant reject, but it can combine with reputation signals (new IP, low volume, weird content, bad DKIM alignment) and push you over the line.

2) Spam scoring and throttling

rDNS and FCrDNS often feed heuristics: inconsistent or missing mapping increases suspicion, which can mean spam placement, rate limiting, or greylisting-like behavior. This is where it gets maddening: your mail “sometimes works,” except for the 15% of recipients who happen to be behind a strict inbound policy.

3) Incident response and abuse handling

When you get flagged for abuse, someone—human or machine—tries to figure out who owns the IP. PTR isn’t authoritative ownership, but it’s a breadcrumb. A clean, consistent rDNS name that points into a domain with working postmaster/abuse mailboxes makes the world treat you like an adult. A PTR of ip-203-0-113-10.somecloud.internal doesn’t help your case.

What receivers do not do (usually)

Receivers generally do not “authenticate” you with PTR. PTR can be spoofed by whoever controls the IP’s reverse zone delegation (almost always the ISP/cloud provider). It’s a weak signal by design. But weak signals are exactly what spam filters feast on—lots of them, weighted and combined.

Here’s the operational mindset: rDNS is not a deliverability magic bullet. It’s table stakes. You don’t win because you have it; you lose because you don’t.

Facts & history: why this still exists

rDNS feels like the landline of DNS features: everyone pretends it’s obsolete, yet it still runs half the world’s business logic. A few concrete facts and historical context points that explain why:

1. PTR records predate modern anti-spam. Reverse mapping existed early as a convenience for naming hosts from IPs; email later adopted it as a trust hint.
2. Reverse zones are usually controlled by IP owners, not domain owners. That’s why you often can’t set PTR in your normal DNS provider UI.
3. The reverse DNS namespace is separate. IPv4 uses in-addr.arpa with octets reversed; IPv6 uses ip6.arpa with nibbles reversed—yes, it’s as fun as it sounds.
4. “FCrDNS” (forward-confirmed reverse DNS) is a pattern, not a protocol. It’s a sanity check: PTR → name → A/AAAA → same IP.
5. Early spam defenses leaned on rDNS because it’s cheap. DNS lookups were easy, and many spammers used dial-up/dynamic pools without stable PTRs.
6. Some networks deliberately set generic PTRs for consumer ranges. That helps mail systems spot “likely residential” senders trying to run SMTP servers.
7. Email is one of the last systems that still rewards static infrastructure signals. HTTP doesn’t care about your PTR. SMTP, culturally and technically, still does.
8. Major providers increasingly combine identity signals. rDNS alone won’t save you, but a missing PTR often correlates with missing SPF/DKIM/DMARC, and filters treat correlation like confession.
9. IPv6 made rDNS operationally harder. The reverse name is long, reverse-nibble delegated, and easy to forget during deployments—so it becomes a frequent “why is v6 mail failing?” culprit.

One quote that belongs on every ops wall, even if you only remember it during outages: Everything fails, all the time. — Werner Vogels

rDNS is a small “everything.” Treat it that way.

Fast diagnosis playbook

This is the “someone escalated deliverability” checklist you run before you start blaming content, marketing automation, or the phase of the moon.

First: identify the actual egress IP used for outbound mail

• Confirm which IP recipients see in SMTP logs or bounce messages.
• If you use a relay, confirm whether you’re on a shared pool or dedicated IPs.
• If you have multiple NICs, NAT, Kubernetes egress, or a firewall rewriting source IPs, assume you’re wrong until proven otherwise.

Second: check PTR existence and correctness

• No PTR at all? Fix that first. Stop debating.
• PTR exists but is generic or wrong domain? Decide whether you can change it; if not, move the mail to a better IP.

Third: check FCrDNS and SMTP greeting

• PTR hostname should resolve forward to the same IP.
• Your MTA’s EHLO/HELO name should be that hostname (or a sane alias that resolves correctly).

Fourth: confirm SPF/DKIM/DMARC aren’t undermining you

• PTR problems often travel with SPF “~all” hand-waving and DKIM that only works on Tuesdays.
• Don’t fix one signal and ignore the rest.

Fifth: check basic blocklist/reputation signals

• If you’re on a dirty IP, correct rDNS won’t launder your reputation.
• If you’re on a new IP, warm it up; don’t “optimize” by blasting full volume immediately.

Short joke #2: Email deliverability is like plumbing: the problem is rarely the fancy faucet, and almost always the pipe you didn’t look at.

Hands-on tasks: commands, output, decisions (12+)

These are real operator tasks. Each includes a command, an example of plausible output, what it means, and what decision you make. Replace IPs/domains with your own. Use a machine that has working DNS recursion (or point tools at a known resolver explicitly).

Task 1: Determine what IP your server uses to reach the internet

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 203.0.113.1 dev eth0 src 203.0.113.10 uid 1000
    cache

Meaning: Your outbound traffic (and likely SMTP egress) uses source IP 203.0.113.10.

Decision: This IP is the one that must have correct PTR. If you expected a different IP, hunt down NAT rules, cloud egress, or load balancer SNAT.

Task 2: Find the public egress IP from outside your network

cr0x@server:~$ curl -4 -s ifconfig.me
203.0.113.10

Meaning: External services see your egress as 203.0.113.10.

Decision: If this differs from what you think your SMTP server binds to, you may be behind NAT. rDNS must be set on the NAT public IP, not your private address.

Task 3: Check PTR (reverse DNS) with dig

cr0x@server:~$ dig +short -x 203.0.113.10
mail01.example.com.

Meaning: The IP has a PTR pointing to mail01.example.com.

Decision: Good start. Next verify that name resolves forward back to the same IP (FCrDNS).

Task 4: Detect missing PTR

cr0x@server:~$ dig -x 203.0.113.11
; <<>> DiG 9.18.24-1-Debian <<>> -x 203.0.113.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1196
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Meaning: No reverse record exists for that IP.

Decision: Fix rDNS at the IP provider (cloud/ISP). Do not keep “testing deliverability” until it’s set—your results will be noisy and mostly bad.

Task 5: Verify forward DNS of the PTR hostname

cr0x@server:~$ dig +short A mail01.example.com
203.0.113.10

Meaning: Forward DNS matches the connecting IP.

Decision: This is FCrDNS passing (at least for IPv4). If you see a different IP, fix the A record, fix NAT expectations, or change PTR to the correct hostname.

Task 6: Verify AAAA too (if you have IPv6)

cr0x@server:~$ dig +short AAAA mail01.example.com
2001:db8:abcd:10::25

Meaning: The hostname also has IPv6.

Decision: If your SMTP listens on IPv6, you must also set IPv6 PTR and ensure IPv6 forward-reverse coherence. If you’re not ready for that, don’t publish AAAA for the mail hostname.

Task 7: Check IPv6 PTR

cr0x@server:~$ dig +short -x 2001:db8:abcd:10::25
mail01.example.com.

Meaning: IPv6 reverse mapping exists and matches.

Decision: Good. If it’s missing, expect some receivers to treat your IPv6 delivery as suspicious or fail entirely; either set it or disable IPv6 SMTP until you can.

Task 8: Inspect what your MTA uses for HELO/EHLO

cr0x@server:~$ postconf -n | egrep '^(myhostname|mydomain|smtp_helo_name)='
mydomain = example.com
myhostname = mail01.example.com
smtp_helo_name = $myhostname

Meaning: Postfix will greet as mail01.example.com.

Decision: Keep it consistent: HELO/EHLO should be a real FQDN with A/AAAA, ideally matching PTR. If you see localhost or a random internal name, fix it.

Task 9: See your SMTP greeting from the outside

cr0x@server:~$ nc -v mail01.example.com 25
Connection to mail01.example.com 25 port [tcp/smtp] succeeded!
220 mail01.example.com ESMTP Postfix

Meaning: The banner shows a sane hostname.

Decision: If the banner shows localhost or an internal host, fix MTA config. Some filters treat mismatched banners as suspicious.

Task 10: Confirm TLS certificate name matches the mail hostname (optional but common)

cr0x@server:~$ openssl s_client -starttls smtp -connect mail01.example.com:25 -servername mail01.example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = mail01.example.com
issuer=CN = R3, O = Let's Encrypt, C = US

Meaning: TLS identity matches mail01.example.com.

Decision: Not required for rDNS, but this is part of the “coherent sender” picture. If it doesn’t match, fix it; you want fewer reasons for receivers to distrust you.

Task 11: Check SPF for the domain you send as

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g'
v=spf1 ip4:203.0.113.10 -all

Meaning: SPF explicitly authorizes the IP and is strict.

Decision: If SPF is missing or doesn’t include your egress IP, fix SPF. A perfect PTR won’t compensate for SPF fail at many receivers.

Task 12: Check DKIM selector presence (DNS side)

cr0x@server:~$ dig +short TXT default._domainkey.example.com | head -n 1
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Meaning: DKIM public key exists for selector default.

Decision: Ensure your MTA signs outbound mail with this selector and that mail headers show DKIM=pass at recipients. If DKIM isn’t in place, rDNS fixes will only partially help.

Task 13: Check DMARC policy

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g'
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Meaning: DMARC exists with quarantine policy and strict alignment.

Decision: If DMARC is absent, deliverability may vary; if DMARC is strict but your From: domain doesn’t align with DKIM/SPF, you’ll sabotage yourself. Fix alignment before tightening policy.

Task 14: Inspect reverse DNS delegation / authority (who can set PTR)

cr0x@server:~$ dig +noall +authority -x 203.0.113.10
10.113.0.203.in-addr.arpa.  3600 IN SOA ns1.provider.net. hostmaster.provider.net. 2026010301 7200 3600 1209600 3600

Meaning: The provider’s nameserver is authoritative for the reverse zone.

Decision: You must set PTR through that provider’s control panel/API or request it via support. Changing your domain DNS provider won’t help.

Task 15: Confirm the PTR you set is visible globally (not just cached locally)

cr0x@server:~$ dig +short -x 203.0.113.10 @1.1.1.1
mail01.example.com.

Meaning: A public resolver sees the correct PTR.

Decision: If public resolvers disagree, you’re racing propagation or split-horizon DNS. Receivers use their own resolvers; trust what public resolvers see.

Task 16: Check for multiple PTRs (usually a bad idea)

cr0x@server:~$ dig -x 203.0.113.10 +noall +answer
10.113.0.203.in-addr.arpa. 300 IN PTR mail01.example.com.
10.113.0.203.in-addr.arpa. 300 IN PTR mail-gateway.example.com.

Meaning: Two PTRs exist for one IP.

Decision: Pick one canonical PTR. Multiple PTRs confuse heuristics and humans. Mail wants one identity per sending IP.

Task 17: Watch SMTP transactions and see rejections tied to rDNS

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log | egrep -i 'reject|rbl|helo|ptr|reverse'
Jan 03 09:14:22 mail01 postfix/smtp[12044]: host mx.remote.example[198.51.100.25] said: 550 5.7.1 Client host rejected: cannot find your reverse hostname (in reply to RCPT TO command)

Meaning: A recipient explicitly rejected due to missing reverse hostname.

Decision: Fix PTR immediately. If PTR is set, verify propagation and that the connecting IP matches the one you fixed.

Task 18: Validate your MTA binds to the intended interface/IP

cr0x@server:~$ sudo ss -ltnp | egrep ':25\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=912,fd=13))

Meaning: SMTP listens on all IPv4 interfaces.

Decision: If you have multiple public IPs and only one has correct PTR, consider binding explicitly or routing outbound mail through the correct source IP.

Task 19: Confirm outbound source IP for SMTP specifically (packet-level)

cr0x@server:~$ sudo tcpdump -ni eth0 tcp port 25 and host 198.51.100.25 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:15:01.102938 IP 203.0.113.10.48214 > 198.51.100.25.25: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0

Meaning: The SMTP connection originates from 203.0.113.10.

Decision: This is the IP whose rDNS must be correct. If you see a different source IP than expected, fix routing/NAT or MTA’s source address configuration.

Task 20: Test reverse + forward in one shot (FCrDNS quick check)

cr0x@server:~$ ip=203.0.113.10; host $ip; hn=$(host $ip | awk '/domain name pointer/{print $5}'); host ${hn%.}
10.113.0.203.in-addr.arpa domain name pointer mail01.example.com.
mail01.example.com has address 203.0.113.10

Meaning: PTR returns mail01.example.com, and that name returns the same IP.

Decision: FCrDNS passes. If the second lookup returns a different IP, you have mismatch—fix either PTR or A record so they agree.

Three corporate mini-stories from the trenches

1) The incident caused by a wrong assumption: “The cloud surely sets rDNS”

A mid-size company migrated from a managed email service to “self-hosted outbound SMTP for cost control.” The plan looked good on a spreadsheet: a couple of VMs, Postfix, a relay for redundancy, and a new dedicated IP range from their cloud provider. They kept SPF and DKIM mostly intact. They even had monitoring on queue depth and latency.

Then the bounces started. Not a dramatic outage—worse. Some customers received mail. Some didn’t. Support tickets got weird: “Password reset never arrives,” “Invoice email missing,” “Your system is flaky.” The team looked at the usual suspects: rate limits, content filters, TLS settings, and whether they were accidentally sending from the wrong domain. They were proud of their automation, so naturally they suspected everyone else.

The wrong assumption was simple: “If the VM has an IP, rDNS will be there.” It wasn’t. Their IP block had PTRs pointing to generic provider hostnames. The MTA greeted as mail.example.com, SPF authorized the IPs, but the reverse identity looked like a disposable host in a compute pool.

The fix was anticlimactic: request custom PTRs from the provider, make them match the MTA’s hostname, ensure the forward A record matched, and wait for caches to expire. The after-action report was more interesting than the repair. They added a pre-flight checklist item: “PTR set and verified externally for all outbound IPs.” It wasn’t a technical breakthrough; it was organizational maturity disguised as boredom.

2) The optimization that backfired: “Let’s rotate egress IPs to spread risk”

Another company had deliverability issues and decided to outsmart reputation systems. The idea: rotate outbound IPs through a pool so that any one IP wouldn’t “accumulate negative reputation.” Someone even called it “sharding deliverability.” That phrase should have been a fire alarm.

They built a clever NAT layer that mapped outbound SMTP connections across several public IPs. The pool included new IPs and a couple that had been quiet for months. Their Postfix instances didn’t bind a specific source IP; the network did the balancing. Engineers love a clean abstraction, and NAT is the cleanest lie we tell ourselves.

What happened next was predictable if you’ve ever dealt with email: receivers saw inconsistent identity signals. One connection came from an IP with a PTR of mail01.example.com. Another came from an IP with no PTR. Another had a PTR pointing to a decommissioned hostname that no longer had a forward A record. HELO was stable, source IP was not. The spam filters didn’t need a PhD: they saw instability and treated it as risk.

Deliverability got worse. They also made debugging harder because bounces referenced different source IPs depending on which NAT mapping won that day. The “optimization” spread their reputation thin and ensured none of the IPs built a consistent history. They rolled back, pinned SMTP egress to a single warmed IP with correct rDNS, and only then introduced a second IP—properly configured—after the first stabilized.

The lesson wasn’t “never use multiple IPs.” The lesson was: if you can’t keep identity coherent across the pool (PTR, forward DNS, HELO, SPF), don’t build a pool. Email punishes cleverness.

3) The boring but correct practice that saved the day: “Treat PTR like a production dependency”

A larger enterprise had a ritual that looked almost comically procedural. Any time a new outbound IP was allocated—cloud, colo, disaster recovery, doesn’t matter—there was a small “mail identity” ticket that had to be closed before the IP could be used. The ticket wasn’t optional. It had a checklist: PTR requested, forward A/AAAA created, HELO configured, SPF updated, and an external validation run from a machine not on corporate DNS.

During a regional outage, they failed over outbound mail to a secondary site. Their MTAs came up, queues drained, and customers barely noticed. Why? Because the secondary IPs already had correct PTRs and forward DNS months earlier, even though the site mostly sat idle. Nothing was “discovered” during the incident. The boring work was prepaid.

There was still work to do—warming volume, watching for reputation shifts, tuning rate limits—but they avoided the worst-case scenario: a failover that technically works while every major provider silently dumps you into spam. That’s the kind of outage that doesn’t show up in CPU graphs and destroys trust anyway.

It’s not heroic engineering. It’s just refusing to run email on half-configured identity. The team’s mantra was basically: if you wouldn’t deploy without TLS, don’t deploy without PTR.

Common mistakes: symptom → root cause → fix

These are the patterns I see repeatedly in production environments. Each one has a specific symptom, a likely root cause, and a fix that doesn’t involve wishful thinking.

1) Symptom: “550 Client host rejected: cannot find your reverse hostname”

Root cause: No PTR record for the connecting IP, or reverse DNS broken due to provider misconfiguration.

Fix: Set PTR at the IP provider. Verify with dig -x from a public resolver. Ensure your SMTP actually egresses from that IP.

2) Symptom: Mail lands in spam at Microsoft/Google but not everywhere

Root cause: PTR exists but is generic, mismatched, or doesn’t forward-resolve back (FCrDNS fails). Often combined with new/low reputation.

Fix: Make PTR point to a hostname you control; ensure that hostname’s A/AAAA points back to the same IP. Keep HELO consistent. Warm the IP gradually.

3) Symptom: Bounces reference an IP you don’t recognize

Root cause: NAT, outbound relay, load balancer, or multi-homed server uses a different egress IP than expected.

Fix: Confirm egress with packet capture or route checks. Bind MTA to a specific source IP if necessary. Configure PTR for the real egress.

4) Symptom: PTR points to a hostname, but forward lookup gives a different IP

Root cause: Someone changed A record during migration, or PTR was copied from old infrastructure. FCrDNS fails.

Fix: Decide which is canonical (usually the real mail hostname for that IP), then update PTR and A/AAAA to match. One sending IP, one identity.

5) Symptom: PTR points to localhost or an internal name in logs

Root cause: MTA’s myhostname or HELO is misconfigured; banner identity doesn’t match reality.

Fix: Set MTA hostname to a real FQDN with correct forward DNS. Ensure HELO uses it. Do not greet as internal hostnames.

6) Symptom: IPv4 mail is fine; IPv6 mail fails more often

Root cause: AAAA record exists; SMTP offers IPv6; but IPv6 PTR is missing or wrong. Or the IPv6 address is from a pool with poor reputation.

Fix: Either configure IPv6 rDNS properly and ensure FCrDNS, or stop advertising IPv6 for outbound mail until you can do it right.

7) Symptom: You “set PTR,” but some receivers still claim it’s missing

Root cause: Propagation/caching, or you set PTR for the wrong IP (common with NAT), or you tested against your internal resolver that lies.

Fix: Query public resolvers directly. Confirm the connecting IP from logs. Wait for TTLs to expire, but don’t confuse waiting with fixing.

8) Symptom: Deliverability drops after moving to a new provider

Root cause: PTR reset to provider default; SPF not updated; HELO mismatch; IP reputation cold start.

Fix: Treat migrations as identity migrations. Pre-provision PTR and forward records. Warm up the new IPs. Keep old sender running during transition if possible.

Checklists / step-by-step plan

Step-by-step: fix missing PTR the safe way

1. Identify the actual sending IP(s). Use bounces, SMTP logs, or packet capture. Don’t guess.
2. Pick a canonical mail hostname per sending IP. Example: mail01.example.com for 203.0.113.10. Keep it stable.
3. Create forward DNS first. Add A (and AAAA if applicable) for the hostname pointing to the sending IP.
4. Request/set the PTR at the provider. Point it to the canonical hostname. Avoid multiple PTRs.
5. Verify FCrDNS. PTR resolves to hostname; hostname resolves back to the IP.
6. Align HELO/EHLO. Configure your MTA to greet as the canonical hostname.
7. Confirm SPF includes the sending IP(s). Use a strict policy if you can support it.
8. Confirm DKIM signing works end-to-end. Verify with message headers at recipients.
9. Check DMARC alignment. Especially if you enforce quarantine/reject.
10. Monitor queues and bounces for 48–72 hours. Expect some caches to lag. Correlate by recipient domain.
11. Document the ownership boundary. Who can change PTR (provider), who can change forward DNS (you), and the SLA.

Operational checklist: before you put a new outbound IP into service

• PTR set and verified from at least two public resolvers.
• A/AAAA for PTR hostname exists and matches IP.
• MTA HELO name is that hostname; banner matches.
• SPF updated for sending domains.
• DKIM selector published; signing enabled; test mail shows DKIM=pass.
• DMARC present and aligned with your authentication strategy.
• IPv6 either fully configured (including rDNS) or intentionally disabled for SMTP.
• Outbound rate limits set; warm-up plan exists for new IPs.
• Logging in place to map message-id → recipient domain → sending IP.

What to avoid when you’re tempted to “just make it work”

• Do not use a dynamic/residential IP for outbound mail.
• Do not rotate source IPs without consistent rDNS and warmed reputation.
• Do not set PTR to a hostname that doesn’t exist in forward DNS.
• Do not greet as localhost, an internal hostname, or a name with no A/AAAA record.
• Do not publish AAAA for your mail hostname if you can’t set IPv6 PTR.
• Do not assume your DNS tests reflect what external receivers see; test with public resolvers.

FAQ

1) Do I absolutely need a PTR record to send email?

You can technically send SMTP without it, but many receivers penalize or reject you. In practice, missing PTR is self-inflicted deliverability damage.

2) Who controls the PTR record—my DNS provider or my ISP/cloud?

The IP owner controls reverse DNS. That’s typically your ISP or cloud provider. Your normal authoritative DNS provider controls forward records (A/AAAA), not PTR.

3) Should PTR match the From: domain?

Not strictly. PTR should match the sending infrastructure identity (the server hostname). If you run your own domain, it’s cleanest when the PTR hostname is under your domain, but it doesn’t have to match the From: domain exactly.

4) What is FCrDNS and is it required?

FCrDNS means PTR → hostname → A/AAAA → same IP. It’s not a protocol requirement, but it’s a widely used sanity check. Passing it reduces suspicion.

5) Can one IP have multiple PTR records?

It can, but you generally shouldn’t. For email, one sending IP should present one stable identity. Multiple PTRs create ambiguity and can hurt heuristics.

6) If I fix PTR, will my deliverability instantly recover?

Sometimes you’ll see immediate improvement in hard rejects. Spam placement can take longer because reputation systems have memory. Fixing PTR stops the bleeding; it doesn’t erase history.

7) What about IPv6—do I need PTR there too?

If you deliver mail over IPv6, yes. Some receivers are stricter on IPv6 because it’s easier for abusive senders to obtain huge address space. If you can’t do IPv6 rDNS correctly, don’t advertise IPv6 for SMTP.

8) My provider only allows PTR like ip-203-0-113-10.provider.net. Is that okay?

It’s better than no PTR, but not ideal. If you can’t set a meaningful PTR and you care about deliverability, consider a provider that supports custom rDNS or use a reputable SMTP relay with dedicated IP options.

9) Does PTR replace SPF/DKIM/DMARC?

No. PTR is a weak infrastructure signal. SPF/DKIM/DMARC are authentication and policy signals. Modern filtering uses all of them, plus reputation and content.

10) What hostname should I use for PTR?

Use a stable, dedicated hostname for outbound mail: mail01.example.com or smtp-out.example.com. Make sure it has matching A/AAAA and that your MTA uses it for HELO.

Next steps you can do today

1. Find your real SMTP egress IP. Don’t trust diagrams; trust packet captures and bounces.
2. Run three lookups: dig -x <ip>, dig A <ptr-name>, and (if applicable) dig AAAA <ptr-name>. Make them agree.
3. Fix your MTA’s HELO/banner hostname so it’s a real, resolvable FQDN that matches your PTR identity.
4. Verify externally using public resolvers to avoid being fooled by internal DNS.
5. Then go after SPF/DKIM/DMARC alignment and IP warm-up. rDNS gets you past the “are you serious?” gate; authentication gets you into the building.

If your deliverability problems feel mysterious, start by making your infrastructure identity boring and consistent. Email rewards boring. It punishes clever.