The Role of PTR Records in Modern Deliverability

• March 2022
• Engineering Memo · External Release

PTR records — the reverse DNS records that map IP addresses to hostnames — were a primary deliverability requirement in the early 2000s when IP-based spam filters commonly rejected messages from IPs without matching forward and reverse DNS. In 2022, PTR records remain a relevant infrastructure configuration, but their role has shifted: they are now a baseline trust signal rather than a primary inbox placement determinant. Understanding what PTR records still accomplish, where they matter most, and what correct PTR configuration looks like clarifies how to prioritise this infrastructure requirement.

What PTR Records Are and How They Work

A PTR record is a DNS record in the in-addr.arpa zone that maps an IP address to a hostname. For an IP address 203.0.113.45, the PTR record is stored at 45.113.0.203.in-addr.arpa and resolves to a hostname such as mail1.brand.com. When a receiving mail server receives a connection from 203.0.113.45, it can perform a reverse DNS lookup to determine what hostname that IP resolves to. The receiving server then typically performs a forward DNS lookup on the resolved hostname (mail1.brand.com → IP address) to verify that the forward and reverse DNS are consistent — a check called forward-confirmed reverse DNS (FCrDNS).

FCrDNS verification confirms that: (1) the sending IP has a PTR record, (2) the PTR record resolves to a hostname, and (3) that hostname resolves back to the original IP (or a group of IPs that includes it). This three-step verification is what receiving servers perform when checking PTR records. An IP with no PTR record fails step 1. An IP whose PTR record points to a hostname that does not exist fails step 2. An IP whose PTR record points to a valid hostname that resolves to a different IP fails step 3. All three failures produce the same result from the receiving server's perspective: a PTR check failure.

PTR records are managed by the IP address owner — typically the hosting or colocation provider. The programme hosting IPs at a datacenter does not directly edit PTR records; they submit a request to the datacenter to set the PTR record for each IP to the desired hostname. The datacenter updates the in-addr.arpa zone entry, making the PTR record visible to receiving servers within 24-48 hours of the request.

Where PTR Records Matter in 2022

Microsoft deliverability: Microsoft's Exchange Online Protection (EOP) places more weight on PTR records than Gmail. A sending IP without a valid PTR record or without FCrDNS consistency may receive elevated deferral rates or rejection at Microsoft, even from IPs with otherwise clean SNDS status. For programmes where Microsoft (Outlook.com, Hotmail, corporate Office 365) is a significant portion of the recipient base, PTR records are a relevant deliverability configuration that merits attention.

Corporate mail servers: On-premises Exchange servers and older corporate mail infrastructure frequently reject or score negatively for messages from IPs without PTR records. For B2B cold email programmes targeting corporate contacts, missing PTR records may cause silent rejections at corporate mail gateways that never appear in the accounting log as explicit 5xx errors — the message is accepted with a 250 but quarantined internally. PTR records are particularly important for the B2B cold email use case.

European ISPs: Several EU consumer ISPs (GMX, Web.de, T-Online) apply explicit PTR validation as part of their connection assessment. Messages from IPs without valid PTR records receive elevated scrutiny or rejection at these ISPs. For programmes with significant EU consumer lists, PTR records are a concrete deliverability requirement rather than a best practice aspiration.

Gmail and Yahoo: The two largest consumer ISPs do not apply strict PTR enforcement for authenticated senders with established domain reputation. A message from an IP with no PTR record but with strong DKIM alignment, High domain reputation, and clean FBL signals will deliver to Gmail and Yahoo without PTR-related problems. For these ISPs, PTR records are a baseline hygiene indicator but not a primary deliverability determinant.

Correct PTR Record Configuration

The correct PTR configuration for commercial sending IPs: each IP in the sending pool should have a PTR record pointing to a hostname that is recognisable as a mail server hostname and that resolves back to the IP (FCrDNS). The hostname format should follow the convention mail[N].sending-domain.com, where sending-domain.com is either the programme's own domain or the infrastructure provider's domain. Examples: mail1.brand.com, smtp2.outbound.brand.com, or mta-01.esp-provider.com.

