---
title: "What Is ARF in Email? Abuse Reporting Format"
description: "ARF (Abuse Reporting Format, RFC 5965) is the standard for DMARC forensic reports and email feedback loops. Annotated sample inside."
publishedAt: 2026-05-06
tags: ["arf", "dmarc", "email-authentication", "rfc-5965", "feedback-loops"]
faq:
  - question: "What is ARF in DMARC?"
    answer: "In DMARC, ARF is the wire format used for forensic reports — the per-message notifications a receiver MAY send when a message fails authentication. RFC 6591 (AFRF) extends RFC 5965 with Feedback-Type: auth-failure and DKIM/SPF failure fields. ARF is the envelope; AFRF is the payload that fills it for DMARC."
  - question: "Is ARF the same as a DMARC failure report?"
    answer: "A DMARC failure report (also called a forensic report or ruf report) is an ARF message with Feedback-Type: auth-failure. So every DMARC failure report is an ARF report, but not every ARF report is a DMARC failure report — most ARF traffic carries Feedback-Type: abuse and is generated when a recipient clicks report spam in their webmail."
  - question: "What does RFC 5965 define?"
    answer: "RFC 5965 (2010) defines the Abuse Reporting Format itself: the multipart/report; report-type=feedback-report outer envelope, the message/feedback-report MIME type, and the initial registry of fields like Feedback-Type, User-Agent, Source-IP, and Reported-Domain. RFC 6591 and RFC 9477 extend the field set later."
  - question: "Why am I not receiving ARF reports for my domain?"
    answer: "Three common reasons. First, most major mailbox providers — Gmail, Microsoft 365, Apple, Fastmail, Proton — do not emit DMARC forensic reports at all (Microsoft has confirmed this in writing). Second, you have not published a ruf=mailto: tag in your DMARC record. Third, ISP feedback loops require separate registration at each provider (Yahoo Sender Hub, Microsoft JMRP/SNDS, Mail.ru, La Poste, Seznam)."
  - question: "What is the difference between ARF and XARF?"
    answer: "ARF (RFC 5965) is the IETF-standard MIME-based format every major receiver emits. XARF is Abusix's vendor extension that adds a JSON payload for richer abuse-type taxonomies — phishing, malware, fraud sub-categories. For DMARC forensic reports, you will only ever see ARF; XARF adoption is concentrated in Abusix's customer base."
  - question: "How do I parse an ARF report programmatically?"
    answer: "Read it as a multipart/report MIME message, extract the message/feedback-report part, and parse the key-value fields per RFC 5965 §3.3. For DMARC forensic reports, apply the RFC 6591 §3.2 extensions for the AFRF field set. The DMARCguard ARF report analyzer does this in the browser — no installation, no language SDK."
  - question: "What is MARF, the Messaging Abuse Reporting Format?"
    answer: "MARF was the IETF working-group name (2007–2012) that produced the ARF family of RFCs (5965, 6591, 6650, 6651, 6652, 6692). The format is called ARF; MARF was just the working group. You will see the term in older M3AAWG and IETF documents — both refer to the same thing."
---
# What Is ARF in Email? Abuse Reporting Format Explained

In email, **ARF stands for Abuse Reporting Format** — the IETF standard
(RFC 5965) that makes spam complaints and DMARC forensic reports
machine-readable. If you have ever seen the phrase "what is ARF in email"
sitting beside a `ruf=` tag in a DMARC record, this is what it means: a MIME
envelope ISP feedback loops and authentication-failure reporters use to
deliver structured complaints back to senders.

ARF matters because it is the wire format underneath every
[DMARC forensic report](/learn/arf/), every "report spam" complaint that
leaves Yahoo or Microsoft, and every modern feedback-loop integration — and
it is one of the rarest signals you will ever ingest. DMARCguard scanner data
(April 2026) shows **16.3% of scanned domains publish a `rua=` aggregate
mailbox**, and only a fraction of those also publish a `ruf=` forensic
mailbox. Among the major mailbox providers, Microsoft has explicitly
confirmed it does not emit forensic reports; the rest are publicly silent.
(That 16.3% is a `rua=` proxy; we do not measure ARF emission directly.)

By the end of this guide you will know the three-part MIME structure defined
by RFC 5965, the field semantics that matter for an admin, why DMARC `ruf=`
reports rarely materialize in 2026, and how to register for the ISP
feedback-loop programs that still emit ARF.

## What Is the Abuse Reporting Format (ARF)?

