rDNS / PTR

Forward DNS goes from name to IP. mail.example.com resolves to 185.10.20.30. That's an A record (or AAAA for IPv6).

Reverse DNS goes the other direction. From 185.10.20.30 back to mail.example.com. That's a PTR record, published in a special zone (20.10.185.in-addr.arpa for IPv4). The IP owner controls the PTR; usually the hosting provider, sometimes the customer via a control panel.

Two different records, configured in two different places, and they have to agree.

Receivers don't just look up rDNS. They verify it. The full check is:

1. Connecting IP is 185.10.20.30.
2. PTR lookup returns mail.example.com.
3. A-record lookup of mail.example.com returns... what?
4. If it returns 185.10.20.30: FCrDNS passes. Trusted hostname.
5. If it returns a different IP, or no IP at all: FCrDNS fails. Receiver downgrades trust.

This is Forward-Confirmed reverse DNS. The "loop closes." Almost every modern receiver runs this check. Failure is one of the most common deliverability misconfigurations.

Hosting providers often ship IPs with default rDNS like:

185.10.20.30 → static.30.20.10.185.example-hosting.net

That's technically valid for FCrDNS as long as the provider's hostname forward-resolves. But it tells receivers something:

• This IP belongs to a hosting pool, not a managed sender.
• The sender hasn't bothered configuring custom rDNS.
• The IP could be reassigned tomorrow without affecting the rDNS.

None of that is a hard reject signal. But it's a soft negative across virtually every reputation system. Custom rDNS aligned with your sending domain looks like a managed, intentional sender. Generic provider rDNS looks like infrastructure that hasn't been touched.

Switch to mail.yourdomain.com → 185.10.20.30 with matching forward DNS, and the same IP looks materially different to receivers.

Configuration happens at the IP owner control panel, almost always your hosting provider rather than your DNS provider:

1. Pick the hostname. Under your sending domain. mail.example.com, mta1.example.com, smtp.example.com. Choose a convention you can extend if you add IPs.
2. Set forward DNS first. A record at your DNS provider: mail.example.com → 185.10.20.30. Wait for propagation (5-15 minutes typical).
3. Set reverse DNS. In your hosting provider's panel, set the IP's PTR to mail.example.com. Wait for propagation (often longer than forward DNS, up to 24 hours for some providers).
4. Verify with our rDNS tester. All three checks should pass: PTR exists, forward A matches, hostname is custom.
5. Update HELO/EHLO in your MTA to declare the same hostname. Mismatched HELO/rDNS is a separate problem with similar effects.

IPv6 has its own reverse DNS zone (ip6.arpa) and the rules are identical: PTR exists, forward AAAA matches, hostname custom. IPv6 misconfigurations are more common because operators sometimes set up IPv4 rDNS and forget the v6 side.

If you're sending over IPv6 to receivers that prefer it (Gmail, Microsoft both prefer v6 when available), broken IPv6 rDNS is the same kind of problem as broken v4 rDNS. The Postmaster Tools authentication dashboard surfaces this.

The hostname your IP reverse-resolves to communicates intent to receivers. Three patterns appear in production sending, with materially different reception.

Generic provider hostnames like vps-12345.provider.net or static.55.66.77.88.example-isp.com. Reverse-resolve mechanically; FCrDNS validates correctly. Receivers treat the IP as transient/shared infrastructure because the hostname suggests neither dedicated nor branded use. Trust scoring is lower; this category is consulted alongside SBL/Barracuda data when receivers calculate per-IP reputation.

Branded but generic hostnames like mail-out-1.yourdomain.com, smtp01.yourdomain.com, or mta.yourdomain.com. FCrDNS validates; hostname is under your sending domain. Trust scoring is higher than generic provider hostnames; this is the minimum acceptable for production sending.

Branded with sending purpose like mail.yourbrand.com for transactional, news.yourbrand.com for marketing, or per-region patterns like eu-mail-1.yourbrand.com. Trust scoring highest; allows receivers to track per-purpose reputation independently. Multi-tenant ESPs benefit from per-customer hostname patterns, allowing customer-specific reputation isolation.

