Why DMARC on your main domain does not cover your country-code TLD

If you publish a DMARC record at your main domain and call the job done, you have only finished a fraction of the work. A recent observation in Australia showed that all ten of the country's largest banks enforce DMARC, and seven of them still leave their .au namespace open to spoofing. The same pattern repeats across sectors and across country-code TLDs.

The reason is structural. DMARC is enforced at the DNS zone where it is published, not at the brand level. A record at _dmarc.yourbrand.com says nothing about _dmarc.yourbrand.com.au, _dmarc.yourbrand.uk, _dmarc.yourbrand.fr, or _dmarc.yourbrand.de. Each zone is a separate scope. None inherits enforcement from the parent.

Why the gap exists

Country-code TLDs often produce multiple sibling zones for the same brand. Three patterns create the gap:

• Direct ccTLD registrations. Several country-code registries opened short-form registrations during the 2020s. Australia enabled direct .au registrations in 2022. If your brand only registered yourbrand.com.au, the parallel yourbrand.au may be unregistered or held by a third party who can use it for mail that looks like you.
• Second-level variants. Legacy patterns like .co.uk, .com.au, .co.fr, and .co.jp are common. Each is its own zone.
• Subsidiary, regional, and product domains. Subsidiary brands, regional product lines, marketing microsites, and acquired-company legacy domains all sit in their own zones. None inherits your DMARC.

Why the gap is dangerous

When an attacker finds an unprotected sibling zone, they can send mail that appears to come from your brand at the user-visible From: line. The receiver sees SPF and DKIM pass against the sibling zone, sees DMARC pass on the sibling zone, and accepts the message. The message looks legitimate because, at the visible From: line, it is.

This is the pattern behind the Australian bank observation. The banks had clean DMARC on commbank.com.au, anz.com.au, and so on. The parallel commbank.au, anz.au, and so on were unprotected. A spoofing email from the unprotected zone would pass DMARC alignment, because alignment was checked against the unprotected zone where the message was sent from, not against the protected zone whose record the bank published.

How to discover your own unprotected zones

You cannot fix what you cannot see. Three cheap steps surface the gap:

1. WHOIS search for the brand across relevant TLDs. Look at every ccTLD where your brand operates, plus .com and .net. A parallel zone that is unregistered, or registered to a third party, is the spoofing surface you need to monitor or claim.
2. Certificate Transparency logs. Search crt.sh for your brand string. CT logs show every certificate ever issued for a domain, including sibling zones. A registered sibling zone with a valid certificate is a live signal that someone can send mail from it.
3. Registrar portfolio audit. List every registrar account your organisation has opened. Acquired companies leave behind domains on their original registrars. Marketing microsites often live on personal accounts. Each is a sibling zone you may not have covered.

How to close the gap

Once you have the list, publish DMARC on every zone you control. The standard pattern is the same at every zone:

• Start with p=none plus a reporting address. This lets you collect aggregate reports from receivers without affecting mail flow.
• Move to quarantine once the zone only sends mail you expect.
• Move to reject once quarantine is stable.

The cheap fallback matters: publish _dmarc.yourbrand.tld with p=reject for every zone you own, even if no legitimate mail is sent from it. An unused zone with p=reject is far safer than an unused zone with no policy at all.

Why single-zone monitoring misses the gap

Most DMARC monitoring tools are configured for one apex domain. They answer "is our primary zone clean?" and stop there. That answer is correct but incomplete. The gap is invisible until you enumerate all zones first. A monitoring approach that asks "which of our zones are unprotected?" surfaces the gap explicitly. This is the reason multi-domain coverage matters for email authentication, and it is why DMARCFlow exposes per-zone status across every domain in your account from a single DNS Health panel. The same per-zone data is available through DMARCFlow Connect for SIEM and SOAR pipelines, so a new sibling zone appearing anywhere in your portfolio triggers an alert the moment it is registered.

A checklist you can use today

1. List the brand and every country where it operates.
2. Search WHOIS for the brand across every relevant TLD. Note which zones are registered and to whom.
3. Search CT logs for the brand string. Note every zone that has ever had a certificate.
4. Audit registrar accounts for legacy domains.
5. For every zone you control, publish or verify DMARC. Use p=none first, then move to quarantine and reject.
6. For every zone a third party could register (parallel ccTLD variants), monitor for new registrations and consider defensive registrations where the brand is strategically important. Watch-list workflows like DMARCFlow's Lookalike Domain Radar are built for exactly this.
7. Configure your monitoring tool to surface unprotected zones explicitly, not just authenticate the apex. DMARCFlow's DNS Health view does this by default across every added zone.

If your monitoring tool cannot show you sibling-zone coverage, your monitoring is not yet complete. The Australian bank measurement is not a story about one country. It is a story about a structural gap that exists wherever a brand holds more than one domain.

Frequently Asked Questions

Does DMARC at brand.com cover brand.com.au?

No. DMARC is enforced per DNS zone. Each zone needs its own DMARC record.

Why does my apex have DMARC but my country-code variant does not?

DMARC does not inherit across zones. You have to publish a separate record at every zone you control.

How do I find every domain I own?

Search WHOIS across relevant TLDs, scan Certificate Transparency logs for your brand string, and audit every registrar account your organisation has opened.

Can attackers spoof my brand from an unprotected sibling domain?

Yes. The receiver sees SPF, DKIM, and DMARC pass against the sibling zone and accepts the message.

Is publishing DMARC at every zone enough, or do I need SPF and DKIM at each?

You need SPF and DKIM at every zone that sends mail. An unused zone with p=reject and no SPF/DKIM is still safe.

How does DMARCFlow multi-domain monitoring work?

One account, one DNS Health view, every zone. DMARCFlow surfaces per-zone status across every domain you add, including sibling and country-code variants.