**ARF, the Abuse Reporting Format, is a MIME-based email format defined in
RFC 5965 (2010). It packages an abuse complaint, a DMARC forensic report, or
an ISP feedback-loop notification into three machine-readable parts so abuse
desks can process them automatically.** That single sentence is the short
answer; the rest of the section explains where it came from and why it sits
at the intersection of two very different workflows.

The format has two parents. AOL built the first large-scale Complaint
Feedback Loop in 2005 using a proprietary format, then helped standardize the
design through the IETF's MARF working group. The result was
[RFC 5965](https://www.rfc-editor.org/rfc/rfc5965.html), which formalized the
`multipart/report; report-type=feedback-report` envelope and a registry of
fields like `Feedback-Type`, `Source-IP`, `Authentication-Results`, and
`Reported-Domain` (RFC 5965 §3.1 for the MIME structure, §3.3 for the field
registry).

A useful framing: ARF is the envelope, and what fills it depends on who is
reporting what. When a Yahoo recipient hits "report spam," the complaint
leaves Yahoo's postmaster as an ARF message with `Feedback-Type: abuse`. When
a receiver sends the publisher of a DMARC record a sample of a message that
failed authentication, it uses the AFRF profile (RFC 6591) with
`Feedback-Type: auth-failure`. Same envelope, different cargo.

You will sometimes see **MARF** ("Messaging Abuse Reporting Format") in older
M3AAWG and IETF documents. MARF is just the working-group name that produced
the ARF family of RFCs (5965, 6591, 6650, 6651, 6652, 6692); the format
itself is always called ARF.

## ARF Format: The Three-Part MIME Structure

The ARF format is a `multipart/report; report-type=feedback-report` MIME
message with three nested parts. RFC 5965 §3.1 fixes the order, and every ARF
emitter you will encounter — Yahoo, Mail.ru, Seznam, the OpenDMARC filter,
the Comcast feedback loop — produces the same shape:

1. **`text/plain`** — the human-readable summary an abuse-desk operator sees
   first.
2. **`message/feedback-report`** — the structured key-value block that
   parsers actually read.
3. **`message/rfc822`** _or_ **`text/rfc822-headers`** — the original message
   in full, or just its headers if the emitter is preserving recipient
   privacy.

The outer wrapper carries the `report-type=feedback-report` parameter; if you
encounter a feedback loop whose outer Content-Type is `multipart/mixed`
instead of `multipart/report`, your parser will reject standards-strict
reports unless you special-case it. (The Comcast feedback loop is the
well-known offender here.)

Part 2 — the `message/feedback-report` block — is where every interesting
field lives. It always carries `Version: 1`, a `Feedback-Type` header, a
`User-Agent` identifying the generator, and at minimum the
`Original-Mail-From`, `Source-IP`, and `Reported-Domain` of the message that
triggered the complaint. RFC 5965 §3.3 defines the canonical registry; later
RFCs extend it for specific use cases.

Part 3 has been the part most affected by privacy regulation. Three variants
exist in the public RFC record:

| Variant               | Part 3 content            | Trade-off                                       |
| --------------------- | ------------------------- | ----------------------------------------------- |
| RFC 5965 (2010)       | `message/rfc822` (full)   | Maximum forensic value, maximum PII             |
| RFC 6591 (2012, AFRF) | `text/rfc822-headers`     | Drops body, keeps DKIM-Signature + Received     |
| RFC 9477 (2023, CFBL) | Opaque `CFBL-Feedback-ID` | GDPR-safe; needs sender-side ID-to-campaign map |

The RFC 9477 pattern is particularly important if you operate inside the EU:
the modern Coordinated Feedback Loop strips the original message down to an
opaque tag the sender injected at send time, so no recipient PII ever leaves
the receiver.

<Figure
  src="/images/blog/what-is-arf/what-is-arf_three-part-mime-structure_diagram.svg"
  alt="Three-part MIME structure of an ARF report: a text/plain human summary, a message/feedback-report key-value block, and a message/rfc822 or text/rfc822-headers original message wrapped in a multipart/report; report-type=feedback-report envelope"
  caption="The three MIME parts every ARF report carries, and the outer multipart/report envelope that binds them (RFC 5965 §3.1)."
  width={960}
  height={520}
/>

## ARF Email Reports Explained: An Annotated Real Example

Captured ISP ARF traffic stays private because it carries complainant PII, so
the verbatim citable samples in the public record live in IETF RFC
appendices. The sample below is RFC 5965 Appendix B.2 — the canonical ARF
email format, reproduced exactly.

<CodeBlock
  lang="email"
  filename="RFC 5965 Appendix B.2 — canonical ARF feedback report"
  code={rfc5965AppendixB2}
/>

The decoder table pairs each field with what it means and what an admin
should actually do.

| Field                    | Value                                | Meaning                                                          | What an admin should DO                                                                   |
| ------------------------ | ------------------------------------ | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| `Feedback-Type`          | `abuse`                              | Recipient hit "report spam" — an FBL/CFL complaint, not a bounce | Suppress the recipient immediately; pull the list-acquisition source for that address     |
| `User-Agent`             | `SomeGenerator/1.0`                  | Generating MUA/MTA at the reporter                               | Map it to a per-ISP runbook (Yahoo!-Mail-Feedback, AOLMP, szn-mime, etc.)                 |
| `Original-Mail-From`     | `somespammer@example.net`            | RFC 5321 MAIL FROM (return-path) the receiver saw                | Confirm it matches a VERP you issued; if not, a third party is using your IP              |
| `Original-Rcpt-To`       | `user@example.com`                   | Complaining recipient                                            | Add to suppression; cross-check with subscription source and double-opt-in record         |
| `Source-IP`              | `192.0.2.1`                          | Connecting MTA at receive time                                   | Look it up against your SPF `ip4:`/`include:` set; absent IP = forwarder, ESP, or spoofer |
| `Reporting-MTA`          | `dns; mail.example.com`              | The ISP MTA that issued the report                               | Whitelist for your inbound abuse-mailbox parser; verify TLS/DKIM on the report itself     |
| `Authentication-Results` | `spf=fail smtp.mail=...`             | SPF failed at the receiver, with the checked identity quoted     | Re-publish your SPF including this `Source-IP`, or revoke the sender if illegitimate      |
| `Reported-Domain`        | `example.net`                        | Receiver-attributed domain of the offending message              | Compare with your `From:` and DKIM `d=` domain — divergence indicates spoof or shadow IT  |
| `Reported-Uri`           | `http://example.net/earn_money.html` | URLs and `mailto:` the ISP flagged inside the body               | Sandbox the URL; if it is your tracking domain, your reputation is leaking through it     |
| `Removal-Recipient`      | `user@example.com`                   | Address the receiver wants suppressed                            | Apply within minutes — many MBPs grade FBL responsiveness on suppression latency          |

The DMARC variant looks slightly different. RFC 6591 (the AFRF profile,
covered next) keeps the same outer envelope but swaps the field set:
`Feedback-Type: auth-failure` replaces `abuse`, DKIM-specific fields appear
(`Auth-Failure: bodyhash`, `DKIM-Canonicalized-Body`, `DKIM-Domain`,
`DKIM-Selector`), and part 3 becomes `text/rfc822-headers` — dropping the
body but preserving the DKIM-Signature, Received chain, and Subject (RFC 6591
§B.1).

If you want to inspect a real ARF report without writing a parser, paste the
raw `.eml` into the
[DMARCguard ARF report analyzer](/tools/arf-report-analyzer/) — it breaks out
the three MIME parts, decodes each field, and flags non-standard quirks like
missing `Date:` headers or base64-wrapped parts.

## ARF and DMARC Forensic Reports (the `ruf=` Tag)

Here is the link between the two formats: **a DMARC forensic report is an
ARF message whose `Feedback-Type` header is `auth-failure`.** RFC 6591
defines the AFRF — Authentication Failure Reporting Format — profile, and
AFRF _is_ the DMARC `ruf=` report on the wire. If you have ever published a
`ruf=mailto:` mailbox and wondered what would land in it, the answer is an
AFRF-flavoured ARF message.

The DMARC [`ruf=` tag](/learn/dmarc/) is the publisher-side mailbox where
receivers MAY send per-message forensic reports. It is paired with the `fo=`
tag, which controls when those reports fire. RFC 7489 §6.3 defines four
values: `fo=0` (default — both SPF and DKIM must fail), `fo=1` (either
fails), `fo=d` (any DKIM failure), `fo=s` (any SPF failure). `fo=1` is the
value most senders actually want; `fo=0` produces almost nothing because both
checks rarely fail simultaneously.

### Why forensic reports rarely materialize

Even when you publish a `ruf=` tag with `fo=1`, you should expect very few
reports. Three reasons drive the scarcity, all of them documented in primary
sources rather than vendor blog rumour.

**1. GDPR and PII friction.** The IETF DMARC working group puts it plainly in
`draft-ietf-dmarc-failure-reporting-25` (Steven M. Jones / Alessandro Vesely,
18 Apr 2026, §7): _"many large-scale providers limit or entirely disable the
generation of failure reports, preferring to rely on aggregate reports, which
provide statistical visibility without exposing sensitive content."_ Forensic
reports carry message bodies, recipient addresses, and subject lines — all
PII under GDPR.

**2. Microsoft 365 explicitly does not emit.** Microsoft has put it on the
record in its own DMARC configuration documentation: _"Microsoft 365 doesn't
send DMARC Forensic reports (also known as DMARC Failure reports), even if a
valid `ruf=mailto:` address exists in the DMARC TXT record of the source
domain."_
([learn.microsoft.com](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure),
accessed 2026-04-28). It is the only on-record statement from a major mailbox
provider, and it is a "no."

**3. Receiver coverage is collapsing.** Of eight major mailbox providers
(Gmail, Yahoo/AOL, Microsoft, Apple, Fastmail, Proton, Comcast, iCloud),
Microsoft is the only one with an on-record statement and the rest are
publicly silent. Practitioner consensus puts Yahoo (via the Red Sift
partnership), NetEase, LinkedIn, and Seznam as the only credible AFRF
emitters in 2026. If you are debugging the
[DMARC failure path](/blog/dmarc-failed-how-to-fix/), aggregate reports
remain the primary signal.

A forwarding wrinkle: AFRF reports include the original
`Authentication-Results` and any
[ARC chain on forwarded mail](/blog/dmarc-forwarding-arc-fix/), so you can
tell whether a failure originated at the sender or at an intermediate hop.
ARC preserves the verdict across hops; AFRF tells you when the chain broke.

## DMARC Failure Reports vs Aggregate Reports

The two DMARC report types serve different jobs. Aggregate (`rua=`) gives you
statistical visibility across millions of messages; forensic (`ruf=`) gives
per-message detail when authentication fails. The trade-offs are stark:

| Dimension              | Aggregate (`rua=`)               | Forensic / AFRF (`ruf=`)                  |
| ---------------------- | -------------------------------- | ----------------------------------------- |
| Wire format            | XML (RFC 7489 Appendix C)        | ARF/MIME (RFC 5965 + 6591)                |
| Granularity            | Hourly/daily counters per source | Per-message sample                        |
| PII exposure           | Anonymized counts                | Subject, body, recipient (when populated) |
| Major-receiver support | Universal                        | Microsoft confirmed no; rest unconfirmed  |
| Volume                 | Reliable daily flow              | Sporadic; often zero for weeks            |
| Best use               | Sender-source inventory          | Spot-checking specific failures           |

In practice, **rely on aggregate reports as your primary signal and treat
forensic reports as a supplementary feed when they show up at all**.
DMARCguard's ingestion mirrors that: every `rua=` report is parsed and
indexed, and any ARF/AFRF mail that does arrive is layered on top with full
field-by-field decoding. If your deliverability runbook needs forensic
reports for daily decisions, the data will not be there.

## ISP Feedback Loops That Still Send ARF in 2026

Most ARF traffic in 2026 is not DMARC forensic at all — it is recipient
"report spam" complaints flowing through ISP feedback-loop programs. These
have their own registration workflow, their own quirks, and their own
trajectory through 2024–2026 consolidation. The table below is the
operational map:

| Program                            | Domains covered                                                                           | Verification                                                           | Active 2026?                   |
| ---------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------ |
| Yahoo Sender Hub CFL               | yahoo.com, aol.com, verizon.net, att.net + 12 AT&T legacy domains, Comcast (in migration) | DNS TXT for ownership + DKIM `d=` (no IP/CIDR)                         | Yes                            |
| Microsoft JMRP (inside SNDS)       | outlook.com, hotmail.com, live.com, msn.com                                               | IP-based; abuse@/postmaster@ confirmation; MS-account auth (Nov 2025+) | Yes                            |
| Comcast FBL                        | comcast.net                                                                               | IP-based or DKIM-domain                                                | Sunsetting via Yahoo migration |
| Mail.ru Postmaster FBL             | mail.ru, list.ru, bk.ru, inbox.ru                                                         | Mail.ru account + emailed confirmation link                            | Yes                            |
| La Poste FBL                       | laposte.net                                                                               | IP-based or DKIM `d=`/selector                                         | Yes                            |
| Seznam FBL                         | seznam.cz                                                                                 | Seznam account + mandatory DKIM + abuse@/postmaster@ confirmation      | Yes                            |
| Validity Universal FBL (paid tier) | Libero, Telenor, Terra, Fastmail, OpenSRS, Rackspace, Synacor, Yandex                     | Validity verification flow                                             | Paid only since Sept 2023      |

Registration URLs are linked from the
[Yahoo Sender Hub FAQs](https://senders.yahooinc.com/faqs/) (the
authoritative reference for Yahoo, AOL, AT&T, and Comcast) and Microsoft's
[SNDS portal](https://sendersupport.olc.protection.outlook.com/snds/).
Mail.ru, La Poste, and Seznam each operate their own postmaster sites.

A few 2024–2026 changes competitor write-ups miss:

- **AT&T migrated to Yahoo MX on August 6, 2025.** All 13 AT&T consumer
  domains (sbcglobal.net, bellsouth.net, etc.) now route via Yahoo and use
  the Yahoo CFL — no standalone AT&T FBL.
- **Microsoft JMRP body-stripping (Nov 2025+).** Per
  [spamresource.com, January 2026](https://www.spamresource.com/), JMRP ARF
  reports now strip the original message body and redact the sender address;
  only original headers, Authentication-Results, Received-SPF, DKIM-Signature,
  and ARC survive.
- **Yahoo CFL is DKIM-only.** Yahoo Sender Hub no longer offers IP/CIDR-keyed
  enrollment.
- **Validity Universal FBL paywall.** Since September 21, 2023, raw ARF feeds
  for the Universal FBL portfolio (Libero, Telenor, Terra, Fastmail, etc.)
  are a paid product (~$1,500/yr per 100k complaints).

Gmail is the deliberate non-FBL exception. Postmaster Tools v2 (V1 retired
September 30, 2025) gives senders an aggregated `Feedback-ID`-keyed dashboard
and API — but **no ARF messages are ever sent**.
[Google's own help page](https://support.google.com/a/answer/6254652)
explains the workflow: senders embed a `Feedback-ID` header on outbound mail,
and identifiers with unusual spam rates surface inside the Postmaster Tools
FBL dashboard. The absence of an outbound ARF feed is the policy.

## ARF vs XARF: When the JSON Variant Matters

XARF (Extended Abuse Reporting Format) is a vendor extension by Abusix. It
adds a JSON payload alongside the standard `message/feedback-report` block,
allowing richer abuse-type taxonomies — phishing, malware, fraud
sub-categories — that vanilla ARF does not encode.

| Format | Authoring body  | Wire format | Field model           | Common adopters                                             |
| ------ | --------------- | ----------- | --------------------- | ----------------------------------------------------------- |
| ARF    | IETF (RFC 5965) | MIME        | Key-value fields      | Yahoo, Microsoft, Mail.ru, Seznam, every DMARC AFRF emitter |
| XARF   | Abusix (vendor) | MIME + JSON | Extensible categories | Concentrated in Abusix's customer base                      |

The neutral framing: XARF is more expressive but adoption is concentrated in
Abusix's customer base. For DMARC forensic reports, `Feedback-Type:
auth-failure` ARF is what every emitting receiver emits. If your abuse desk
ingests both, treat ARF as the baseline parser and XARF as an optional
enrichment path.

## How to Read an ARF Report in Practice

The five-step workflow below is what an admin actually does when an ARF
report lands in their abuse mailbox. Each step maps to a specific field in
the `message/feedback-report` block:

1. **Confirm the outer Content-Type.** It should be
   `multipart/report; report-type=feedback-report`. If you see
   `multipart/mixed` instead (the Comcast quirk), your standards-strict
   parser will reject the message — special-case Comcast or skip it.
2. **Read `Feedback-Type` first.** `abuse` means a user complaint: suppress
   the recipient immediately and route the report to the deliverability
   queue. `auth-failure` means an AFRF/DMARC forensic report: route it to the
   security queue and do **not** suppress the recipient.
3. **Decode `Source-IP`.** Cross-reference it against your SPF `include:`
   chain. If the IP is absent from your authorized senders, you are looking
   at a forwarder, an unauthorized ESP, or a spoofer.
4. **Cross-reference `Original-Mail-From` with `Reported-Domain`.** The first
   is the return-path (RFC 5321 envelope sender); the second is the
   From-header domain. Divergence is your alignment-drift indicator.
5. **For AFRF, read `Auth-Failure`.** Values are `spf`, `dkim`, `bodyhash`,
   or `dmarc`. Each tells you exactly which mechanism failed at the receiver
   and points you at the right
   [DKIM alignment](/blog/dkim-alignment-failure-fix/) or SPF fix.

That is the manual workflow. Skip the parsing step entirely by pasting your
raw `.eml` into the [DMARCguard ARF checker](/tools/arf-checker/), which runs
every step above in the browser and surfaces the admin actions inline with
each field.

## FAQ

### What is ARF in DMARC?

In DMARC, ARF is the wire format used for forensic reports — the per-message
notifications a receiver MAY send when a message fails authentication. RFC
6591 (AFRF) extends RFC 5965 with `Feedback-Type: auth-failure` and DKIM/SPF
failure fields. ARF is the envelope; AFRF is the payload that fills it for
DMARC.

### Is ARF the same as a DMARC failure report?

A DMARC failure report (also called a forensic report or `ruf` report) is an
ARF message with `Feedback-Type: auth-failure`. So every DMARC failure report
is an ARF report, but not every ARF report is a DMARC failure report — most
ARF traffic carries `Feedback-Type: abuse` and is generated when a recipient
clicks "report spam" in their webmail.

### What does RFC 5965 define?

RFC 5965 (2010) defines the Abuse Reporting Format itself: the
`multipart/report; report-type=feedback-report` outer envelope, the
`message/feedback-report` MIME type, and the initial registry of fields like
`Feedback-Type`, `User-Agent`, `Source-IP`, and `Reported-Domain`. RFC 6591
and RFC 9477 extend the field set later.

### Why am I not receiving ARF reports for my domain?

Three reasons. First, most major mailbox providers — Gmail, Microsoft 365,
Apple, Fastmail, Proton — do not emit DMARC forensic reports at all
(Microsoft confirmed this in writing). Second, you may not have published a
`ruf=mailto:` tag. Third, ISP feedback loops require separate registration at
each provider (Yahoo Sender Hub, Microsoft JMRP, Mail.ru, La Poste, Seznam).

### What is the difference between ARF and XARF?

ARF (RFC 5965) is the IETF-standard MIME format every major receiver emits.
XARF is Abusix's vendor extension that adds a JSON payload for richer
abuse-type taxonomies — phishing, malware, fraud. For DMARC forensic reports
you will only ever see ARF; XARF adoption is concentrated in Abusix's
customer base.

### How do I parse an ARF report programmatically?

Read it as a `multipart/report` MIME message, extract the
`message/feedback-report` part, and parse the key-value fields per RFC 5965
§3.3. For DMARC forensic reports, apply the RFC 6591 §3.2 extensions for the
AFRF field set. The DMARCguard
[ARF report analyzer](/tools/arf-report-analyzer/) does this in the browser —
no installation, no language SDK.

### What is MARF, the Messaging Abuse Reporting Format?

MARF was the IETF working-group name (2007–2012) that produced the ARF family
of RFCs (5965, 6591, 6650, 6651, 6652, 6692). The format is called ARF; MARF
was just the WG. You will see the term in older M3AAWG and IETF documents —
both refer to the same thing.

## What ARF Means for Your DMARC Programme in 2026

So: what is ARF in email? It is the MIME format (RFC 5965) that makes abuse
complaints and DMARC forensic reports machine-readable. Three parts — a human
summary, a structured `message/feedback-report` block, and the original
message or its headers — wrapped in a
`multipart/report; report-type=feedback-report` envelope.

- DMARC `ruf=` reports use the AFRF variant (RFC 6591) but rarely materialize
  in 2026, because Gmail, Microsoft 365, Apple, and most EU receivers do not
  emit them.
- Real ARF traffic lives in ISP feedback-loop programs — Yahoo Sender Hub,
  Microsoft JMRP, Mail.ru, La Poste, Seznam — each with its own registration
  workflow and its own quirks.
- Aggregate `rua=` reports remain the primary DMARC signal you should rely
  on; treat any forensic data that does arrive as supplementary.

DMARCguard ingests both your DMARC aggregate reports and any forensic or
feedback-loop messages your domain receives, then surfaces the field-level
admin actions inline. Start free — no credit card. For the deeper protocol
reference, the [ARF learn-page deep dive](/learn/arf/) walks through every
field in the RFC 5965 registry alongside the AFRF and CFBL extensions.