Migration between patterns is operationally safe but takes time to fully resolve. Receivers cache the rDNS-to-reputation mapping for varying periods (sometimes weeks). Migrating from generic to branded improves long-term reputation but doesn't move the needle in the first 7 days; budget 30-60 days for full effect.

rDNS uses the in-addr.arpa namespace (and ip6.arpa for v6), which is delegated by regional internet registries (ARIN, RIPE, APNIC, LACNIC, AfriNIC) down through ISPs and hosting providers to end customers. The chain matters because it determines who can set the PTR record. End customers cannot directly publish in in-addr.arpa for IPs they're using; the network operator who owns the IP block does that.

This creates the rDNS dependency on hosting providers. Three failure modes appear. First, providers that do not support custom rDNS at all (some budget VPS providers): unsupported. Switch providers; this is a disqualifying constraint for production sending. Second, providers that support rDNS but require tickets for changes: workable but slow; budget 24-48 hours for each change. Third, providers offering self-service rDNS through control panel: ideal; you make changes immediately and verify within an hour.

For multi-IP operations across multiple providers, rDNS management overhead is real. Coordinating changes across 5-10 providers when sending domains change (after rebrand or migration) involves orchestration. Some larger operations consolidate IP allocations to a single provider specifically for rDNS management simplicity, accepting concentration risk for operational simplification. The trade-off is reasonable for 5-50 IP operations; not for very large operations where concentration risk outweighs the operational benefit.

The mechanical procedure for configuring reverse DNS depends on who owns the IP range. The three common ownership scenarios each have different procedural paths to a working PTR record.

Hosting provider owns the IP: the most common case. The hosting provider has authority over the reverse DNS zone for their IP allocations and configures PTR records on customer request. The mechanism varies by provider: some offer self-service in their control panel, others require support ticket request with the desired hostname. The PTR value should be a hostname under the customers domain (e.g., mail01.example.com) rather than the providers default hostname. Changes typically take effect within hours; full DNS propagation to all resolvers can take 24-48 hours.

Customer owns the IP range: the customer has authority over the reverse DNS zone and configures it through their own DNS infrastructure. The reverse zone is structured as octet-reversed plus .in-addr.arpa for IPv4 (e.g., 56.34.12.185.in-addr.arpa for IP 185.12.34.56) or nibble-reversed plus .ip6.arpa for IPv6. The RIR (RIPE for EMEA, ARIN for North America, APNIC for APAC, LACNIC for Latin America, AFRINIC for Africa) that allocated the range needs to delegate the reverse zone to the customers nameservers; this is a one-time setup that the IP-range purchase documentation references.

Shared IP on managed infrastructure: some smaller cloud providers and shared hosting environments do not offer customer-configurable PTR. The PTR is set by the provider to a generic hostname (often something like ec2-185-12-34-56.compute.amazonaws.com) that is not aligned with the customers brand. The only path to brand-aligned PTR in this case is upgrading to dedicated IP infrastructure where the provider does support customer-configurable PTR.

The PTR hostname must forward-resolve back to the same IP for FCrDNS to validate. This requires publishing a corresponding A record (or AAAA for IPv6) in the customers domain DNS pointing to the IP. The forward record is configured in the customers domain DNS independently of the reverse record; both need to be configured for FCrDNS to work.

The HELO/EHLO greeting that an MTA presents during SMTP connection identifies the senders hostname to the receiver. RFC 5321 requires this hostname to be the actual hostname of the sending MTA, and receivers increasingly validate that the HELO hostname matches the PTR record for the connecting IP.

The validation pattern: receiver sees connection from IP 185.12.34.56, queries PTR record which returns mail01.example.com, receives HELO command with hostname argument that should also be mail01.example.com. If the HELO hostname matches the PTR hostname, the alignment validates and the receiver applies normal processing. If the HELO hostname differs from the PTR hostname, the receiver applies additional scrutiny or treats the mismatch as a soft negative signal.

The MTA configuration that produces HELO/PTR alignment varies by software. PowerMTA uses the smtp-source-host setting which can be configured per VirtualMTA to match the PTR for the source IP. Postfix uses myhostname which applies globally; multi-IP Postfix setups need smtp_helo_name per output interface to match per-IP PTR. Exim uses helo_data which can be conditional on the outbound interface.

