What is a PTR (Reverse DNS) record and what does it do for email?
A PTR record is a DNS record that maps an IP address back to a host name. Most people think of DNS as “domain name → IP address” (A/AAAA records). Reverse DNS (rDNS) works the other way around: “IP address → host name.” In email delivery, many receiving mail servers check whether the connecting IP has a valid reverse DNS entry.
This isn’t about “encryption” or a single magical trust signal. It’s a practical indicator of operational hygiene. A lot of abusive or poorly managed sending sources (infected machines, random cloud instances, misconfigured servers) either have no PTR record or have an inconsistent one. A properly managed business mail server typically has a stable, meaningful reverse DNS setup. PTR won’t guarantee inbox placement, but missing or sloppy rDNS can contribute to filtering, higher spam scores, or outright rejections depending on the recipient’s policy.
Forward DNS vs reverse DNS: why FCrDNS matters
In email administration you’ll often see “FCrDNS,” short for Forward-Confirmed reverse DNS. It’s a consistency check that typically looks like this:
- Your sending IP address has a PTR record that returns a host name.
- That host name has an A (or AAAA) record that resolves back to the same IP address.
This two-way match doesn’t replace SPF, DKIM, or DMARC, but it can strengthen the overall trust profile of your infrastructure. One key operational detail: you usually can’t set PTR records in your normal domain DNS panel. PTR is managed by whoever controls the IP space (your hosting provider, ISP, or internal network team). Meanwhile, the A/AAAA record for the chosen host name is managed in your own domain’s DNS. Achieving FCrDNS is therefore a coordination task across both sides.
How PTR affects email deliverability in practice
Receiving systems make decisions based on a mix of signals: IP reputation, authentication (SPF/DKIM/DMARC), TLS usage, sending patterns, content quality, and infrastructure consistency. PTR/rDNS falls into the “infrastructure consistency” bucket. It’s rarely the only factor, but it’s a common baseline expectation for legitimate senders.
What if there’s no PTR record?
If your sending IP has no PTR record, some recipients may reject the SMTP connection or the message. Others may accept but treat it as lower trust and route it to spam. Many systems simply add negative scoring. The strictness varies, but “no rDNS” is an avoidable risk for business email.
What if the PTR exists but looks generic?
A generic PTR like “host-203-0-113-10.provider.example” is not automatically a deal-breaker. However, a clean, purposeful name such as “mail.yourcompany.com” is easier to manage and tends to look more deliberate. The most important point is consistency and, ideally, a forward-confirmed match.
How PTR relates to SPF/DKIM/DMARC
PTR is not a substitute for authentication. SPF authorizes which IPs can send for a domain, DKIM signs messages, and DMARC sets policy and alignment rules. Reverse DNS supports the overall credibility of the sending host. Strong deliverability comes from getting all of these basics right together.
Designing reverse DNS for a mail server: what “good” looks like
The goal is a stable, readable host name that clearly represents your mail-sending system. Common patterns include:
- If you have one sending IP: mail.yourcompany.com or smtp.yourcompany.com
- If you have multiple IPs: mail1.yourcompany.com, mail2.yourcompany.com, etc.
- Ensure the host name used in PTR has an A/AAAA record pointing back to the same sending IP.
- Avoid unrelated branding, random strings, or misleading names.
Another related detail is the SMTP server’s HELO/EHLO name (the host name your server announces during the SMTP session). While policies vary, keeping “HELO name ↔ PTR name ↔ A/AAAA” consistent is a widely accepted best practice and avoids unnecessary suspicion.
How to set up PTR (rDNS): a practical checklist
1) Identify the real outbound sending IP
First, confirm which IP address recipients actually see when your system sends mail. In some environments, your application server is behind NAT, a gateway relays outbound SMTP, or your email service uses its own egress IPs. Setting PTR on the wrong IP is a very common mistake.
2) Determine who controls reverse DNS for that IP
PTR records live in the reverse DNS zone for the IP block and are typically controlled by the IP owner. This is often managed through:
- Your hosting provider’s control panel
- An ISP ticket/request process
- An internal network team if you own the IP space
Seeing a “PTR” option in a domain DNS interface doesn’t necessarily mean you can set reverse DNS for your server’s IP. Authority matters.
3) Create the matching forward record (A/AAAA)
In your domain DNS, create an A record (for IPv4) and, if applicable, an AAAA record (for IPv6) for the host name you plan to use in your PTR. The forward record should point to the same outbound sending IP.
4) Validate the forward and reverse match
Once changes propagate, test both directions: reverse lookup on the IP should return your chosen host name; forward lookup on that host name should return the same IP. Keep in mind DNS propagation and TTL values; plan changes during a maintenance window if needed.
5) Align the SMTP/HELO host name
Configure your mail server so the HELO/EHLO name is consistent with your rDNS identity (or at least within the same domain and clearly related). The goal is to avoid a situation where the server “claims” to be one host name while reverse DNS suggests another.
Common PTR/rDNS mistakes that cause email issues
Expecting multiple PTR records to help
While multiple PTRs for a single IP can exist, it’s not recommended for email sending. It can create ambiguity and scoring issues. Use one stable PTR per sending IP.
PTR pointing to an unrelated domain
If you send as yourcompany.com but your PTR points to a different domain (an old brand, a random domain, or something unrelated), some recipients may treat it as suspicious or simply “low quality.” When possible, keep the PTR host name under your own domain.
Forgetting IPv6 reverse DNS
If your server can send over IPv6, you need PTR for the IPv6 address too (ip6.arpa reverse zone). Dual-stack setups can behave inconsistently if only IPv4 rDNS is configured.
Fixing rDNS while the actual egress IP stays different
In cloud and NAT scenarios, you may configure everything for one IP but the system still sends from another. If recipients keep reporting rDNS problems, re-check the real outbound path and confirm the egress IP.
Is PTR enough by itself? When to look elsewhere
Even with perfect reverse DNS, you can still face deliverability problems. Treat PTR as a baseline hygiene step, then validate the rest of your sending fundamentals:
- Is your SPF record correct and does it include all legitimate senders?
- Are you signing with DKIM, and does it verify reliably?
- Is DMARC configured appropriately, including alignment?
- What do sending patterns look like (volume spikes, list quality, complaint rates)?
- Are message content and links triggering filters?
Reverse DNS usually won’t “fix everything,” but it prevents avoidable failures and removes a common reason for reduced trust.
Final quick checks and an operational takeaway
- Does every outbound sending IP have a PTR record?
- Does the PTR host name resolve back to the same IP via A/AAAA (FCrDNS)?
- Is your SMTP HELO/EHLO name consistent with that identity?
- If you use IPv6, is IPv6 PTR configured as well?
- Have you allowed enough time for DNS propagation and TTL?
When you manage business email infrastructure, reverse DNS is one of those fundamentals that’s easy to overlook until it becomes a problem. Keeping PTR/rDNS consistent alongside SPF, DKIM, DMARC, and TLS leads to more predictable outcomes. If you’re reviewing your setup during a migration or a cleanup project, including rDNS checks in your DNS and server checklist can reduce avoidable delivery issues for teams using MX1Mail or any standards-based email platform.