Corporate

5 MIN READ

Apr 13, 2026

Reverse DNS and Email Deliverability: Why You're Being Blocked

A missing or mismatched PTR record is one of the most common reasons business email is blocked or spam-foldered. This guide explains FCrDNS, how to configure PTR records correctly, and how major mail providers use rDNS as a trust signal.

The Hidden Requirement Most Mail Admins Miss

You have set up SPF, DKIM, and DMARC. Your domain reputation is clean. Your mail server is properly configured and has a valid TLS certificate. And yet your emails are still being rejected or landing in spam folders at Gmail, Outlook, and Yahoo Mail. In a significant number of cases, the missing piece is a correctly configured PTR record — the DNS record that performs reverse resolution from your mail server's IP address back to a hostname. Receivers combine this with the SMTP client name you advertise after EHLO/HELO (RFC 5321) and with forward A/AAAA checks as part of best current practice, not as a substitute for SPF/DKIM/DMARC.

Reverse DNS for email is not a new concept, but it remains consistently under-configured because PTR records are managed differently from all other DNS records. While you manage your A records, MX records, and SPF TXT records through your domain registrar or DNS provider, PTR records are controlled by whoever owns the IP address block — typically your ISP or hosting provider. This creates a setup step that is easy to overlook and difficult to debug if you do not know what to look for.

How Receiving Mail Servers Check Reverse DNS

When your mail server initiates an SMTP connection to a receiving server, the receiving server sees your connecting IP immediately. Before it accepts any message content, it performs several trust checks. Reverse DNS verification is one of the earliest. Here is the sequence:

Your mail server at IP 203.0.113.10 connects to the recipient's SMTP server.
Your server issues an EHLO mail.yourdomain.com command, announcing its hostname.
The receiving server performs a PTR lookup on 203.0.113.10 and expects to get mail.yourdomain.com (or at least a fully qualified hostname that matches).
If the PTR lookup returns nothing (NXDOMAIN) or returns a generic ISP hostname like static-203-0-113-10.isp.net, the receiving server may reject the connection, assign a higher spam score, or rate-limit your server.

The relationship between what your server announces in EHLO and what the PTR record says is critical. A mismatch is treated as a trust signal failure, because legitimate mail servers are expected to have consistent, intentional identity — not the mismatched credentials of an impersonator.

Forward-Confirmed Reverse DNS (FCrDNS)

FCrDNS is the highest-confidence identity check in the email trust chain. It performs three lookups to confirm that IP address, PTR hostname, and forward A record all form a consistent, non-contradictory identity:

Observe the connecting IP: 203.0.113.10.
Perform rDNS lookup on that IP: the PTR record returns mail.yourdomain.com.
Perform a forward DNS A lookup on mail.yourdomain.com: the A record must return 203.0.113.10.

If all three values are consistent — the IP resolves to the hostname, and the hostname resolves back to the same IP — the server is considered FCrDNS verified. This does not guarantee the message is legitimate, but it confirms that whoever controls the IP has also taken deliberate action to configure consistent DNS records, which spammers using hijacked infrastructure or transient IP blocks often fail to do.

Several enterprise mail systems and the anti-spam tools embedded in them — including SpamAssassin's PTR_RDNS check and Exchange Online Protection's inbound spam filters — explicitly check for FCrDNS compliance. Failing FCrDNS does not automatically reject your mail, but it contributes significant points to the spam score.

Common PTR Record Configurations and Their Impact

PTR Record State	Example	Deliverability Impact	Action Required
No PTR record (NXDOMAIN)	IP lookup returns nothing	High — many servers reject at connection	Contact ISP/hosting provider to create PTR
Generic ISP hostname	static-203-0-113-10.isp.net	Medium-High — fails FCrDNS, high spam score	Request ISP to set a custom PTR matching your EHLO
Hostname that does not match EHLO	PTR = server1.hoster.com, EHLO = mail.yourdomain.com	Medium — FCrDNS mismatch, increased spam scoring	Align EHLO hostname with PTR, or update PTR to match EHLO
Correct PTR, no forward A record	PTR = mail.yourdomain.com, no A record	Medium — incomplete FCrDNS	Add A record for your mail hostname pointing back to the IP
Full FCrDNS (IP → PTR → A = IP)	203.0.113.10 ↔ mail.yourdomain.com ↔ 203.0.113.10	None — passes all checks	No action needed; maintain consistency

