The PTR Misconfiguration Epidemic: What Google's New DMARC Data Reveals

In mid-2025, Google quietly added a new data layer to DMARC aggregate reports: SMTP rejection data. Previously, DMARC aggregate reports showed only authentication results — which sources were signing with DKIM, whether SPF was passing, and whether DMARC was aligning. The new SMTP rejection data added something different: information about messages that were rejected at the SMTP level before authentication was even evaluated. When Al Iverson from Spam Resource and Valimail's Scott Ziegler were among the first practitioners to analyze this new data at scale, they discovered something surprising and alarming: a significant fraction of commercial email is being rejected because of PTR (reverse DNS) record misconfiguration — a problem that had been largely invisible because it manifests as SMTP-level rejection rather than authentication failure or spam folder placement.

Google's SMTP Rejection Data in DMARC Reports — The New Signal

DMARC aggregate reports (the XML files delivered to the rua= address in a DMARC record) were originally designed to show authentication results — specifically, whether email claiming to be from a domain passed or failed SPF, DKIM, and DMARC alignment checks. A DMARC aggregate report historically showed you the disposition (delivered, quarantined, rejected) and authentication results for email claiming to be from your domain, but only for email that made it past initial SMTP-level rejections. Email rejected at the connection level — before the DATA command — never appeared in DMARC aggregate reports at all.

Google's mid-2025 extension to DMARC reporting changed this for Gmail-bound traffic. Google began including SMTP rejection data in their aggregate reports — information about connections that were rejected before authentication evaluation, along with the rejection reason codes. This data was, in effect, a window into a category of email failure that had been completely invisible in standard DMARC monitoring: connection-level rejections that never generated any data visible to the sender.

The first practitioners to systematically analyse this new data — Valimail's team and Al Iverson at Spam Resource — found something unexpected: a substantial volume of commercial email was being rejected by Gmail at the connection level, before authentication was even checked. And the dominant reason for these rejections was not authentication failure or reputation problems. It was PTR record misconfiguration — specifically, sending IP addresses that either had no PTR record or had a PTR record that did not resolve back to the sending IP in forward DNS (failed FCrDNS validation).

What the Data Actually Showed: A Hidden Epidemic

The SMTP rejection data from Google's extended DMARC reports revealed that PTR misconfiguration is not an edge case affecting a few poorly configured small senders. It is a widespread problem affecting email infrastructure that was previously functioning correctly — infrastructure that worked at the time it was configured but subsequently became misconfigured through a common failure mode that email operations teams consistently underestimate.

The pattern Iverson and colleagues identified: a domain name changes, but the DNS hostname associated with the sending IP's PTR record doesn't get updated. This sounds simple and easy to avoid, but in practice it happens constantly because the PTR record for a sending IP is controlled by the IP's hosting provider (not by the domain owner), and the PTR record update requires a coordinated change between the IP hosting provider and the DNS operator. When a company changes its email sending domain, its email service provider, or its DNS configuration, the PTR records for the sending IPs often do not get updated in sync with the other changes — because the PTR update requires contacting the hosting provider separately from the standard DNS management workflow.

The email infrastructure that was "working fine" before a sending domain change may be generating silent PTR-based rejections at Gmail after the domain change — and nobody notices because the rejection appears as a 5xx SMTP error in the MTA's accounting log (if anyone is watching), but generates no bounce notification to the original sender, no complaint report, no Postmaster Tools alert. The email simply fails to reach Gmail recipients without any visible signal to the sender that something is wrong.

Gmail's specific error code for PTR/FCrDNS failure is 550-5.7.25. If you see this error in your MTA accounting log or in an SMTP debug session, the sending IP's PTR record is either missing or failing FCrDNS validation. The Google Help page at support.google.com/a/answer/175365 documents this error code explicitly — "The sending IP must have a PTR record that points back to the sending hostname." This requirement is not new; Gmail has required PTR records for years. What is new is that the scale of this failure is now visible in DMARC aggregate reports for the first time.

Why PTR Misconfiguration Happens — The Infrastructure Change Problem

PTR records occupy an unusual position in email infrastructure: they are the only email authentication-related DNS record that is controlled by the IP address owner (the hosting provider) rather than the domain owner. An A record, MX record, TXT record (SPF, DKIM, DMARC) — all of these are in the domain's DNS zone and can be modified by whoever manages the domain's DNS. A PTR record lives in the reverse DNS zone operated by whoever owns the IP block — typically the hosting provider, ISP, or colocation facility.

This split ownership creates a coordination problem. When a company changes its email sending domain:

