Full Participation: Why a DMARC Standard Doesn't Mean p=reject for Everyone

Part 4 of the DMARCbis series. Start with the overview.

So, do I still have to move to reject?

For three parts, this series has been about mechanics: what DMARCbis changes at a high level, what the individual tags do, and how the DNS tree walk resolves policy and alignment. If you have followed along this far, you can read a DMARC record and know how a 9989 receiver processes it. That leaves the question that usually surfaces in a customer conversation before any of the technical detail: so now what? Do I still have to move to reject?

Two assumptions sit behind that question. The first: DMARC is a standard now, so it must be mandatory. The second: full participation means being on p=reject. The first is wrong; the second is thinking too narrowly.

The old rule of thumb was that reject is the goal. DMARCbis corrects that. The target state is called enforcement, and enforcement is any state other than p=none, meaning quarantine or reject. Which of the two is right is a deliberate, needs-based decision, not a formality. For a domain whose users post to mailing lists, quarantine can be the sensible end state, not merely a stepping stone to reject.

This part clears up what "standard" really means here, what the RFC means by full participation, and what is off about both assumptions.

What "standard" means here, and what it doesn't

With DMARCbis, "standard" is not a label; it carries a precise status, and that status is often reported in shorthand. DMARCbis was published as RFC 9989, on the Standards Track, in the Proposed Standard category. That is more than DMARC used to be: RFC 7489 was merely Informational, published through the Independent Submission Stream, so without IETF consensus and without IESG approval. RFC 9989, by contrast, was developed by consensus in an open working group, the DMARC Working Group, rather than reflecting the view of individual authors, and was then approved by the steering body of the IETF process, the IESG. For the first time, DMARC is a genuine IETF standard, not just documented practice.

But this is exactly where the misunderstanding starts. In this context, "standard" means a specification agreed by consensus that implementations are expected to follow, so that senders and receivers mean the same thing. It does not mean legally binding. An RFC obliges no one to deploy DMARC. It describes how DMARC works if you use it, not that you must.

A standard here means a consensus specification, not a legal mandate.

There is a further subtlety that the "DMARC is a standard now" shorthand tends to bury: Proposed Standard is the entry rung of the Standards Track, not the finish line. It is a full standard, but explicitly one that is still expected to gather real-world experience. Turning that into "mandatory from now on" overstretches the word in two directions at once: legally, where the RFC prescribes nothing, and in maturity, where Proposed Standard is less settled than the word "standard" suggests.

That leaves the obvious follow-up: if no RFC forces me to deploy DMARC, who does? There is an answer, but it comes not from the technology, it comes from regulation and duty of care. That is the subject of the final part of this series; here we leave it open on purpose.

What the RFC means by full participation

DMARCbis does something RFC 7489 did not: in a dedicated section, and in binding language, it states what full DMARC participation means. The section is titled "Conformance Requirements for Full DMARC Participation" (Section 8), and it phrases its requirements normatively, with MUST and MUST NOT, not as loose advice.

For the Domain Owner, it says:

• Send mail that produces an SPF-authenticated identifier aligned with the Author Domain.

• Send mail that produces a DKIM-authenticated identifier that is aligned.

• Set up a mailbox for aggregate reports, and collect and analyze those reports.

• Publish a DMARC record, for the Author Domain and, where different, the Organizational Domain.

• Do not rely on SPF alone once the policy is set to reject.

Here is the point that matters. Nowhere does it say reject. Full participation means authenticating cleanly, over both SPF and DKIM, then monitoring and publishing. Which enforcement level you end up choosing, none, quarantine, or reject, is not a question of conformance but a separate decision.

Full participation does not mean reject.

This holds all the way down: p=none is standards-conformant too. DMARCbis even has a name for it, Monitoring Mode (Section 3.2.12), the state of p=none plus ongoing analysis of the aggregate reports. A domain that authenticates cleanly, publishes its record, and analyzes its reports is a fully conformant DMARC participant, even if it never moves beyond p=none.

The second assumption from the first section, that full participation means being on reject, is thus settled. It confuses participation with enforcement level. The RFC keeps the two cleanly apart, and that separation carries the next two sections.

Two axes: conformance and enforcement