How Major Mail Providers Use PTR Records

Each major receiving provider handles PTR verification differently, and understanding those differences helps you prioritize fixes.

Gmail / Google Workspace: Google does not publish its exact filtering criteria, but its Postmaster Tools platform shows sender reputation per domain and IP. Missing PTR records reliably degrade IP reputation scores. Google's Bulk Sender Guidelines, updated in 2024, explicitly require that sending IPs have PTR records pointing to a hostname that resolves back to the sending IP.

Microsoft 365 / Exchange Online Protection (EOP): Microsoft checks for PTR records as part of its connection filtering. IPs with no PTR record are subject to rate throttling. EOP also uses its own IP reputation data in combination with Spamhaus ZEN, and a missing or mismatched PTR record lowers the IP's composite reputation score. Persistent absence of PTR records can result in permanent rejection codes.

Yahoo Mail / AOL: Yahoo's inbound filtering documentation explicitly states that mail from IPs without valid PTR records has a higher probability of rejection or spam classification. Yahoo also participates in the Complaint Feedback Loop (CFL) program, and IPs with poor authentication records including PTR are deprioritized in reputation ranking.

How to Configure a PTR Record

PTR records live in a special DNS zone called the reverse DNS zone, maintained by the IP block owner rather than by your domain registrar. The process to configure them depends on your infrastructure:

Dedicated server or VPS with a /32 or /29: Log into your hosting provider's control panel. Most major providers (Hetzner, DigitalOcean, Linode/Akamai, Vultr, OVH) have a PTR/rDNS configuration field directly in the server management interface. Set it to match your mail server's EHLO hostname exactly.
IP block from an ISP or data center without a control panel: Open a support ticket with your ISP requesting that they set the PTR record for your IP to the hostname you specify. Include both the IP address and the desired hostname in your request. This is standard practice and should be processed within 24–48 hours.
AWS EC2: AWS Elastic IPs allow PTR record configuration through the AWS console under the Elastic IP settings. You must own a domain and set the forward A record first; AWS verifies the forward resolution before creating the PTR.
Google Cloud: Configure reverse DNS for Compute Engine instances through the Cloud Console under the External IP Addresses section, with the same requirement that a forward A record must exist first.

Common Misconceptions

Misconception 1: PTR Records Work Like Other DNS Records

Standard DNS records — A, MX, TXT, CNAME — are managed through your domain registrar or DNS provider because your domain is the namespace being managed. PTR records live in a different namespace: the reverse DNS zones for IP address blocks. Those zones are controlled by whoever owns the IP block, not whoever owns the domain. This is why you cannot set a PTR record in Cloudflare or Route 53 for an IP address you do not own the block for — the hosting provider or ISP must configure it.

Misconception 2: SPF Alone Replaces the Need for PTR

SPF verifies that a sending IP is authorized to send on behalf of a domain. It does not provide any information about whether that IP has a PTR record or whether that PTR record matches the EHLO hostname. Receiving servers evaluate both independently. An IP can pass SPF validation and still fail PTR/FCrDNS checks. Both are necessary components of a complete email authentication setup.

Misconception 3: A Generic ISP PTR Record Is Fine

Generic PTR records like static-203-0-113-10.isp.net satisfy the technical requirement of having some PTR record, but they fail the FCrDNS check because they do not match the domain you are using as your EHLO hostname. Spam filters treat generic PTR records as a weaker trust signal than a custom PTR record aligned with your mail server's identity. For business email, always request a custom PTR record that matches your mail server's FQDN.

Misconception 4: PTR Misconfiguration Only Affects Outbound Mail

