SPF, DKIM, and DMARC all live in your domain's DNS zone. You control them: open your DNS panel, edit the record, done. PTR is different. It's checked as hard as the others by receiving servers, it will get your mail rejected if it's wrong — and it isn't in your zone at all. You can't fix it where you fix everything else, and that's why it's the one that surprises people.
Forward DNS versus reverse DNS
Normal DNS is forward: a name points to an address. mail.yourdomain.com → 203.0.113.24. You own the name, so you own the record.
Reverse DNS goes the other way: an address points back to a name. 203.0.113.24 → mail.yourdomain.com. That record — the PTR — lives in a special zone (in-addr.arpa) that belongs to whoever owns the IP address, which is your hosting provider, your ISP, or your ESP. Not you. You can publish anything you like in yourdomain.com's zone and it will never create a PTR, because the PTR isn't in your domain. It's in the IP's.
Forward: mail.yourdomain.com A 203.0.113.24 ← your zone, you edit it Reverse: 203.0.113.24 PTR mail.yourdomain.com ← the IP owner's zone
What receiving servers do with it
A receiving mail server, before it even looks at your content, takes the IP that connected and asks two questions:
- Does this IP have a PTR at all? An IP with no reverse DNS is treated as suspicious. Legitimate mail servers have proper reverse DNS; a large share of spam comes from IPs that don't. Many receivers reject on a missing PTR outright.
- Does it confirm forward and back? The PTR should name a host, and that host's forward record should resolve back to the same IP. That round trip is called forward-confirmed reverse DNS (FCrDNS). If
203.0.113.24claims to bemail.yourdomain.combutmail.yourdomain.comresolves to a different address, the claim fails, and the mail is downgraded or refused.
Then there's the quiet killer: the generic PTR. Your mail is sending from an IP whose reverse DNS is still the provider's default — something like host-203-0-113-24.pool.isp-example.net. It's technically present and it round-trips, but it's obviously a dynamic or unconfigured host, and receivers score it as a home connection or a bot, not a real mail server. The mail authenticates and still lands in spam.
Who this actually affects
If you send through Google Workspace, Microsoft 365, or a reputable ESP, this is already handled — their sending IPs have correct, non-generic PTRs, and you'll never think about it. The problem shows up in two situations:
- You run your own mail server, on a VPS or a dedicated IP, and never set the PTR — because your DNS panel has no field for it and it wasn't obvious it lived somewhere else.
- You were assigned a dedicated IP by a provider and the reverse DNS was left at the provider's generic default.
In both cases the fix is not in your DNS panel. You open a request with whoever owns the IP — your host, your VPS provider, your ESP — and ask them to set the PTR for that IP to a hostname you control, then publish the matching forward A record in your own zone so it round-trips. Two records, two different owners, and they have to agree.
Check what your sending IP resolves to
Because the PTR isn't in your zone, it's easy to have never looked at it — and a missing or generic one is invisible from your outbox, exactly like a DKIM alignment failure. A domain check that follows your mail path will show you what your sending IP resolves to: check your domain. If the PTR line comes back missing or generic, no amount of editing your SPF, DKIM, or DMARC will move it — because the record you need to change was never yours to begin with.