Reverse DNS for Email: Why PTR Records Matter
Reverse DNS maps a sending IP address back to a hostname using a PTR record. Receiving mail servers run that lookup during the SMTP handshake to confirm the machine connecting to them is an identified, accountable sender. Missing or generic reverse DNS is a routine cause of deferrals, spam placement, and outright connection refusal.
What reverse DNS actually is
Normal DNS resolution goes one direction: you ask for a name and get an IP address. mail.example.com resolves to 203.0.113.25 through an A record (or AAAA for IPv6). Reverse DNS goes the other way. You hand a resolver an IP address and it hands back a hostname.
The mechanism is a special zone. The IPv4 address 203.0.113.25 is rewritten octet-by-octet in reverse and appended to in-addr.arpa, producing 25.113.0.203.in-addr.arpa. A PTR record at that name points to mail.example.com. IPv6 uses the same idea with nibble-reversed names under ip6.arpa, which is why IPv6 reverse zones look absurdly long.
The critical detail most people miss: the PTR record does not live in your domain's zone file. It lives in the reverse zone for the IP block, which is delegated to whoever owns the address space. If you rent a server, that is your hosting provider. If you send through a shared platform, it is the platform. You almost never edit it yourself in the same place you edit your MX and TXT records.
How receiving servers use the PTR check
When your server opens a connection on port 25, the receiving side knows exactly one thing about you: the IP address the packets came from. Reverse DNS is the first cheap identity signal it can pull. A typical sequence looks like this:
- The receiver takes the connecting IP and performs a PTR lookup.
- If a hostname comes back, the receiver performs a forward lookup on that hostname.
- It checks whether the forward lookup resolves back to the original IP. A match is called forward-confirmed reverse DNS, or FCrDNS.
- It compares the PTR hostname against the name your server announced in its HELO or EHLO command.
- It scores all of that alongside SPF, DKIM, DMARC, and the IP's reputation history.
None of these checks is a pass/fail gate on its own at most providers, but they compound. A sender with no PTR, a mismatched HELO, and a cold IP looks like a compromised machine. A sender with clean FCrDNS, a matching HELO, and aligned authentication looks like infrastructure someone owns and maintains. Some receivers — particularly corporate gateways and smaller ISPs — do reject outright on missing or generic PTR, which is why the failure mode is often "everyone gets it except one stubborn domain."
What a correct PTR record looks like
| Scenario | PTR value for 203.0.113.25 | Forward lookup result | How receivers read it |
|---|---|---|---|
| Ideal | mail.example.com | 203.0.113.25 | FCrDNS passes; branded, accountable sender |
| Mismatched | mail.example.com | 198.51.100.9 | FCrDNS fails; treated as misconfigured or spoofed |
| Generic provider default | 203-0-113-25.static.hostingco.net | 203.0.113.25 | Technically passes, but anonymous — weak signal |
| Dynamic-looking | 203-0-113-25.dsl.dyn.isp.net | 203.0.113.25 | Strong negative; looks like a residential bot |
| No PTR at all | NXDOMAIN | n/a | Frequent deferral or 550 rejection |
Note the third row. Many teams check reverse DNS, see that something resolves, and declare victory. A generic provider hostname is better than nothing, but it tells the receiver nothing about who you are. Replacing it with a hostname on your own domain is a small change with real payoff, especially on a dedicated IP where reputation accrues to you specifically.
Reverse DNS, HELO, and the envelope sender. Three identifiers get compared during a single SMTP conversation, and they should tell a consistent story:
- The PTR hostname — what the IP claims to be.
- The HELO/EHLO name — what your mail server announces itself as.
- The envelope sender domain — the Return-Path, which SPF is evaluated against.
The strongest configuration has the PTR and HELO identical, both resolving to the sending IP, and the envelope domain either the same or an obvious sibling. A machine whose PTR says mail.example.com but which greets receivers as localhost.localdomain is announcing a sloppy setup. That mismatch alone will not blackhole you, but it is exactly the kind of signal filters accumulate when deciding whether a borderline message lands in the inbox.
Who controls your PTR record
| Sending setup | Who sets the PTR | What you should do |
|---|---|---|
| Self-hosted server on a VPS or cloud instance | Your hosting provider | Set it in the provider console or open a support ticket with the desired hostname |
| Shared IP pool at an email platform | The platform | Nothing — the platform's PTR is already in place and shared across senders |
| Dedicated IP at an email platform | The platform, on request | Ask for a branded PTR and add the matching A record on your domain |
| On-premise mail server behind your own ASN | You | Manage the in-addr.arpa or ip6.arpa zone directly |
This is one of the practical advantages of sending through a managed platform. When you use a hosted SMTP relay service, the reverse DNS, the HELO name, and the forward records are already consistent before you send your first message — you inherit infrastructure that has been maintained rather than assembling it yourself.
How to check your reverse DNS in two minutes
From any terminal, run the reverse lookup against your sending IP:
dig -x 203.0.113.25 +short— returns the PTR hostname, or nothing at all.dig +short mail.example.com— run this on whatever the first command returned, and confirm the IP matches. That confirms FCrDNS.host 203.0.113.25— the quicker one-liner if you just want a yes or no.
You can also read it out of a delivered message. Open the full headers of an email you sent to yourself and look at the topmost Received: line added by the receiving server. It typically records both the reverse-resolved hostname and the IP in parentheses, which shows you exactly what the receiver saw. If the hostname is absent or reads as the bare IP, your PTR is missing. Pairing that header check with a broader email deliverability review will usually surface authentication gaps at the same time.
Common reverse DNS mistakes that hurt delivery
- Assuming DNS propagation is instant. Reverse zones are often cached aggressively. Allow up to 24–48 hours before judging a change.
- Setting the PTR without the matching A record. A PTR pointing at a hostname that does not resolve is worse than a generic default, because it fails FCrDNS explicitly.
- Using a marketing domain that changes. Point the PTR at a stable infrastructure hostname you will not rename during a rebrand.
- Ignoring IPv6. If your server has an AAAA record and connects over IPv6, receivers check the IPv6 PTR. Missing IPv6 reverse DNS causes intermittent failures that look random because only some connections take the v6 path.
- Multiple PTRs on one IP. Legal in DNS, but ambiguous to filters. Keep exactly one.
- Fixing PTR and expecting a reputation reset. Reverse DNS is a hygiene requirement, not a reputation cure. If the IP already has complaint history, correcting the PTR will not undo it.
Where reverse DNS fits alongside SPF, DKIM, and DMARC
| Check | What it proves | Layer | Who configures it |
|---|---|---|---|
| Reverse DNS / PTR | The connecting IP has a claimed, verifiable identity | Connection | IP owner |
| SPF | The IP is authorized to send for the envelope domain | Envelope | Domain owner |
| DKIM | The message content and headers were not altered in transit | Message | Domain owner |
| DMARC | The visible From domain aligns with SPF or DKIM, plus a failure policy | Policy | Domain owner |
These are complementary, not redundant. Reverse DNS answers "is this machine anybody?" while the authentication stack answers "is this machine allowed to speak for this domain?" You need both. Platforms that configure SPF, DKIM, and DMARC automatically remove most of the second half of that problem, but you still want to confirm the reverse DNS on the IPs actually carrying your mail.
What to do when you cannot set a PTR record
Sometimes the IP owner will not delegate reverse DNS — common on cheap shared hosting and some consumer connections. You have three realistic options. Move the sending function to infrastructure where PTR is available, route your outbound mail through a relay whose IPs are already correctly configured, or accept a persistent deliverability tax. The middle option is almost always the right one: you keep your application, your domain, and your templates, and you stop fighting a DNS zone you do not control.
Frequently asked questions
Is a PTR record required to send email?
It is not required by the SMTP standard, but many receiving servers treat a missing PTR as a strong spam signal and some reject the connection outright. In practice, sending production email from an IP with no reverse DNS is not viable.
Can I set a PTR record in my domain's DNS settings?
No. PTR records live in the reverse zone for the IP block, which is delegated to whoever owns the address space. You request the change from your hosting provider or email platform, not from your registrar's DNS panel.
What is forward-confirmed reverse DNS?
FCrDNS means the PTR lookup on your IP returns a hostname, and a forward lookup on that hostname returns the same IP. It proves both directions agree, which is much harder to fake than a one-way record.
Do I need reverse DNS if I use a shared IP pool?
Your provider already maintains it for the pool, so there is nothing for you to configure. The tradeoff is that the PTR is generic to the provider rather than branded to your domain.
Will fixing my PTR record improve my open rates?
Indirectly, by increasing how many messages reach the inbox instead of the spam folder. It does nothing for subject lines or content — reverse DNS only affects whether the message gets accepted and where it is filed.
Ready to stop debugging DNS zones you do not control? IGSendMail handles reverse DNS, SPF, DKIM, and DMARC on infrastructure built for 99% inbox deliverability, with unlimited contacts on paid plans from $19/mo. Launch your first campaign with IGSendMail.