PTR configuration affects inbound reputation as well, through its impact on your IP's overall reputation score in blacklist databases and mail provider feedback loops. An IP with no PTR record that is sending spam — even a single spam campaign — will remain associated with that reputation data even after you fix the PTR. This is why getting PTR right from the first day you provision a sending IP is significantly easier than cleaning up a reputation built under a misconfigured setup.

Pro Tips for Mail Server Administrators

Set PTR before sending the first email: IP reputation databases begin tracking an IP the moment it first sends mail. Starting with correct PTR configuration means you never have to clean up reputation damage from an early misconfigured period.
Verify FCrDNS using dig: Run dig -x YOUR_IP to confirm your PTR record exists. Then run dig YOUR_HOSTNAME A to confirm the forward record matches. Both should agree on the same IP address and hostname pair before you send any production mail.
Align your EHLO, PTR, and certificate CN/SAN: The most defensible configuration has your mail server's EHLO hostname, PTR record, and the Common Name or Subject Alternative Name in your TLS certificate all pointing to the same FQDN. Inconsistencies between these create unnecessary trust signal failures.
Use Google Postmaster Tools and Microsoft SNDS: Both provide per-domain and per-IP reputation data that reflects how your mail is actually being received. These dashboards are the fastest way to confirm whether a PTR change has improved your deliverability standing.
Separate your sending IPs by mail stream: Transactional mail (password resets, receipts), marketing bulk mail, and internal corporate mail should each use dedicated IPs with their own PTR records. If your marketing campaigns generate complaints and your transactional IP is separate, the complaint damage stays contained.
Document your PTR configuration in your runbook: PTR records are frequently forgotten during server migrations and IP re-allocations. Explicitly including PTR verification in your server provisioning and migration checklists prevents the common scenario where a newly provisioned server sends mail for days without a PTR record because no one remembered to set it.

Reverse DNS configuration is one of the few email deliverability factors that requires action outside your normal DNS management workflow. Getting it right is a one-time task per IP address that pays ongoing dividends in spam score reduction and deliverability reliability. Check your IP's PTR record and rDNS status here.

Frequently Asked Questions

Q.What is a PTR record and why does it matter for email?

A PTR (Pointer) record is a DNS record that maps an IP address back to a hostname, performing the reverse of what an A record does. For email, PTR records allow receiving mail servers to verify that the IP sending the message is associated with a legitimate, intentionally configured hostname. Missing or mismatched PTR records are one of the most common causes of legitimate business email being rejected or classified as spam.

Q.What is FCrDNS and how does it differ from a basic PTR check?

FCrDNS (Forward-Confirmed Reverse DNS) is a three-step verification: the connecting IP resolves to a hostname via PTR lookup, and that hostname then resolves back to the same IP via a forward A record lookup. A basic PTR check only verifies that some hostname exists for the IP. FCrDNS confirms that the forward and reverse DNS records are consistent with each other, which is a stronger identity signal because it requires deliberate configuration of both record types.

Q.Why can't I set my own PTR record in Cloudflare or Route 53?

PTR records live in the reverse DNS zones for IP address blocks, which are controlled by the organization that owns the IP block — your ISP or hosting provider — not your domain registrar. Cloudflare and Route 53 manage records in zones for domain names you own, not zones for IP address blocks. To set a PTR record, you must contact your hosting provider or ISP and request that they create or update the PTR for your IP.

Q.Does Gmail require a PTR record?

Google's 2024 Bulk Sender Guidelines explicitly require that sending IPs have PTR records pointing to a hostname that resolves back to the sending IP. While Google does not always reject mail outright from IPs without PTR records, the absence of a valid PTR reliably degrades IP reputation in Google Postmaster Tools, increasing the probability that mail is classified as spam or delivered to the Promotions tab rather than the Primary inbox.

Q.What should my PTR record be set to?

Your PTR record should be set to the fully qualified domain name (FQDN) that your mail server uses in its EHLO/HELO command. For example, if your mail server identifies itself as mail.yourdomain.com in EHLO, the PTR for its IP should return mail.yourdomain.com. You should also ensure that mail.yourdomain.com has an A record pointing back to the same IP to complete the FCrDNS loop.

