DMARC Analyzer

TL;DR

• A PTR (Pointer) record is a DNS resource record type (RFC 1035 §3.3.12) that maps an IP address back to a hostname — the inverse of an A or AAAA record.
• PTR records live in the special-use in-addr.arpa zone (IPv4) and ip6.arpa zone (IPv6) (RFC 8499) with the IP octets / nibbles reversed and suffixed: 192.0.2.25 becomes 25.2.0.192.in-addr.arpa, and 2001:db8::25 becomes 5.2.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 FCrDNS check (Forward-Confirmed Reverse DNS) is what mail receivers run against every connecting SMTP client: PTR lookup → A/AAAA lookup of the returned hostname → verify the returned IP matches the connecting IP. If they do not match, the client is rejected or heavily spam-scored.
• Mail receivers REJECT IPs without matching PTR. RFC 1912 operational guidance plus RFC 5321 §4.1.1.4 + §5.1 plus every major mailbox provider (Gmail, Microsoft 365 / Outlook.com, Yahoo, AOL) require valid FCrDNS before accepting mail. Missing or generic provider PTR is the single most common cause of "mail is being rejected" deliverability complaints.
• The SPF "ptr" mechanism is EXPLICITLY DEPRECATED. RFC 7208 §5.5: "SHOULD NOT BE PUBLISHED" in new deployments. Performance cost (extra receiver-side DNS lookups) plus security ambiguity (PTR is controlled by the IP-block holder, not the domain). PTR records remain operationally important (FCrDNS, sender reputation), but they do NOT belong inside an SPF record.
• Per-provider PTR setup varies. Amazon EC2 requires a PTR submission form for Elastic IPs; Google Cloud sets PTR via instance metadata; Azure VM PTR requires a portal-side request; Hetzner has a Robot panel rDNS UI; DigitalOcean uses the droplet name; Linode uses the Cloud Manager. Self-hosted environments configure in-addr.arpa zones in BIND directly. The end-customer renting an IP CANNOT publish PTR records directly — only the IP-block holder can.
• IPv6 PTR is mandatory if you send over IPv6. Gmail in particular has been aggressive about IPv6 preference since 2014 and REJECTS IPv6 mail from IPs without matching ip6.arpa PTR with a 550 5.7.1 bounce. Dual-stack senders need both in-addr.arpa and ip6.arpa entries.
• Recommended TTL: 3600 to 86400 seconds. PTR records change rarely (typically only when migrating mail servers to new IPs), so longer TTLs improve cache efficiency. Lower to 300 to 3600 seconds BEFORE a planned IP migration and raise back afterwards. See DNS propagation for the pre-emptive-TTL- reduction pattern.

1. Overview: what reverse DNS and PTR records are

Every internet name lookup most operators are familiar with goes in one direction: a hostname like mail.example.com is resolved to an IP address like 192.0.2.25. The DNS RR types that drive the forward direction are A (for IPv4) and AAAA (for IPv6). Reverse DNS is the OTHER direction: given an IP address, what hostname does the IP-block holder claim for it?

Reverse lookups are answered by PTR records, a DNS resource record type defined by RFC 1035 section 3.3.12. PTR records do not live in the forward DNS zone with the A and AAAA records; they live in two special-use DNS zones reserved by IANA: in-addr.arpa for IPv4 and ip6.arpa for IPv6. The zones are delegated hierarchically to match the hierarchical IP-block allocation done by ARIN, RIPE, APNIC, AfriNIC, and LACNIC, so the authoritative nameservers for a PTR record on 192.0.2.25 are owned by whoever holds the 192.0.2.0/24 IP block — typically the hosting provider or ISP renting the IP to the end-customer.

For email delivery, PTR records are operationally load-bearing. Mail receivers query the PTR record of every connecting SMTP client as part of the trust-baseline check that runs BEFORE any envelope or header data is transmitted, BEFORE SPF can be evaluated, BEFORE DMARC can be checked. A missing PTR or one that does not forward-confirm causes the receiver to reject the connection outright with a 550 5.7.1 series error or to apply a heavy spam-scoring penalty. This page is the deep dive on what PTR records ARE, how the FCrDNS check works, why receivers care, the in-addr.arpa and ip6.arpa zone encoding, per-provider PTR setup procedures, and the troubleshooting funnel for "mail is bouncing because reverse DNS is missing".

2. PTR record syntax (in-addr.arpa and ip6.arpa)

A PTR record is a single-string RDATA RR. The DNS query name encodes the IP, and the RDATA payload is the hostname the IP maps back to. The encoding rules differ between IPv4 and IPv6.

2.1 IPv4 PTR (in-addr.arpa)

For an IPv4 address, the octets are REVERSED and suffixed with .in-addr.arpa:

; Forward zone (example.com):
mail.example.com.    IN  A     192.0.2.25

; Reverse zone (2.0.192.in-addr.arpa, owned by the /24 holder):
25.2.0.192.in-addr.arpa.   IN  PTR   mail.example.com.

Verifying with dig:

$ dig -x 192.0.2.25 +short
mail.example.com.

$ dig PTR 25.2.0.192.in-addr.arpa +short
mail.example.com.

The two queries are equivalent — dig -x is a convenience wrapper that automatically constructs the reversed in-addr.arpa name from the IP argument.

2.2 IPv6 PTR (ip6.arpa)

For an IPv6 address, the full 128-bit address is expanded (no :: shorthand), each hex nibble is reversed, and the result is suffixed with .ip6.arpa:

; Forward zone:
mail.example.com.    IN  AAAA  2001:db8::25

