Table of Contents
When Everything Looks Fine but Nothing Works
It started with a Slack message from our sales lead: “Hey, a client says they never got my quote. Third one this week.”
We didn’t think much of it at first — email gets lost, people miss things. But by the end of the day, we had a pattern. Multiple recipients across different companies were reporting the same thing: our emails simply weren’t arriving. Not bouncing. Not erroring. Just silently landing in spam folders, or vanishing entirely.
Here’s the frustrating part: everything on our end looked perfectly healthy. The mail server was up. Messages left our queue without errors. Our logs showed successful handoffs. From where we stood, we were sending mail into a black hole.
What followed was a week of debugging that took us down three wrong paths before we found the real culprit — a single missing DNS record we hadn’t even thought to check. This is the full story, including the dead ends, because the dead ends are where the real lessons live.
Wrong Turn #1: “It Must Be SPF or DKIM”
Modern email deliverability lives and dies by authentication, so that’s where we started. If your SPF, DKIM, or DMARC records are misconfigured, receiving servers will happily dump your mail in spam.
We checked SPF first:
dig +short TXT example.com | grep spf
# "v=spf1 include:_spf.google.com ip4:203.0.113.25 ~all"Our sending IP was included. Good.
Then DKIM:
dig +short TXT selector1._domainkey.example.com
# "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."The public key was published and matched our signing key. We even sent test messages to a mail-tester service, which confirmed our DKIM signatures were valid.
Finally, DMARC:
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
dig +short TXT _dmarc.example.com
# "v=DMARC1; p=none; rua=mailto:[email protected]"All present. All correct. A full day gone, and authentication was ruled out.
Wrong Turn #2: “We Must Be Blacklisted”
The next obvious suspect: our sending IP had landed on a spam blacklist (an RBL/DNSBL). This happens more often than people think — a shared IP range, a previous tenant’s bad behavior, or a compromised account can get you listed.
We checked our IP against the major blocklists. You can query a DNSBL manually by reversing your IP and appending the blacklist’s zone:
# Check 203.0.113.25 against Spamhaus ZEN
dig +short 25.113.0.203.zen.spamhaus.org
# (empty result = not listed)An empty response means you’re not on the list. We ran this against Spamhaus, Barracuda, SORBS, and a handful of others using an online multi-RBL checker to be thorough.
Clean. Every single one. Our reputation wasn’t the problem either. Day three, and we were still guessing.
The Turning Point: Reading the Rejection Header
We had been staring at our logs the whole time. The breakthrough came when we stopped looking at what we sent and started looking at what the receiving servers were telling us.
One recipient kindly forwarded us the full headers of a message that had been quarantined. Buried in the diagnostic text was this:
Received: from mail.example.com (unknown [203.0.113.25])
...
X-Spam-Status: ... REVERSE_DNS_FAIL ...Two things jumped out: the word unknown where a hostname should have been, and the tag REVERSE_DNS_FAIL.
The receiving server had tried to look up who 203.0.113.25 was — a reverse DNS (PTR) lookup — and got nothing back. To a spam filter, a mail server with no reverse DNS is a giant red flag. Legitimate mail servers almost always have a PTR record; spam bots frequently don’t.
We had been so focused on SPF, DKIM, and blacklists that we’d never checked the most basic identity record of all.
Confirming the Root Cause
A PTR (Pointer) record does the reverse of a normal DNS lookup. A regular lookup maps a hostname to an IP address; a PTR record maps an IP address back to a hostname. Mail servers use it as a fundamental sanity check on who’s connecting to them.
We ran the reverse lookup on our own sending IP:
dig -x 203.0.113.25 +short
# (empty — no output at all)Nothing. For comparison, here’s what a healthy mail server looks like — Google’s, for instance:
dig -x 8.8.4.4 +short
# dns.google.That empty result was our smoking gun. Our outbound mail server had no PTR record whatsoever. Every receiving server that bothered to check saw an anonymous IP claiming to be a mail server, and treated it accordingly.
We double-checked with nslookup to be certain it wasn’t a dig quirk:
nslookup 203.0.113.25
# ** server can't find 25.113.0.203.in-addr.arpa: NXDOMAINNXDOMAIN — the record didn’t exist. Confirmed.
The Deeper Lesson: PTR Alone Isn’t Enough — You Need FCrDNS
Here’s the part most tutorials skip, and it cost us extra time: simply having a PTR record isn’t sufficient. What mail servers actually want is FCrDNS — Forward-Confirmed reverse DNS.
FCrDNS means the lookup works both ways and agrees:
- The PTR record for your IP points to a hostname (e.g.,
203.0.113.25→mail.example.com). - The A record for that hostname points back to the same IP (
mail.example.com→203.0.113.25).
flowchart LR
IP["203.0.113.25"] -->|PTR record| Host["mail.example.com"]
Host -->|A record| IP
IP -. "both directions must match" .- HostIf the PTR points to a hostname whose A record points somewhere else — or nowhere — many filters still reject you. So the fix wasn’t just “add a PTR record.” It was “add a PTR record whose hostname resolves back to this exact IP.“
The opinion I’ll stand behind: Most guides tell you how to check a PTR record and stop there. The real-world requirement is FCrDNS consistency. A mismatched forward/reverse pair will sink your deliverability just as surely as a missing record — and it’s far harder to notice, because a naive
dig -xwill show a result and lull you into thinking you’re fine.
The Fix: Who Actually Controls Your PTR Record
This tripped us up too. You cannot add a PTR record in your own domain’s DNS zone. Reverse DNS for an IP is controlled by whoever owns the IP block — your ISP, hosting provider, or cloud vendor — not by you as the domain owner.
Our server was on a cloud provider, so the fix went like this:
- Set the forward record first. In our own DNS zone, we made sure
mail.example.comhad an A record pointing to203.0.113.25. - Request the PTR from the provider. For our cloud host, this was a setting in the instance’s network configuration (“Reverse DNS / PTR”). For a traditional ISP, it’s typically a support ticket asking them to set the PTR for
203.0.113.25tomail.example.com. - Wait for propagation. Reverse DNS changes can take anywhere from minutes to a day to propagate.
Once it was live, we verified the full FCrDNS chain — both directions:
# Reverse: IP → hostname
dig -x 203.0.113.25 +short
# mail.example.com.
# Forward: hostname → IP (must match the original IP)
dig +short mail.example.com
# 203.0.113.25Both directions matched. FCrDNS was intact.
The Results: Before and After
We didn’t want to trust our gut, so we measured. Here’s our inbound-acceptance rate (percentage of test messages reaching the inbox across Gmail, Outlook, and a corporate Exchange server) before and after the fix:
| Metric | Before (no PTR) | After (FCrDNS fixed) |
|---|---|---|
| Gmail inbox placement | 34% | 98% |
| Outlook/Office 365 inbox placement | 21% | 96% |
| Corporate Exchange acceptance | 12% | 99% |
REVERSE_DNS_FAIL flags | Present on ~80% | 0 |
The difference was night and day. Within hours of the PTR record propagating, the spam complaints stopped and our test messages sailed straight into inboxes.
The Checklist We Wish We’d Had
If we’d run through this list on day one, we’d have saved a week. Here’s the pre-flight check we now run before any mail server goes live:
- [ ] PTR record exists —
dig -x <your-ip> +shortreturns a hostname, not empty. - [ ] Forward record matches —
dig +short <that-hostname>returns the same IP (FCrDNS). - [ ] Hostname is meaningful — it should look like a mail server (
mail.example.com), not a generic provider default (ip-203-0-113-25.cloud.example). - [ ] SPF authorizes the sending IP.
- [ ] DKIM is signing and the public key is published.
- [ ] DMARC policy is published.
- [ ] IP is not on major blocklists (Spamhaus, Barracuda, etc.).
- [ ] HELO/EHLO hostname matches the PTR hostname (another consistency check filters love).
That last point is worth its own note: for the cleanest reputation, the hostname your server announces in its HELO/EHLO greeting should also match its PTR record. Full consistency — HELO, forward, and reverse all pointing at the same identity — is what separates trusted mail servers from suspicious ones.
Takeaways
- When mail silently disappears, check reverse DNS early. It’s not the first thing most of us think of, but it’s one of the easiest to overlook and one of the most impactful.
- A missing PTR record makes you look like a spam bot to receiving servers, regardless of how perfect your SPF/DKIM/DMARC setup is.
- PTR alone isn’t enough — aim for FCrDNS. The forward and reverse records must agree.
- You don’t control your own PTR record — your IP’s owner (ISP/cloud provider) does. Plan for a support request and propagation time.
- Measure before and after. Deliverability is invisible until you quantify it.
The commands to check a PTR record — dig -x and nslookup — take two seconds to run. The lesson that cost us a week was knowing when and why to run them, and understanding that a passing reverse lookup is only half the story.
Have you been burned by a reverse DNS issue? Drop your story in the comments — and if you want the full pre-launch mail-server checklist as a runnable shell script, subscribe and we’ll send it over.