1. The company updates its DNS records (MX, SPF, DKIM, DMARC) — changes in its own DNS zone, immediate
2. The company updates its email service provider or MTA configuration — changes in software configuration, immediate
3. The company needs to update the PTR record for the sending IP — change in the hosting provider's reverse DNS zone — requires a support ticket, approval, and processing time that may be hours or days

Step 3 is almost always forgotten. The email infrastructure team knows about steps 1 and 2 and handles them as part of the domain change workflow. Step 3 is an afterthought that requires contacting a separate party (the hosting provider), and in the pressure of a domain migration or ESP switch, it gets skipped. The result: the sending IP continues to have the old PTR record (pointing to the old hostname or the old domain), which fails FCrDNS validation against the new sending hostname in the EHLO/HELO command.

A second common cause: IPv6 addresses being added to the sending pool without PTR records configured. Many hosting providers assign IPv6 addresses without configuring PTR records by default — the customer must request PTR record configuration separately. If new IPv6 sending addresses are added without corresponding PTR records, all email sent from those IPv6 addresses fails the PTR check at Gmail and increasingly at other ISPs that enforce the same requirement.

PTR, FCrDNS, and EHLO: The Complete Technical Picture

Understanding the PTR validation chain requires understanding how Gmail (and other ISPs) validate sending IP identity during an SMTP connection:

# What happens during an SMTP connection to Gmail:

# Step 1: Sending MTA connects to Gmail's MX server
# Gmail records the connecting IP: 203.0.113.10

# Step 2: Sending MTA issues EHLO command
EHLO mail.brand.com
# Gmail records the claimed hostname: mail.brand.com

# Step 3: Gmail performs PTR lookup (reverse DNS)
# dig -x 203.0.113.10
# Expected result: mail.brand.com

# Step 4: Gmail performs forward DNS lookup (FCrDNS)  
# dig A mail.brand.com
# Expected result: 203.0.113.10

# FCrDNS validation passes if:
# IP 203.0.113.10 → PTR → mail.brand.com → A → 203.0.113.10
# The forward and reverse lookups form a matching pair

# FCrDNS validation FAILS if:
# IP 203.0.113.10 → PTR → NXDOMAIN (no PTR record)
# IP 203.0.113.10 → PTR → mail.olddomain.com → A → 203.0.113.10
#   (PTR exists but points to old hostname that doesn't match EHLO)
# IP 203.0.113.10 → PTR → mail.brand.com → A → 203.0.113.99
#   (PTR exists but forward lookup returns different IP)

# Gmail's response to FCrDNS failure:
# 550-5.7.25 The IP address sending this message does not have a PTR record 
# setup, or the corresponding forward DNS entry does not point to the sending
# IP. As a policy, Gmail does not accept messages from IPs with missing PTR
# records. Please visit https://support.google.com/mail/answer/175365 for more
# information. [SMTP code]

How to Identify PTR Problems in Your Infrastructure

The PTR audit for any commercial sending programme involves three steps: (1) identify all sending IPs, (2) verify PTR records for each IP, and (3) verify FCrDNS for each IP.

# Step 1: Identify all sending IPs
# From PowerMTA: grep "smtp-source-host" /etc/pmta/config
# From Postfix: look for "inet_interfaces" and network config
# From ESP: check the ESP's sending domain settings

# Step 2: Check PTR record for each IP
dig -x 203.0.113.10 +short
# Expected output: mail.brand.com.
# Problem output: (empty — no PTR record)
# Problem output: mail.olddomain.com. (old hostname)

# Step 3: Verify FCrDNS
# If PTR returns mail.brand.com, verify forward:
dig A mail.brand.com +short
# Expected output: 203.0.113.10
# Problem output: 203.0.113.99 (different IP — FCrDNS fails)

# Quick automated PTR check for multiple IPs:
for IP in 203.0.113.10 203.0.113.11 203.0.113.12; do
    PTR=$(dig -x $IP +short | tr -d '.')
    if [ -z "$PTR" ]; then
        echo "FAIL: $IP has no PTR record"
    else
        FORWARD=$(dig A $PTR +short)
        if echo "$FORWARD" | grep -q "$IP"; then
            echo "PASS: $IP → $PTR → $IP (FCrDNS OK)"
        else
            echo "FAIL: $IP → $PTR → $FORWARD (FCrDNS mismatch)"
        fi
    fi
done

Additional verification tool: MXToolbox's "Reverse Lookup" tool (mxtoolbox.com/ReverseLookup.aspx) provides both PTR lookup and FCrDNS validation in a browser-accessible interface without requiring command-line access. Mail-tester.com includes PTR/FCrDNS validation as part of its full email test — sending a test email through the target sending infrastructure to mail-tester.com and checking the report will surface PTR failures if present.

