Your SPF, DKIM, and DMARC records all pass, yet a chunk of your mail still lands in spam or bounces outright. The check nobody looks at is the PTR record on your sending IP — a reverse DNS entry that has nothing to do with your domain's own DNS zone, which is exactly why it gets missed. EmailControl is an email deliverability monitoring service that watches business domains for spam blacklist listings and SPF, DKIM, and DMARC failures, and a broken PTR record is one of the most common causes of a listing that authentication checks alone never catch. Left alone, it costs you the quiet way: no bounce message, no error in your logs, just a slowly rising share of messages that never reach an inbox.
A PTR record is a DNS entry that maps an IP address back to a hostname, the reverse of the A record that maps a hostname to an IP address. When a receiving mail server gets a connection from your sending IP, it looks up the PTR record for that IP, then checks whether the hostname it gets back resolves forward to the same IP again. Mail servers call this a forward-confirmed reverse DNS check, and most large mailbox providers run it before they even look at your message body, because it is cheap to run and hard for a spammer to fake at scale.
What Happens When a PTR Record Is Missing or Generic?
If the lookup returns nothing, or it returns a generic hostname your hosting provider assigned by default — something like 123-45-67-89.static.example-host.net — the receiving server treats your connection as coming from an anonymous or residential-looking source. That alone will not always trigger a hard block, but it strips away trust the message needed to clear a spam filter, and it is exactly the kind of signal that pushes a borderline sender onto a blacklist. Google's and Yahoo's bulk sender requirements, published alongside their DMARC and one-click unsubscribe rules, both call for sending IPs to carry a valid, matching PTR record — the same requirement that pushed most bulk senders to also publish SPF, DKIM, and DMARC.
| PTR state | What the receiving server sees | Typical outcome |
|---|---|---|
| No PTR record at all | Reverse lookup returns nothing | Message often rejected outright or heavily downgraded |
| Generic host-assigned PTR | Hostname with no relation to your domain | Treated as unverified; more likely to land in spam |
| PTR matches your mail domain and resolves forward | Consistent, verifiable identity | One more trust signal in your favor |
How Do You Check Your PTR Record?
You do not need special tools, just a terminal and the IP address your mail server sends from. The whole check takes about two minutes once you know the commands.
- Find the IP address your outbound mail actually uses — check your mail server's outbound relay setting, not just the A record for your domain, since those can point to different servers.
- Run a reverse lookup:
dig -x your.server.ip.address +short. - Note the hostname it returns. If nothing comes back, you have no PTR record at all.
- Run a forward lookup on that hostname:
dig your-returned-hostname +short. - Confirm the forward lookup resolves back to the same IP you started with. If it does not match, the PTR is broken even though one technically exists.
- If the hostname is generic or unrelated to your sending domain, contact your host or VPS provider — PTR records are set at the IP owner's end, not in your domain's own DNS zone, so your registrar cannot fix this for you.
How Does PTR Relate to SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC all authenticate the domain named in the message headers or envelope. PTR authenticates the IP the connection is coming from, independent of anything your domain's DNS zone says. A message can pass SPF and DKIM cleanly and still get flagged if the connecting IP has no credible reverse DNS — the two checks are not measuring the same thing, and passing one does not excuse failing the other. RFC 1912, the long-standing operational guidance for DNS administrators, specifically recommends that every host with a public-facing service have a PTR record that matches its forward record for exactly this reason, and mail is the service where receiving servers actually enforce it.
Checking this by hand means running the same dig commands every time you rotate a sending IP, add a new mail server, or move hosting providers — easy to do once, easy to forget six months later when nothing looks obviously wrong. EmailControl checks your domain's blacklist status against Spamhaus ZEN, Barracuda, SORBS, and SpamCop alongside your SPF, DKIM, and DMARC records on a schedule, so a reputation problem shows up as a specific alert instead of a slow decline in replies you only notice weeks later. The full list of what gets checked and how the health score is weighted is on the FAQ page.
Isn't PTR the Hosting Provider's Problem, Not Mine?
Technically yes — you cannot edit the reverse DNS zone yourself, so it is tempting to treat it as someone else's responsibility. In practice, the deliverability damage lands on your domain's reputation, not your host's, and most hosting support teams will not proactively check it unless you ask. The honest answer is that you still own the outcome even though you do not own the record: open a ticket, name the exact IP and the hostname you want it to resolve to, and confirm the fix with the same dig command afterward. It is a five-minute conversation once you know what to ask for, and it is far cheaper than diagnosing a slow deliverability decline months later with no obvious cause.
The other honest objection is that a broken PTR record feels like a small thing next to a full authentication failure, so it gets deprioritized. Treat it with the same urgency: EmailControl's health score weights blacklist cleanliness at 50%, authentication records at 30%, and trend versus your previous checks at 20%, and a PTR problem tends to show up first as a slow trend decline rather than a sudden drop — exactly the pattern that gets ignored until a customer mentions a missing email.
What Is a Realistic Next Step?
Add your domain and EmailControl will check your mail server's blacklist status on Spamhaus, Barracuda, SORBS, and SpamCop along with your SPF, DKIM, and DMARC records, starting on the free plan with weekly checks and no credit card. If you want the same checks running daily against up to ten domains, the Pro plan is $19 a month. Either way, you get a specific alert the moment a check changes state, instead of finding out from a customer who says your email never arrived. Start free monitoring and add your domain — it takes about a minute, and the first check runs automatically.