PTR records pointing to generic hostnames like customers.123.hosting-provider.com or dynamic-ip.isp.net are less effective trust signals than properly formatted mail server hostnames, because generic hosting provider PTR records indicate consumer or small business hosting rather than a dedicated commercial mail server. ISPs that weight PTR records in their trust model look for PTR records that match the pattern of dedicated commercial sending infrastructure, not generic consumer hosting.

The EHLO hostname (the hostname the sending MTA uses in its EHLO command during the SMTP session) should match the PTR record for each sending IP. In PowerMTA, the EHLO hostname is configurable per VMTA using the ehlo-hostname directive. Setting ehlo-hostname to match the PTR record produces consistent DNS identity signals: the EHLO presents mail1.brand.com, the PTR for the connecting IP resolves to mail1.brand.com, and the A record for mail1.brand.com resolves to the connecting IP. This three-way consistency — EHLO hostname, PTR record, A record — is the full DNS identity signal that receiving mail servers evaluate.

PTR records are a 30-minute infrastructure configuration task that produces permanent deliverability benefit across Microsoft, EU ISP, and corporate mail server destinations. The configuration request to the datacenter (or cloud provider, for AWS Elastic IPs, GCP floating IPs) takes a few minutes; the PTR propagation takes 24-48 hours. After that, the PTR records produce their trust signal benefit for every connection the sending IPs make, indefinitely, without any ongoing maintenance. The investment-to-return ratio is exceptional: minimal one-time effort, permanent benefit at a significant subset of destinations. Configure them correctly, verify them with dig -x [IP] from outside the network, and treat them as permanently solved infrastructure that requires attention only when new IPs are added to the pool.

PTR Records and Blocklist Evaluation

Several major blocklists (DNSBLs) use PTR record quality as part of their listing criteria. Spamhaus's ZEN blocklist includes a component (the Policy Block List, PBL) that lists IP ranges that Spamhaus considers should not be sending email directly — typically consumer broadband IP ranges. These ranges are identified partly by PTR record patterns: ISP-assigned PTR records following patterns like dynamic-ip.customer.isp.net indicate consumer broadband rather than a commercial sending IP. IPs with professional mail server PTR records (mail1.brand.com) are less likely to appear on the PBL regardless of whether the IP is technically capable of sending mail.

The Spamhaus Exploits Block List (XBL) and Return Path's blocklists also weight PTR record quality in their listing evaluations. An IP with no PTR record or with a generic consumer-ISP PTR pattern is more likely to be listed or elevated in blocklist risk scoring than an IP with a properly formatted commercial mail server PTR record and FCrDNS consistency. PTR record configuration is therefore relevant not just for direct SMTP delivery but also for maintaining clean blocklist status.

For new IPs provisioned for sending, setting the PTR record before any sending begins is the correct operational sequence. A new IP that sends without a PTR record in its first few days of operation may receive blocklist evaluations that include the missing PTR in the listing evidence. Removing the blocklist listing becomes more complex when the reason for listing included PTR absence, because the blocklist may require both adding the PTR and demonstrating a period of clean sending before delisting. Setting PTR records before sending avoids this sequence entirely.

The EHLO/HELO Identity Triangle

The receiving server's trust evaluation of an incoming SMTP connection considers three DNS identity signals together: the EHLO/HELO hostname, the PTR record for the connecting IP, and the A record for the EHLO hostname. When these three form a consistent triangle — the EHLO hostname matches the PTR record, and the A record for the EHLO hostname resolves to the connecting IP — the receiving server has a fully verifiable, self-consistent DNS identity for the sender. This consistency is the DNS equivalent of a sender presenting matching identification documents; it confirms that the sender controls the hostname they claim to be using.

Inconsistency in this triangle is a red flag for spam filters: an IP whose EHLO claims to be mail1.google.com (a hostname the sender does not control) while the PTR record for that IP resolves to something else is attempting identity impersonation. Modern spam filters detect this inconsistency and apply negative scoring. This is why the EHLO hostname should always be a hostname that the sender controls and that correctly represents the sending IP.

