← RFC Reference

RFC 6591: Authentication Failure Reporting (AFRF)

Why This Exists

Email authentication mechanisms like SPF, DKIM, and DMARC detect spoofed or unauthorized messages. When these checks fail, the receiving server takes action (reject, quarantine, or allow). But the domain owner — the one being spoofed — needs to know about these failures to:

• Detect unauthorized use of their domain (phishing, spoofing)
• Identify misconfigured legitimate senders (e.g., a marketing platform not signing with DKIM)
• Debug authentication record problems (broken SPF includes, wrong DKIM key)
• Build a picture of attack patterns before switching DMARC to p=reject

DMARC aggregate reports (rua) provide statistical summaries, but they do not include message details. DMARC forensic reports (ruf) use the AFRF format defined by this RFC to provide per-message detail: the actual headers, the authentication results, and the specific failure reason.

RFC 6591 extends RFC 5965 (ARF) by adding the Feedback-Type: auth-failure report type and defining additional fields for authentication-specific data.

How It Works

An AFRF report is an ARF message (multipart/report with report-type=feedback-report) where the machine-readable part uses Feedback-Type: auth-failure and includes authentication-specific fields.

AFRF Report Example

From: dmarc-reporter@receiver.example.com
To: dmarc-ruf@example.com
Subject: Auth failure report for example.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
    boundary="AFRF-BOUNDARY-001"

--AFRF-BOUNDARY-001
Content-Type: text/plain

Authentication failure report for a message claiming
to be from example.com, received from IP 192.0.2.55.

--AFRF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: Receiver-DMARC/2.0
Version: 1
Original-Mail-From: spoofed@example.com
Arrival-Date: Tue, 10 Mar 2026 16:42:00 -0500
Source-IP: 192.0.2.55
Auth-Failure: dmarc
Authentication-Results: receiver.example.com;
    dkim=fail header.d=example.com;
    spf=fail smtp.mailfrom=spoofed@example.com;
    dmarc=fail header.from=example.com
Reported-Domain: example.com
DKIM-Domain: example.com
Delivery-Result: reject

--AFRF-BOUNDARY-001
Content-Type: text/rfc822-headers

From: ceo@example.com
To: finance@receiver.example.com
Subject: Urgent wire transfer needed
Message-ID: <fake-msg-001@192.0.2.55>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
    s=selector1; b=INVALID...

--AFRF-BOUNDARY-001--

Key Technical Details

Fields Added by RFC 6591

These fields appear in the message/feedback-report part alongside the standard ARF fields:

Auth-Failure Values

Relationship to DMARC Reporting

DMARC (RFC 7489) defines two reporting addresses in its DNS record:

• rua — aggregate reports (XML). Statistical summaries of authentication results across all messages.
• ruf — forensic reports. Per-message detail using the AFRF format defined by this RFC.

In practice, forensic reporting via ruf has limited adoption. Many large mailbox providers (Gmail, Yahoo) do not send forensic reports due to privacy concerns. Those that do often redact the message body and recipient address. Aggregate reports (rua) remain the primary source of DMARC feedback.

Common Mistakes

• Expecting forensic reports from all receivers. Most major mailbox providers do not send AFRF reports. Do not rely on ruf as your sole source of authentication failure data. DMARC aggregate reports (rua) are far more widely supported.
• Confusing AFRF with ARF abuse reports. Both use multipart/report with report-type=feedback-report, but they have different Feedback-Type values. An auth-failure report means an authentication check failed; an abuse report means a user clicked "Report Spam." Handle them differently.
• Ignoring the Auth-Failure field. The Auth-Failure field tells you exactly which check failed. A dkim failure suggests a signing problem; a spf failure suggests a missing IP in your SPF record; a dmarc failure means neither mechanism aligned.
• Not publishing a ruf address. While most receivers will not use it, some smaller providers and enterprise gateways do send forensic reports. Including ruf in your DMARC record costs nothing and may provide useful data.
• Treating forensic reports as bounces. An authentication failure report does not mean the message was not delivered. Check the Delivery-Result field — the message may have been delivered to the spam folder despite the failure.

Deliverability Impact

• Early detection of spoofing campaigns. When someone is phishing with your domain, AFRF reports (where available) provide the specific headers and source IPs of the forged messages, enabling faster incident response.
• Debugging authentication misconfigurations. A forensic report showing Auth-Failure: dkim with a specific selector and domain tells you exactly which DKIM key or signing configuration is broken.
• Safe DMARC rollout. When moving from p=none to p=quarantine or p=reject, forensic reports help you identify legitimate senders that are failing authentication before those messages start being blocked.
• Complementing aggregate data. Aggregate DMARC reports show you that 50 messages failed authentication from IP 192.0.2.55. A forensic report shows you the actual headers of one of those messages, revealing whether it was a phish or a misconfigured legitimate system.

Related RFCs