Q.How do I check my current PTR record?

On Linux or macOS, run dig -x YOUR_IP_ADDRESS in a terminal to query the PTR record. On Windows, use nslookup YOUR_IP_ADDRESS. Online tools like MXToolbox's Reverse Lookup or our IP checker can also show your PTR record without needing terminal access. After verifying the PTR exists, also run dig YOUR_HOSTNAME A to confirm the forward record resolves back to the same IP.

Q.Can I have multiple PTR records for one IP?

Technically the DNS protocol supports multiple PTR records per IP, but this is strongly discouraged for mail servers. Most mail filtering systems expect a single, unambiguous PTR record. Multiple PTR records create ambiguity and can cause unpredictable behavior in spam filters. Maintain a clean one-to-one relationship between your sending IP and its PTR record.

Q.Will fixing my PTR record immediately improve deliverability?

PTR changes take effect as soon as the DNS change propagates, typically within minutes to a few hours. However, IP reputation scores at major mail providers update on their own schedules — often daily — so measurable improvements in deliverability may take 24 to 72 hours to appear in tools like Google Postmaster Tools. If your IP is also on a blacklist, you will need to address that separately; a correct PTR record alone will not trigger automatic delisting.

Q.What is the EHLO hostname and how does it relate to PTR?

The EHLO (Extended HELO) hostname is the name your mail server announces when it opens an SMTP connection to a receiving server. This should be the FQDN of your mail server. The PTR record for your sending IP should return exactly this hostname. When the EHLO hostname and the PTR record disagree, spam filters treat it as a trust signal failure indicating that the sender may not legitimately control the IP they are using.

Q.Does Microsoft Exchange Online Protection check PTR records?

Yes. Microsoft Exchange Online Protection checks for PTR records as part of its connection filtering. IPs without PTR records are subject to rate throttling and receive lower reputation scores in EOP's composite rating system. Microsoft also cross-references PTR data with third-party IP reputation data sources including Spamhaus. Persistent absence of PTR records can result in permanent rejection codes from EOP.

Q.What happens to email deliverability when my server IP changes?

When you change your mail server's IP address, you must update both the A record for your mail hostname and request a new PTR record from the owner of the new IP block. Sending mail from a new IP without a PTR record configured will trigger immediate deliverability problems. New IPs also start with no reputation history, which means a warm-up period of gradually increasing send volume is necessary before the IP is treated the same as a well-established sending IP.

Q.Can a transactional email provider like SendGrid or Mailgun handle PTR for me?

Yes. When you use a transactional email service, your mail is sent from their IP addresses, which they configure with proper PTR records as part of their infrastructure. If the service allows you to use a dedicated IP address (typically available on paid plans), they provide a control panel option to set a custom PTR record for that IP matching your domain. Using a shared IP pool on their service means you rely on their existing PTR configuration.

Q.What is the difference between a PTR record and an MX record?

An MX record specifies which mail server should receive incoming email for your domain — it maps a domain name to a mail server hostname. A PTR record performs reverse DNS lookup for an IP address, mapping the IP back to a hostname. MX records are used for inbound mail routing; PTR records are used to verify the identity of outbound sending IPs. Both are important for email, but they serve completely different purposes in the mail flow.

TOPICS & TAGS

rdns emailemail deliverabilityptr record emailspam preventionsmtp securityFCrDNSforward confirmed reverse DNSHELO hostnamesender reputationpostfix PTR recordreverse dns and email deliverability success guidewhy matching your reverse and forward dns matters 2026forward confirmed reverse dns fcrdns explainedptr record importance for gmail and outlook deliverysmtp security best practices for business domainspreventing email impersonation via rdns checkshow spam filters use ptr records to verify identityresolving mismatch between helo and ptr hostnamesimproving sender reputation for high volume mailbuilding trust with global mail receiving serversfixing blocked business emails with correct rDNStechnical guide to setting up ptr records with ispsavoiding promotions folder with valid rdns lookupit checklist for server identification protocolsSPF DKIM DMARC and PTR combined email trusttransactional email server PTR configuration