Understanding rDNS and EHLO Hostname Alignment

• May 2022
• Engineering Memo · External Release

Every IP address used for email sending should have a properly configured reverse DNS (PTR) record — a DNS record that maps the IP address back to a hostname. This PTR record should match the hostname that the sending MTA uses in its EHLO command when opening an SMTP session. When PTR record and EHLO hostname are aligned, the sending server presents a consistent identity to receiving mail servers. When they are misaligned, or when the PTR record is missing, many receiving servers apply negative reputation adjustments or outright reject connections.

Despite being a foundational email sending requirement, rDNS configuration is one of the most frequently misconfigured aspects of email infrastructure — particularly for programmes migrating to new IP allocations or changing hosting providers. This note documents what correct rDNS and EHLO alignment looks like, how to verify it, and the specific delivery consequences of misconfiguration.

What PTR Records Are and Why They Matter

PTR (Pointer) records are DNS records in the reverse DNS namespace that map IP addresses to hostnames. For IPv4, the reverse DNS namespace is in-addr.arpa: for IP address 203.0.113.45, the PTR record is looked up at 45.113.0.203.in-addr.arpa. The PTR record's value is the hostname that the IP address resolves to: for example, mail1.sender.com.

PTR records serve as the IP address's "name" in the email system's identity verification framework. When a receiving server accepts a connection from a sending IP, it typically performs a PTR lookup on the connecting IP to determine its hostname. This PTR-resolved hostname is then compared against the EHLO hostname that the sending MTA presents — if they match, the server identity check passes; if they do not match, some receiving servers apply negative scoring or rejection.

PTR records are controlled by the owner of the IP address allocation, not by the domain name's DNS operator. For dedicated IPs provisioned by a hosting provider, the PTR record must be configured with the hosting provider (not in the domain's DNS registrar), because the hosting provider controls the reverse DNS zone for their IP allocation. This is one of the most common sources of PTR configuration errors: operators configure the forward DNS records (A records) correctly but do not configure the PTR records with the hosting provider, resulting in no PTR record for the sending IP.

The Forward-Confirmed Reverse DNS (FCrDNS) Requirement

Beyond basic PTR existence, many receiving servers perform Forward-Confirmed Reverse DNS (FCrDNS) verification: the PTR record's hostname must also have a forward A record that resolves back to the original IP address. This creates a bidirectional identity chain: IP → PTR hostname → A record → same IP. If the chain is broken (the PTR hostname does not have an A record, or the A record resolves to a different IP), FCrDNS verification fails.

