← RFC Reference

RFC 6652: SPF Authentication Failure Reporting

Why This Exists

SPF (RFC 7208) validates that a sending IP is authorized for the envelope sender domain. When SPF fails, it could mean:

• A spoofer is forging your domain
• A legitimate third-party sender (marketing platform, CRM) is missing from your SPF record
• A forwarding server is relaying your mail (breaking SPF alignment)
• Your SPF record has a syntax error or exceeds the 10-lookup limit

Without failure reports, you are blind to these events. DMARC aggregate reports (RFC 7489) give you daily summaries, but RFC 6652 provides per-message forensic reports specifically for SPF failures. These reports use the ARF format (RFC 5965) with the auth-failure feedback type extended by RFC 6591.

How It Works

The domain owner publishes a special DNS TXT record at _spf._report.<domain> that tells receivers where to send SPF failure reports.

DNS Record

; Request SPF failure reports be sent to this address
_spf._report.example.com.  IN TXT  "v=spf-report1; ra=spf-reports; rp=100; rr=all"

Record Fields

Example Failure Report (ARF Format)

From: arf-generator@receiver.example
To: spf-reports@example.com
Subject: SPF failure report for example.com
Content-Type: multipart/report; report-type=feedback-report;
    boundary="SPF-REPORT-001"

--SPF-REPORT-001
Content-Type: text/plain

SPF authentication failure report for a message
claiming to be from example.com.

--SPF-REPORT-001
Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: Receiver-MTA/2.0
Version: 1
Auth-Failure: spf
Authentication-Results: receiver.example;
    spf=fail smtp.mailfrom=example.com
Original-Mail-From: user@example.com
Source-IP: 198.51.100.50
Reported-Domain: example.com
Delivery-Result: reject

--SPF-REPORT-001
Content-Type: text/rfc822-headers

From: user@example.com
To: recipient@receiver.example
Subject: Important update
Message-ID: <msg-001@example.com>

--SPF-REPORT-001--

Key Technical Details

Auth-Failure Field Values for SPF

The Auth-Failure field distinguishes SPF reports from DKIM or DMARC failure reports that also use the auth-failure feedback type (defined in RFC 6591).

Relationship to DMARC Reporting

DMARC (RFC 7489) has its own reporting mechanism with two types:

• Aggregate reports (rua) — daily XML summaries of authentication results, sent to the address in the DMARC record.
• Forensic reports (ruf) — per-message failure reports. DMARC's forensic reports cover both SPF and DKIM alignment failures.

RFC 6652 reports are SPF-specific and independent of DMARC. In practice, most receivers generate DMARC aggregate reports (widely supported) but few generate RFC 6652 or DMARC forensic reports due to privacy concerns. However, where supported, RFC 6652 reports provide the most detailed per-failure data for SPF specifically.

Privacy Considerations

Failure reports may contain recipient addresses and message headers, raising privacy concerns. Many receivers limit what they include or do not generate these reports at all. The rp tag lets the domain owner request a percentage less than 100 to reduce report volume.

Common Mistakes

• Expecting widespread adoption. Very few receivers generate RFC 6652 reports in practice. Most SPF failure visibility comes from DMARC aggregate reports instead. Publish the reporting record, but do not rely on it as your only visibility into SPF failures.
• Not monitoring the reporting mailbox. If you publish a reporting address, monitor it. Unread reports provide no value. Parse them automatically or use a DMARC/SPF reporting service.
• Confusing with DMARC ruf reports. DMARC forensic (ruf) reports and RFC 6652 reports are separate mechanisms. Both use ARF format, but they are triggered by different records and may be generated by different receivers.
• Setting rp=100 on high-volume domains. For domains that send millions of messages, requesting 100% failure reporting can generate overwhelming volume. Start with a low percentage and increase as needed.
• Forgetting the _spf._report prefix. The DNS record must be at _spf._report.yourdomain.com, not in the SPF record itself. This is a separate TXT record from your SPF policy.

Deliverability Impact

• Identifies unauthorized senders. Failure reports reveal which IPs are sending mail with your domain in the envelope sender but failing SPF. This could be spoofing or a forgotten legitimate service.
• Supports SPF record refinement. Before tightening your SPF policy from ~all to -all, failure reports help you identify any legitimate senders you have not yet authorized.
• Complements DMARC reporting. While DMARC aggregate reports tell you pass/fail ratios, RFC 6652 forensic reports give you the specific headers and source IPs for individual failures — critical for investigating new spoofing campaigns.
• Early warning for forwarding breakage. When a mailing list or forwarding service relays your messages, SPF will fail because the forwarding server's IP is not in your SPF record. Failure reports help you identify these cases so you can adjust your authentication strategy (e.g., rely on DKIM for forwarded mail).

Related RFCs