The most common HELO/PTR misalignment pattern is the default MTA configuration that uses the systems hostname (which is usually a single value) regardless of which IP the connection is going out from. Multi-IP sending operations need explicit per-IP HELO configuration; relying on the default produces consistent misalignment across all but one of the sending IPs.

The receiver-side impact of HELO/PTR misalignment varies. Some receivers (most enterprise gateways, increasingly Microsoft) treat persistent misalignment as a reason to apply additional scrutiny or to outright reject. Gmail and Yahoo treat it as a soft negative signal that combines with other factors. The Inbox Anatomy section on the homepage walks through the specific signals receivers evaluate including HELO compliance.

The distinction between generic ISP-provided PTR (e.g., 185-12-34-56.example-isp.net) and brand-aligned PTR (e.g., mail01.example.com) has become more significant through 2024-2026 as receivers have increased weighting on PTR quality.

Generic PTR signals to receivers that the IP is operated as part of a generic ISP allocation rather than as dedicated sending infrastructure. Receivers apply this signal as a moderate negative weight that combines with other signals to determine placement. The impact varies by receiver: Gmail and Yahoo treat it as a soft factor that other signals can overcome, while enterprise gateways (Mimecast, Proofpoint, Barracuda) apply stricter weighting that can produce quarantine or rejection even with otherwise-clean reputation.

Brand-aligned PTR signals dedicated sending infrastructure operated specifically for the brand. Receivers treat this as a baseline expectation for legitimate bulk sending; the presence of brand-aligned PTR does not produce special positive signal, but the absence of brand-aligned PTR produces negative signal. The asymmetry is sharp enough that brand alignment is operationally required for any sending that targets corporate or enterprise audiences.

For senders specifically targeting consumer audiences (Gmail consumer, Yahoo, Microsoft consumer), generic PTR is operationally workable if other reputation signals are strong. The placement penalty is measurable but not catastrophic. For senders targeting business audiences (Microsoft 365 commercial, corporate gateways), generic PTR is operationally problematic and produces enforcement that other signals cannot overcome. The audience composition determines whether the brand-aligned PTR investment is required or merely beneficial.

The migration from generic to brand-aligned PTR is a standard operation: request the new hostname from the IP provider, configure the corresponding forward A record, verify FCrDNS resolution using the tester on this site, configure the MTA HELO to match the new hostname. The change takes effect within 24-48 hours of all the components being properly configured. The placement improvement at receivers that weight PTR quality typically takes 14-30 days to materialize as receivers accumulate trailing reputation data on the new configuration.

IPv6 sending has expanded substantially through 2022-2026 driven by IPv6 deployment at major receivers and IPv6 availability from major IP allocators. The RDNS handling for IPv6 follows the same conceptual model as IPv4 but with operational differences that matter at scale.

The IPv6 reverse zone is nibble-reversed under .ip6.arpa. An IPv6 address like 2001:db8::1 has the reverse zone 1.0.0.0.0.0.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. The verbose format reflects the 128-bit address space; each hex digit becomes a separate level in the reverse hierarchy. The RIR that allocated the IPv6 range delegates the reverse zone similar to IPv4 delegation.

The receiver-side handling of IPv6 RDNS has matured through 2023-2025. Major receivers (Gmail, Microsoft, Yahoo) check IPv6 PTR and FCrDNS with weighting similar to IPv4. Some receivers apply stricter requirements to IPv6 specifically because the address space is so large that IPv6 senders without PTR are statistically more likely to be unprofessional senders than IPv4 equivalents.

Operational considerations specific to IPv6: most production sending operations have substantially fewer IPv6 PTR records than IPv4 PTR records, which produces operational inconsistencies if not managed carefully. The two address families should have parallel PTR configuration so that dual-stack sending produces consistent receiver-side signals. Many sending operations have inadvertent IPv6 PTR omissions because their original deployment was IPv4-only and IPv6 was added later without parallel reverse-DNS configuration.

For senders running dual-stack sending, the operational best practice is to configure parallel PTR for both IPv4 and IPv6 addresses on each sending hostname, then verify both families resolve correctly through the tester on this site. The verification catches the common case where IPv4 works but IPv6 does not because the IPv6 reverse zone configuration was missed during initial setup.