RUF: The DMARC Tag Almost Nobody Still Uses

A customer asked me a version of this question last month: "I've got ruf=mailto:... sitting in my DMARC record next to rua=. Is that doing anything?" Fair question, and the honest answer took longer to give than I expected, because the short version — "basically no" — undersells what's actually going on. RUF isn't broken. It isn't a mistake someone made. It's a feature that worked exactly as designed, got used the way it was designed to be used, and then the internet decided that design was a problem.

This is that story. What RUF was supposed to do, why it made sense on paper, what actually happened when real mail volumes met real privacy law, and what you should do with a ruf= tag sitting in your own DNS record today.

Who this is for:

• Anyone who's spotted ruf= next to rua= in a DMARC record and wondered what it's for
• IT and security people deciding whether to add, remove, or ignore the tag
• Anyone curious why two tags that sound almost identical ended up in completely different places

The one-sentence version

RUF asked mailbox providers to forward you a copy of each individual email that failed DMARC, close to the moment it happened; almost none of them do that anymore, because doing so meant forwarding pieces of someone else's private email around the internet, and that turned out to be a bigger problem than the tag's designers accounted for.

What DMARC actually offers, and where RUF fits

DMARC gives you two separate ways to find out what's happening to mail sent using your domain. They sound like siblings, and technically they are — both are reporting mechanisms defined in the same standard, both get configured with a mailto: address in your DNS record. But they were built to answer two different questions, at two different scales.

RUA — Reporting URI for Aggregate reports — answers "who's been sending mail as my domain, and how much of it passed or failed, over the last day?" One report, once a day, covering every sender, bundled into a single machine-readable file. If you want the full picture of what that tag does and how to configure it, we covered it in What Is the RUA Tag? A Plain-English Explanation.

RUF — Reporting URI for Forensic reports — answers a much narrower, much more specific question: "show me the actual message that just failed." Not a count. Not a summary. The real thing — headers, and depending on configuration, potentially the body — sent to you close to real time, individually, one report per failing message.

Think of the difference like a store's security setup. RUA is the end-of-day tally the manager reviews — how many people came in, how many left without buying anything suspicious. RUF is more like getting handed the actual shoplifter's bag, right at the door, the moment it happens, so you can look inside yourself.

On paper, RUF sounds like the better tool. More detail, faster, per-incident instead of once a day. That was genuinely the thinking behind including it in the DMARC standard back when the specification was written in the early 2010s. The people designing DMARC weren't wrong that detailed, immediate visibility into individual failures would be useful. They just didn't fully see where that idea would run into trouble once it left the design document and started operating at the scale of Gmail, Outlook, and Yahoo Mail.

What a forensic report actually contains

To understand why RUF became a problem, it helps to know what one of these reports actually holds. The format is called an Abuse Reporting Format message, or ARF — a standardized way of packaging up details about a piece of email that failed some kind of check.

A RUF report, when a provider sends one, typically includes:

• The full set of headers from the failing message — sender, recipient, subject line, routing information, timestamps
• The authentication results — exactly which check failed, and why
• Depending on how the provider configured it, some or all of the message body itself

That last point is where everything unravels. A forensic report isn't a summary of a suspicious email. It's a copy of it — potentially including real content, sent by a real person, about a real subject, routed automatically to a domain owner who had no part in that original conversation.

Where this goes wrong, concretely

Picture a mid-sized company that publishes DMARC with ruf= configured. Somewhere else on the internet, someone forges an email using that company's domain — spoofing [email protected], sending it to a personal Gmail address, trying to run a phishing scam. Gmail's systems catch the failure. Under the original design, Gmail would then forward a forensic report back to the domain in the From: field — meaning a copy of that phishing email, potentially including whatever the scammer wrote, lands with the spoofed company.

That specific case is arguably fine — the company being spoofed has a legitimate interest in seeing what's being sent in its name. But DMARC forensic reporting doesn't have a way to distinguish "this failure looks like a phishing attempt" from "this failure was a legitimate person's email that simply wasn't authenticated correctly." A misconfigured mailing list, a forwarded message that broke SPF alignment, an employee using a personal device with the wrong settings — any of these can trigger a DMARC failure just as easily as a forgery does. And when they do, the same mechanism forwards a copy of that ordinary person's private email to a third party they've never heard of, who did nothing to earn access to it beyond owning a domain name that happened to appear in the From: field.