Reading the New SMTP Rejection Data in DMARC Reports

Google's extended DMARC aggregate reports include a new section that contains SMTP rejection data. The structure in the XML report:

<!-- Standard DMARC record (authentication result) -->
<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>5000</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <auth_results>...</auth_results>
</record>

<!-- New SMTP rejection record (Google extension) -->
<extension>
  <smtp_rejection>
    <source_ip>203.0.113.11</source_ip>
    <count>850</count>
    <smtp_error_code>550</smtp_error_code>
    <smtp_enhanced_status>5.7.25</smtp_enhanced_status>
    <smtp_rejection_reason>PTR record missing or invalid</smtp_rejection_reason>
  </smtp_rejection>
</extension>

<!-- The source_ip 203.0.113.11 is rejecting 850 messages per day 
     due to PTR failure -- this IP would be invisible in standard
     DMARC data because it never passes authentication evaluation -->

Most DMARC reporting tools (dmarcian, EasyDMARC, PowerDMARC) have begun incorporating this new SMTP rejection data into their reporting dashboards. Look for a "SMTP Rejection" or "Rejection Data" section in the DMARC reporting tool — if you see IP addresses appearing there that are not in your authenticated sends list, investigate whether these are your sending IPs or third parties attempting to spoof your domain with misconfigured infrastructure.

Fixing PTR Misconfiguration: Provider-Specific Guide

Fixing a PTR record requires contacting the IP address owner (the hosting provider) — you cannot change it yourself through your domain's DNS management interface. The process varies by provider:

AWS EC2 / Amazon: PTR records (Reverse DNS) can be set directly in the AWS console for Elastic IP addresses. EC2 console → Elastic IPs → select the IP → Actions → Update Reverse DNS. The reverse DNS hostname must be publicly resolvable to the IP. Amazon processes the change immediately after validation.

Hetzner (common for EU email infrastructure): Hetzner Server Cloud console → Servers → Networking → the IP → Reverse DNS. Enter the desired hostname. Hetzner processes PTR changes within minutes.

DigitalOcean: PTR records are set via the DigitalOcean control panel → Networking → Floating IPs or Droplets → Reverse DNS. Alternatively, naming the Droplet with the desired FQDN causes DigitalOcean to automatically configure the PTR record to match the Droplet name.

OVH / OVHcloud: OVH Control Panel → Server → IPs → Reverse → Configure. Enter the desired PTR hostname. OVH processes PTR changes within 24 hours.

Colocation / Dedicated servers: Open a support ticket with the colocation provider specifying the IP address and the desired PTR hostname. Processing time varies by provider, typically 24-72 hours.

For ESPs (Mailgun, SendGrid, Postmark): Sending IPs from managed ESPs typically have PTR records managed by the ESP. For shared IP pools, PTR records point to ESP infrastructure hostnames — no action needed. For dedicated IPs, contact the ESP's support team to ensure the PTR record for the dedicated IP reflects the correct hostname for the sender's domain.

Ongoing PTR Health Monitoring

PTR record monitoring should be added to the standard email infrastructure monitoring stack alongside blacklist checks and authentication monitoring. PTR records, unlike most DNS records, can break silently — the IP continues to send email, the MTA continues to inject messages, but Gmail silently rejects them at the connection level. Without active monitoring, PTR failures generate no visible alert.

Automated PTR monitoring: add all sending IPs to a monitoring script that runs the PTR + FCrDNS validation check daily and alerts on any failure. The script above (the bash PTR check for multiple IPs) is sufficient for monitoring purposes when run as a cron job with email alerting on failure. Commercial email infrastructure monitoring tools (MXToolbox Monitor, Validity Everest) also support PTR monitoring for enrolled IPs.

The DMARC SMTP rejection data provides the authoritative real-world signal: if Gmail's DMARC reports show SMTP rejections from a source IP, that IP has a PTR problem regardless of what direct PTR checks show (there can be edge cases where the PTR check passes locally but fails at Google's resolver due to propagation or caching differences). Treat DMARC SMTP rejection data for a sending IP as the highest-priority PTR investigation trigger.

The PTR misconfiguration epidemic, now visible through Google's extended DMARC data, is a concrete example of how email infrastructure monitoring that was sufficient in 2024 is insufficient in 2026. The new DMARC SMTP rejection data is a gift to email infrastructure operators who know how to read it — it surfaces failures that were completely invisible before and provides the evidence needed to identify, fix, and prevent one of the most common silent email delivery failures in commercial email infrastructure.