What we did

On 19 August 2026 we took the Tranco top-1 million list published 17 August 2026 (list ID K9L5W), filtered it to every domain ending in .au — 8,376 of them — and looked up the DMARC, SPF, DKIM and MX records for each using the same engine behind the checker on our homepage. These are DNS lookups only: no mail was sent, and no connection was made to anybody's mail server.

DMARC: published is not the same as enforced

A DMARC record tells receiving servers what to do with mail that fails authentication. The policy tag is the part that matters. p=none asks for reports and nothing else — forged mail is still delivered. Only quarantine and reject actually stop anything.

No DMARC record2,282 · 27.2%

p=none (monitor only)2,656 · 31.7%

p=quarantine1,413 · 16.9%

p=reject2,016 · 24.1%

Malformed / no policy tag9 · 0.1%

6,094 domains (72.8%) publish a DMARC record, but only 3,429 (40.9%) set a policy that actually blocks anything. The rest have done the paperwork and left the door open: a p=none record produces reports for an administrator who may not be reading them, while forged mail continues to arrive in inboxes exactly as before.

A further 128 domains set pct below 100, applying their policy to only a sample of failing mail — a deliberate rollout step, but one that is easy to leave switched on and forget.

SPF is nearly universal, and often toothless

SPF lists which servers may send for a domain. The final mechanism decides what happens to everyone else: -all is a hard fail, ~all a soft fail that most receivers still accept, and neither leaves the record advisory.

-all (hard fail)3,163 · 37.8%

~all (soft fail)3,570 · 42.6%

Neither311 · 3.7%

No SPF record1,332 · 15.9%

Who runs Australian email

Counted over the 7,236 domains with MX records, by the operator behind the lowest-priority mail host. Anything we could not attribute confidently is left in "Other / self-hosted" rather than guessed at.

Microsoft 3652,506 · 34.6%

Other / self-hosted2,047 · 28.3%

Google Workspace1,463 · 20.2%

Proofpoint477 · 6.6%

Mimecast414 · 5.7%

Trend Micro76 · 1.1%

Zoho68 · 0.9%

Barracuda50 · 0.7%

Cloudflare Email21 · 0.3%

Fastmail20 · 0.3%

Does your mail provider predict whether you enforce?

Splitting DMARC enforcement by mail operator. If the platform makes authentication easy — or turns it on by default — its customers should look different.

Mail operator	Domains	Publish DMARC	Enforce it
Microsoft 365	2,506	88.9%	51.3%
Other / self-hosted	2,047	63.5%	32.7%
Google Workspace	1,463	81.5%	32.7%
Proofpoint	477	95.6%	79.0%
Mimecast	414	94.7%	64.7%
Trend Micro	76	90.8%	48.7%
Zoho	68	79.4%	20.6%
Barracuda	50	94.0%	56.0%

Operators with fewer than 25 domains are omitted.

By type of Australian domain

Namespace	Domains	DMARC	Enforcing	SPF	Receives mail
`com.au`	6,331	76.7%	40.7%	89.0%	92.3%
`au (direct)`	553	12.5%	7.8%	15.4%	16.3%
`org.au`	417	79.1%	45.6%	90.9%	91.4%
`gov.au`	401	93.3%	81.3%	93.5%	80.5%
`net.au`	399	52.6%	28.6%	77.2%	85.2%
`edu.au`	255	92.9%	66.3%	95.3%	94.1%

Do the biggest domains do better?

Group	Domains	DMARC	Enforcing	SPF
Top 100	100	96.0%	83.0%	98.0%
Rest of list	8,276	72.5%	40.4%	83.9%

Methodology

Population: Every domain ending in .au in the Tranco list published 17 August 2026 (ID K9L5W, permanently retrievable at https://tranco-list.eu/list/K9L5W) — 8,376 domains. That is the whole .au subset of the list, not a sample.
Measurement: DNS only. TXT at _dmarc.<domain> for DMARC, TXT at the apex for SPF, MX at the apex, and TXT/CNAME at <selector>._domainkey.<domain> for DKIM. No mail was sent and no mail server was contacted.
Why the DKIM number is a floor, not a rate: DKIM selectors are arbitrary strings chosen by whoever set the domain up, and there is no way to enumerate them from outside. We probe 13 common ones, so a domain signing with a custom selector is recorded as "not detected" even though its mail is signed. Treat 60.7% as the lower bound of DKIM use, and do not compare it to the DMARC and SPF figures, which are exact.
Guarding against a silent failure: Every check here reports "not found" for a lookup that timed out, exactly as it does for a domain that genuinely has no record — so an overloaded resolver does not produce errors, it produces a confident and completely wrong result. Our first attempt at this scan hit precisely that: too many parallel workers flattened the upstream resolver, and the run had to be thrown away. The scanner now treats any domain that returns nothing at all as suspect, re-checks a control name known to have both MX and DMARC records, and refuses to record the result until the resolver demonstrably answers. The published run completed with no such backoff triggered.
What this does not measure: We check the apex domain only, so subdomain policies (sp) and per-subdomain records are out of scope except where noted. We do not verify that SPF records resolve within the ten-lookup limit, evaluate DKIM key strength, or check whether reporting addresses accept mail. A domain with no MX may still send mail, which is why the enforcement figures are reported against all scanned domains rather than only those receiving mail.
Point in time: A single scan on 19 August 2026. DNS changes constantly.
Reproducing it: The aggregated results are published as JSON under a CC BY 4.0 licence. The Tranco list ID pins the exact input, and the scanning code is the same engine behind the homepage checker, so any domain in the set can be re-checked by hand.

Corrections welcome. If a domain here is measured wrongly, or you can see a methodological problem we have missed, tell us and we will correct the page and say what changed.