In PowerMTA, the EHLO hostname is configured per VMTA with the ehlo-hostname directive. Setting this to match the PTR record for each VMTA's source IP ensures that the EHLO/HELO triangle is consistent for all sends from that VMTA. For VMTAs with multiple source IPs in a pool, the ehlo-hostname should be a hostname that resolves to the full IP pool — or per-IP EHLO configuration should be used to ensure each IP uses its own correct hostname. The PowerMTA configuration documentation covers both approaches; the correct choice depends on whether the pool shares a single hostname (pool.brand.com resolving to all IPs) or uses per-IP hostnames (mail1.brand.com, mail2.brand.com).

Verifying PTR Configuration

PTR record verification is a quick command-line check that confirms the FCrDNS chain is correctly configured. From any Linux/Mac terminal with network access outside the sending server's own network: dig -x 203.0.113.45 +short returns the PTR record for the IP. Then dig A mail1.brand.com +short verifies that the hostname returned by the PTR lookup resolves to the original IP (or pool of IPs). If both lookups produce consistent results, FCrDNS is correctly configured.

The verification should be run from outside the sending server's own network because some DNS configurations may return local values from within the server's network that differ from the globally visible DNS. Using a network outside the sending environment (a laptop on home broadband, an online DNS lookup tool like dnschecker.org) confirms the globally visible DNS state that receiving mail servers will see.

For programmes with multiple IPs, PTR verification should be run for each IP individually, not assumed from a single check. A batch script that loops through all IPs in the pool and runs the two-step FCrDNS verification for each produces a complete PTR audit in minutes. This batch verification should be part of the infrastructure onboarding checklist for each new IP added to the pool.

When PTR Records Are Missing: The Diagnostic Path

When PTR records are identified as missing (by MX Toolbox, by post-delivery investigation of unusual rejection patterns at Microsoft or GMX, or by the batch PTR audit), the remediation path is straightforward: contact the IP hosting provider, request PTR record assignment for the affected IPs, specify the desired hostname (mail1.brand.com format), and verify 24-48 hours after the request that the PTR is correctly visible from external networks.

Cloud providers have specific processes for PTR record management: AWS allows setting Elastic IP PTR records through the EC2 console or API; GCP provides PTR record management through the Cloud DNS interface; Hetzner (a common European datacenter provider) accepts PTR requests via the control panel or API. The datacenter or cloud provider's documentation provides the specific process; the actual PTR record assignment typically takes 24 hours from request submission to global propagation.

PTR records represent a small but permanent part of the deliverability configuration that, when correctly implemented, generates trust signals across a meaningful subset of destinations without any ongoing operational cost. Configure them correctly at provisioning, verify them after any IP changes, and treat them as solved infrastructure that supports delivery silently and reliably. In the full stack of deliverability configuration — authentication, reputation, list quality, per-ISP domain blocks, and DNS identity — PTR records are the easiest element to configure correctly and the easiest to overlook. Overlook them at the cost of Microsoft and EU ISP delivery friction; configure them correctly for permanent benefit across every SMTP connection the sending infrastructure makes.

PTR Records in the Broader DNS Identity Stack

PTR records are one component of the broader DNS identity configuration that commercial sending infrastructure should maintain. The full DNS identity stack for each sending IP: the PTR record (IP → hostname), the A record for the mail server hostname (hostname → IP), the MX record for the sending domain (domain → mail server, for the receiving path), the SPF record for the sending domain (domain → authorised IPs), the DKIM key records (domain/selector → public key), and the DMARC record (domain → policy). Each element of this stack contributes to the receiving server's assessment of the sender's identity and legitimacy. PTR records are the layer that establishes IP-level identity before authentication mechanisms are evaluated.

