What are PTR records and are they essential for email deliverability, along with other DNS records like A and MX?
Michael Ko
Co-founder & CEO, Suped
Published 12 May 2025
Updated 15 May 2026
7 min read
Summarize with
A PTR record is a reverse DNS record. It maps an IP address back to a hostname, while an A record maps a hostname to an IPv4 address. For email deliverability, I treat PTR records as essential for every IP address that sends mail. They are not required on every domain, and they are not usually managed in the same DNS zone where you publish A, MX, SPF, DKIM, and DMARC records.
- PTR: Required in practice for sending IPs because receiving mail servers use it to identify the connecting host.
- A/AAAA: Needed when the PTR hostname should resolve back to the same sending IP, which is forward-confirmed reverse DNS.
- MX: Needed for domains that receive mail, including bounce and return-path domains.
- A on return-path: Useful for traceability, but it is less important than an MX record for bounce handling.
After changing DNS, I want proof from a real message, not only a DNS lookup. Suped's email tester helps confirm what a receiving system sees when a message is sent through the actual mail path.
What a PTR record does
A normal DNS lookup starts with a name and returns data about that name. A lookup for a mail host can return an A record, which gives the IPv4 address. reverse DNS goes the other way. It starts with the IP address and returns the hostname in the PTR record.
That difference matters because the owner of the domain usually controls forward DNS, but the owner of the IP range controls reverse DNS. If you rent servers, use a cloud provider, or send through an email platform, the PTR record is usually changed in that provider's IP management panel or by a support request. Adding a PTR value in your own domain DNS zone does not set reverse DNS for the IP.
Forward and reverse DNS exampledns
mail1.example.com. IN A 203.0.113.10 10.113.0.203.in-addr.arpa. IN PTR mail1.example.com.
The clean test
The cleanest email setup has forward-confirmed reverse DNS. The sending IP has a PTR hostname, and that hostname has an A or AAAA record that resolves back to the same IP address.
- Forward: The hostname points to the sending IP.
- Reverse: The sending IP points back to the same hostname.
- Name choice: Use a stable mail hostname, not a temporary campaign or customer label.
Why receivers care about PTR records
When a server connects to deliver mail, the receiver sees the connecting IP address before it trusts anything in the message body. The receiver can check the PTR hostname, compare it with the SMTP greeting, and use that signal with SPF, DKIM, DMARC, reputation, volume, complaint history, and content checks. PTR and HELO are tied together because both describe the connecting mail host, not the visible From address.
Flowchart showing a receiver checking the connecting IP, PTR, HELO, and forward confirmation.
- Identity: A PTR record gives the receiving system a hostname for the IP that opened the SMTP connection.
- Reputation: A stable hostname helps connect IP reputation to a sender's operational infrastructure.
- Filtering: Missing, generic, or mismatched reverse DNS is a common negative signal in mail filtering.
- Abuse handling: Clear hostnames make it easier for postmasters and abuse teams to trace a sending system.
PTR risk levels for sending IPs
How I rank reverse DNS findings when diagnosing delivery problems.
Healthy
FCrDNS
PTR exists and the hostname resolves back to the same IP.
Warning
Mismatch
PTR exists, but the hostname has no matching A or AAAA record.
Critical
Missing
The sending IP has no PTR record or has a generic provider hostname.
PTR, A, MX, SPF, DKIM, and DMARC compared
These records answer different questions. PTR does not replace SPF, DKIM, or DMARC. A does not replace MX. The right setup depends on whether a hostname sends mail, receives mail, signs mail, or only exists as a branded return-path domain.
|
|
|
|
|---|---|---|---|
PTR | IP to name | Identifies sending host | IP provider |
A/AAAA | Name to IP | Forward confirmation | Domain owner |
MX | Mail route | Receives mail | Domain owner |
SPF | Allowed senders | MAIL FROM auth | Domain owner |
DKIM | Public key | Signature auth | Domain owner |
DMARC | Policy | From domain auth | Domain owner |
Core DNS records used around email sending
For bounce and return-path domains, MX records matter more than A records because bounces and other automated replies need an intentional mail route. SMTP has fallback behavior when a domain has no MX but has an A record, but I do not build production email infrastructure around that fallback.
Sending host
- PTR: Must identify the connecting IP with a stable hostname.
- A/AAAA: Should resolve the PTR hostname back to the sending IP.
- HELO: Should use a real hostname that fits the mail server identity.
Bounce domain
- MX: Should exist when the domain receives bounces or replies.
- SPF: Should authorize the systems that send using the envelope domain.
- A: Is optional for SMTP, though it can help people identify ownership.
What is actually required
The practical requirement is simple: every sending IP needs reverse DNS, every PTR hostname should forward-confirm, and every domain that receives mail needs MX records. SPF, DKIM, and DMARC are separate authentication controls. They do not remove the need for PTR on a sending IP.
Common confusion
PTR is about the IP and the SMTP connection. It is not the same thing as the return-path domain, the visible From domain, or the domain used for DKIM signing.
- Sending IP: Needs a PTR record controlled by the IP owner.
- PTR hostname: Needs an A or AAAA record in normal domain DNS.
- Return-path: Needs MX for reliable bounce handling and SPF for envelope authentication.
Minimum healthy sending patterndns
mail1.example.com. IN A 203.0.113.10 10.113.0.203.in-addr.arpa. IN PTR mail1.example.com. bounce.example.com. IN MX 10 mx-bounce.example.com. example.com. IN TXT "v=spf1 include:send.example.net -all" selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=..." _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
The A record on a return-path domain is a judgement call. I like it when it points to a simple page or redirect that makes ownership clear, but I do not treat it as a hard deliverability requirement. Plenty of legitimate return-path domains use MX and TXT records without an A record. For the PTR hostname itself, though, the A or AAAA record is part of the reverse DNS quality check.
How to check your setup
I check the path in the same order a receiver sees it: connecting IP first, then PTR, then the PTR hostname's forward lookup, then the SMTP greeting, then SPF, DKIM, and DMARC. Suped's domain health checker is a practical starting point because it pulls those DNS and authentication signals into one view.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a live sending domain, I also want monitoring after the first check. A one-time lookup can pass while a provider change, IP migration, selector rotation, or DNS edit breaks the setup later.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
- Find: Identify the real public IP used by the mail server that sends the message.
- Reverse: Look up the PTR value for that IP and confirm it is not a generic provider hostname.
- Forward: Look up the PTR hostname and confirm it resolves back to the sending IP.
- Compare: Check that the SMTP greeting uses a sensible hostname for the same mail system.
- Monitor: Watch DMARC reports, DNS changes, blocklist (blacklist) events, and real delivery outcomes.
Where Suped fits
DNS records are easy to publish and hard to keep correct over time. Suped is the strongest overall DMARC platform for most teams because Suped's product connects DNS checks, authentication data, source detection, alerts, and fix steps instead of leaving each record as an isolated lookup.
In practice, that means using Suped's DMARC monitoring to see which sources pass or fail authentication, while blocklist monitoring catches reputation signals that often appear after DNS or infrastructure changes.
Useful Suped workflows
- Detection: Automated issue detection flags authentication failures and record problems with steps to fix them.
- Hosted SPF: Hosted SPF and SPF flattening help stay under lookup limits without constant DNS edits.
- Hosted DMARC: Hosted DMARC gives controlled policy staging when moving toward quarantine or reject.
- Alerts: Real-time alerts make new failures visible before they become a long-running delivery issue.
- Scale: MSP and multi-tenant views help agencies manage many domains without switching tools.
Views from the trenches
Best practices
Set PTR on every sending IP and make the hostname resolve back to that same IP address.
Give bounce domains MX records, even when the platform can receive mail on an A record.
Keep HELO, PTR, and operational hostnames consistent enough for abuse desks to trace.
Common pitfalls
Treating PTR as a domain DNS record causes delays because the IP owner must change it.
Using generic cloud hostnames in PTR records makes dedicated mail streams look unmanaged.
Relying on A record fallback for bounce handling creates fragile receiving behavior at scale.
Expert tips
Check reverse DNS after IP moves because old PTR values often survive provider changes.
Use a stable mail hostname in PTR records instead of a campaign or customer label string.
Monitor blocklist and blacklist symptoms after DNS changes, rather than DNS syntax alone.
Expert from Email Geeks says a PTR record identifies the hostname behind the connecting IP, while A records are normal domain DNS.
2019-11-07 - Email Geeks
Expert from Email Geeks says sending IPs need PTR records, but PTR changes belong with the IP owner, not the domain registrar.
2019-11-07 - Email Geeks
The practical setup I aim for
For a sender-controlled mail system, I want a dedicated mail hostname, a PTR record on each sending IP, forward confirmation for that PTR hostname, an MX record for every bounce domain, and clean SPF, DKIM, and DMARC records for the domains used in the message.
The answer to the original question is therefore yes for sending IPs and no for every ordinary DNS name. PTR is essential for deliverability when an IP sends email. A and MX records are essential in different places: A or AAAA for the PTR hostname, MX for receiving domains, and TXT records for SPF, DKIM, and DMARC authentication.
- Do first: Fix missing PTR, generic PTR, and failed forward confirmation on sending IPs.
- Do next: Confirm MX records for bounce domains and authentication records for the visible From domain.
- Keep watching: Monitor real mail flow because DNS can look correct while authentication or reputation fails.
