BIMI requires a setting the standard deleted

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: two glass rulebooks facing each other, one page crumbling into light

Sometimes a standard and its usage drift apart slowly, without anyone noticing. In email there is one case where the divergence is total, documented on both sides, and perfectly visible: you only need to read two documents published four months apart.

The first removes a setting from the DMARC standard. The second still requires it.

That setting is called pct.

What the DMARC standard did in May 2026

DMARC was republished in May 2026 as RFC 9989, on the Standards Track, and that publication obsoletes RFC 7489 and RFC 9091. The change of status is an event in itself: until then, DMARC was only an informational document.

Along the way, the standard did some housekeeping. Appendix A.6 is titled “Removal of the ‘pct’ Tag”, and its explanation is blunt:

“Operational experience showed that the ‘pct’ tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.”

The IANA registry of DMARC tags now carries the note that closes the case: pct is marked “historic”.

A p=quarantine with pct=50 was meant to apply the policy to half the traffic. In practice every operator did what it wanted with it. The standard chose to remove the tag rather than keep describing a fiction.

What BIMI still requires

BIMI is the mechanism that displays a brand’s logo next to its messages. It rests entirely on DMARC: no strict policy, no logo.

The BIMI specification, in its version dated 1 May 2026, says this:

“The policy record MUST express either a Requested Mail Receiver policy of ‘quarantine’ with an effective percentage of 100%, or a Requested Mail Receiver policy of ‘reject’ (with any percentage value).”

The BIMI Group implementation guide is more direct still: “Note: ‘None’ policies or ‘pct’ less than 100 percent are not accepted”.

And Google’s documentation, updated on 26 August 2026, leaves no ambiguity about what it expects:

“The percent option (pct) must be set to 100. This value applies the DMARC policy to all outgoing mail (100 percent) from your domain.”

So here we are in September 2026. The DMARC standard in force has removed the tag. Three separate documents, including Google’s, still ask for it.

How you get out of this contradiction

The answer fits in one sentence, and it is reassuring: do not publish pct at all.

The default value of the old tag was 100. A DMARC record without pct therefore behaves, for any operator still reading that tag, exactly like a record with pct=100. And for an operator following RFC 9989, there is simply nothing to ignore.

A record that satisfies both readings looks like this, and it contains no exotic values:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com

Adding pct=100 is not a mistake, it is a redundancy with the advantage of being readable by operators still on the old reading. Writing pct=50, on the other hand, drops you out of BIMI without protecting you from anything.

The subdomain, the oversight that costs you the logo

The BIMI specification is not satisfied with the organizational domain policy alone. It describes the algorithm the receiver follows, and step 8 is a guillotine:

“If the DMARC record for the Author Domain or Author Organizational Domain includes a subdomain policy, and that subdomain policy is sp=none then BIMI processing MUST NOT be performed for this message.”

Many companies have hardened their main domain while leaving sp=none, precisely to avoid breaking sends from poorly inventoried subdomains. That caution is common, and it cancels BIMI.

The sp tag itself is still in RFC 9989. On that point, standard and implementation agree.

What this contradiction says about the rest

It would be easy to turn this into an accusation of incompetence. That would miss the point.

BIMI is not a published standard: it is a working document, rewritten regularly, whose latest version expires on 2 November 2026. An operator’s documentation, on the other hand, describes what its machine does today. The two live at different speeds, and nothing synchronises them.

The practical consequence is this: in deliverability, the standard says what ought to be, the operator’s documentation says what is. When they diverge, the second one decides the fate of your messages.

What to do tomorrow morning

Query your DMARC record and read it in full, without summarising it.

If you find a pct other than 100, you have two problems rather than one: a policy applied unpredictably depending on the operator, and a logo that will display nowhere.

If you find sp=none, know what that caution buys you. It avoids breaking a forgotten stream, it forbids BIMI, and it leaves your subdomains on a weaker policy than the one Gmail requires from bulk senders.

And if you find no pct at all, do not add one to look modern. Absence is here the most correct answer on both sides.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.