The receiving server's evaluation sequence for an incoming SMTP connection: TCP connection → PTR/EHLO identity check (PTR records) → TLS negotiation → EHLO/HELO command → MAIL FROM → RCPT TO → DATA → authentication check (SPF, DKIM, DMARC). PTR records are evaluated in the earliest stage of this sequence, before the message body arrives and before authentication can be verified. A PTR failure at this early stage can cause rejection or elevated filtering that no amount of good authentication or reputation can overcome, because the connection may be rejected before those signals are evaluated.

This early-evaluation position is why PTR records, despite being a simple DNS configuration, have disproportionate impact at destination types that weight PTR records heavily (Microsoft, EU ISPs, corporate gateways). The PTR check happens before any authentication or reputation signal is evaluated — it is the first identity verification the receiving server performs, and for conservative filtering systems, a PTR failure at this first check is sufficient reason to reject or heavily filter the connection regardless of what the sender's authentication or reputation signals would otherwise indicate.

PTR Record Maintenance: The Full Infrastructure Lifecycle

PTR records require attention at specific points in the infrastructure lifecycle rather than continuously. At IP provisioning: request PTR records from the hosting provider before any sending begins. At VMTA reconfiguration: verify that the EHLO hostname in PowerMTA still matches the PTR records when VMTA configuration changes are made. At IP pool expansion: request PTR records for all new IPs as the first provisioning step. At infrastructure migration: verify PTR records for the new IP pool at the destination provider before any production traffic routes through the new IPs.

Beyond these lifecycle events, PTR records are stable and require no routine maintenance. They do not expire (unlike DKIM keys, which should be rotated annually), they do not need updating as sending volume changes, and they are not affected by reputation events. The one scenario that requires PTR record attention outside lifecycle events is a hosting provider IP reassignment — when the provider reassigns the IP to a different customer, the PTR record may be changed to reflect the new customer's configuration. Monitoring the PTR record for each sending IP monthly (a trivial automation task) catches any such reassignment before it affects production deliverability.

PTR records have been a constant in email infrastructure requirements for over 25 years. Their role has evolved from a primary rejection criterion to a baseline trust signal, but their importance has not disappeared. Every commercial sending IP should have a correctly configured PTR record that passes FCrDNS verification. This is not a deliverability optimisation that can be deferred — it is baseline infrastructure hygiene that should be completed before any production sending begins from any IP. Configure it correctly at provisioning, verify it thoroughly, and PTR records will never be the reason a message fails to reach its intended inbox.

Summary: The PTR Record Priority Matrix

The correct way to prioritise PTR record configuration is based on the programme's specific recipient mix. For programmes with significant Microsoft/Outlook recipients (B2B or consumer), or significant EU consumer ISP exposure (GMX, T-Online, Web.de), or B2B cold outreach to corporate mail servers, PTR records are a high-priority configuration that materially affects deliverability. For programmes sending exclusively to Gmail and Yahoo with established High domain reputation and clean FBL data, PTR records are a baseline hygiene item that is worth configuring correctly but that is unlikely to produce visible inbox placement improvement given that these ISPs do not weight PTR records heavily for authenticated senders.

In all cases, the correct answer is to configure PTR records correctly regardless of the priority level. The configuration cost is negligible (a few minutes of hosting provider interaction per IP). The benefit is permanent and accrues across all destination types that check PTR records. There is no deliverability scenario in which missing or incorrect PTR records are an advantage. Configure them correctly for every IP in every pool before any production sending begins, and the PTR layer of the DNS identity stack will never be a source of deliverability friction for any programme the infrastructure supports.

PTR records are one of the quietest infrastructure requirements in email deliverability — they require minimal attention, produce permanent benefit, and their absence generates friction that is often attributed to other causes before the PTR configuration is investigated. Understanding their role, configuring them correctly, and verifying them systematically at each infrastructure lifecycle event is the operational discipline that keeps the DNS identity layer clean and consistent across the full sending infrastructure.

IP addresses speak first. PTR records are what they say. Make sure every IP in the sending pool says something correct, recognisable, and verifiably consistent with the hostname it claims to be.

Set it once. Verify once. Done forever. That is the operational profile of correct PTR configuration.