Multiply that across every domain publishing ruf=, every mailbox provider honoring it, and every kind of authentication failure that isn't actually malicious — accidental misconfigurations vastly outnumber real forgery attempts on most domains — and you get a reporting mechanism that was, in practice, routing a meaningful volume of real people's email content to unrelated third parties, automatically, with no human reviewing whether that made sense in any individual case.

Why the big providers pulled back

Nobody woke up one day and decided RUF was evil. What happened was slower and more mundane than that, which is usually how these things go. Over the years following DMARC's original 2012 specification, mailbox providers ran forensic reporting at real scale and watched the privacy exposure play out for real — not in theory, in actual production traffic.

A few things converged around the same period:

Privacy regulation caught up with what forensic reporting actually did. GDPR came into force in 2018, and it wasn't written with DMARC forensic reports specifically in mind — but the underlying principle applies directly: personal data shouldn't move between organizations without a clear legal basis and a defined purpose. A forensic report containing a private individual's email content, auto-forwarded to a domain owner with no relationship to that person, sits awkwardly inside that framework at best. Providers operating at global scale, serving users across jurisdictions with real regulatory teeth, had every incentive to treat that as a genuine legal risk rather than a hypothetical one.

The abuse surface ran the wrong direction. A mechanism that auto-forwards message content based on a domain's own DNS configuration is also a mechanism that can be pointed at targets. Nothing in the original design stopped a bad actor from configuring ruf= on a domain, deliberately triggering authentication failures involving other people's mail, and harvesting the forwarded content. It's a narrower and more obscure abuse path than most, but "narrow and obscure" isn't the same as "safe to ignore" once you're operating at the scale Gmail or Microsoft operate at.

The genuinely useful case — real forgery detection — mostly didn't need it. The failures worth actually investigating showed up in aggregate reports too, just without the message content attached. A security team chasing down active abuse of their domain almost always already has RUA data telling them which servers are failing and how often; the forensic copy of any one specific message rarely changed what they did next. The cost-to-benefit calculation for providers tipped hard toward "not worth the exposure."

So, quietly, over roughly the last decade, one major provider after another either stopped sending forensic reports altogether or restricted them so heavily — rate-limited, redacted, opt-in only for specific enterprise arrangements — that in practice, publishing ruf= on a domain today gets you close to nothing back from Gmail, Outlook.com, or Yahoo Mail. There was no announcement, no deprecation notice with a firm date. It just stopped mattering, the way a feature quietly does when the providers who'd have to support it decide the juice isn't worth the squeeze.

So is ruf= completely dead?

Not with 100% certainty, which is why I'm careful not to overstate this. A small number of specialized or enterprise mail systems — some corporate gateways, some security vendors running their own mail infrastructure, occasionally an ESP with a niche compliance arrangement — may still honor forensic report requests, sometimes under a negotiated agreement rather than the open standard. If you're running a domain that sends and receives mail almost exclusively through a closed enterprise ecosystem, it's conceivable a ruf= tag is doing something there.

But for the overwhelming majority of domains — anything sending or receiving mail that touches Gmail, Outlook.com, Yahoo Mail, or any of the other large consumer mailbox providers, which covers nearly every domain doing business with the public — a ruf= tag today is, functionally, decoration. It parses. It doesn't cause an error. It also doesn't do meaningfully more than leaving it out.

Should you remove it, then?

Honestly, it doesn't matter much either way, and I wouldn't lose sleep over which side of this you land on.

The case for leaving it in: it costs nothing. A ruf= tag sitting unused in a DMARC record doesn't slow anything down, doesn't count against SPF's lookup limits (that's a separate mechanism entirely — see our guide on the SPF 10-lookup limit if that's a different problem you're dealing with), and doesn't create any known risk on its own. If a provider that does still honor it happens to be in your mail path, you'd get whatever marginal value that provides, for free.

The case for removing it: it's one less thing in your DNS record to explain to the next person who inherits it and asks the same question my customer asked me. DNS records accumulate cruft the same way any configuration does — tags added because a guide said to, never revisited, never quite understood by whoever's looking at the record three years later. If you're already in there cleaning up or rebuilding a DMARC record, dropping ruf= is a reasonable piece of tidying. If it's already there and working fine, there's no urgency to go remove it.

What I'd actually push back on is spending real time configuring ruf= on a domain that doesn't have it yet, or treating its absence as a gap that needs fixing. That's where the energy is genuinely better spent elsewhere.