The confusion behind almost every misunderstanding in this area is the one between two independent axes. One axis is conformance: does the domain meet the Section 8 requirements, does it authenticate cleanly over SPF and DKIM, does it publish its record, does it analyze its reports? The other axis is the enforcement level: how should the receiver treat mail that fails the check, none, quarantine, or reject? The two axes are independent; every combination is possible.

The matrix shows the uncomfortable consequence at a glance. A domain can be on p=reject and still not be conformant: publish reject but rely on SPF alone and never analyze the reports, and you have the strictest policy on the weakest foundation, which Section 8 flags as non-conformant. Conversely, a domain can deliberately stay on quarantine, conformant and stable, as a legitimate target configuration rather than a halfway house to somewhere else. The enforcement level alone therefore says nothing about whether a configuration is sound. A p=reject record can be more fragile than a well-run p=none record.

The counterintuitive core: a standard doesn't mean blind enforcement

Here is the point where most readers pause. You might expect that now DMARC is an IETF standard, receivers must enforce p=reject. The RFC says the opposite. For the first time, in binding language, it states that a receiver must not blindly honor p=reject.

The starting point is Section 5.4: the final handling of any message is always a matter of the receiver's local policy. A receiver may accept mail that fails DMARC even when the published policy is reject. And Section 7.4, together with the conformance list in Section 8, turns that into a hard requirement: a receiver must not reject a message solely because the domain published p=reject (MUST NOT). It has to weigh the policy together with other knowledge and its own analysis. Absent that analysis, the receiver must treat the mail as if the policy were quarantine, not reject.

The reason is in the same section, and it is not theoretical: indirect mail flows. When a user posts through a mailing list, the list alters the message, DKIM alignment breaks, and the mail fails under p=reject even though it is legitimate. A receiver that enforces reject rigidly throws exactly that mail away and adds to the collateral damage DMARC explicitly sets out to avoid.

What is striking is how candid the RFC is about reality. It states the MUST rule and, in the same section, concedes that in practice hardly any receiver applies such mitigations, and that this is unlikely to change much. Mail sent through mailing lists with an unchanged From is therefore still rejected under p=reject in practice. The normative requirement stands, but the standard harbors no illusions about how well it is followed. And that is precisely why the decision to move to reject is one you make with your eyes open, not on the assumption that receivers will do the right thing.

It is worth being clear about what this does not mean. It does not devalue reject. Reject remains the Domain Owner's protection goal, the clearest statement that unvalidated mail is unwanted. The RFC merely reassigns responsibility cleanly: the Domain Owner states what it wants, the receiver decides, with due care, what it does.

The p value is a request, not an instruction.

That is the real payoff of this part. At the very moment DMARC becomes a standard, the same standard records that there is no protocol police. A standard describes how the parties interoperate, not that anyone forces anyone. Turn "DMARC is a standard now" into "reject is enforced everywhere now" and you have misread the standard twice.

The road to reject: deliberate, not reflexive

If reject is a decision and not a formality, the question is what actually drives it. Two questions: who are my senders, and have I seen all of them?

The first question is about indirect mail flows, where things often get lumped together. Plain forwarding, an alumni forwarder or a role address for instance, usually breaks only SPF: the mail arrives from the forwarder's IP, not from the authorized sender, but the DKIM signature stays intact. Such mail still passes DMARC via DKIM. That is exactly the reason for the Section 8 rule not to rely on SPF alone at reject: with forwarding, DKIM is what carries the pass.

Mailing lists are the harder case. A list alters the message, appending a footer or writing a tag into the subject, which breaks the DKIM signature (the cryptographic check covers the message body; see RFC 6377 on DKIM and mailing lists). At the same time the mail comes from the list's server, so SPF no longer aligns with the Author Domain either. Both mechanisms fail, yet the Author Domain still sits in the From. Under p=reject this legitimate mail is rejected, and because list software responds to such rejections with automatic unsubscription, users drop off their lists in droves. The ecosystem has responded with a workaround familiar to anyone who posts to lists: the list rewrites the From to its own address. That is why list mail often no longer shows the original sender in the From. A clean technical way out, ARC (RFC 8617), was not in wide use at the time the RFC was published.

The consequence is uncomfortable but clear: for a domain whose users post to mailing lists, reject is not the self-evident goal. Quarantine can be the right end state here, not as a compromise but because reject hits legitimate mail that no one wants to stop.