The correct FCrDNS chain for sending IP 203.0.113.45: PTR for 203.0.113.45 = mail1.sender.com; A record for mail1.sender.com = 203.0.113.45. Both records must exist and be consistent. When setting up new sending IPs, both the PTR record (configured with the hosting provider) and the forward A record (configured in the domain's DNS) must be provisioned — and the PTR must point to a hostname with a corresponding A record that resolves to the same IP.

FCrDNS failure is one of the most common reasons that newly provisioned IPs fail identity checks at receiving servers during the first campaign after infrastructure setup. The IP was provisioned, the PowerMTA VMTA was configured, the DKIM key was added — but the PTR record was not updated with the hosting provider, so the IP has either no PTR or a generic PTR from the hosting provider's default naming scheme. The FCrDNS check then fails, and some receiving servers (particularly corporate mail servers) reject or heavily penalise connections from the improperly configured IP.

EHLO Hostname Best Practices

The EHLO hostname should be the sending IP's PTR hostname — matching exactly, including case. PowerMTA's ehlo-hostname setting in the VMTA configuration controls what value the MTA presents in its EHLO command. Setting this to the correct PTR hostname for each VMTA's source IP ensures alignment. For VMTAs that bind to multiple IPs (rotating across a pool), the ehlo-hostname configuration should use a hostname that is valid for all IPs in the pool — which requires that all IPs in the pool have PTR records pointing to hostnames that forward-resolve back to the specific IP.

Common EHLO hostname mistakes: using a localhost or internal hostname (EHLO localhost, EHLO mailserver.internal) that does not resolve from the public internet; using the domain's primary hostname (EHLO sender.com) rather than a mail-specific hostname (EHLO mail1.sender.com) when the primary domain's A record does not resolve to the sending IP; using a wildcard PTR hostname pattern that does not have corresponding individual A records for each IP. All of these produce FCrDNS failures for at least some receiving servers.

A practical PTR hostname naming convention that scales cleanly for large IP pools: mailN.sender.com where N is a sequential number. Each IP gets its own PTR hostname (mail1.sender.com for the first IP, mail2.sender.com for the second, etc.), each with a corresponding A record. This naming convention is interpretable (human-readable, clearly mail-related), specific (each IP has a unique hostname), and scalable (add new IPs by adding new numbered hostnames). It is the naming convention we use for all managed infrastructure and recommend for any dedicated IP sending setup.

rDNS configuration is foundational infrastructure that is set once during IP provisioning and rarely changed. The verification checklist in this note should be run for every new IP before any production sending begins — not as an afterthought when delivery problems appear. A properly configured rDNS and EHLO alignment is invisible during normal operation; a misconfiguration becomes visible as delivery problems at corporate mail servers, Proofpoint-protected domains, and ISPs with strict identity checks. Configure it correctly from the start, verify it with the checklist, and rDNS will be one less thing to investigate when delivery problems occur.

How Receiving Servers Use PTR Records

Different receiving servers use PTR records in different ways, which determines how severe the delivery impact of PTR misconfiguration is for each ISP. Gmail performs PTR lookup and uses the result as one factor in its overall IP reputation model — a missing or mismatched PTR is a negative signal but does not typically cause outright rejection for IPs with established High domain reputation. Microsoft's Exchange Online Protection performs FCrDNS verification and uses the result in its spam score calculation — a failed FCrDNS adds points to the spam score that may tip marginal messages into spam classification.

Corporate mail servers protected by Proofpoint or Mimecast frequently perform strict FCrDNS verification and may reject connections entirely from IPs with failed FCrDNS — producing a 550 "Service unavailable; client host [IP] blocked" response. For programmes sending B2B email to corporate domains, FCrDNS failures can cause significant delivery problems that appear to be reputation-based but are actually configuration-based. The fix is the PTR configuration correction, not reputation remediation.

Yahoo uses PTR records in its domain reputation attribution: messages from IPs with properly configured PTR records pointing to hostname patterns consistent with legitimate bulk senders (mailN.domain.com) are attributed positive reputation signals; messages from IPs with generic hosting provider PTR records (pool-203-0-113-45.dynamic.example-host.com) are evaluated with more scrutiny. This pattern recognition — legitimate mail infrastructure has purposeful PTR naming; compromised or residential IPs have generic provider PTR names — is built into Yahoo's reputation model.

IPv6 rDNS: Additional Complexity

If the sending infrastructure supports IPv6 sending (which is becoming more common as ISPs begin accepting or requiring IPv6 connections), the same rDNS configuration requirements apply to IPv6 addresses — with additional complexity from IPv6's longer address format. An IPv6 PTR record is looked up in the ip6.arpa namespace, where the address nibbles are reversed. For IPv6 address 2001:db8::45, the PTR lookup is at 5.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

IPv6 rDNS is frequently misconfigured or absent because many hosting providers require explicit requests to configure IPv6 PTR records, and the IPv6 address format makes manual configuration error-prone. For programmes sending via IPv6, verifying IPv6 PTR configuration with the same checklist as IPv4 is essential — and if the hosting provider cannot support custom IPv6 PTR records, disabling IPv6 sending for email (using only IPv4 addresses for SMTP connections) is a practical alternative that avoids the IPv6 rDNS complexity.

Diagnosing rDNS-Related Delivery Problems

rDNS-related delivery problems produce distinctive accounting log patterns that distinguish them from reputation or content-related rejections. The characteristic pattern: 550 rejections with response text that references the connecting IP's hostname, such as "550 Service unavailable; client host [203.0.113.45] blocked using SpamAssassin" or "550 PTR lookup failed for 203.0.113.45" or "550 Connection rejected because reverse DNS failed." These response texts explicitly mention the IP or its PTR/rDNS status, pointing directly to the configuration cause.

For programmes that add new IPs to their pool and immediately experience 550 rejections at specific corporate destinations that were previously delivering normally, rDNS misconfiguration is the first thing to check — before investigating reputation or content causes. Run the four-point verification checklist from this note for the new IPs; if any check fails, correct it before proceeding with any other investigation. rDNS misconfiguration is the most common cause of delivery problems that appear immediately after IP provisioning rather than developing gradually over time.

Correctly configured rDNS is invisible during operation — receiving servers perform the PTR lookup, it resolves correctly, FCrDNS passes, and the SMTP session proceeds without any note of the identity check in the accounting log. The configuration only becomes visible in the accounting log when it fails. This invisibility makes rDNS easy to overlook in deliverability management discussions, but its failure mode — immediate, persistent rejection at corporate and Proofpoint-protected destinations — makes it operationally significant enough to verify carefully for every new IP. Configure it once, verify with the checklist, and it will remain invisible as it should be for the operational lifetime of the infrastructure.

rDNS as Part of the Infrastructure Launch Checklist

Every new IP provisioned for email sending should pass through a launch checklist before any production traffic is routed through it. The rDNS verification checklist from this note is the identity section of that broader launch checklist. The complete launch checklist also includes: DKIM key generation and DNS publication, SPF record update to include the new IP, warmup schedule creation, Postmaster Tools IP reputation monitoring setup, SNDS registration, FBL registration where applicable, and accounting log pipeline confirmation that the new IP's sending events are being captured correctly.

Skipping the rDNS verification step in a rush to begin warmup is a common operational shortcut that almost always produces a delivery problem within the first few campaigns. The 30 minutes spent on rDNS configuration and verification during launch eliminates weeks of investigation time when unexplained 550 rejections begin appearing for specific corporate destinations during warmup. The launch checklist is the investment that makes the warmup period focused on reputation building rather than configuration debugging.

For hosted managed infrastructure, the rDNS configuration and verification should be handled by the infrastructure provider as part of IP provisioning — not left to the programme's team to manage independently. If the managed infrastructure provider does not include rDNS configuration verification in their IP provisioning process, it is a gap that should be explicitly addressed before any production sending begins. Ask the provider to confirm: what is the PTR record for this IP? Does the PTR hostname have a forward A record resolving to this IP? What EHLO hostname is PowerMTA configured to use for this VMTA? All three answers should be consistent before the first campaign is sent through the new IP.

rDNS and EHLO hostname alignment is not an advanced configuration topic — it is foundational email infrastructure that every sending IP requires from day one. It is documented here because it is foundational, not because it is complex. The complexity is in understanding why it matters (identity chain for receiving server verification) and what happens when it is missing (delivery failures that can be misdiagnosed as reputation problems). With the understanding from this note, rDNS configuration becomes a verified checklist item that is completed correctly once and never requires revisiting. That is the outcome that correct foundational infrastructure always delivers — not ongoing attention, but reliable invisible operation for the entire programme lifetime.

PTR Record Naming Conventions and Professional Standards

Beyond the technical requirements, PTR record naming signals something about the sender's professionalism and intent to ISP systems and postmaster teams who investigate sending infrastructure. A PTR hostname of mail1.sender.com signals deliberate, professionally configured email infrastructure. A PTR hostname of pool-203-0-113-45.dynamic.example-hosting.com signals unconfigured or consumer/residential infrastructure — the kind of PTR naming that ISP reputation models associate with spam-sending compromised hosts rather than legitimate commercial senders.

This naming-signal distinction is not just ISP prejudice — it reflects statistical reality. The vast majority of IPs with generic hosting-provider PTR names that are used for email sending are generating spam or are compromised systems, not legitimate commercial senders who simply did not update their PTR records. The ISP's pattern-matching on PTR names is a practical anti-spam measure that occasionally catches legitimate senders with misconfigured PTR records — and the remediation (configure a proper PTR) is straightforward.

The naming convention recommendation for commercial sending infrastructure is consistent across major ESP and deliverability guides: use a deliberate, interpretable hostname pattern that identifies the server as email infrastructure. Formats that work well: mail1.sender.com, smtp1.sender.com, mx-out1.sender.com. Formats that do not signal legitimate infrastructure: generic IP-based names, random strings, or internal hostnames not visible from the public internet.

The PTR record naming convention is an infrastructure decision that is made once and persists for the lifetime of the IP allocation. Choose the convention deliberately, apply it consistently across all sending IPs, and the PTR naming will always signal the professional, deliberately-configured email infrastructure identity that ISP systems and postmaster teams associate with legitimate senders. That signal is part of the overall sender identity picture that accumulates into the reputation the programme relies on for inbox placement. Every detail of correct infrastructure configuration contributes to that picture; rDNS and EHLO alignment is one of the most visible details, at least from the receiving server's perspective.

PTR records, FCrDNS, and EHLO alignment are the infrastructure foundation beneath the reputation and authentication layers that usually dominate deliverability discussion. They receive less attention precisely because they are foundational — they are configured correctly during setup and then forgotten. This note exists to ensure they are configured correctly during setup, because the alternative — discovering the misconfiguration via delivery problems after warmup has begun — is a significantly more expensive way to learn the same lesson.

Monitoring rDNS Configuration Over Time

PTR records can become invalid after initial configuration if the hosting provider changes the reverse DNS zone management, if IPs are transferred between providers, or if the provider's infrastructure changes affect the reverse DNS delegation. Although these events are infrequent, they can cause previously working PTR records to become invalid without any notification to the programme.

Including PTR record verification in the quarterly infrastructure audit — running the four-point verification checklist from this note for all active sending IPs — detects PTR misconfiguration before it causes delivery problems. The quarterly audit takes 5-10 minutes for a pool of 4-8 IPs and provides the confidence that PTR configuration that was correct during provisioning has remained correct. For larger IP pools, a simple monitoring script that performs the PTR and FCrDNS checks for all sending IPs and alerts on any failure provides continuous rather than periodic verification.

The quarterly PTR audit should also verify that the PowerMTA EHLO hostname configuration still matches the PTR records for all VMTAs. If a VMTA was added or reconfigured since the last audit, confirming that the ehlo-hostname setting matches the new IP's PTR record prevents silent EHLO mismatches that may not produce immediate delivery failures but contribute to negative identity signals at receiving servers over time.

Proper rDNS and EHLO hostname alignment is one of the simplest deliverability requirements to get right and one of the easiest to overlook when there is no delivery problem drawing attention to it. This note documents it not because it is difficult but because it is important — part of the complete infrastructure configuration picture that the delivery system depends on operating correctly from day one. Verify it during provisioning. Include it in the quarterly audit. And let it be invisible infrastructure that earns its value by never causing the delivery problems that PTR misconfiguration reliably produces when overlooked.

Reverse DNS is the identity layer beneath authentication, reputation, and content. Without it, the sending server lacks the basic identity verification that receiving servers use to establish trust. With it properly configured, the sending server presents a clear, consistent, verifiable identity that supports everything else the programme does to earn inbox placement. Configure it correctly; verify it quarterly; and it will do its job invisibly, reliably, and permanently.

IP → hostname → A record → same IP. That four-step chain, verified for every sending IP before production sending begins, is the complete rDNS requirement for professional email infrastructure. Verify the chain. Match the EHLO. Name the hostnames deliberately. The receiving servers will see a clear, verifiable identity — and that clarity supports everything else the programme does to earn and maintain inbox placement.

The receiving server performs its identity check in milliseconds. The configuration that makes that check pass -- PTR record, FCrDNS verification, matching EHLO hostname -- takes one day to set up correctly. The return on that single day of foundational configuration is a sending identity that receives consistent positive treatment from receiving servers for the entire operational lifetime of the infrastructure. Foundational configurations earn foundational returns. rDNS is the foundation beneath the foundation.