What to focus on instead

If forensic, per-message visibility into what's happening to your domain's mail is what you were actually hoping ruf= would give you, the honest answer is: that specific vision — a live, message-by-message feed of every forgery attempt — isn't something the current DMARC ecosystem delivers for most domains, regardless of configuration. What it does deliver, reliably, is the aggregate picture through RUA.

That's not a consolation prize. A well-read RUA feed tells you which sending sources are using your domain, how consistently they pass or fail, and where the pattern looks like an old marketing tool nobody removed from your SPF record versus where it looks like someone actively spoofing you from infrastructure you've never heard of. It doesn't hand you the contents of any one email, but it reliably tells you where to look. We go through exactly how to read one of these reports, field by field, in Reading DMARC Aggregate Reports: A Field-by-Field Guide.

The practical shift, if you're the kind of person who wanted RUF's real-time detail, is treating RUA data as something worth checking regularly rather than something that arrives once and gets ignored — which, in our experience building grimDMARC, is the actual gap on most domains we look at. Not "we're missing forensic detail." Almost always: "nobody's been reading the daily reports we do have." A dashboard that flags an unrecognized sending source is worth more, in practice, than a forensic copy of one email would have been — it catches the pattern, not just the single instance. That's the gap Hosted DMARC is built to close: someone actually looking at what the aggregate reports say, instead of the reports arriving and sitting unread the way they do on most domains we've seen.

Checking your own domain

If you want to see exactly what's published in your own DMARC record — whether ruf= is sitting in there, whether rua= is configured and pointed somewhere that's actually being monitored — the DMARC Analyzer shows the full parsed record in plain language, no DNS lookup tools required. If you're not sure DMARC is even the right place to start, the Domain Scanner covers the wider picture across SPF, DMARC and transport security together. And if you're building a record from scratch, the DMARC Builder & Validator will generate a correct one without asking you to weigh in on tags like this one that mostly don't matter anymore.

Frequently asked questions

What does RUF stand for? Reporting URI for Forensic reports — the tag that, in theory, sends you a copy of each individual email that failed DMARC, close to when it happened. In practice, almost no major mailbox provider still sends these.

Is RUF officially deprecated in the DMARC standard? Not formally removed from the specification — it's still a valid, documented part of DMARC. What changed is that the large mailbox providers stopped honoring requests for it in practice, which has the same real-world effect as deprecation without there being a formal announcement anyone can point to.

Why did providers stop sending forensic reports? Mainly privacy exposure. A forensic report can include the actual content of a failing email, and DMARC has no reliable way to tell a genuine forgery attempt apart from an ordinary person's misconfigured or misrouted mail. Forwarding real message content to an unrelated third party at scale became a liability providers weren't willing to keep carrying, especially once regulation like GDPR raised the bar for handling personal data.

Should I remove ruf= from my DMARC record? It's optional either way. Leaving it costs nothing and occasionally still reaches a provider that honors it. Removing it is reasonable housekeeping if you're already editing the record. Neither choice meaningfully changes your domain's actual protection.

Does losing RUF mean I have no visibility into forged emails anymore? No — RUA still gives you a full daily picture of who's sending mail as your domain and whether it's passing or failing, just as aggregate counts rather than individual message copies. For almost every domain, that's the reporting mechanism actually worth paying attention to.

Is there any modern replacement for what RUF was trying to do? Not really, and that's worth being honest about. No mechanism in current widespread use hands a domain owner a real-time copy of individual failing messages the way RUF's original design intended. The practical answer is reading RUA data consistently and treating an unrecognized or newly-failing sending source as the signal worth investigating — not waiting for a forensic copy that, for most domains, isn't coming.

Where to go from here

Run your own domain through the DMARC Analyzer to see exactly what's published — rua=, ruf=, or neither. If reports are already flowing somewhere and nobody's been reading them, that's worth fixing before it turns into the kind of gap we describe in why "we have DMARC" often means less than it sounds like. And if you want the full breakdown of what RUA can tell you, What Is the RUA Tag? A Plain-English Explanation is the place to start.

About this article

I'm part of the team building grimDMARC, a managed DMARC, SPF and BIMI platform for MSPs and their customers. Spotted something above that doesn't match what you're seeing on your own domain, or have a forensic-reporting edge case we didn't cover — reach me at [email protected].

Last updated: September 2026 · Reading time: 11 minutes