Build1 publisher3 min readPublished
Five fields in the aggregate XML decide when DMARC can leave p=none
Publishing p=none starts an XML report feed and enforces nothing. A practitioner sequence for getting a domain to p=reject turns on an owned sender inventory, aligned DKIM and a written condition for each step.
The Engineer · Build desk
What happened
- A dev.to write-up argues that stalled DMARC rollouts look alike: a p=none record, an aggregate report feed nobody reads, and no defined condition for moving to p=quarantine.
- Its sequence runs from p=none with rua= reporting through aligning every known sender, quarantine at a low pct=, stepped pct= increases with observation periods, p=reject, then sp=reject for subdomains.
- Third-party senders such as marketing platforms, ticketing systems, CRM tools and payment processors often cannot do DKIM without a support request, and finding them after the move to quarantine is the most common cause of rollback.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Writing the promotion condition down is what makes p=none a stage someone can fail to leave; absent it, a domain can sit in monitoring for years while the record implies protection.
- constraint The inventory sets the schedule: enforcement cannot be dated until every sending service has a named business owner and a known SPF or DKIM capability.
- cost Quarantine at a low pct= means an undiscovered sender loses a fraction of its mail and shows up in the next report; the same mistake made at p=reject costs the whole stream.
- exposure Enforcing on the parent domain alone leaves a forgotten subdomain as a usable spoofing address for a phishing campaign.
Publishing p=none buys a data feed and nothing else. Receivers send aggregate XML to the address in the rua= tag, in the format RFC 7489 Appendix C defines, and none of that traffic changes delivery [9][20]. Five fields in the file carry a rollout decision: the source IP, the count, the SPF result, the DKIM result and the disposition [20][1]. What a decision needs is one number per sender, the count of messages that would fail under the policy you are proposing to publish [21]. A short script gets that out of a large file [20][21].
The stall, in the dev.to post's account, is that nobody is assigned to run the script. A policy record does not supply a named owner for the report feed, a documented list of legitimate sending sources including third parties, or a written condition for each policy transition [11]. Without an owner and an exit condition, the record sits at p=none indefinitely, on a policy that is monitoring only [10]. The author's position is that the specifications are stable and well documented, and the failure is sequencing [3].
Alignment is the reason the reports outrank the record. SPF (RFC 7208) authorises sending hosts by IP address, and DKIM (RFC 6376) authorises messages by cryptographic signature [4][5]. Either can pass for a domain the recipient never sees: SPF against an envelope domain that does not match the From header, DKIM against a signing domain that is never displayed [8]. DMARC (RFC 7489) binds both to the visible From domain, and it is the only one of the three that carries an instruction to the receiver [6][7]. A source that passes SPF but fails alignment fails DMARC [24]. So the inventory records, per sender, whether it can be configured for SPF, DKIM or both, which domain it sends as, its volume and recipient population, and its business owner [12].
The pct= tag applies the policy to part of the mail stream [16]. At a low percentage, an undiscovered sender at the quarantine step is survivable, and each increase is meant to be followed by a defined observation period and a check of the reports for new failures [16][15]. Moving to quarantine while a legitimate source still fails alignment produces delivery failures that look like an outage [22].
A record on the organisational domain does not reach subdomains unless an sp= tag sets a subdomain policy or a wildcard record covers them [14]. The sequence puts sp=reject last, after subdomain senders are inventoried, and p=reject before it, since reject is the only value that stops delivery of unauthenticated mail using the domain [15][17]. BIMI sits downstream of all of it, requiring an enforced DMARC policy and a Verified Mark Certificate [19].
This is one practitioner's write-up, and it asserts that most stalled rollouts share the same profile without giving a count [1]. The sequence transfers to a given mail estate only if every legitimate sender appears in the aggregate reports during the observation window. A quarterly mailer run by a vendor nobody remembers buying will not, and the inventory of business owners is what surfaces it [12][13].
What to watch
- Whether the author publishes the parsing script and a length for the observation period; the post does not give a number of days.
- A measured dataset of stalled rollouts would test the claim that most of them stall at the same point.
- Any third-party sender that starts signing DKIM for customer domains without a support ticket removes the step that sets the schedule.