DMARC for multiple domains is mostly a question of order. One US management company running 87 domains went from fewer than half at p=reject to 76 in under four weeks, with 10 at quarantine and 1 at p=none. Each registered domain needs its own DMARC record (subdomains inherit their parent's), but all of them can report to one address, which is what made the rest possible: one view, unused domains locked, the senders the reports exposed fixed, then enforcement domain by domain.
The company provides management services to a group of businesses and runs the domains for all of them. It is a paying yourDMARC account; we have left its name and its domains out. The policy, DNSSEC and MTA-STS counts below were checked against live DNS on 2 November 2026. The rest come from our dated rollout records.
What did the starting point look like?
In early October 2026 the company had 87 domains in its DNS account, but only 23 of them were in its DMARC dashboard. Another 44 already sent their aggregate reports to us without being in the dashboard, so nobody saw them. Fewer than half of the 87, about 39, were at p=reject.
The remaining 64 domains were added in a single day. From then on every domain's reports landed in the same place, so the team could see, per domain, which services sent mail and whether that mail passed SPF or DKIM with alignment.
Why lock the unused domains first?
Unused domains are the safest place to start, because nothing legitimate sends from them, and they are easy to spoof because nobody watches them. Twenty of the 87 had no mail server and no SPF record. All 20 went to p=reject in one day, and the next day each got the SPF record v=spf1 -all, which authorises no server at all.
That covered almost a quarter of the estate. A domain without an MX record can still be used to send mail, which is exactly why these domains need an explicit policy rather than being left alone. Each registered domain needs its own _dmarc record, because a policy never carries across to a different domain: sp= only covers subdomains of the domain that publishes it.
What does a fully locked unused domain look like?
A fully locked unused domain publishes four records: a reject policy, an SPF record that allows nothing, a null MX and an empty DKIM key. Together they tell receivers that no mail from or to the domain is legitimate. For a domain example.com:
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:reports@example.net"
example.com. TXT "v=spf1 -all"
example.com. MX 0 .
*._domainkey.example.com. TXT "v=DKIM1; p="
The null MX (RFC 7505) says the domain accepts no mail. The empty p= in the DKIM record revokes any key a forged message might claim. In this rollout the 20 domains got the first two records in October and the null MX on 2 November 2026; the empty DKIM key is the one left to add.
When the aggregate reports go to an address on a different domain, that domain must authorise it with a record such as example.com._report._dmarc.example.net TXT "v=DMARC1". Without it, receivers drop the reports. Sending every domain's reports to one address is what makes a single view across many domains possible.
What did the DMARC reports uncover?
The reports showed several legitimate senders failing authentication, each a fault that would cost mail once policies tightened. A DNS check can show that a DKIM key is missing, but only the reports show which real mail depends on it, and how much.
- Websites signing with keys that were never published. Seven live websites on one web host signed their mail with DKIM, but their public keys were missing from DNS. Six staging copies of those sites did the same. Once all 13 keys were published, the live sites' mail passed from the next day.
- Google Workspace with DKIM never set up. Twelve domains on Google Workspace had no DKIM key, and a thirteenth had a key in DNS but signing switched off. All 13 now sign.
- Vendors sending without domain authentication. An online forms vendor and a bulk email service were sending as company domains without authenticating as them. The bulk email sender's domain was held at quarantine. The forms vendor sends as a domain already at reject, so its messages are rejected until the vendor is set up to sign for that domain.
- Failures that were not spoofing. Some failures came from recipients' security gateways passing messages on, which breaks SPF. Reading those as attacks would have wasted time.
How did the sending domains move to enforcement?
About 39 domains were already at reject before the rollout. The other sending domains moved up one step at a time, towards quarantine and then reject, and a domain was meant to move only once its reports showed its legitimate sources passing with alignment. A domain with an open problem stayed where it was while the others moved on.
One slip shows why that matters. Four of the website domains went to quarantine before the missing website keys had been spotted, and 27 legitimate messages were quarantined until the keys were published. Three more website domains had been at reject since before the rollout, and about 26 of their legitimate messages were rejected for the same reason.
By mid-October 61 domains were at reject, and today 76 are. The policy records themselves moved to hosted DMARC: each domain's _dmarc name became a CNAME pointing at a record we host, so later policy changes are made in the dashboard instead of in the DNS account.
What else was hardened beyond DMARC?
DMARC stops others using a domain in the From address, at receivers that enforce it. It does not protect DNS answers from tampering or mail in transit from downgrade, so three more controls were added across the estate.
- DNSSEC. Signing was switched on for all 87 zones, and 76 of them now have a DS record at their registrar and validate. The other 11 still need their DS record added at the registrar.
- MTA-STS. 23 mail-receiving domains publish an MTA-STS policy, with TLS reporting switched on. The policies are in testing mode, which reports problems but does not yet block a downgrade. Enforce mode is the next step.
- Lookalike watching. Our Certificate Transparency watch looks for new certificates on names that look like the company's domains. In late October the watch flagged its first lookalike.
Where does the rollout stand today?
As of 2 November 2026, 76 of the 87 domains are at p=reject, 10 are at p=quarantine and 1 is at p=none. Each of the remaining eleven moves only when its own reports show its legitimate mail passing.
All 87 domains report to one dashboard, every policy is hosted, and the unused domains have reject policies, SPF records that allow nothing and a null MX.
What can an MSP or multi-brand company take from this?
The order matters more than the tooling: one view first, unused domains next, report-driven fixes, then staged enforcement. That order moved most of this estate to reject in weeks, and the one slip came from moving four domains before their missing keys had been found.
The same steps apply to an MSP running client domains. Here the unused-domain step closed almost a quarter of the estate in a day, and it needs no report data at all. If you would rather hand the work over, our managed DMARC service runs the same rollout for you, and the partner programme covers MSPs managing client domains.
Key takeaways
- Bring every domain into one dashboard before changing any policy; here 64 of 87 were missing.
- Lock unused domains with p=reject, v=spf1 -all, a null MX and an empty DKIM key.
- Authorise external report addresses with a _report._dmarc record, or the reports never arrive.
- Read the reports before moving a sending domain: they show missing DKIM keys, unauthenticated vendors and forwarding noise.
- Move sending domains one step at a time, and hold any domain whose reports still show a legitimate failure.
- Add DNSSEC, MTA-STS (testing mode with TLS reporting first, then enforce) and lookalike watching to cover what DMARC alone does not.
