The DKIM Gap: Why 29.5% of Australian DMARC Records Aren't Actually Protecting Email

In March 2026 we scanned 3,930 of Australia's most important domains — every state and federal government agency, every ASX-listed company, the largest schools, hospitals, banks, mining companies, retailers, and not-for-profits. We checked DMARC, SPF, DKIM, MTA-STS, and TLS-RPT.

The headline finding was the one most Australian DMARC reports have been telling us for years: adoption is improving but enforcement is lagging. 68.7% have a DMARC record. Only 26.2% are at p=reject. That story is well-worn.

The finding that surprised us was different — and it has direct consequences for any business that thinks it's protected by DMARC today.

The DKIM gap: 29.5% of Australian DMARC records are doing less than people think

Here's the number we want you to sit with: 29.5% of Australian domains have a DMARC record but no detectable DKIM key. Across the dataset, 68.7% have DMARC, but only 39.2% have DKIM configured.

That gap matters because DMARC is not a standalone control. It's a policy layer that sits on top of two underlying authentication checks — SPF and DKIM. For DMARC to actually pass, at least one of those two has to align with the From: domain. And in practice, only one of them survives the most common thing email does in the real world: forwarding.

Why "DMARC + SPF only" breaks the moment email is forwarded

Most Australian businesses don't think about email forwarding, but their customers do it constantly. A staff member sets up a forward from their old work address to their new one. A customer forwards an invoice to their bookkeeper. A board member forwards a report to their assistant. A mailing list rewrites the message and sends it on.

When email is forwarded, the IP address that hands the message to the recipient is no longer the original sender's IP. That's an SPF failure — and it's the correct outcome. SPF is a check on the sending IP, and the IP genuinely changed.

DKIM is what saves the email. DKIM is a cryptographic signature attached to the message itself. As long as the message body and the signed headers aren't modified in transit, the DKIM signature stays valid no matter how many times the email is forwarded.

This is why the standard email authentication advice is the same everywhere: SPF and DKIM are not redundant. You need both. SPF protects against direct-path spoofing. DKIM protects against everything else.

What this looks like in production

If your domain has DMARC at p=reject, SPF configured, and no DKIM, here's what happens to your legitimate forwarded email:

1. The original message is sent from your authorised mail server. SPF passes at the original hop.
2. The recipient forwards it to a colleague, supplier, or external address.
3. The forwarding server resends the message from its own IP. SPF fails at the new hop because that IP isn't in your SPF record.
4. There is no DKIM signature to fall back on.
5. DMARC sees no aligned authentication. With p=reject, the receiving server discards the message.

The legitimate email never arrives. The sender thinks it was delivered. The recipient never sees it. And because most receivers don't bounce p=reject failures back to the sender (that's the whole point of reject), no one knows it happened.

This isn't theoretical. It's the most common reason businesses pause DMARC enforcement after going live: legitimate email starts disappearing and nobody can explain why.

Why so many Australian domains are stuck without DKIM

From the 3,930 domains we scanned, the pattern is consistent: organisations got DMARC right at the front door (publish a record, set rua, point it at a monitoring tool) and got SPF mostly right (list your sending services). DKIM is where progress stalls.

There are a few reasons:

• DKIM is per-service, not per-domain. SPF is a single DNS record at your apex. DKIM requires a separate signing key for every email service you use — Microsoft 365, Google Workspace, Mailchimp, HubSpot, your CRM, your invoicing system, your helpdesk. Each one needs its own DKIM record published at its own selector.
• The DNS records aren't where you'd expect. SPF lives at yourdomain.com.au. DKIM lives at selector1._domainkey.yourdomain.com.au — a subdomain you have to know exists. If you've never been told the selector name, you can't add the record.
• Vendors don't always volunteer the keys. Some platforms enable DKIM signing automatically using a shared signing domain (which doesn't align with your domain for DMARC purposes). Others require you to dig through admin settings to generate a customer-specific key. The default is usually the cheaper, non-aligning option.
• Scanners can miss DKIM keys. Our scanner checks for keys at common selectors. Some domains may have DKIM published at non-standard selectors and show up as "no DKIM" in our data — which is itself a finding. If your scanner can't find your DKIM record, neither can the receivers checking your email.

How to tell if your domain has the gap

Three checks will tell you where you stand:

1. Does your DMARC record exist? Look up the TXT record at _dmarc.yourdomain.com.au. If it starts with v=DMARC1, you have one.
2. What's your DMARC policy? Look for p=none, p=quarantine, or p=reject. If you're at none, the gap is less urgent — failing email is still being delivered. If you're at quarantine or reject, the gap matters now.
3. Is DKIM signing your outgoing mail? Send an email from your domain to a Gmail account. Open the message, click the three-dot menu, and choose "Show original". Look for a DKIM line in the authentication results. It should say PASS with d=yourdomain.com.au. If it says d=mailservice.com or there's no DKIM line at all, you have the gap.

How to close the gap

Closing the DKIM gap is mechanical, but it has to be done service by service. There's no central switch.

1. Inventory your sending services. Every system that sends email "from" your domain needs DKIM. Microsoft 365, Google Workspace, your CRM (HubSpot, Salesforce, Pipedrive), your marketing platform (Mailchimp, ActiveCampaign, Campaign Monitor), your transactional sender (SendGrid, Postmark, Mailgun), your invoicing tool (Xero, MYOB), your helpdesk (Zendesk, Intercom). If you're not sure what's sending mail, your DMARC aggregate reports will tell you — that's what they're for.
2. Enable DKIM in each service's admin panel. Every platform has its own process. Microsoft 365 generates two CNAME records that point to keys hosted by Microsoft. Google Workspace gives you a TXT record to publish. Mailchimp generates a CNAME. The exact steps differ; the outcome is the same — a DNS record that lets receivers verify the signature.
3. Publish the DNS records. Each service hands you a record to publish. Add it to your DNS exactly as supplied. Wait 24–48 hours for propagation, then re-test.
4. Verify alignment. DKIM passing isn't enough on its own — it has to align with the From: domain for DMARC to consider it a pass. Check by sending a test email and reading the headers, or by reading your DMARC aggregate reports.

For a small business with two or three sending services, this is a half-day's work. For a mid-sized organisation with ten or fifteen integrations, it's a project — and it's the project most organisations defer indefinitely after publishing their DMARC record.

The sector picture

The DKIM gap shows up everywhere in our data, but not evenly. State Government leads overall with an average score of 66/100 — and even there, DKIM remains the weakest of the three controls. Education at the school level trails at 40/100, with DKIM adoption far below DMARC adoption.

The pattern is consistent across sectors: DMARC and SPF go up together; DKIM lags. Organisations with mature security programs (banks, federal agencies, large ASX listings) are closer to closing the gap. Sectors with smaller IT teams (schools, not-for-profits, SMEs, hospitality) are further from it.

For the full sector ranking — including DKIM rates, DMARC enforcement rates, and overall scores for each of the 20 sectors we measured — see the State of DMARC Adoption in Australia 2026 report.

What this means for compliance

Several Australian frameworks now reference email authentication: SMB1001:2026 requires DMARC, SPF, and DKIM at Levels 2 and 3. PCI DSS 4.0 includes DMARC under anti-phishing controls. The ACSC recommends DMARC at p=reject.

None of these frameworks treat DMARC-without-DKIM as compliant. Having a DMARC record published is the visible signal, but the controls underneath have to be present and aligned for the framework's intent — preventing spoofing and protecting deliverability — to actually be met.

If your organisation has been told it's "DMARC compliant" and the underlying domain doesn't sign mail with DKIM, the compliance claim is technically defensible but practically thin. An auditor checking the framework intent rather than the checkbox will spot the gap.

The bottom line

DMARC adoption in Australia is genuinely improving. Two-thirds of major domains now publish a record, and the trajectory is positive. But the gap between "has DMARC" and "is protected by DMARC" is wider than the headline numbers suggest. Nearly a third of Australian domains with DMARC records don't have the DKIM key needed to make that DMARC record withstand the most ordinary thing email does — getting forwarded.

If you're managing email authentication for an Australian business, the highest-value next move probably isn't progressing your DMARC policy from p=none to p=quarantine. It's making sure DKIM is signing every service that sends mail as you. Without that, progressing the policy will eat your legitimate forwarded email.

For the full data — sector-by-sector scores, methodology, the executive summary PDF, and the complete CSV dataset — visit our State of DMARC Adoption in Australia 2026 research report. For more on how to fix specific issues, read our guide on DMARC compliance in Australia for 2026 or why emails go to spam and how to fix it.