The second question, have I seen all my senders, governs the pace. There is a cookbook rule going around that you must spend a month on p=none and then a month on quarantine. The RFC does mention this staging, but as a SHOULD and explicitly only for domains whose users post to mailing lists. It is not a universal waiting requirement. The real variable is not time but completeness: do I know every legitimate sender of my domain? For a new or tightly controlled domain with a manageable set of senders, that is quickly answered, and you can move straight to an enforcement level without a long monitoring phase. For a long-established domain with an unclear sprawl of senders, the opposite holds: watch the aggregate reports until no more surprises show up. Time is only a proxy for completeness here, and a poor one.

What this means in practice

Two of the Section 8 requirements sound technical and are in fact operational decisions.

The first: analyzing reports is mandatory, not optional. Section 8 requires the Domain Owner not only to set up a mailbox for aggregate reports but also to collect and analyze them. That is a MUST, not a good intention. It makes a common practice formally non-conformant: setting a rua entry but never looking at the reports. Do that and you have a DMARC record but no DMARC participation in the sense of the standard. Analyzing here does not mean piling up XML files in a mailbox; it means actually reading the data, usually machine-processed, since the raw formats are barely human-readable.

The second: reject without DKIM is non-conformant. A domain on p=reject that relies on SPF alone and sets no aligned DKIM signature violates a MUST NOT in Section 8. It has the strictest policy and, at the same time, a configuration the standard expressly forbids. This is not a theoretical edge case but a finding that turns up regularly in an audit: reject set, DKIM missing or not aligned.

Both findings confirm what the matrix above shows: the p value is the wrong first checkpoint; conformance is the right one.

A side effect this exposes: the phase in which you analyze the reports is not waiting time but working time. Reading the aggregate reports anyway, you see two things that can be fixed in the same step. First, the SPF record: RFC 7208 caps an SPF evaluation at ten DNS lookups (beyond that the receiver returns a permerror and the SPF check fails), plus a separate limit of two void lookups. Long-grown records with includes for services shut down long ago blow through these limits easily, and monitoring makes such leftovers visible. Second, the DKIM keys: RFC 8301 sets 1024 bits as the hard minimum, below which a signature is invalid, but explicitly recommends at least 2048 bits. Keys still on 1024 are a good candidate for rotation.

Conclusion: conformant is not optimal, and a standard is not a mandate

Let's sum up. DMARC is a genuine IETF standard now, with RFC 9989, but a standard means a consensus specification, not a legal mandate: the RFC forces no one to deploy DMARC and no receiver to enforce reject, and it even bars blind enforcement. Full participation means authenticating cleanly over SPF and DKIM, publishing, and actually analyzing the reports, not reject.

From that follows a sober checklist for any DMARC configuration, your own or a customer's:

• The p value is not the first checkpoint. A p=reject record can be more fragile than a well-run p=none record.

• The first question is conformance: is authentication aligned over SPF and DKIM, and are the reports analyzed?

• Reject is a deliberate decision, not a formality. It presupposes intact DKIM alignment and calls for a look at indirect mail flows, mailing lists above all.

• The pace toward reject is set by the completeness of sender discovery, not by a fixed waiting period.

Once you have internalized this, you read a DMARC record differently: not as a traffic light whose goal is green on reject, but as the expression of a risk decision that has to fit the particular domain.

Want to run this checklist against your own record? Our analysis tool, mailaudit, is a starting point. It checks what the DNS can substantiate: whether a DMARC record exists and with which policy, whether DKIM selectors can be found, whether a RUA target is set and, for reports going to an external domain, authorized there. Two things sit on a different page and belong in the operator's hands: whether the aggregate reports are actually analyzed, and whether no aligned DKIM signature truly exists, since a selector you cannot find is no proof of its absence. The tool shows where the DNS-visible part stands and where a closer look is needed.

With that, the technical arc of the series closes. What remains is the question the technology does not answer: if no RFC forces you to deploy DMARC, who or what does? That is the subject of the final part.

DMARCbis series

1. Overview

2. Tag Changes

3. DNS Tree Walk

4. p=reject / Full Participation (this post)

5. NIS2 (coming)