; Reverse zone (under the /48 or /64 holder's authoritative servers):
5.2.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. IN PTR mail.example.com.

The verbose nibble-reversed encoding is what makes ip6.arpa hierarchical delegation match the /4 boundary of the IPv6 address, which is why a single IPv6 PTR query name has 32 hex characters separated by 31 dots. The dig -x wrapper handles IPv6 transparently.

3. The forward-confirmed reverse DNS (FCrDNS) check

FCrDNS is the trust-baseline check that mail receivers run against every connecting SMTP client. Most modern receivers (Gmail, Microsoft 365 / Outlook.com, Yahoo, AOL, Apple iCloud, and the major commercial spam-filtering vendors: Proofpoint, Mimecast, Barracuda, Cisco IronPort) run FCrDNS unconditionally; the only way to AVOID the check is to not run mail at all. The procedure has four steps and a single pass/fail outcome:

1. Record the connecting IP. Whatever IP the SMTP client used to open the TCP connection on port 25 (or port 587 / 465 for authenticated submission — FCrDNS applies to both).
2. Query PTR for the connecting IP. Reverse-resolve via dig -x equivalent. The receiver expects a hostname back; if the result is NXDOMAIN or the PTR is missing entirely, FCrDNS FAILS.
3. Query A or AAAA for the returned hostname. Forward-resolve the PTR result. The receiver expects an IP back.
4. Compare the forward-resolved IP to the connecting IP. Match → FCrDNS PASSES; mismatch → FCrDNS FAILS.

The check is operationally significant because it is the lowest-cost trust signal a receiver can compute: a single PTR lookup plus a single A/AAAA lookup, both cacheable, evaluated before any SMTP DATA has been received. Spammers cannot easily produce matching PTR records on the IPs they hijack — botnet IPs typically inherit a generic provider PTR (something like 1-2-3-4.dynamic-pool.example-isp.com) that does NOT resolve back to the same IP that connected, so the botnet traffic fails FCrDNS while legitimate operator-controlled mail servers pass. Even a single PTR-only check (without the forward-confirmation step) is enough to reject ~30 percent of total botnet traffic per publicly-published Gmail and Microsoft anti-abuse data.

4. Why mail receivers reject IPs without matching PTR

The receiver-side rejection rule is rooted in RFC 1912 section 2.1 ("PTR records") which documents the operational expectation that every IP advertised on the public internet SHOULD have a matching PTR record, and that mail servers in particular MUST. The MUST language is reinforced by RFC 5321 section 4.1.1.4 (the EHLO greeting expects a fully-qualified domain that resolves back to the connecting IP) and section 5.1 (the mail-delivery sequence assumes the sender is a properly-configured SMTP MTA, which by RFC 1912 operational guidance means PTR-published).

In practice, the receiver-side enforcement has converged on these rejection patterns:

• Gmail: rejects with 550 5.7.1 The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS does not match the reverse DNS. The error has been in Gmail's published anti-abuse documentation since 2010.
• Microsoft 365 / Outlook.com: rejects with 550 5.7.1 Client host rejected: cannot find your reverse hostname, [your.ip.address] or the Sender-Score-based equivalent.
• Yahoo / AOL: rejects with 550 5.7.1 Connection denied (Mode: normal) ... reverse DNS does not resolve.
• Spam-filter vendors (Proofpoint, Mimecast, Barracuda): apply heavy spam-score penalty rather than outright rejection, but the practical effect is the same — mail goes to the recipient's junk folder or is silently dropped.

The single most common cause of "mail is being rejected" deliverability complaints from new-mail-server operators is missing or mis-aligned PTR. Operators on shared-IP hosting (typical VPS providers, basic cloud droplets) inherit the generic provider PTR (something like vps-203-0-113-25. example-cloud.net) which technically passes FCrDNS but is heavily penalized by every major mailbox provider because the hostname contains the dynamic-pool / generic-VPS signature.

5. PTR records for IPv6 (ip6.arpa)

IPv6 PTR is structurally the same as IPv4 PTR but encoded in the ip6.arpa special-use zone instead of in-addr.arpa. The nibble-reversed encoding is what makes ip6.arpa hierarchical delegation match the /4 boundary of the IPv6 address: a /48 IPv6 block holder is delegated authority over the corresponding /48-prefix nibbles in ip6.arpa, a /64 holder over the /64-prefix nibbles, and individual /128 PTR records live at the leaf of the 32-character nibble-reversed name.

Why IPv6 PTR matters more than operators expect: Gmail has been progressively expanding its IPv6 transport preference since 2014, and since 2016 has rejected outbound IPv6 mail from IPs without matching ip6.arpa PTR with a 550 5.7.1 bounce containing the literal text "IPv6 sending server must have PTR record". Microsoft 365 / Outlook.com applies the same rule. The practical consequence: a mail server with valid IPv4 PTR but missing IPv6 PTR sees normal delivery to most receivers but Gmail specifically (which represents a huge fraction of total recipient endpoints) returns 550 bounces, sometimes randomly when the dual-stack sender alternates between IPv4 and IPv6 transport based on receiver AAAA-record publication.

Recommended IPv6 PTR strategy:

• If you publish AAAA on your mail host: you MUST also publish ip6.arpa PTR for every IPv6 address the AAAA resolves to. Symmetric forward / reverse is the baseline.
• If your mail host is dual-stack but you only want to send IPv4: explicitly bind the outbound SMTP socket to the IPv4 interface (in Postfix: inet_protocols = ipv4; in Exim: the equivalent disable_ipv6 directive; in Sendmail: the O DaemonPortOptions Address4 binding). Without this, the kernel may default to IPv6 outbound when an AAAA record exists, and the mail server will silently use IPv6 with the missing ip6.arpa PTR.
• Safe default: publish both in-addr.arpa and ip6.arpa PTR for every outbound interface that has any forward record, even if you're not yet actively sending IPv6. An inadvertent IPv6 path enabled later does not silently break delivery.

6. Per-provider PTR setup

The end-customer renting an IP from a hosting provider CANNOT publish PTR records directly — only the IP-block holder (the provider) can. Per-provider setup procedures vary significantly. The following are the operator-facing patterns as of 2026 for the major providers operators encounter; the underlying authoritative-nameserver configuration is the same in all cases (an in-addr.arpa or ip6.arpa PTR record published by the provider on the customer's request).

6.1 Amazon EC2 / SES

• EC2 with Elastic IP: AWS provides the default generic PTR (ec2-203-0-113-25.compute-1.amazonaws.com) automatically. To set a custom PTR (mail.example.com), submit the "Request to Remove Email Sending Limitations" form in the AWS Support Center. The form requires the EIP to be allocated, the forward A/AAAA record to be published first (so FCrDNS passes immediately when the PTR takes effect), and the domain to be controlled by the requestor. Amazon processes manually with a 24-48-hour turnaround.
• SES managed IPs: Amazon publishes the PTR automatically on the SES-managed IP pool; no operator action. For dedicated SES IPs, the customer's configured "From" domain drives the PTR.

6.2 Google Cloud Compute

• PTR is configured per-instance via the Compute Engine metadata. The gcloud compute instances add-access-config command accepts a --public-ptr-domain-name flag that sets the PTR for the instance's external IP. Alternatively, in the Cloud Console: VM Instances → Edit → Network interfaces → External IP → Public DNS PTR. Verification of forward ownership is automated against the domain's published TXT challenge.

6.3 Microsoft Azure VMs

• Azure publishes a generic PTR (cust-azure-203-0-113-25.cloudapp.net) by default. Custom PTR requires a portal-side request through Azure Support or programmatically via Set-AzPublicIpAddress with the -ReverseFqdn parameter. As with EC2, the forward record MUST be published before the PTR change.

6.4 Hetzner

• Hetzner exposes PTR management in the Robot panel (dedicated servers) or Cloud Console (cloud servers). Customers can update PTR self-service with no support ticket. The change propagates within minutes.

6.5 DigitalOcean

• DigitalOcean derives PTR from the droplet name automatically: rename the droplet mail.example.com and the PTR updates to match within a few minutes. No separate PTR configuration screen. Verification of forward ownership is the operator's responsibility.

6.6 Linode

• Linode exposes PTR in the Cloud Manager under Networking → rDNS. Self-service; propagation within minutes; forward-record ownership is the operator's responsibility.

6.7 Self-hosted (BIND)

• For on-prem deployments where the organization holds the IP block directly (typically a /24 or larger from ARIN), the operator runs BIND with an in-addr.arpa reverse zone:

// /etc/bind/named.conf.local
zone "2.0.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.0.2";
    allow-transfer { trusted; };
};

// /etc/bind/zones/db.192.0.2
$TTL    86400
@   IN  SOA ns1.example.com. hostmaster.example.com. (
            2026052101 ; Serial
            3600       ; Refresh
            900        ; Retry
            604800     ; Expire
            86400 )    ; Minimum TTL
    IN  NS  ns1.example.com.
    IN  NS  ns2.example.com.
25  IN  PTR mail.example.com.

7. PTR and email authentication (SPF, DMARC, MX)

PTR is operationally UPSTREAM of SPF, DKIM, and DMARC. The order of receiver-side checks during an inbound SMTP transaction is:

1. TCP handshake on port 25
2. FCrDNS check on the connecting IP — FAIL here and the connection is rejected before any envelope or header data transmits
3. EHLO greeting (the sender announces its hostname)
4. MAIL FROM (envelope sender)
5. RCPT TO (envelope recipient)
6. DATA (header + body)
7. Receiver-side processing: SPF check (against MAIL FROM domain), DKIM check (against signed headers), DMARC alignment check (against From: header)

Steps 1-2 are the trust-baseline gate; if PTR is missing or FCrDNS fails, the receiver-side SPF / DKIM / DMARC machinery is never even invoked. This is why "I have perfect SPF and DMARC alignment but mail is still being rejected" is almost always a PTR / FCrDNS problem — SPF and DMARC are OPERATIONALLY DOWNSTREAM of PTR and cannot rescue a PTR failure.

For MX records on the INBOUND side, PTR is the natural sibling check: the MX target hostname SHOULD have a forward A/AAAA record matching the PTR of the MX target IP. See the MX records deep dive for the inbound side and the "reverse-DNS on the resolved IP" troubleshooting funnel that anchors against this page.

8. The deprecated SPF "ptr" mechanism (RFC 7208 §5.5)

Historically, SPF supported a "ptr" mechanism that instructed receivers to reverse-resolve the sending IP via PTR, then check whether the returned hostname was within the domain named in the SPF record:

; Deprecated syntax (DO NOT USE):
v=spf1 ptr:example.com -all

The mechanism is EXPLICITLY DEPRECATED by RFC 7208 §5.5: the language is "SHOULD NOT BE PUBLISHED". Two reasons drove the deprecation:

1. Performance. Every SPF "ptr" evaluation requires the receiver to perform a PTR lookup followed by one or more A/AAAA lookups against each returned hostname to check domain membership. This dramatically inflates the receiver-side DNS query budget — SPF already has a 10-DNS-lookup hard limit (RFC 7208 §4.6.4) and "ptr" mechanisms count against that limit at a higher per-record cost than any other mechanism. Receivers running high-volume mail benefit from SPF records without "ptr" because the per-message DNS cost is lower.
2. Security and ambiguity. PTR records are controlled by the IP-BLOCK HOLDER, not by the domain owner. An attacker who compromises an IP block (or who rents an IP from a careless provider that does not require forward- record proof) can manipulate PTR responses to forge SPF passes. The "ptr" mechanism also has ambiguous semantics around CNAME chains in the PTR response and around IPv4-mapped IPv6 addresses. RFC 7208's authors concluded that the cost did not justify keeping it.

The deprecation has been honored by every major SPF library and receiver since 2014. Modern SPF deployments use ip4: / ip6: / a / mx / include: mechanisms and avoid ptr entirely. See the SPF explained and SPF lookup limit deep dives for the modern SPF authoring guidance.

Important: this deprecation applies to the SPF "ptr" MECHANISM, not to PTR records themselves. PTR records remain operationally important for the FCrDNS receiver-side check that runs OUTSIDE the SPF evaluation pipeline.

9. Shared IPs, NAT, and cloud load balancers

The simple "one mail server = one IP = one PTR" model breaks in several common deployment topologies. Each has a different PTR consideration.

9.1 Shared IPs (typical VPS, basic cloud hosting)

On shared-IP hosting, multiple customer mail servers share a single egress IP. Only ONE PTR record can be published for that IP, and it is chosen by the IP-block holder — almost always the provider's generic PTR. Customers on shared-IP hosting CANNOT publish a custom PTR; the practical workaround is to use a transactional ESP (Amazon SES, Mailgun, SendGrid, Postmark) which operates dedicated IP pools with provider-managed FCrDNS, or to upgrade to a dedicated-IP plan.

9.2 NAT

When the mail server lives behind a NAT gateway (typical on-prem deployment with private RFC 1918 IPs internally), the PTR must be published for the PUBLIC NAT IP, not the private internal IP. Internal IPs in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 are not routable on the public internet and do not need (and cannot have) public PTR records. The mail server's HELO/EHLO greeting must announce a hostname that resolves to the PUBLIC NAT IP (not the private one) for FCrDNS to pass.

9.3 Cloud load balancers (AWS ELB / GCP Load Balancer / Azure Load Balancer)

Mail traffic does NOT typically traverse HTTP/HTTPS load balancers because SMTP is not a layer-7 protocol the load balancer understands. For sender-side mail behind a Network Load Balancer (layer 4), each egress IP of the NLB needs its own PTR. AWS NLB provides PTR on the static EIPs assigned to the NLB; GCP and Azure equivalents work similarly. The complication: NLB elastic IPs are typically shared with other NLB deployments unless the operator specifically assigns dedicated EIPs.

9.4 Outbound-mail clusters

Operators running a mail cluster (multiple Postfix or Exim instances behind a round- robin DNS or SMTP-load-balancing layer) need PTR on EVERY EGRESS IP individually. The cluster's outbound interface set is what the receiver sees; if one of the egress IPs lacks PTR, mail from that path fails FCrDNS while mail from the other paths succeeds — producing the confusing "sometimes mail delivers, sometimes it bounces" pattern that is hard to diagnose without inspecting the Received: header chain to see which egress IP was used.

10. PTR record TTL recommendations

PTR records change rarely — typically only when migrating mail servers to new IPs or when rebuilding mail infrastructure — so longer TTLs improve cache efficiency at the millions of recursive resolvers across the internet. The recommendations mirror the general DNS TTL guidance in the DNS propagation deep dive:

• Stable production PTR: 3600 to 86400 seconds (1 hour to 24 hours). This is the default for almost every operator-managed and provider-managed PTR.
• Pre-migration: lower to 300 to 3600 seconds AT LEAST 24-48 hours BEFORE a planned IP migration so the new PTR propagates within the lowered TTL window. After the migration is stable, raise back to the long default.
• Emergency rollback: if a wrong PTR was published and is being actively cached, raise the long TTL is useless — the change takes the old TTL to age out at receivers, not the new TTL. The pre-emptive-TTL-reduction pattern is the operational discipline that prevents this trap.

11. Common PTR-record mistakes

• Generic provider PTR on a custom mail-sending IP. Operators rent an Elastic IP from AWS and start sending mail immediately without filing the PTR-change request. The PTR resolves to ec2-203-0-113-25.compute-1.amazonaws.com; FCrDNS technically passes (the forward record exists and resolves back to the connecting IP) but Gmail and Microsoft 365 heavily penalize the compute.amazonaws.com / amazonaws.com / cloudapp.net generic-PTR signature for outbound mail.
• Missing IPv6 PTR when dual-stack is enabled. The forward AAAA record exists; mail server picks IPv6 outbound; Gmail rejects with 550 5.7.1 "IPv6 sending server must have PTR record". The operator sees intermittent bounces because the kernel sometimes picks IPv4 (which works) and sometimes IPv6 (which doesn't).
• Mismatched forward / reverse. PTR resolves to mail.example.com but the A record for mail.example.com points to a different IP. FCrDNS fails; all major receivers reject. The fix is to update either the PTR target or the forward A record so both ends match the connecting IP exactly.
• PTR pointing at a CNAME. RFC 1034 §3.6.2 explicitly prohibits PTR records from targeting CNAME aliases — the PTR RDATA must be a hostname that resolves directly to an A or AAAA record. Some legacy provider portals quietly accept CNAME-pointing PTR; receivers treat them as missing.
• Multiple PTR records on a single IP. RFC 1912 §2.1 recommends a single PTR per IP; multiple PTRs are legal but produce undefined receiver behaviour (some receivers pick the lexicographically first; others reject randomly). For mail, publish exactly one PTR.
• PTR not updated after an IP change. The mail server moved from old IP to new IP; A record was updated; PTR was forgotten. The new IP returns the provider-generic PTR which FCrDNS-passes but Gmail penalizes. Audit PTR on every IP change as part of the migration runbook.

12. Troubleshooting "reverse DNS missing"

When a receiver bounces mail with the 550 5.7.1 series error containing "reverse DNS does not resolve" or "Client host rejected: cannot find your hostname" or "PTR record does not resolve", work the diagnostic funnel:

1. Identify the connecting IP. Inspect the Received: header chain of a bounce message or the SMTP transcript to find the IP your mail server actually connected from. For NAT or cluster-egress topologies, this may NOT be the IP you expected.
2. Confirm PTR exists. Run dig -x your.sending.ip +short. Expected output: a hostname like mail.example.com. NXDOMAIN or empty → PTR is missing entirely; file a PTR change with your IP-block holder.
3. Confirm forward-confirmation passes. Take the PTR result from step 2, run dig +short the.returned.hostname, and compare the result IP to the connecting IP from step 1. Mismatch → either the forward A/AAAA is wrong (fix it under your control) or the PTR is pointing at a different host than you intend.
4. Check IPv4 vs IPv6. If your mail server is dual-stack, repeat the check for both. Gmail specifically rejects on missing ip6.arpa PTR even when in-addr.arpa is fine.
5. Verify the provider PTR is acceptable. If the PTR resolves to a generic provider hostname (ec2-*, compute.amazonaws.com, cloudapp.net, example-cloud.net), the FCrDNS check technically passes but Gmail / Outlook will heavily spam-score or reject. File a custom-PTR request with the provider.
6. Check the EHLO greeting. The HELO/EHLO hostname the mail server announces should match the PTR target. Mismatch is not strictly FCrDNS-failing but is heavily spam-scored. Configure myhostname in Postfix or the equivalent in your MTA to match the PTR.
7. Check IP reputation. The DMARC Analyzer Blacklist Checker queries the major RBLs against the sending IP; if the IP is listed, FCrDNS may pass but mail is still rejected. PTR is necessary but not sufficient.

13. FAQ — common questions about reverse DNS and PTR

What is a PTR record?

A PTR (Pointer) record is a DNS resource record type defined by RFC 1035 section 3.3.12 that maps an IP address back to a hostname — the inverse of the more familiar A or AAAA record. PTR records live in two special-use DNS zones standardized by RFC 8499: in-addr.arpa for IPv4 and ip6.arpa for IPv6.

What is FCrDNS and why do mail receivers care?

FCrDNS is the Forward-Confirmed Reverse DNS check: the receiver looks up PTR for the connecting IP, then looks up A/AAAA for the returned hostname, and accepts the connection only if the returned IP matches the connecting IP. The check is operationally significant because spammers cannot easily produce matching PTR records on the IPs they hijack, so FCrDNS is the cheapest available trust-baseline filter at the SMTP handshake layer.

Does my PTR record affect SPF or DMARC?

PTR is operationally upstream of SPF and DMARC. The receiver runs FCrDNS during the SMTP connection handshake, BEFORE SPF or DMARC are evaluated. A failed PTR causes the connection to be rejected before SPF / DMARC are even checked, so SPF and DMARC alignment cannot rescue a PTR failure.

How do I set up a PTR record on an Amazon EC2 instance?

For EC2 with an Elastic IP, submit Amazon's "Request to Remove Email Sending Limitations" form which doubles as the PTR-modification request. The form requires the EIP allocated, the forward A/AAAA record published first, and domain ownership of the PTR target. Amazon processes the request manually with a 24-48-hour turnaround.

Do I need an IPv6 PTR if my mail server only sends over IPv4?

If your mail server is genuinely IPv4-only (no AAAA record on the forward, outbound socket bound to the IPv4 interface), IPv6 PTR is irrelevant. If your mail server is dual-stack with AAAA on the forward, you MUST publish ip6.arpa PTR — Gmail and Microsoft 365 reject IPv6 mail from IPs without it.

Why was the SPF "ptr" mechanism deprecated?

RFC 7208 section 5.5 explicitly deprecated the SPF "ptr" mechanism in 2014 with the language "SHOULD NOT BE PUBLISHED" for two reasons: performance (PTR lookups dramatically inflate the receiver-side DNS query budget within the 10-DNS-lookup SPF limit) and security ambiguity (PTR is controlled by the IP-block holder, not the domain). PTR records themselves remain operationally important for FCrDNS; the SPF mechanism is what was deprecated.

What is the in-addr.arpa zone and why does PTR live there?

in-addr.arpa is a special-use DNS zone reserved by IANA for reverse-mapping IPv4 addresses to hostnames. The reversed-octet encoding (192.0.2.25 becomes 25.2.0.192.in-addr.arpa) makes the hierarchical DNS delegation match the hierarchical IP-block allocation by the regional internet registries.

What does 550 5.7.1 reverse DNS does not resolve mean?

The 550 5.7.1 series of SMTP errors are receiver-side rejections caused by a failed PTR or FCrDNS check. Remediate by confirming the PTR exists (dig -x your.ip), confirming the forward record resolves back to the same IP, and filing a custom-PTR change with the IP-block holder if the provider-default PTR is generic.

14. Related guides

• MX records explained — the inbound-mail-routing record whose troubleshooting funnel terminates in the PTR check on the resolved MX target IP.
• DNS propagation — the cross-cutting operational deep dive on TTL mechanics and resolver caching that applies to PTR as well as every other DNS record type.
• SPF explained — the email-authentication layer whose "ptr" mechanism was deprecated by RFC 7208 §5.5 (this page cross-references that deprecation).
• SPF lookup limit — the 10-DNS-lookup budget that made the "ptr" mechanism prohibitively expensive and motivated its deprecation.
• DKIM explained — the cryptographic email-authentication layer that runs DOWNSTREAM of the PTR check.
• DMARC records explained — the policy layer that authorizes what receivers should do with SPF and DKIM verdicts; operationally downstream of PTR.
• DMARC alignment — the per-message alignment check between MAIL FROM, DKIM signing domain, and the From: header.
• Email spoofing techniques and defenses — the SMTP-message-layer threat catalogue that runs DOWNSTREAM of the FCrDNS gate this page documents. Where this page documents the connection-layer identity check that runs BEFORE any SMTP DATA is transmitted (FCrDNS per RFC 1912 §2.1 confirms the connecting IP / PTR / forward-A triplet), the spoofing page documents the seven canonical attacker techniques that operate ON the SMTP DATA the receiver agreed to accept after FCrDNS passed: exact-domain From-header forge, Punycode/IDN homograph From-domain substitution, Display-Name-only spoofing, Reply-To substitution, envelope-MAIL-FROM- vs-From split, subdomain abuse, and lookalike-TLD attacks. A clean PTR passes FCrDNS but does NOT prevent any of these RFC 5322-layer spoofing techniques — PTR is the trust-baseline gate, the seven techniques are the adversary's response once they have obtained a clean-PTR sending IP (often via compromised legitimate hosts or clean-PTR cloud-provider IPs). Read this page for the connection-layer check; read the spoofing page for the message-layer attacks that DMARC identifier alignment closes downstream.
• DMARC for Microsoft 365 — the M365-specific deployment guide whose preflight checklist includes the PTR check.
• DMARC for Google Workspace — the Google Workspace deployment guide; Gmail is the receiver most aggressive about FCrDNS enforcement.
• DMARC troubleshooting — the cross-cutting diagnosis guide whose first triage step is "check PTR / FCrDNS".
• DMARC for shared hosting — the PTR-RECORD-OWNERSHIP-AT- SHARED-HOSTING-SHARED-IP-POOL-IS- PROVIDER-MANAGED companion to this FCrDNS-PTR-publication-discipline reference. Where THIS page documents the canonical operator-controlled PTR-record publication discipline (the in-addr.arpa octet-reversal convention, the ip6.arpa nibble-reversal convention, the FCrDNS check sequence per RFC 1912 §2.1, the canonical RBL/DNSBL consultation order, the operator-side diagnostic workflow for PTR-vs-HELO mismatch debugging), the shared-hosting spoke is the per-provider deployment companion documenting FOUR shared- hosting-PTR-constraint dimensions: (i) shared-hosting outbound IP pool is PROVIDER-MANAGED — the per-tenant outbound SMTP egress originates from one of N IPs in the provider's shared outbound IP pool, and the PTR record for each IP in the pool points to a provider-managed generic hostname (mail-out-N.<provider>.com, smtp-relay-N.<provider>.com), NOT the operator's own brand-domain — the shared-hosting spoke documents the canonical OPERATOR- EMPOWERMENT-CEILING where the PTR- record-says-provider-brand-not- operator-brand reality forces operator-side acceptance that the in-flight per-message identity is SHARED with every OTHER tenant on the same shared-IP-pool — and the per- provider escalation paths to a dedicated outbound IP with operator- managed PTR; (ii) generic provider-default PTR trips FCrDNS at major mailbox-provider receivers — Gmail's RFC 5321 receiver-discipline flags generic-looking PTRs (cust-203-0-113-1.isp.example, dynamic-pool-N.hosting.example) as residential-pool / dynamic-pool indicators and applies deliverability- floor penalties even before SPF / DKIM / DMARC evaluation runs — the shared-hosting spoke documents the canonical operator-side deliverability-floor symptom (legitimate operator-authored marketing or transactional mail from a shared- hosting tenant routes to Gmail's spam folder DESPITE 100% SPF/DKIM/DMARC pass rate, due to PTR-FCrDNS receiver-side penalty), and the per-receiver diagnostic discipline (Postmaster Tools receiver-side IP reputation report confirms the IP-identity-layer floor penalty); (iii) per-tenant PTR escalation paths at the shared- hosting boundary — dedicated-IP upgrade with operator-managed PTR, per-account static-IP allocation, white-label PTR delegation to the operator's own brand-domain, escalation to managed-VPS-with-operator-controlled- PTR tier — the shared-hosting spoke documents the per-provider tier-up paths (cPanel "Dedicated IP Address" add-on, Plesk "Dedicated IP" per- domain assignment, DirectAdmin per-account static-IP provisioning, managed-hosting white-label PTR delegation contract) that unlock the operator-controlled PTR-publication discipline this page documents at the shared-hosting boundary; (iv) shared-hosting PTR-vs-HELO mismatch as recurring deliverability symptom — provider-managed PTR announces one hostname while the shared-MTA HELO announces a DIFFERENT hostname, producing the canonical PTR-vs-HELO mismatch that receivers flag — the shared-hosting spoke documents the canonical operator- side diagnostic-workflow when an operator-authored deliverability- incident traces back to the provider-side PTR-vs-HELO mismatch the operator cannot directly fix, and the per-provider escalation discipline (open a ticket → confirm provider- side PTR / HELO alignment intent → request HELO override if the provider supports per-tenant HELO authoring). Read the shared-hosting spoke when an operator-authored deliverability incident traces back to the IP-identity- layer PTR-FCrDNS check this page documents and the operator is on cPanel / Plesk / DirectAdmin shared hosting — the spoke is the authoritative per-provider operational reference for the PTR-FCrDNS-meets- shared-hosting-shared-IP-pool cross- cluster boundary.
• Email deliverability — the FCrDNS-PTR-RECORD-AS-IP-IDENTITY- LAYER-REPUTATION-INPUT-FOR-MAILBOX-PROVIDER- INBOX-PLACEMENT-DECISION companion documenting the umbrella inbox-placement outcome (Gmail / Yahoo / Outlook / AOL / Apple iCloud / Fastmail mailbox-provider inbox-vs-junk-folder routing decisions) the IP-identity-layer FCrDNS-verification discipline on this PTR- records reference is the load-bearing input to. Where THIS page documents the SMTP-connection-layer FCrDNS check (the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR record publication discipline per RFC 1912 §2.1, the forward-confirmed reverse-DNS symmetric-verification check the mailbox- provider's MX-receiving-MTA performs at SMTP-connection time BEFORE the message envelope is even accepted, the receiver-side enforcement disparity between Gmail / Yahoo / Microsoft 365 / hosted-MTA vendors), the email-deliverability spoke is the UMBRELLA- OUTCOME companion documenting WHY FCrDNS- verification posture matters at the receiver- side deliverability boundary. The four-axis FCrDNS-VS-DELIVERABILITY-OUTCOME comparison exposes the structurally-distinct IP- IDENTITY-LAYER-REPUTATION-INPUT roles: (i) mailbox providers use FCrDNS-pass as the FIRST-PASS connection-layer trust signal BEFORE any message-identity (SPF / DKIM / DMARC) check runs — an FCrDNS-fail at the SMTP-connection layer produces an immediate downweight in Gmail's IP reputation tier and an automatic spam-folder routing decision at Microsoft 365 / EOP, INDEPENDENT of subsequent message- identity outcomes; the FCrDNS-pass-rate over the last 30 days is one of the load-bearing inputs to "IP reputation" in Gmail Postmaster Tools, "IP rating" in Microsoft SNDS, and the equivalent Yahoo Sender Hub / Apple Postmaster receive-side scores; (ii) FCrDNS- misaligned connecting IPs produce inbox- placement degradation that operators MISREAD as content-filter penalty or DMARC- misconfiguration — the deliverability spoke documents the specific Gmail Postmaster Tools / Microsoft SNDS / Yahoo Sender Hub diagnostic surfaces the FCrDNS-misalignment manifests through; the operator-debugging workflow MUST evaluate the IP-identity layer (FCrDNS) BEFORE re-evaluating the message-identity layer (SPF / DKIM / DMARC) when troubleshooting deliverability churn; (iii) new sending IPs (brought online for IP warming, capacity expansion, geo-redundancy) MUST publish PTR records pointing to a forward-A- record-resolvable hostname BEFORE the first production message is sent — the deliverability-warming-cadence (a few hundred messages per day on day 1, doubling each subsequent day) the deliverability spoke documents is GATED by the FCrDNS prerequisite documented on this page; (iv) shared- sending-IP-pool providers (transactional ESPs, marketing-mail platforms, Microsoft 365 EOP shared egress IPs, Google Workspace shared egress IPs) manage FCrDNS on behalf of their tenants — the deliverability spoke documents the tenant-vs-provider FCrDNS-management boundary; tenants on shared infrastructure inherit the FCrDNS posture their provider publishes, which means tenant deliverability is bounded above by the provider's IP-reputation posture even if the tenant's message-identity layer is perfect. Read the email-deliverability spoke when scoping the umbrella inbox-placement outcome the FCrDNS-verification discipline on this PTR-records reference is engineered to sustain, and when building the IP-reputation- monitoring feedback loop that detects FCrDNS- misalignment churn at the mailbox-provider receive boundary.
• Email authentication intro — the cluster intro that places PTR in the broader email-auth picture.
• TLS-RPT record syntax — the PARALLEL-DNS-RR-BYTE-ANATOMY- COMPANION-AT-DIFFERENT-NAMESPACE-BOUNDARY companion documenting the structural- parallel DNS-record-publication discipline operators apply across two DNS-record family namespaces this site references: (a) the in-addr.arpa / ip6.arpa reverse-namespace PTR-record publication discipline THIS page documents (the per-IP PTR-record byte-anatomy + the FCrDNS-verification- time receiver-side check this page's Gmail-Postmaster / Microsoft-SNDS / Yahoo-Sender-Hub matrix references), AND (b) the _smtp._tls.<domain> forward-namespace TLS-RPT-record publication discipline the TLS-RPT- record-syntax spoke documents (the per- domain TLS-RPT TXT-record byte-anatomy + the TLS-handshake-time receiver-side check that produces the failure-report stream the rua= tag routes to operator-published endpoints). Where THIS page documents the PTR-record- publication discipline (the per-IP reverse-zone PTR-record byte-anatomy, the FCrDNS forward-confirmed verification contract, the per-IP DNS-publishing- authority delegation chain (typically the IP-provider-controlled reverse-zone, NOT the customer-domain forward-zone), the per-IP rotation-cadence operator discipline), the TLS-RPT-record-syntax spoke is the FORWARD-NAMESPACE-PARALLEL REFERENCE documenting the structurally- analogous DNS-record-publication discipline on the per-domain forward- namespace. The four-axis IN-ADDR-ARPA- REVERSE-NAMESPACE-VS-FORWARD-NAMESPACE- TLS-RPT-PUBLICATION comparison exposes the structurally-distinct DNS-RECORD- BYTE-ANATOMY-ACROSS-NAMESPACE parallels: (i) PTR-record per- IP byte-anatomy at in-addr.arpa reverse- namespace → TLS-RPT-record per- domain byte-anatomy at _smtp._tls.<domain> forward-namespace — both records publish at structurally- different namespace boundaries (PTR at the reverse-zone derived from per-IP octets, TLS-RPT at the per-domain forward-zone with underscore-prefixed subdomain), both encode policy-relevant identity in DNS-record byte-shape (PTR encoding the per-IP-to-hostname binding the FCrDNS verifier consumes, TLS-RPT encoding the per-domain-to-reporting- URI binding the failure-report dispatch consumes), the spoke documents the TLS- RPT-specific byte-anatomy parallel to this PTR-byte-anatomy reference; (ii) PTR-publishing-authority delegation discipline at IP-provider- controlled-reverse-zone boundary → TLS-RPT-publishing-authority discipline at customer-domain-controlled-forward- zone boundary — PTR-record publication is typically delegated to the IP-provider via the cloud-provider Console (AWS-EC2-instance reverse-DNS- delegation, Azure-VM reverse-DNS- delegation, GCP-Compute-Engine reverse- DNS-delegation), creating a per-IP publishing-authority delegation gap between the customer-domain operator and the IP-provider; TLS-RPT-record publication is at the customer-domain- controlled forward-zone, eliminating the delegation gap — the spoke documents this operator-discipline asymmetry the customer-domain operator must coordinate with the IP-provider-side PTR-publishing authority for; (iii) PTR-record- publication regression-detection at FCrDNS-verification-failure-time → TLS-RPT-record-publication regression- detection at TLS-handshake-failure-time observability — PTR-record- publication regression manifests as FCrDNS-fail at the per-IP SMTP-connection time (typical detection window: minutes- to-hours after the regression, observed by the receiver's daily SMTP-reject-rate spike), TLS-RPT-record-publication regression manifests as failure-report non-receipt at the per-domain reporting- endpoint (typical detection window: 24-hours after the regression because TLS-RPT reports are typically daily- aggregate), the spoke documents the TLS-RPT-side regression-detection observability surface as STRUCTURALLY- PARALLEL but TIME-SHIFTED detection infrastructure to this PTR-side FCrDNS- verification-failure surface; (iv) per-IP-vs-per-domain PTR-and- TLS-RPT coordination observability → cross-namespace DNS-publication- pipeline holistic-KPI — when the customer-domain operator manages BOTH (a) IP-provider-coordinated PTR- records for the per-IP outbound MTA IPs AND (b) per-domain TLS-RPT records for the per-domain reporting-endpoint infrastructure, the coordination becomes the holistic DNS-publication- pipeline health-KPI; the spoke documents the TLS-RPT-side per-domain observability metric (per-day per- domain TLS-RPT-record-DNS-resolution- availability, per-period TLS-RPT report-receipt-rate) parallel to this PTR-side per-IP observability metric the page documents (FCrDNS-verification- pass-rate, per-IP reverse-DNS-publication- availability). Read the TLS-RPT-record- syntax spoke when the operator's PTR- record-publication discipline at the IP-provider-coordination boundary is being extended to per-domain TLS-RPT publication at the customer-domain- controlled forward-zone — the spoke is the structural-parallel reference whose DNS-RR-publication-discipline pattern the PTR-operator already has the per- record-byte-anatomy + per-record- publication-quality-KPI muscle-memory for.
• TLS-RPT JSON report format — the PTR-RDNS-FEEDS-TLS-RPT-RECEIVING- MX-HELO companion to this PTR-record / FCrDNS deep dive. Where THIS page documents the SMTP-connection-layer identity-check (the PTR record on the in-addr.arpa / ip6.arpa zone, the forward-confirmed reverse-DNS check per RFC 1912 §2.1, and the receiver-side enforcement disparity between Gmail / Yahoo / Microsoft 365 / hosted-MTA vendors), the TLS-RPT report-format spoke documents the RFC 8460 §4 JSON schema whose failure-details[] array captures the receiving-mx-helo / receiving-ip / receiving-mx-hostname triplet every TLS-handshake-attempt produces — the SAME triplet the PTR/FCrDNS check on THIS page validates at the SMTP-connection layer one protocol step EARLIER. The PTR-RDNS-FEEDS-TLS-RPT-RECEIVING-MX-HELO cross-reference establishes four specific PTR-to-TLS-RPT correlation points the FCrDNS triage workflow consumes: (i) the receiving-mx-helo JSON field captures the EHLO hostname the receiving MTA presented during the failed TLS handshake — the SAME EHLO hostname the PTR check on THIS page recommends match the connecting-IP's PTR record per RFC 1912 §2.1; (ii) the receiving-ip JSON field is the connecting peer IP whose PTR record the sender-side FCrDNS check verifies; if the PTR-to-EHLO mismatch surfaces here, it is the SAME mismatch any Authentication-Results-line FCrDNS check would flag; (iii) the receiving-mx-hostname JSON field is the DNS-resolved MX target where the TLS handshake terminated — when the cert presented does NOT match this hostname, the failure surfaces as certificate-host-mismatch in the result-type enum (RFC 8460 §4.3), and PTR-record mis-publication on the sender-side MX is a common upstream cause; (iv) the sts-webpki-invalid result-type value indicates the cert subject didn't match the receiving-mx-hostname the MTA-STS policy declared — PTR-FCrDNS mismatches frequently precede these cert-validation failures in the diagnostic timeline. Read THIS page when triaging the SMTP-connection-layer PTR / FCrDNS identity check; read the TLS-RPT report-format spoke when reading the JSON report whose receiving-mx-helo / receiving-ip / receiving-mx-hostname triplet captures the SAME identity check at the TRANSPORT-LAYER protocol step after.
• MTA-STS vs DANE — the PTR-FCrDNS-IDENTITY-CHECK-AS- SIBLING-MX-LAYER-DISCIPLINE-TO-MTA-STS-VS- DANE-PROTOCOL-CHOICE companion reference. Where THIS page documents the PTR-FCrDNS publication discipline at the SMTP-CONNECTION-LAYER (the in-addr.arpa / ip6.arpa reverse-zone PTR-record publication, the forward- confirmed reverse-DNS check per RFC 1912 §2.1, the receiver-side enforcement disparity at Gmail / Yahoo / Microsoft 365 / hosted-MTA vendors, and the operator-publication discipline for the sending-side outbound MX), the MTA-STS-vs-DANE spoke documents the SIBLING MX-LAYER operator-discipline decision at the TRANSPORT-LAYER one protocol step LATER: the across-protocol comparison between MTA-STS and DANE as the operator's binary choice for receiver-side MX-hostname TLS-enforcement, sharing FOUR structural parallels with the PTR-FCrDNS discipline THIS page documents: (i) BOTH are MX-hostname- keyed receiver-side enforcement disciplines (PTR-FCrDNS keys on the connecting-IP PTR-record / EHLO-hostname match, MTA-STS keys on the policy-file mx: list / connecting-MX-hostname match, DANE keys on the _25._tcp.mx.<domain> TLSA-record fingerprint match); (ii) BOTH have a sender-side publication discipline AND a receiver- side enforcement disparity across major receivers (PTR-FCrDNS enforcement is non-uniform across Gmail / Yahoo / Microsoft 365 / hosted-MTA vendors; MTA-STS-vs-DANE enforcement-coverage also splits across the same receiver population — Gmail and Microsoft 365 enforce MTA-STS, German and Dutch receivers enforce DANE, many large receivers enforce BOTH); (iii) BOTH have a DNS-publication-syntax surface the operator MUST get right (PTR-record publication on the in-addr.arpa zone, MTA-STS publication on the _mta-sts.<domain> TXT record + /.well-known/mta-sts.txt policy file, DANE publication on the _25._tcp.mx.<domain> TLSA record under a DNSSEC-signed zone); (iv) BOTH produce per-failure forensic evidence at the TLS-RPT layer (the TLS-RPT JSON failure-details[] array captures BOTH PTR-FCrDNS mismatches AS certificate-host-mismatch result-type entries AND MTA-STS / DANE TLS-policy-failure events AS sts-webpki-invalid / tlsa-invalid / sts-policy-fetch-error result-type entries — the SAME report stream surfaces both layers' failures). Read the MTA-STS-vs-DANE spoke alongside this page when the PTR-FCrDNS triage workflow surfaces TLS-RPT certificate-host-mismatch or sts-webpki-invalid events — the transport-security protocol-choice and the PTR-FCrDNS publication discipline are sibling MX-layer disciplines and a complete MX-publication audit must verify BOTH.
• MTA-STS policy syntax — the PTR-FCrDNS-PUBLISHED-MX- HOSTNAME-AS-LOAD-BEARING-INPUT-TO-MTA- STS-POLICY-FILE-MX-ALLOW-LIST-AUTHORING- DISCIPLINE companion reference. Where THIS page documents the PTR-FCrDNS publication discipline at the SMTP- CONNECTION-LAYER (the in-addr.arpa / ip6.arpa reverse-zone PTR- record publication, the forward- confirmed reverse-DNS check per RFC 1912 §2.1, the receiver-side enforcement disparity at Gmail / Yahoo / Microsoft 365 / hosted-MTA vendors, and the operator-publication discipline for the sending-side outbound MX), the MTA-STS-policy-syntax spoke is the BYTE-SHAPE-OF-THE-POLICY- FILE-BODY reference documenting the RFC 8461 §3.2 line-grammar whose mx: hostname-pattern allow-list takes the PTR-FCrDNS- published forward-confirmed reverse-DNS hostname set as a load-bearing input. Four cross-layer coordination dimensions the spoke addresses: (1) mx: hostname-pattern enumeration vs PTR-published hostname set — the policy file's mx: allow-list MUST enumerate the SAME forward-confirmed reverse-DNS hostnames the operator publishes in the in-addr.arpa / ip6.arpa zones for the receive-side MX inventory, so that a receiver-side TLS handshake to the connecting MX host can verify BOTH the PTR-FCrDNS identity check AND the MTA-STS policy mx: allow-list match against the SAME hostname — a divergence between the PTR-published FCrDNS hostname and the policy file's mx: allow-list creates a receiver-side decision split where connection-layer PTR-FCrDNS passes but transport-layer MTA-STS rejects (or vice versa), surfacing in TLS-RPT as certificate-host-mismatch or sts-webpki-invalid result-type entries; (2) mode progression discipline coordinated with PTR-publication cadence — the operator's deployment cadence requires PTR records to be published FIRST (forward-confirmed reverse-DNS in both directions per RFC 1912 §2.1), THEN the MTA-STS policy published in mode: testing for the first 2-4 weeks so TLS-RPT aggregates surface per-receiver per-day PTR / MX / TLS-cert consistency failures WITHOUT blocking delivery, THEN the policy advanced to mode: enforce after both the PTR-FCrDNS-published forward- confirmed reverse-DNS check AND the TLS-RPT failure rate fall below the operator's risk threshold — the spoke documents the per-mode behaviour difference at sender-MTA enforcement time and the cross-layer sequencing with PTR-publication; (3) max_age cache-TTL choice coordinated with PTR-record TTL — the operator's receive-MX-inventory-rollover cadence (adding a new receive-MX with a fresh PTR-FCrDNS publication, rotating an MX hostname behind a load-balancer FQDN, DR-failover MX substitution with PTR re-publication on the failover IP) determines the max_age: seconds value the publisher chooses — the spoke documents the cache-TTL bounds-check RFC 8461 §3.2 imposes; (4) _mta-sts.<domain> TXT-record id= versioning coordinated with PTR-publication cutover — the policy file body changes (a new mx: hostname added because a new receive- MX was provisioned WITH a matching PTR-FCrDNS publication, a mode: flip, a max_age: tightening) must be paired with an id= bump in the _mta-sts.<domain> TXT-record so sending-MTAs respecting the policy detect the change and invalidate their cached copy at next-fetch opportunity — the spoke documents the id=-keyed cache-invalidation contract sending- MTAs implement against the policy file body. Read the MTA-STS-policy- syntax spoke alongside this page when coordinating PTR-FCrDNS publication with MTA-STS policy publication — the PTR-published forward-confirmed reverse-DNS hostname set is the load-bearing input the policy file body's mx: allow-list MUST agree with before the receive- side MTA-STS enforcement-coverage guarantee RFC 8461 §3.2 byte-grammar delivers can be declared consistent with the connection-layer identity check THIS page documents.
• Email authentication glossary — defines PTR, FCrDNS, in-addr.arpa, ip6.arpa, and the other vocabulary terms used on this page.
• SPF DNS-record syntax — the RFC-7208-§5.5-SPF-ptr- MECHANISM-DEPRECATION-AS-DEPRECATED- COUNTERPART-TO-RECEIVER-SIDE-FCrDNS- CONNECTION-FILTERING companion to this PTR / reverse-DNS reference. Where THIS page documents the per-receiver FCrDNS-verification discipline that runs at the SMTP-connection- establishment phase (per RFC 1912 §2.1 + RFC 5321 §4.1.1.4), the SPF DNS- record syntax spoke documents the per-domain v=spf1 TXT-RR byte-grammar within which the RFC 7208 §5.5 SPF ptr-mechanism deprecation is the per-mechanism publication-discipline anchor. The four-axis DEPRECATED-SPF-ptr-vs- PERSISTENT-FCrDNS parallel-dimension comparison exposes the structurally- distinct per-mechanism roles: (i) the RFC 7208 §5.5 SPF ptr-mechanism (per- message receiver-side reverse-DNS lookup chain that authorised envelope-MAIL-FROM senders based on the connecting IP's PTR hostname forward-resolving back to the authorised set) was EXPLICITLY DEPRECATED by the IETF as slow and brittle, so publishers MUST NOT include ptr in per-domain v=spf1 TXT-RR publication — whereas the per- receiver-side FCrDNS connection- filtering gate this page documents PERSISTS as an independent IP- identity-validation primitive that every major mailbox provider runs at SMTP-connection-establishment BEFORE per-message SPF / DKIM / DMARC evaluation — the SPF DNS-syntax spoke documents the per-domain v=spf1 TXT-RR publication-byte-grammar within which the ptr-mechanism deprecation rationale is formalised; (ii) per- domain v=spf1 TXT-RR publication-byte-grammar (the 255-octet character-string- fragmentation rule, the "exactly one SPF record per scope" rule, the publication- mode commitment -all / ~all) is the per- publisher per-domain DNS- publication primitive that survives the ptr-mechanism deprecation by being explicitly DOMAIN-SCOPED rather than IP- SCOPED, whereas per-publisher per-connecting-IP PTR publication (this page's canonical IPv4 <reversed-octets>.in-addr.arpa / IPv6 nibble-reversed ip6.arpa encoding) is the per-connecting-IP DNS- publication primitive that runs INDEPENDENT of the per- domain SPF policy — the SPF DNS-syntax spoke documents the per-domain v=spf1 publication-discipline that every PTR-publishing operator coordinates ALONGSIDE the per- connecting-IP PTR-RR publication-discipline THIS page documents, with the two DNS-publication primitives materialising at structurally- distinct DNS SCOPES (per- connecting-IP reverse-zone vs per-domain forward-zone) and structurally-distinct publication-discipline contracts (per-IP PTR as receiver-side connection- filtering-input vs per-domain SPF TXT-RR as receiver-side per-message authentication- policy-input); (iii) per-publisher per- connecting-IP PTR publication couples the per-IP DNS identity to the per-MX-host SPF-authorised set via the per-domain v=spf1 TXT-RR's mx: / a: / ip4: mechanism choice — the publisher's decision to publish a custom per-sending-IP PTR matching the per-domain SPF-authorised-hostname-set is the per-publisher per- sending-IP-identity-and- authentication-policy alignment discipline both protocols' receiver-side evaluation reward at the reputation-scoring layer (Gmail Postmaster Tools SENDER REPUTATION score improves when per-IP PTR hostname matches per-domain SPF-authorised-hostname set) — the SPF DNS-syntax spoke documents the per-domain v=spf1 TXT-RR byte-grammar within which the operator's mx: / a: / ip4: mechanism-choice determines whether the per-sending-IP PTR-vs-SPF alignment surface this page documents is even operationally available; and (iv) per- publisher per-domain SPF v=spf1 TXT- RR publication-mode commitment (-all hard- fail vs ~all soft-fail vs ?all neutral) is the per- domain publisher commitment the receiver-side SPF evaluator consumes at per-message evaluation, STRUCTURALLY PARALLEL to the per-connecting-IP PTR publication this page documents as the per-IP publisher commitment the receiver-side connection- filtering layer consumes at SMTP-connection- establishment — both are per-publisher publication-discipline commitments about how to handle deviation from the publisher's authentication policy, BUT at distinct DNS-publication scopes (per-connecting-IP PTR vs per-domain SPF TXT-RR) and distinct receiver-side evaluation phases (SMTP-connection- establishment vs per- message evaluation) — the SPF DNS-syntax spoke documents the per- publisher per-domain SPF publication-mode- commitment discipline every PTR-publishing operator must coordinate ACROSS the per-IP-vs- per-domain DNS-publication- scope boundary at the per-publisher authentication-policy- commitment layer. Read the SPF DNS-record syntax spoke BEFORE publishing a custom per- sending-IP PTR record documented on this page (audit the per-domain v=spf1 TXT-RR publication- byte-grammar AND the per-sending-IP PTR publication ALIGNMENT in the same change-set — the receiver-side reputation layer scores the alignment higher than uncoordinated publication), and when diagnosing a per-message DMARC failure whose root cause may be a per- domain SPF v=spf1 TXT- RR syntactic error DOWNSTREAM of a FCrDNS-pass-vs-FCrDNS- fail receiver-side connection-filtering gate THIS page documents the publication discipline for.
• DKIM DNS-record syntax — the DKIM-FORWARD-DNS-TXT-RECORD- PUBLICATION-DISCIPLINE-AS-LOAD-BEARING- SIBLING-DNS-PUBLICATION-DISCIPLINE-TO- REVERSE-DNS-PTR-PUBLICATION-DISCIPLINE-AT- FOUR-PER-DNS-RECORD-PUBLICATION- DIMENSIONS companion to this reverse-DNS PTR reference. Where THIS page documents the per-publisher per-IP reverse-DNS PTR- record publication discipline (the in-addr.arpa / ip6.arpa per-IP PTR-record FQDN, the forward- confirmed reverse-DNS [FCrDNS] bidirectional-match discipline, the per- IP PTR-record byte-grammar, the per- publisher upstream-provider PTR provisioning-lag discipline), the DKIM- DNS-record-syntax spoke is the FORWARD- DNS TXT-record-publication-discipline sibling reference documenting the per- publisher per-selector publication discipline at FOUR per-DNS-record- publication dimensions: (i) per- publisher per-name FQDN publication- location discipline — DKIM at <selector>._domainkey.<d-tag> per RFC 6376 §3.6.1 vs PTR at <reversed-IP>.in-addr.arpa / <reversed-IP>.ip6.arpa per RFC 1035 / 8499 — the DKIM- DNS-record-syntax spoke documents the per-publisher per-selector forward-DNS FQDN publication-location discipline STRUCTURALLY PARALLELING the per- publisher per-IP reverse-DNS FQDN publication-location discipline this page documents; both are per-publisher per- name FQDN-publication primitives the receiver-side authentication / connection- filtering / reputation pipeline consumes by NAME LOOKUP at the canonical location; (ii) per-publisher per-record byte-grammar discipline — DKIM tag-list byte-grammar (v=DKIM1; k=rsa; p=<base64>; h=sha256; t=y) per RFC 6376 §3.6.1 vs PTR-record byte- grammar (the FQDN-formatted hostname result per RFC 1035 §3.3.12) — the DKIM-DNS-record-syntax spoke documents the tag-list TXT-record byte- grammar discipline (255-octet character- string-fragmentation, semicolon- delimited tag-value pairs, tag-order independence, whitespace-tolerance) STRUCTURALLY PARALLELING the per- publisher per-IP PTR-record-byte-grammar discipline this page documents (canonical FQDN form, single-label-per-octet format, terminating-dot publication); both are per-publisher per-record DNS-record- byte-format publication-discipline primitives; (iii) per-publisher per-record cryptographic-anchor / identity- anchor publication-discipline — DKIM p=<base64-encoded-public-key> as the per-selector cryptographic-anchor forward-DNS publication primitive vs PTR <hostname> as the per- IP identity-anchor reverse-DNS publication primitive whose FCrDNS-pass receiver-side discipline THIS page documents — the DKIM-DNS- record-syntax spoke documents the per-selector cryptographic-key publication primitive whose receiver- side validation is the canonical message-layer authentication gate STRUCTURALLY PARALLELING the per-IP hostname publication primitive whose receiver-side FCrDNS validation is the canonical transport-layer connection- filtering gate this page documents; both are per-publisher per-record DNS- published identity / cryptographic-anchor publication-discipline primitives the receiver-side authentication pipeline consumes; (iv) per-publisher per-record publication-propagation-lag discipline — DKIM per-selector DNS TTL- bounded cache-invalidation propagation delay vs PTR per-IP upstream-provider rDNS-provisioning propagation delay (often 24-72 hours between PTR-update ticket-submission and receiver-side visibility) — the DKIM- DNS-record-syntax spoke documents the per-selector publication-propagation- lag discipline (TTL-bounded DNS cache- invalidation, per-resolver propagation- timing variance, the per-rotation overlap-window discipline for old-and- new selector parallel publication) STRUCTURALLY PARALLELING the per-IP PTR-record publication-propagation-lag discipline this page documents (upstream- provider PTR-provisioning ticket- turnaround, per-IP rDNS cache-staleness, per-receiver FCrDNS-lookup-cache invalidation timing). Read the DKIM- DNS-record-syntax spoke when publishing a per-publisher per-selector <selector>._domainkey.<d-tag> forward-DNS TXT-RR ALONGSIDE a per- publisher per-IP PTR-RR FCrDNS-pass publication this page documents — both are per-publisher DNS-record-publication- discipline primitives the receiver-side authentication pipeline consumes at message-layer vs transport-layer gates, and the receiver-side composite verdict depends on BOTH per-record publication disciplines being operationally coordinated by the same publisher.
• SPF mechanism comparison: include vs ip4 vs a vs mx — the RFC-7208-§5-PER-MECHANISM- EVALUATION-CATALOGUE-AS-LOAD-BEARING- PER-SOURCE-IP-FORWARD-DNS-RESOLUTION- COUPLING-TO-PER-SOURCE-IP-REVERSE- DNS-FCRDNS-PUBLICATION-DISCIPLINE companion to this PTR-RR / FCrDNS pillar reference. Where THIS page documents the per-publisher per-source- IP in-addr.arpa / ip6.arpa PTR-RR publication discipline (the per-MTA FCrDNS forward-confirmation invariant, the EHLO-PTR-coherence invariant, the per-egress-shard PTR- RR uniformity coordination, the per-source-IP identity-attribution primitive every receiver consults at the IP-routing layer), the include_ vs_ip4_vs_a_vs_mx spoke documents the structurally-coupled per-RFC- 7208-§5-mechanism-choice catalogue at FOUR per-mechanism-choice-vs- PTR-RR-publication-coordination dimensions: (i) per- publisher a: mechanism AS LOAD-BEARING per-source-IP- forward-A-RR-resolution PRIMITIVE whose receiver-side evaluation produces the per-source-IP-forward- DNS-confirmation half of the FCrDNS validation THIS page documents on the reverse-DNS side — the per-publisher a:<hostname> SPF mechanism's per-message receiver- side evaluation resolves the per- source-IP forward-A-RR for every message claiming origin from that hostname; the include_vs_ip4_vs_a_ vs_mx spoke documents this per- mechanism forward-DNS-resolution discipline whose forward-half is the structural twin of the per-source-IP PTR-RR reverse-DNS-resolution discipline THIS page documents on the FCrDNS validation pipeline; (ii) per-publisher mx: mechanism AS LOAD- BEARING per-source-IP-forward-MX- RR-then-A-RR-resolution PRIMITIVE whose per-MX-host forward-A-RR set IS the canonical per-MX-host PTR- RR publication-target inventory the operator must maintain forward-and-reverse coherence across — the per-publisher mx: mechanism's per- message receiver-side evaluation resolves the per-publisher MX-RR set then per-MX-host forward-A-RR set; the include_vs_ip4_vs_a_vs_ mx spoke documents the per-mx- mechanism per-MX-host forward- resolution discipline whose per-MX-host-IP set IS the canonical PTR-RR-publication- target inventory THIS page documents the per-MX-host PTR-RR FCrDNS-pass invariant across; (iii) per-publisher deprecated ptr: mechanism's RFC-7208-§5.5- DEPRECATION as load-bearing STRUCTURAL CONSEQUENCE OF per- publisher per-source-IP PTR-RR- based SPF-mechanism evaluation being EXPLICITLY DEPRECATED in favour of forward-DNS-based mechanism evaluation — RFC 7208 §5.5 deprecates the ptr: mechanism even though per-source-IP PTR-RR publication remains operationally critical for FCrDNS validation on the IP-routing layer; the include_vs_ip4_vs_a_vs_mx spoke documents the RFC-7208-§5.5- deprecation invariant whose receiver-side semantic IS the structural complement to the per-source-IP PTR-RR FCrDNS publication-discipline THIS page documents — the deprecated SPF-mechanism does NOT obsolete the IP-routing-layer PTR-RR discipline; (iv) per- publisher ip4: / ip6: mechanism LITERAL-CIDR PUBLICATION AS LOAD-BEARING per-source-IP- identity-publication PRIMITIVE WHOSE forward-publication MUST coordinate with per-source-IP PTR-RR reverse-publication for FCrDNS-pass at the IP-routing layer — the per- publisher ip4:<CIDR> / ip6:<CIDR> literal-CIDR mechanisms publish per-source-IP authorization without forward-A-RR resolution; the include_vs_ip4_vs_a_vs_mx spoke documents the per-literal- CIDR forward-publication discipline whose every per- source-IP in the CIDR must have a coordinated PTR-RR reverse- publication for FCrDNS-pass at the IP-routing layer THIS page documents. Read the include_vs_ ip4_vs_a_vs_mx spoke alongside this PTR-RR / FCrDNS pillar reference whenever the per- publisher operator scopes a per-publisher per-source-IP forward-and-reverse-DNS publication-discipline plan — the per-RFC-7208-§5-mechanism- catalogue the spoke documents IS the canonical UPSTREAM forward-DNS-publication primitive whose per-source-IP forward-half MUST be coordinated with the per-source-IP PTR-RR reverse-half THIS page documents for FCrDNS-pass at the IP- routing layer.
• Domain Security Checker — live DNS lookup tool that surfaces the PTR on the resolved MX target IP and reports FCrDNS status.
• Blacklist Checker — queries the major RBLs against the sending IP; PTR is necessary but not sufficient for IP reputation.
• Email Header Analyzer — parses Received: chains to identify the connecting IP and the EHLO hostname; useful for diagnosing PTR / FCrDNS mismatches.
• Business Email Compromise (BEC) — the PTR-FCrDNS-AS-IP-IDENTITY- LAYER-BEC-CAMPAIGN-DELIVERY-REPUTATION- FILTER companion to this reverse-DNS-PTR publication-discipline reference. Where THIS page documents the per-publisher per-IP PTR / FCrDNS publication-and- verification discipline (PTR resource- record byte-anatomy at <reversed-octets>.in-addr.arpa, the FCrDNS forward-confirmed reverse-DNS cross-check, the receiver-side PTR-on- connect reputation evaluation, the SPF ptr mechanism RFC 7208 §5.5 deprecation, the bidirectional FQDN-to- IP-and-back symmetry requirement), the business-email-compromise spoke documents the canonical BEC financial-fraud-attack- category catalogue (six canonical variants per FBI IC3 USD 2.9B reported 2023 loss + USD 55B+ cumulative since 2013) and the per-variant defense-in- depth control stack whose IP-IDENTITY- LAYER FOUNDATION is the PTR/FCrDNS publication discipline THIS page documents — at four PTR-to-BEC-financial-fraud- campaign-delivery coupling dimensions: (i) PTR-missing-or-generic-default as BEC-delivery-reputation-flag at major mailbox-provider receivers — BEC campaign infrastructure frequently relies on transient sender-IPs that lack the FCrDNS-symmetry discipline THIS page documents (no PTR, generic provider-default PTR like 123-45-67-89.unknown.example.com, or asymmetric forward-vs-reverse lookup); major mailbox-provider receivers (Gmail / Yahoo / Microsoft 365 / Mail.ru / AOL) treat the missing/generic/asymmetric PTR as a strong negative reputation signal at the SMTP-connect boundary, structurally filtering BEC-campaign-delivery before the message-layer DKIM/SPF/DMARC gate is even evaluated; (ii) PTR-as-receiver- side-IP-identity-attribution input for BEC-incident-response forensics — the BEC incident-response playbook the spoke documents (finance / treasury team notification + wire-transfer recall + SAR filing + FBI IC3 reporting) relies on the per-connecting-IP per-source PTR-FCrDNS identity-attribution evidence THIS page's publication-discipline produces to correlate BEC-campaign sender-IPs back to attacker-controlled hosting infrastructure across multiple in-the-wild BEC campaigns; (iii) PTR-hostname-as-cousin- domain-detection input for BEC-lookalike- impersonation defense — BEC attackers frequently register cousin- domains for executive-impersonation purposes (acme-corp.example vs acme-c0rp.example); the per-connecting-IP PTR hostname THIS page's publication-discipline produces is the load-bearing receiver-side evidence the BEC defense-in-depth-control-stack consumes to detect cousin-domain hosting patterns (multiple cousin-domains resolving to the same PTR-hostname, or to PTR-hostnames sharing the same ASN / network-segment); (iv) PTR-FCrDNS-publication- discipline as per-publisher per-IP BEC- defense outbound-reputation hygiene primitive — the per-publisher outbound-IP PTR-FCrDNS-publication discipline THIS page documents is the load-bearing per-publisher per-IP reputation-hygiene primitive that DIFFERENTIATES the publisher's legitimate outbound mail-stream from the BEC- campaign-delivery infrastructure at the per-receiver per-connection reputation- evaluation boundary; absent this PTR-FCrDNS publication discipline, the publisher's own legitimate outbound mail can be mis-attributed to BEC-campaign-delivery patterns by reputation-scoring algorithms. Read the BEC spoke ALONGSIDE this reverse- DNS-PTR publication-discipline reference whenever the per-publisher per-IP outbound- reputation posture is being scoped for BEC- financial-fraud-campaign-defense coverage — the PTR/FCrDNS publication discipline THIS page documents IS the IP-IDENTITY- LAYER primitive the BEC defense-in-depth- control-stack the BEC spoke documents structurally consumes at every per- connecting-IP receiver-side reputation evaluation.
• DMARC attacker-bypass techniques (defender's red-team catalogue) — the MISSING-OR-FORGED-PTR-AND- FCrDNS-FAILURE-AS-LOAD-BEARING-SOURCE-IP- IDENTITY-LAYER-ATTACKER-BYPASS-VECTOR companion to this reverse-DNS PTR + FCrDNS reference. Where THIS page documents the per-publishing-IP PTR-publication discipline (in-addr.arpa / ip6.arpa delegation chain, RFC 1912 §2.1 per-IP-PTR-publication requirement, RFC 5321 §4.1.1.4 EHLO-vs-PTR coherence, FCrDNS forward-confirmed reverse-DNS round-trip verification), the DMARC-attacker-bypass spoke is the OPERATOR- SIDE 22-technique attacker-bypass classification framework whose SOURCE-IP- IDENTITY-LAYER-IMPERSONATION technique class consumes the per-publishing-IP missing-PTR and forged-PTR misconfigurations at FOUR PTR-misconfiguration-to-IP-identity-attacker- bypass-exploitation dimensions: (i) missing-PTR attacker exploitation via per-publishing-IP identity-absence ambiguity — the attacker sends mail from infrastructure whose per-source-IP PTR is unpublished or empty, exploiting the per-publisher per-domain DMARC- aggregate-report per-source-IP-attribution evidence-row vocabulary's reliance on the per-source-IP PTR-resolution result to attribute the per-source-IP-organisational- identity, producing per-receiver per- source-IP per-day aggregate-report rows with empty or unresolvable per-source-IP identity attribution that the SOC analyst CANNOT pivot to specific operator-side remediation — the attacker- bypass spoke documents this as the canonical missing-PTR attacker-bypass class the per-publishing-IP RFC 1912 §2.1 PTR- publication discipline THIS page documents protects against; (ii) forged-PTR attacker exploitation via attacker- controlled in-addr.arpa delegation — the attacker controls the in-addr.arpa delegation chain for the per-source-IP sub-block (typically via compromised ISP-side reverse-DNS-management interface OR via the attacker's own AS-controlled IP allocation) and publishes a forged PTR pointing at a legitimate-looking hostname masquerading as a trusted ESP, exploiting per-receiver per-source-IP reputation- model evaluation that consumes the per- source-IP PTR as a load-bearing per- source-IP reputation-attribution primitive — the attacker- bypass spoke documents this as the canonical forged-PTR attacker-bypass class the FCrDNS forward-confirmed-reverse-DNS verification discipline THIS page documents protects against; (iii) FCrDNS- verification-bypass attacker exploitation via partial-control of forward-and-reverse- DNS — the attacker controls BOTH the in-addr.arpa delegation chain AND the forward-DNS A/AAAA record for the legitimate-looking hostname the forged PTR points at, producing FCrDNS- verification-pass-but-misattributed- identity at per-receiver per-source-IP reputation evaluation, the most dangerous per-source-IP identity-layer attacker- bypass class because it survives BOTH the PTR-resolution check AND the FCrDNS round-trip verification — the attacker-bypass spoke documents this as the canonical FCrDNS-bypass attacker- bypass class requiring per-publishing-IP operator-side rDNS-zone-control verification + per-source-IP reputation-score-floor layered defense; (iv) EHLO-vs-PTR- incoherence attacker exploitation via per- publishing-IP EHLO-rewriting at SMTP- connection establishment — the attacker exploits the per-publishing-IP EHLO-vs-PTR coherence-absence to send mail from infrastructure whose EHLO announces a legitimate-looking hostname distinct from the per-source-IP PTR- resolved hostname, exploiting per- receiver SMTP-receive-side reputation- model evaluation that consumes EHLO-vs- PTR coherence as a load-bearing per- source-IP connection-establishment-layer reputation primitive — the attacker-bypass spoke documents this as the canonical EHLO-vs-PTR-incoherence attacker-bypass class the RFC 5321 §4.1.1.4 EHLO-vs-PTR coherence discipline THIS page documents protects against. Read the DMARC-attacker-bypass spoke ALONGSIDE this reverse-DNS PTR + FCrDNS reference when designing the per-publisher per- domain per-source-IP-identity-layer- attacker-bypass-defense posture and when investigating per-receiver per-source-IP per-day aggregate-report evidence rows with anomalous per-source-IP identity- attribution patterns — the spoke is the canonical 22-technique attacker- bypass classification framework whose source-IP-identity-layer-impersonation technique class consumes the per- publishing-IP PTR-misconfiguration primitives this page documents.
• TLS-RPT explained — the canonical protocol-layer TLS-RPT reference whose per-receiver per-publisher per-day aggregate JSON evidence stream consumes the per-source-IP IN-ADDR.ARPA reverse- zone PTR-RR publication discipline THIS page documents at four PTR-RR- publication-to-TLS-RPT-receiver- attribution resolution dimensions: (i) the per-source-IP FCrDNS forward-confirmed-reverse-DNS publication discipline is the canonical load-bearing per-source- IP identity-attribution input into the per-receiver per-publisher TLS-RPT JSON policy-block per-source-IP TLS-handshake- attribution row — receivers attribute per-source-IP TLS- handshake failures to a publisher organisational domain via the per-source-IP FCrDNS-confirmed PTR-RR identity, then aggregate the per-source-IP per-day tls-rpt failure rows into the per-receiver per-publisher per-day summary-block JSON report THIS PTR-RR-publication- discipline reference IS the canonical publisher-side prerequisite for; (ii) the per- source-IP EHLO-PTR-coherence discipline (receivers compare the SMTP EHLO/HELO-presented identity against the per-source-IP PTR-RR FQDN at TLS handshake time) is the canonical load-bearing per- source-IP per-TLS-handshake identity-coherence input into the per-receiver per-publisher TLS-RPT JSON failure-details block — per-source-IP EHLO-PTR-mismatch outcomes flow into per-receiver per-source-IP certificate-host-mismatch and certificate-not-trusted failure-type rows the TLS-RPT operator triages via the per- source-IP PTR-RR identity published per THIS page's discipline; (iii) the per-source- IP NXDOMAIN-or-SERVFAIL reverse-zone-PTR-resolution outcome is the canonical load- bearing per-source-IP per-TLS- handshake-attempt attribution-failure input into the per-receiver per-publisher TLS-RPT JSON certificate-not-trusted / validation-failure / dns-error failure-type rows — receivers emit per-source-IP TLS-handshake- anomaly rows when the per-source- IP PTR-RR resolution fails the FCrDNS forward-confirmation check, and the per-receiver per-day TLS-RPT JSON-aggregate report the publisher consumes IS the downstream evidence stream THIS PTR-RR-publication- discipline reference IS the canonical publisher-side prerequisite for; and (iv) the per-publisher per-egress-shard PTR-RR-publication-discipline- uniformity coordination (uniform per-source-IP organisationally-attributable PTR-RRs across primary mailbox + transactional ESP + marketing ESP + per-acquired domain Mergers and Acquisitions integration egress paths) is the canonical load-bearing per- publisher portfolio-wide publisher-side discipline the per-receiver per-publisher TLS-RPT JSON-aggregate per- egress-shard attribution infrastructure depends on for per-egress-shard operationally-meaningful per-day per-failure-type evidence-row attribution. Read the TLS-RPT spoke ALONGSIDE this reverse-DNS-PTR reference whenever the publisher scopes a per-publisher per-source-IP TLS-transit-observability coordination plan — the per-source-IP PTR-RR publication discipline THIS page documents IS the load- bearing publisher-side identity-attribution prerequisite the per-receiver per-publisher per-day TLS-RPT JSON-aggregate evidence stream the TLS-RPT spoke documents the per-receiver emission discipline of structurally consumes.
• SPF mechanisms explained — the RFC-7208-§5-CATALOGUE-WITH-THE-§5.5-DEPRECATION-OF-THE-ptr-MECHANISM companion to this reverse-DNS-PTR-RR-publication reference — the RFC-7208-§5-CATALOGUE- WITH-THE-§5.5-DEPRECATION-OF-THE- ptr-MECHANISM companion to this reverse-DNS-PTR-RR-publication reference. Where THIS page documents the per-source-IP per-egress-shard reverse-DNS PTR-RR publication discipline as the canonical load-bearing publisher- side identity-attribution prerequisite for the per-receiver per-publisher per-day TLS-RPT JSON-aggregate per-egress-shard evidence stream the per-publisher consumes, the spf_mechanisms_ explained spoke documents the ORTHOGONAL RFC 7208 §5 SPF MECHANISM CATALOGUE in which the per-source-IP PTR-RR publication appears once as the ptr mechanism the RFC 7208 §5.5 deprecation guidance catalogues as the canonical SPF- mechanism the per-publisher SHOULD NOT publish — making the spf_ mechanisms_explained spoke the canonical RFC 7208 §5 SPF-side primary-source reference for the ONLY SPF context the per-source-IP PTR-RR publication infrastructure THIS page documents intersects with the per-publisher SPF- publication discipline. FOUR structurally-distinct PER-SOURCE-IP- PTR-RR-PUBLICATION-VS-PER-RFC-7208- §5-MECHANISM-CATALOGUE-INTERACTION dimensions the per-publisher per- source-IP PTR-RR publication discipline THIS page documents structurally requires the per- publisher operator to coordinate with the per-publisher SPF- mechanism authoring discipline the spoke catalogues at: (i) per-publisher ptr-mechanism ABSENCE-FROM-PER-PUBLISHER-SPF- RECORD AS LOAD-BEARING-PER- PUBLISHER-RFC-7208-§5.5-DEPRECATION- COMPLIANCE-INVARIANT-DESPITE-PER- SOURCE-IP-PTR-RR-PUBLICATION- DISCIPLINE — the per- publisher per-source-IP PTR-RR publication discipline THIS page documents (FCrDNS forward- confirmation + EHLO-PTR-coherence + per-egress-shard PTR-RR uniformity) is operationally NECESSARY for per- receiver-side per-source-IP identity-attribution; the spf_ mechanisms_explained spoke documents the per-publisher SPF- record-publication discipline of EXCLUDING the ptr mechanism token per RFC 7208 §5.5 SHOULD-NOT-BE-USED guidance — the two disciplines coexist (per- source-IP PTR-RR publication for identity-attribution + zero ptr-token in SPF record for §5.5 deprecation compliance) at the per-publisher DNS-publication level; (ii) per-publisher per-source-IP PTR-RR publication AS LOAD-BEARING- FCrDNS-FORWARD-CONFIRMATION-INPUT- TO-PER-RECEIVER-MTA-PER-MESSAGE- PRE-DATA-PHASE-VALIDATION-PARALLEL- TO-PER-PUBLISHER-SPF-a- OR-mx-MECHANISM- AUTHORIZATION — the per- receiver-side per-message pre-DATA FCrDNS forward-confirmation that validates the per-source-IP PTR-RR publication THIS page documents runs in per-receiver evaluation parallel to the per-publisher SPF a / mx / ip4 / ip6 mechanism-authorization the spf_ mechanisms_explained spoke catalogues: both produce a per- receiver per-source-IP per-message verdict the per-receiver-side anti-spam / MTA-validation pipeline consumes simultaneously; (iii) per-publisher per-egress- shard PTR-RR publication AS LOAD- BEARING-PER-PUBLISHER-PER-EGRESS- SHARD-IDENTITY-ATTRIBUTION- INFRASTRUCTURE-PARALLEL-TO-PER- PUBLISHER-PER-ENVELOPE-DOMAIN-SPF- PUBLICATION-PARTITIONING — the per-publisher per-egress- shard PTR-RR publication coordination THIS page documents (primary mailbox + transactional ESP + marketing ESP + M&A integration egress paths) is the per-publisher per-egress-shard identity-attribution discipline operating in per-publisher coordination with the per- envelope-domain SPF-publication partitioning the spf_mechanisms_ explained spoke catalogues (per- envelope-domain SPF-mechanism token-stack authoring per-shard); (iv) per-publisher per- source-IP PTR-RR publication AS LOAD-BEARING-PER-SOURCE-IP- ATTRIBUTION-INPUT-TO-PER-RECEIVER- EXISTS-MECHANISM-EVALUATION — the per-publisher exists: mechanism the spf_mechanisms_explained spoke catalogues per RFC 7208 §5.6 can be MACRO-EXPANDED with per-source- IP-PTR-derived data at per-receiver- side evaluation-time; the per- publisher per-source-IP PTR-RR publication THIS page documents is a load-bearing per-source-IP attribution-input to the per- publisher exists: macro-expansion evaluation the spf_mechanisms_explained spoke documents at the per-mechanism evaluation-semantic level. Read the spf_mechanisms_explained spoke ALONGSIDE this reverse-DNS- PTR-RR-publication reference whenever the per-publisher per- source-IP PTR-RR publication discipline THIS page documents intersects with the per-publisher RFC 7208 §5 SPF-mechanism- authoring discipline — the spoke is the canonical RFC 7208 §5 PER- MECHANISM CATALOGUE REFERENCE with the canonical RFC 7208 §5.5 ptr-mechanism- deprecation rationale the per- publisher per-source-IP PTR-RR publication infrastructure THIS page documents operationally coexists with at the per- publisher SPF-record-publication discipline level.
• DMARC for cPanel-hosted domains — the PER-CPANEL-WHM-MANAGED- VPS-AND-DEDICATED-SERVER companion to this reverse-DNS- PTR-RR-publication reference. Where THIS page documents the per-source-IP in-addr.arpa reverse-zone PTR-RR publication discipline (the per-IP X.X.X.X.in-addr.arpa owner-name format, the FCrDNS-forward-confirmation coherence requirement, the EHLO- PTR-coherence per-mail-source invariant, the NXDOMAIN / SERVFAIL receiver-side attribution-failure outcomes), the dmarc_for_cpanel spoke documents the per-cPanel-WHM- managed-VPS infrastructure whose WHM Cluster + rDNS authorization + Hostname configuration interface IS the canonical load- bearing per-tenant PTR-RR- publication authority the per- publisher per-source-IP PTR-RR publication discipline THIS page documents resolves to at the per-cPanel-managed-server deployment boundary. FOUR structurally-distinct PER-CPANEL- WHM-INTERFACE-VS-PTR-RR- PUBLICATION-STAGE-COUPLING- DIMENSIONS the dmarc_for_cpanel spoke operationally documents: (i) per-cPanel-WHM "Hostname" → fully-qualified- domain-name configuration coordinated with hosting- provider-managed X.X.X.X.in-addr.arpa PTR-RR publication AS LOAD- BEARING-PER-VPS-IP-IDENTITY- ATTRIBUTION-PRIMITIVE — cPanel/WHM exposes the canonical per-server Hostname field (Configuration → Server Configuration → Change Hostname) whose FQDN MUST match the per- source-IP PTR-RR-published hostname for FCrDNS-forward- confirmation coherence; the dmarc_for_cpanel spoke documents the canonical WHM Hostname configuration discipline + the per-hosting-provider PTR-RR- update support-ticket workflow (DigitalOcean, Linode, Hetzner, OVH, AWS Lightsail each expose a per-customer PTR-RR-update interface) the per-source-IP PTR-RR publication THIS page's FCrDNS coherence discipline depends on at the per-cPanel- VPS deployment boundary; (ii) per-cPanel-WHM "Exim Configuration Manager" → SMTP- banner-hostname coordinated with per-source-IP PTR-RR-published hostname AS LOAD-BEARING-EHLO- PTR-COHERENCE-PRIMITIVE — Exim's SMTP banner + EHLO/HELO hostname is set from the WHM Hostname field; per- source-IP PTR-RR-published hostname divergence from the Exim EHLO/HELO hostname violates the EHLO-PTR coherence invariant THIS page's per-mail-source EHLO- PTR-coherence discipline catalogues; the dmarc_for_cpanel spoke documents the canonical per-cPanel-WHM Exim Configuration Manager → SMTP-banner-hostname synchronization with the WHM Hostname field + with the hosting-provider PTR-RR- published hostname every per- source-IP EHLO-PTR-coherence outcome THIS page's coherence- check discipline depends on at the per-cPanel-VPS deployment boundary; (iii) per- cPanel-WHM Multi-IP "Reseller IP Delegation" + per-account dedicated-IP assignment coordinated with per-source-IP PTR-RR-publication AS LOAD- BEARING-PER-RESELLER-PER- ACCOUNT-IP-ATTRIBUTION-PRIMITIVE — cPanel/WHM resellers + multi-IP deployments expose per-account dedicated-IP assignment interfaces; per- dedicated-IP PTR-RR publication attributes the per-source-IP outbound mail-stream to the per-reseller per-account organizational-identity the receiver-side reverse-DNS-lookup debugger pivots on; the dmarc_ for_cpanel spoke documents the canonical WHM IP Functions → IP-Migration-Wizard + Reseller Center → IP-Delegation workflow coordinated with the hosting- provider PTR-RR-update workflow the per-reseller per-account per-dedicated-IP PTR-RR publication THIS page's per- source-IP identity-attribution discipline depends on at the per- cPanel-multi-IP-VPS deployment boundary; (iv) per- cPanel-WHM "Tweak Settings" → "send mail from account's dedicated IP address" toggle coordinated with per-account per-source-IP PTR-RR-published- hostname AS LOAD-BEARING-PER- ACCOUNT-OUTBOUND-EGRESS- ATTRIBUTION-DISCIPLINE-PRIMITIVE — cPanel's per-account dedicated-outbound-IP toggle binds the per-account outbound mail-stream to a single dedicated source-IP whose PTR- RR-published hostname IS the per- account identity the receiver- side aggregate-report XML per-row <source_ip> element resolves back to via receiver-side reverse-DNS lookup; the dmarc_for_cpanel spoke documents the canonical per- account dedicated-outbound-IP + per-account PTR-RR-published- hostname coordination discipline every per-account per-source-IP identity-attribution outcome THIS page's per-publisher per- source-IP attribution discipline depends on at the per-cPanel- VPS-multi-account deployment boundary. Read the dmarc_for_ cpanel spoke ALONGSIDE this reverse-DNS-PTR-RR-publication reference whenever a per-cPanel- WHM-managed-VPS-or-dedicated- server operator scopes a per- source-IP PTR-RR-publication deployment plan — the per-cPanel- WHM Hostname + Exim Configuration + Reseller IP Delegation + Tweak Settings stack THIS deployment spoke documents IS the canonical load-bearing per-cPanel-managed- server infrastructure every per- source-IP PTR-RR-publication outcome THIS page's reverse-DNS- publication discipline depends on at the per-server deployment boundary.
• SPF forwarding issues (the second-hop break) — the SPF-FORWARDING-BREAK-AS-CANONICAL- DOWNSTREAM-CONSUMER-OF-PER-FORWARDER-IP- PTR-RR-PUBLICATION-DISCIPLINE companion to this reverse-DNS-PTR-RR-publication reference. Where THIS page documents the per-publisher per-source-IP PTR-RR publication discipline (RFC 1035 PTR-RR byte syntax, in-addr.arpa / ip6.arpa zone delegation, forward-confirmed rDNS / FCrDNS reciprocal lookup discipline, per-source-IP per-mailbox-provider reputation evaluation inputs), the SPF-forwarding-issues spoke is the FORWARDER-HOP-IDENTITY-LAYER consumer companion documenting how the per-forwarder per-source-IP PTR-RR publication discipline THIS page architectures is itself re-evaluated at every forwarder hop where envelope-rewriting causes the receiver-side SPF evaluator to authenticate against the forwarder's source-IP rather than the original publisher's source-IP. The reverse-DNS-vs-SPF- forwarding-issues relationship is per-source- IP-identity-layer-correctness-at-every-hop: at the original-publisher hop, the per-publisher source-IP PTR-RR-publication discipline is load-bearing for the publisher's first-hop reputation evaluation; at every forwarder hop where envelope-rewriting occurs (Return- Path: rewriting via SRS, .forward / Sieve forwarders, MLM list-expansion), the forwarder's own per-source-IP PTR-RR-publication discipline is load-bearing for the second-hop receiver-side SPF evaluation against the forwarder's source-IP. Four per-forwarder-IP- rDNS-vs-SPF-forwarding-break coupling dimensions matter at the forwarder-hop- identity-layer-correctness boundary: (i) per-forwarder per-source-IP forward-confirmed rDNS (FCrDNS) publication discipline — when the forwarder's per-source-IP A/AAAA forward record AND in-addr.arpa / ip6.arpa PTR record reciprocally match, the per-forwarder- IP-identity at the second hop authenticates consistently and the second-hop SPF evaluation against the forwarder's source-IP proceeds against a verified identity; (ii) per-forwarder per-source-IP SRS (Sender Rewriting Scheme) envelope-MAIL-FROM rewriting coordination with PTR-RR publication — the SRS-rewritten envelope-MAIL-FROM at the forwarder hop must align with the forwarder's per-source-IP PTR-RR publication so the second-hop SPF evaluation reaches an SPF=pass outcome against the forwarder's rewritten identity; (iii) per-forwarder per-source-IP reputation evaluation at downstream mailbox- provider receive-side as gated on PTR-RR publication discipline — even when the second-hop SPF evaluation passes against the forwarder's source-IP, the per-mailbox- provider reputation evaluation inputs (Gmail / Microsoft Outlook / Yahoo / Apple iCloud) all require the forwarder per-source- IP PTR-RR-publication discipline THIS page architectures to be valid for the forwarder- delivered message to reach the per-recipient inbox; (iv) per-forwarder ARC sealer adoption coordination with PTR-RR publication — when the forwarder cryptographically commits the original-publisher SPF verdict through the AAR header per RFC 8617, the forwarder's own per-source-IP PTR-RR-publication discipline determines whether the forwarder qualifies as a per-receiver per-trusted-sealer-list- eligible operator at the second-hop ARC chain- validation boundary. Read THIS page when AUTHORING the per-publisher per-source-IP PTR- RR-publication discipline at the in-addr.arpa / ip6.arpa zone-delegation layer; read the SPF- forwarding-issues spoke when DIAGNOSING the canonical second-hop forwarder-induced SPF- fail scenario whose receiver-side per-source- IP reputation evaluation is gated on the per- forwarder-IP PTR-RR-publication discipline.
• MTA-STS explained — the PER-RECEIVER-PER-MX-HOST-FCrDNS- PUBLICATION-DISCIPLINE-AS-UPSTREAM- PREREQUISITE-OF-THE-MTA-STS-MX-ALLOW- LIST-ENFORCEMENT-CONTRACT companion to this reverse-DNS/PTR/FCrDNS publication discipline reference. Where THIS page documents the per-publisher per- connecting-IP PTR/FCrDNS publication discipline at the DNS-foundation layer whose receiver-side connection- filtering gate runs at SMTP-connection- establishment phase, the MTA-STS- explained pillar documents the RFC 8461 transport-layer TLS-enforcement-policy whose per-publisher policy-file mx: allow-list enforcement is STRUCTURALLY DEPENDENT on every per- receiver per-MX-host's FCrDNS publication discipline at four cross- layer FCrDNS-vs-MTA-STS-enforcement coupling dimensions: (i) per- receiver per-MX-host FCrDNS-pass as upstream prerequisite for MTA-STS certificate-host-match enforcement — sending MTAs honoring MTA- STS mode: enforce require the receiver-side MX-hostname to forward-resolve and reverse-resolve consistently; per-MX-host PTR publication discipline is the receiver-side prerequisite for the sending-MTA STARTTLS-with-cert- validation decision producing certificate-host-match=pass TLS-RPT result-type; per-receiver per- MX-host FCrDNS misconfiguration surfaces as certificate-host- mismatch in TLS-RPT JSON- aggregate evidence the publisher receives; (ii) per-publisher mx: allow-list pattern consistency with per-receiver per-MX- host FCrDNS-published hostname set — the policy-file mx: allow-list lines enumerate per-receiver MX hostnames whose underlying connecting-IP per-MX-host PTR publication MUST agree with the glob pattern; divergence between publisher-pinned mx: pattern and receiver-side FCrDNS- published PTR hostname creates per- sending-MTA delivery-rejection at the MTA-STS-enforce boundary; (iii) per-connecting-IP-pool PTR publication discipline at receiver- side MX-IP pool as cross-layer load- bearing input to the transport-layer TLS-handshake — shared-IP- pool tenancy (cloud-hosted MX infrastructure on AWS / GCP / Azure / Cloudflare) requires per-tenant per-MX-host coordination with IP- owner registrar to publish PTR records that forward-resolve to per- tenant MX hostname AND match the per-tenant TLS certificate SAN; per- tenant FCrDNS gap is upstream root- cause of per-tenant MTA-STS- enforcement-failure surfacing in certificate-host-mismatch TLS-RPT rows; and (iv) per- sending-MTA-IP PTR publication discipline as forensic-attribution primitive for MTA-STS-enforce rejection root-cause analysis — when sending-MTA delivery fails at the MTA-STS-enforce boundary, the publisher's TLS-RPT JSON-aggregate sending-mta-ip field requires per-sending-MTA-IP PTR- resolvable FCrDNS-pass hostname for operator-readable root-cause attribution; per-sending-MTA-IP PTR publication discipline is the cross- layer attribution primitive translating opaque transport-layer rejection evidence into operator-actionable sending-tenant identity for the per- rejection root-cause analysis workflow. Read the MTA-STS-explained pillar alongside this reverse-DNS/PTR publication-discipline reference when co-deploying per-publisher per-domain transport-layer TLS-enforcement publication and per-receiver per-MX- host DNS-foundation FCrDNS publication across the per-publisher per-domain authoritative DNS zone and IP-owner per-IP reverse-DNS publication boundary.
• SPF PermError vs TempError Four PTR-vs-SPF-error-mode coupling dimensions: (i) per-publisher per-domain SPF ptr-mechanism evaluation as load-bearing rDNS-cascade consumer producing permerror when rDNS infrastructure fails — RFC 7208 §5.5 ptr-mechanism evaluation requires the receiver-side evaluator to perform a per-source-IP reverse-DNS lookup, then a forward-DNS lookup against the returned PTR target, and the per-IP forward-confirmed reverse DNS (FCrDNS) validation discipline determines whether the SPF evaluator returns pass (FCrDNS confirmed) or permerror (PTR lookup chain broken); the ptr-mechanism is deprecated by RFC 7208 §5.5 BUT remains a per-publisher SPF-record-publication footgun at legacy authoring sites, where the PTR-RR publication discipline THIS page documents is the load-bearing rDNS-infrastructure substrate the SPF ptr-mechanism evaluation depends on; (ii) per-source-IP rDNS validation cascade producing transient temperror from receiver-side resolver outages — per-receiver-side DNS-resolver outages against the per-source-IP rDNS endpoint produce per-message spf=temperror verdicts in the per-receiver Authentication-Results header (and downstream per-publisher per-receiver per-day RUA stream), and the per-receiver retry-behaviour is governed by the per-IP rDNS RR TTL and per-receiver resolver-cache discipline THIS page documents the per-IP-owner publication baseline of; (iii) per-publisher per-domain SPF macro-expansion %{p} (PTR macro) producing permerror from per-IP rDNS publication-discipline violation — the per-publisher SPF-record macro-expansion %{p} token expands to the per-source-IP rDNS validated FCrDNS hostname, and per-IP rDNS publication-discipline violation (missing PTR / non-matching forward DNS / generic-rDNS pattern) at the per-IP-owner boundary produces per-receiver spf=permerror verdicts when the macro-expansion cannot resolve to an FCrDNS-validated target; (iv) per-source-IP rDNS publication discipline as per-receiver SPF-evaluator-side anti-abuse query-throttling determinant producing cross-tenant temperror amplification — when per-receiver SPF evaluators detect per-IP rDNS publication-discipline drift (generic patterns, no-PTR, mismatched forward DNS) at scale, they apply per-IP anti-abuse query-throttling against the per-publisher per-domain SPF-record DNS endpoint, producing cross-tenant spf=temperror amplification at the per-receiver evaluator boundary that the per-publisher per-domain operator must coordinate diagnosis for. Read the SPF-permerror-vs-temperror spoke alongside this reverse-DNS/PTR reference when investigating per-publisher per-domain RUA-attributed spf=permerror/temperror rows correlating with per-source-IP rDNS publication-discipline gaps, when auditing per-publisher per-domain SPF-record macro-expansion %{p}/%{i} evaluation discipline against the per-IP-owner rDNS publication baseline, or when authoring per-publisher per-domain SPF-error-mode diagnosis runbooks coordinating per-IP rDNS publication discipline against per-receiver per-message SPF-evaluator behaviour.
• DMARC reporting pipeline — the PER-SOURCE-IP-RDNS-PTR-RR-PUBLICATION- AS-PER-PUBLISHER-PER-DOMAIN-RUA-AGGREGATE- XML-PER-SOURCE-IP-PER-RECORD-ROW-ATTRIBUTION- BASELINE companion to THIS reverse-DNS/PTR reference. Where THIS page documents the per-IP-owner per-source-IP reverse-DNS PTR-RR publication discipline (the per-IP in-addr.arpa/ip6.arpa PTR-RR publication at the IP-owner authoritative-DNS zone, the per-IP forward- confirmed reverse DNS FCrDNS validation baseline, the per-IP rDNS generic-pattern- vs-specific-hostname publication-discipline floor, the per-IP rDNS publication coordination with per-publisher per-domain forward-DNS A/AAAA-RR publication), the DMARC-reporting-pipeline spoke documents the per-publisher per-domain RFC 7489 §7 RUA aggregate-XML ingestion-and-parsing pipeline (per-receiver per-day per-publisher per-domain RUA aggregate-XML stream consumed at the rua=mailto:- published endpoint, per-record per-source- IP per-disposition row dedup, per-receiver- organisation per-day per-publisher per- domain attribution storage) through which the per-source-IP rDNS publication discipline materially renders as per- publisher per-domain per-receiver per-day per-source-IP attribution disambiguation evidence at FOUR per-source-IP-rDNS-vs- DMARC-reporting-pipeline coupling dimensions: (i) per-publisher per- domain RUA aggregate-XML per-source-IP per- record row attribution as load-bearing per- source-IP rDNS-baseline-resolved disambiguation evidence — every per-receiver per-day per-publisher per- domain RUA aggregate-XML report's per- record row captures the per-source-IP attribution at the row/source_ip XML element, and the per-publisher per-domain operator resolves the per-source-IP attribution against the per-IP-owner rDNS PTR-RR publication baseline THIS page documents to ATTRIBUTE the per-source-IP to specific per-tenant per-publisher per-domain legitimate-mail-flow sources (per-tenant ESP, per-tenant marketing platform, per- tenant transactional-mailer) vs per- attacker per-source-IP mail-flow sources — without the per-source-IP rDNS PTR-RR publication baseline, per-source-IP attribution remains opaque in the per- publisher per-domain RUA aggregate-XML report-stream; (ii) per-publisher per-domain RUA aggregate-XML per-source-IP per-record row attribution correlated against per-IP FCrDNS validation as per- receiver per-day per-publisher per-domain sender-reputation-attribution evidence — per-receiver per-publisher per-domain reputation-attribution at major receivers (Gmail / Yahoo / Microsoft) consumes per- source-IP rDNS FCrDNS-validation evidence at the per-receiver per-message Authentication-Results header boundary, and the per-receiver per-day per-publisher per-domain RUA aggregate-XML report's per- source-IP per-record row distribution attributes per-message disposition outcomes to per-source-IP rDNS FCrDNS-validation states the per-publisher per-domain operator MUST audit against the per-IP- owner rDNS publication baseline; (iii) per-publisher per-domain RUF forensic-report per-message per-source-IP per-failure-reason attribution as per- source-IP rDNS-baseline-violation root- cause attribution evidence — when per-receiver per-day per-publisher per- domain RUA aggregate-XML report-attributed per-source-IP per-record row disposition regression correlates with per-source-IP rDNS publication-discipline drift (missing PTR-RR, generic-rDNS-pattern, mismatched forward DNS), the per-publisher per-domain RUF forensic-report stream THE DMARC-reporting-pipeline spoke ingests provides per-message per-source-IP per- failure-reason attribution evidence the per-publisher per-domain operator needs to attribute disposition regression to specific per-source-IP rDNS publication- discipline root causes; (iv) per- publisher per-domain DMARC reporting- pipeline ingestion-discipline-floor as per- source-IP rDNS-baseline-evolution observability surface — the per- publisher per-domain operator reads per- receiver per-day per-publisher per-domain RUA aggregate-XML report-stream rolling- window per-source-IP per-record row distribution to observe per-source-IP rDNS publication-baseline evolution (new IP- owner per-source-IP rDNS PTR-RR publication deployment, existing IP-owner per-source-IP rDNS publication-discipline drift, per- source-IP mail-flow re-routing across different rDNS-published IP pools) at the per-publisher per-domain operator- discipline forecast boundary the per-IP- owner per-source-IP rDNS publication- discipline THIS page documents materially coordinates against. Read THIS reverse-DNS/ PTR reference when AUDITING per-IP-owner per-source-IP rDNS PTR-RR publication discipline AND when COORDINATING per- publisher per-domain mail-flow per-source- IP attribution against per-IP rDNS baseline; read the DMARC-reporting-pipeline spoke when OPERATING the per-publisher per-domain RUA-and-RUF aggregate-and-forensic-report ingestion-and-parsing discipline against per-source-IP rDNS-publication-baseline disambiguation evidence THIS page documents.
• CAA records explained — the structurally parallel per-publisher per-domain DNS-publication-discipline companion to this reverse-DNS PTR publication-discipline reference. Where THIS page documents the per-IP per-publisher reverse-DNS PTR publication discipline at the per-publisher per-arpa-zone commit-and- propagation boundary, the CAA-records spoke documents the structurally parallel per- publisher per-domain CAA RR publication discipline at the per-publisher per-domain- zone commit-and-propagation boundary — both are per-publisher DNS-publication-discipline primitives gating per-receiver-side verification-pipeline evaluation.
• DMARC forensic reports
• MTA-STS for Microsoft 365 — the PER-M365-TENANT-PER-CUSTOM- DOMAIN-MTA-STS-DNS-AND-HTTPS-PUBLICATION- AS-STRUCTURALLY-PARALLEL-REVERSE-DNS-PTR- PUBLICATION companion to this reverse-DNS PTR reference. Where THIS page documents the per-publisher per-IP per-egress-MX- hostname reverse-DNS PTR-RR publication discipline (per-IP PTR-RR authoring, forward-confirmed-reverse-DNS verification, per-egress-MX-hostname publication consistency), the M365 MTA-STS spoke is the PER-M365-TENANT TRANSPORT-LAYER DNS- PUBLICATION reference structurally parallel to the per-publisher per-IP reverse-DNS publication discipline at the per-publisher composite DNS-publication-portfolio coordination floor. Four per-publisher DNS- publication-discipline parallel coupling dimensions: (i) PER-M365-TENANT-MTA-STS- TXT-RR-PUBLICATION-VS-PER-IP-REVERSE-DNS- PTR-RR-PUBLICATION (per-M365-tenant _mta-sts TXT-RR publication discipline is structurally parallel to per-publisher per-IP in-addr.arpa / ip6.arpa PTR-RR publication discipline — both are per-publisher DNS-zone-authored RR-publication primitives whose receiver-side fetch is required for per-receiver-side evaluation pipeline operation); (ii) PER-M365-TENANT-MTA-STS- HTTPS-POLICY-FILE-VS-PER-IP-FORWARD- CONFIRMED-REVERSE-DNS-VALIDATION (per-M365- tenant HTTPS-served policy-file is structurally parallel to per-IP forward- confirmed-reverse-DNS validation — both are receiver-side validation prerequisites for per-publisher publication readiness); (iii) PER-M365-TENANT-MTA-STS- DUAL-CHANNEL-COORDINATION-VS-PER-PUBLISHER- FORWARD-AND-REVERSE-DNS-COORDINATION (per- M365-tenant MTA-STS requires BOTH DNS TXT- RR AND HTTPS policy-file publication for receiver-side acceptance — structurally parallel to per-publisher per-IP forward- confirmed-reverse-DNS coordination requiring BOTH per-IP A/AAAA + per-IP PTR publication to validate); (iv) PER-M365-TENANT-MTA-STS- PUBLICATION-FAILURE-VS-PER-IP-REVERSE-DNS- PTR-PUBLICATION-FAILURE-AS-PARALLEL- DELIVERABILITY-EROSION (per-M365-tenant MTA-STS publication breakage erodes per- publisher per-MX-host inbound delivery from STARTTLS-aware senders — structurally parallel to per-publisher per-IP PTR publication breakage eroding per-publisher per-IP outbound deliverability against receiver-side anti-spam filters requiring FCrDNS). Read the M365 MTA-STS spoke alongside this reverse-DNS PTR guide when AUTHORING the per-publisher composite DNS- publication-portfolio coordination discipline, when AUDITING per-publisher per- MX-host both reverse-DNS PTR and per-tenant MTA-STS publication readiness, or when INVESTIGATING per-publisher composite deliverability regressions correlating with either DNS-publication-discipline breakage.
• MTA-STS for Google Workspace — the Workspace-tenant twin of the M365 MTA-STS reference above: the Workspace-tenant dual-channel publication discipline (DNS TXT-RR at _mta-sts.<workspace-domain> + HTTPS-served policy file at https://mta-sts.<workspace-domain>/.well-known/mta-sts.txt) whose per-tenant DNS-publication-discipline component is structurally parallel to the per-publisher per-IP per-egress-MX-hostname reverse-DNS PTR-RR publication discipline this page documents. Both are operator-owned DNS-zone publication obligations the sending side must keep current; a stale PTR and a stale MTA-STS TXT-RR both degrade transport-time trust at the receiver before any application-layer auth is evaluated.
• Why SPF alone is insufficient
• DMARC for transactional-email senders — the per-egress-IP-pool-PTR-RR- publication-vs-per-transactional-stream- DMARC-ramp coordination companion to this reverse-DNS PTR-RR publication pillar. Where THIS page documents the per-publisher per-IP reverse-DNS PTR-RR publication discipline (the <reversed-IP>.in-addr.arpa PTR-RR-to-hostname mapping per RFC 1035 §3.3.12, the FCrDNS forward-confirmed reverse-DNS check sequence per RFC 1912 §2.1, the per-receiver EHLO- banner-vs-PTR-vs-forward-A consistency-check sequence), the transactional-email spoke documents the per-publisher per-transactional- stream DMARC ramp at which per-egress-IP- pool PTR-RR hygiene IS the load-bearing infrastructure-layer trust-baseline anchor. Four coupling axes connect them: (i) per- egress-IP-pool PTR-RR publication discipline (every transactional-ESP egress-IP MUST resolve PTR-RR → matching forward-A) IS pre-condition for receiver-side trust- baseline acceptance gating per-stream reputation-floor preservation — transactional-stream warm-up cadence depends on per-IP-pool PTR-RR hygiene before high- volume bursts emit; (ii) per-IP-pool PTR-RR publication-discipline parallel to per-stream DKIM-Signature publication-discipline at DISTINCT cryptographic-infrastructure layers (infrastructure-layer DNS PTR-RR + application-layer DKIM TXT-RR) JOINTLY drive transactional-stream reputation-floor preservation; (iii) per-egress-IP HELO/EHLO- banner-matches-PTR-matches-forward-A discipline drives per-receiver per-mailbox- provider (Gmail, Yahoo, Microsoft) 2024 Bulk-Sender-Requirements composite floor satisfaction — mis-published per- egress-IP PTR-RR collapses the composite floor regardless of per-stream DKIM-aligned- pass / SPF-pass evidence-row presence; (iv) per-egress-IP-pool warm-up cadence for transactional bursts MUST be coordinated with DMARC enforcement-mode ramp progression — cold-IP pools sending high-volume transactional bursts under per-publisher per-domain DMARC p=reject IS a self-inflicted per-IP-pool reputation- collapse vector at the receiver-side trust- baseline-vs-policy-tier interaction boundary. Read the transactional-email spoke alongside this reverse-DNS PTR-RR pillar when AUTHORING per-egress-IP-pool PTR-RR publication discipline at transactional-ESP onboarding, when AUDITING per-IP-pool FCrDNS hygiene ahead of high-volume burst emission, or when PLANNING per-stream DMARC enforcement-mode ramp sequencing against per-IP-pool warm-up cadence.
• DKIM selectors explained — the PER-PUBLISHER-PER-SELECTOR-DKIM- TXT-RR-PUBLICATION-DISCIPLINE-AS- STRUCTURALLY-PARALLEL-DNS-PUBLICATION- DISCIPLINE-COMPANION-TO-PER-PUBLISHER-PER- EGRESS-IP-PTR-RR-PUBLICATION-DISCIPLINE companion to this reverse-DNS PTR-RR / FCrDNS pillar at four per-publisher per-selector-vs-per-egress-IP DNS- publication coupling dimensions: (1) the <selector>._domainkey.<domain> TXT-RR application-layer publication is structurally parallel to the <reversed-octets>.in-addr.arpa PTR-RR reverse-DNS publication per RFC 1035 §3.5 — both are per-publisher per- infrastructure-resource DNS publication- discipline references; (2) per-publisher per-egress-IP PTR-RR FCrDNS hygiene drives per-source-IP attribution per RFC 1912 §2.1 feeding per-receiver per-message DKIM- signing-MTA verdict-evaluator confidence which gates per-publisher per-selector DKIM-aligned-pass attribution at the per-receiver per-message authentication- evaluator boundary; (3) per-publisher per-selector DKIM key-rotation cadence coordinates with per-publisher per-egress- IP PTR-RR publication-cadence at the per-publisher composite-DNS-publication- discipline coordination boundary (selector rotation gating per-stream DKIM-aligned- pass leg, PTR-RR rotation gating per-egress FCrDNS leg); (4) DKIM dkim=permerror traceable to mis-published TXT-RR byte- grammar at <selector>._domainkey.<d> is structurally parallel to PTR-RR FCrDNS- mismatch traceable to mis-published reverse- DNS byte-grammar at <ip>.in-addr.arpa — both per-publisher per-publication-leg verdict-fail root-cause diagnostic ladders.
• DMARC monitoring
• DKIM replay attacks
• DKIM failures explained — the per-publisher per-selector per-message DKIM-verdict catalogue covering the full result-class taxonomy per RFC 8601 §2.7.1 (dkim=pass / fail / permerror / temperror / none / neutral / policy) plus the operator-side root-cause- attribution diagnostic ladder for each per- message verdict-fail-class (body-hash mismatch from forwarder body-rewrite or l=-tag overflow / signature-verification failure from key-mismatch or selector rotation drift / public-key-fetch temperror from DNS resolver- side TTL-expiry or transient-fail). The per- publisher per-egress-IP per-MX-host PTR-RR FCrDNS hygiene-validation evidence stream THIS reverse-DNS page documents the publication-discipline of IS per-receiver- side per-source-IP attribution-trustworthiness- evidence primitive that per-receiver per- day per-publisher per-domain DKIM-failure- verdict attribution analytics consume for per-publisher per-egress-IP per-MX-host DKIM-aligned-pass-rate floor regression triage at the per-publisher per-egress-IP- attribution-and-DKIM-application-layer- authentication-leg-verdict-attribution coordination boundary. Pair the PTR-RR publication-discipline this page documents (the per-source-IP attribution-evidence primitive) with the DKIM-failures verdict catalogue (the per-receiver per-message verdict-attribution-and-diagnostic-ladder reference) for the complete per-publisher per-domain per-egress-IP-PTR-RR-FCrDNS- hygiene-validation-feeds-per-receiver-per- day-DKIM-verdict-attribution-analytics cross-layer attribution-and-verdict- diagnostic-pipeline reference every per- publisher per-domain DKIM operator must understand at the per-publisher per-egress- IP per-receiver per-day per-message verdict-attribution-and-floor-preservation coordination boundary.
• DMARC multi-domain strategy
• SPF qualifiers explained — a sending IP's PTR/FCrDNS posture and the SPF all qualifier both decide how a receiver treats an unlisted source IP; a published -all hard-fail is the envelope-layer complement to a clean reverse-DNS record, so read the qualifier reference to make the SPF leg reject the same forged egress your PTR hygiene is meant to flag.
• DKIM signatures explained — a clean PTR/FCrDNS record establishes the sending IP's transport-connection-layer reputation, while the DKIM-Signature header documented there carries the cryptographic message-layer identity a receiver verifies independently of the connecting IP. Read the signature byte-layout reference to see the b=/bh=/d=/s= tags whose aligned dkim=pass survives the forwarding that detaches a message from the egress IP your reverse-DNS hygiene vouches for.
• DKIM for Microsoft 365 — the provider-specific message-layer-identity companion to this connection-layer reputation reference for mail sent from Microsoft 365. Where a clean PTR/FCrDNS record vouches for the connecting egress IP, the DKIM-for-M365 spoke documents the selector1/selector2._domainkey CNAME-delegated signing keys that carry the message-layer cryptographic identity a receiver verifies independently of the source IP. The two layers are complementary reputation signals an M365 tenant publishes in parallel: outbound Exchange Online IPs already carry Microsoft-managed PTR records, while the operator publishes the DKIM selector CNAMEs — read the DKIM-for-M365 spoke for the message-signature leg that pairs with the reverse-DNS hygiene this page documents.
• DMARC deployment checklist — valid reverse DNS is a sender-readiness item to settle before the checklist's enforcement phase. Many receivers down-rank or reject mail from sending IPs without a matching forward-confirmed PTR record, so the FCrDNS hygiene this page documents is part of the deliverability baseline a domain needs while it ramps to p=reject. Read the deployment checklist for the phased path this reverse-DNS step supports.
• DKIM canonicalization (relaxed vs simple c=) — forward-confirmed reverse DNS is one sender-readiness signal a receiver weighs at connection time; DKIM canonicalization governs whether the message-layer cryptographic identity survives transit once that connection is accepted. The c= choice (relaxed vs simple header/body) decides whether an intermediary's whitespace or MIME change quietly breaks the signature. Both contribute to the trust a receiver places in your mail — FCrDNS at the IP-reputation layer, an aligned dkim=pass at the message-authentication layer. Read it to round out the sender-readiness picture beyond the reverse-DNS hygiene this page covers.
• Microsoft SNDS + JMRP monitoring — PTR records are one half of IP-level sending hygiene; the other half is watching what Microsoft's consumer network thinks of that IP: SNDS filter verdicts, blocked ranges, and JMRP Junk-click complaints per address.

Key IETF references:

• RFC 1035 — Domain Names: Implementation and Specification — defines the PTR resource record type in section 3.3.12.
• RFC 1912 — Common DNS Operational and Configuration Errors — section 2.1 documents the operational requirement that every public IP SHOULD have a matching PTR.
• RFC 5321 — Simple Mail Transfer Protocol — sections 4.1.1.4 (EHLO expectations) and 5.1 (mail-delivery sequence) implicitly require receiver-side trust-baseline checks on every connecting SMTP client.
• RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — section 5.5 EXPLICITLY DEPRECATES the SPF "ptr" mechanism with "SHOULD NOT BE PUBLISHED" language.
• RFC 8499 — DNS Terminology — formalizes the vocabulary around PTR, in-addr.arpa, ip6.arpa, and the reverse-DNS terminology used by this page.
• DANE TLSA explained (RFC 7672) — the PER-MX-HOST-PTR-RR-AS-COORDINATING- WITH-PER-MX-HOST-DANE-TLSA-RR companion to this PTR-RR / FCrDNS pillar reference. Where THIS page documents the per-publisher per-MX-host in-addr.arpa / ip6.arpa PTR-RR FCrDNS publication-discipline (the per- MTA FCrDNS forward-confirmation invariant, the EHLO-PTR-coherence invariant, the per- egress-shard PTR-RR uniformity coordination, the per-source-IP identity-attribution primitive every receiver consults at the IP-routing layer), the DANE-TLSA-explained spoke is the RFC 7672 per-publisher per-MX- host DNSSEC-anchored transport-confidentiality reference whose per-MX-host TLSA-RR publication-discipline coordinates with the per-publisher per-MX-host PTR-RR publication-discipline THIS page documents at the per-MX-host transport-layer evaluation boundary. The PER-MX-HOST-PTR- RR-VS-PER-MX-HOST-DANE-TLSA-RR cross- reference establishes FOUR structurally- distinct per-publisher per-MX-host triple- DNS-publication coordination dimensions: (i) per-publisher per-MX-host forward-A-RR + per-MX-host-reverse-PTR-RR + per-MX-host-DANE-TLSA-RR triple-DNS- publication coordination AS LOAD-BEARING per-publisher per-MX-host operational- integrity discipline — the per-publisher per-MX-host triple-DNS-publication coordination is the per-publisher per- MX-host operational-integrity invariant the per-receiver-MTA's per-MX-host- identity-attribution-and-certificate- pinning evaluation pipeline depends on — the per-publisher per-MX-host forward- A-RR publication, the per-publisher per- MX-host PTR-RR FCrDNS publication, and the per-publisher per-MX-host DANE-EE- TLSA-RR publication together establish the per-publisher per-MX-host operational- integrity invariant; the DANE-TLSA- explained spoke documents the per-publisher per-MX-host TLSA-RR publication leg complementing the per-publisher per-MX- host PTR-RR FCrDNS publication leg THIS page documents; (ii) per-publisher per-MX-host FCrDNS forward-confirmation + per-MX-host DANE-EE-TLSA-pinning AS load-bearing per-publisher per-MX-host dual-layer per-receiver-MTA identity- validation primitive — per-receiver-MTA per-MX-host identity-validation pipeline consults BOTH per-MX-host PTR-RR FCrDNS AND per-MX-host TLSA-RR-pinned-certificate as load-bearing dual-layer evaluation primitives — the per-receiver- MTA per-MX-host identity-validation pipeline at the SMTP-connect IP-routing layer (per-MX-host PTR-RR FCrDNS forward- confirmation) AND at the SMTP-STARTTLS certificate-pinning layer (per-MX-host DANE-EE-TLSA-RR pinning) together provide per-receiver-MTA dual-layer per-MX-host- identity-validation; the DANE-TLSA- explained spoke documents the per-MX-host- DANE-EE-TLSA-pinning evaluation leg complementing the per-MX-host FCrDNS forward-confirmation evaluation leg THIS page documents; (iii) per-publisher per-MX-host PTR-RR rotation-cadence + per- MX-host DANE-EE-TLSA-RR rollover-cadence operational-coordination AS LOAD-BEARING per-publisher per-MX-host operational- discipline — both per-publisher per-MX- host DNS-publication rotation-cadences coordinate with the per-publisher per- MX-host operational-lifecycle (per-MX-host- IP renumber, per-MX-host certificate renewal, per-MX-host DNSSEC-key rollover) — the per-publisher per-MX-host PTR-RR rotation-cadence coordination with the per-publisher per-MX-host TLSA-RR rollover-cadence is a per-publisher per- MX-host operational-discipline requirement; the DANE-TLSA-explained spoke documents the per-MX-host TLSA-RR rollover-cadence operational-discipline coordinating with the per-MX-host PTR-RR rotation-cadence operational-discipline THIS page documents; (iv) per-publisher per-MX-host PTR-RR EHLO-coherence + per-MX-host DANE- EE-TLSA-RR subject-DN-vs-MX-host-name- coherence AS LOAD-BEARING per-publisher per-MX-host name-resolution-coherence operational-invariant — both per-publisher per-MX-host DNS-publication legs are anchored on the per-MX-host hostname- coherence invariant — the per- publisher per-MX-host PTR-RR EHLO-coherence invariant (per-MX-host reverse-DNS-name matching per-MX-host SMTP-EHLO-banner- announced hostname) and the per-publisher per-MX-host DANE-EE-TLSA-RR subject-DN- vs-MX-host-name-coherence invariant (per-MX-host TLSA-pinned-certificate subject-DN matching per-MX-host-name the per-receiver-MTA resolves at the per- MX-host RR lookup boundary) together establish the per-publisher per-MX-host name-resolution-coherence operational- invariant; the DANE-TLSA-explained spoke documents the per-MX-host subject-DN-vs- MX-host-name-coherence invariant complementing the per-MX-host PTR-RR EHLO-coherence invariant THIS page documents. Read the DANE-TLSA-explained spoke alongside this PTR-RR / FCrDNS pillar reference whenever the operator scopes a per-publisher per-MX-host triple- DNS-publication coordination plan — the per-publisher per-MX-host PTR-RR + per- MX-host DANE-EE-TLSA-RR coordination IS the canonical per-publisher per-MX-host operational-integrity discipline the per- receiver-MTA's per-MX-host identity- validation-and-certificate-pinning evaluation pipeline at the per-MX-host transport-layer evaluation boundary structurally depends on.
• BIMI certificates — another per-publisher DNS-and-PKI publication discipline a receiver evaluates, sitting at the brand-trust top of the stack rather than the IP-identity base this page anchors. Where the FCrDNS / PTR-RR discipline here establishes which IP a receiver trusts to connect, a Verified Mark Certificate (VMC) establishes which logo a receiver trusts to display — both are operator-published trust signals a receiver checks, and both presuppose the domain has already reached DMARC enforcement on a clean authentication posture. Read the BIMI certificates spoke to see how the verified-logo PKI layer complements the reverse-DNS identity layer in the receiver’s overall trust evaluation.

15. Audit your reverse DNS now

DMARC Analyzer's Domain Security Checker performs a live PTR lookup against every IP resolved from your MX, SPF, and sending-pool records (via includes/DnsChecker.php) and reports the PTR target, FCrDNS pass/fail status, TTL, and matching IP-reputation signals. Use it to confirm your mail-sending IPs are correctly configured for FCrDNS, that the PTR is not pointing at a generic provider hostname, and that IPv6 PTR is published if AAAA is present on the forward side. The Email Header Analyzer parses Received: chains from captured messages (via includes/EmailHeaderParser.php) so you can identify the exact connecting IP and EHLO hostname for an inbound message — the key inputs to a PTR / FCrDNS troubleshooting session.

Audit my mail-server reverse DNS Sign up — Free plan