How Gov.uk Uses DMARC to Protect Non-Existent Domains

Most organizations publish DMARC for the domains they use. Gov.uk appears to do something different: it publishes DMARC and SPF reject records for subdomains that don't exist. If you query DNS for any random string under gov.uk - something that has never been delegated, never registered, never used - you get back a DMARC policy that says reject. Not no record found. Not nxdomain. A real TXT record with `v=DMARC1;p=reject`. That's unusual. And it might be one of the most effective anti-phishing measures a large organization has quietly deployed. ### What gov.uk is actually doing The pattern was documented by security researcher Joe Tiedeman, who noticed it while investigating phishing resistance around UK government domains. When querying TXT records for undelegated gov.uk subdomains, the namespace returns authentication records regardless of whether the subdomain exists. For example, running `dig TXT randomstring.gov.uk` returns: ``` randomstring.gov.uk. 1800 IN TXT "v=DMARC1;p=reject;rua=mailto:govuk-rua@dmarc.service.gov.uk" randomstring.gov.uk. 1800 IN TXT "v=spf1 ?all" ``` The response is a wildcard at the zone level. Any label under gov.uk that isn't explicitly delegated gets this response. The DMARC record applies by inheritance - `_dmarc.gov.uk` at the apex covers every subdomain because there is no override at the subdomain label. ### Why this matters for anti-phishing Attackers commonly abuse domain names that don't exist. They register `hmrc-tax-refund.gov.uk`, `secure-hmrc-payment.gov.uk`, or other plausible labels under real government namespaces. These domains are available because the organization hasn't claimed them, and they pass surface-level scrutiny because they look official. In normal DNS delegation, an undelegated name returns nothing - or more precisely, an NXDOMAIN that tells resolvers the name doesn't exist. Receivers see no SPF, no DMARC, no signal - and often no reason to reject the message. The domain isn't in the registry with a bad reputation, so it slides through. Gov.uk's wildcard record changes this. When a receiver checks `_dmarc.randomstring.gov.uk`, it finds a `p=reject` policy. But here's the detail that matters: the receiver isn't finding an explicit record at `randomstring.gov.uk` - it's receiving a DNS answer from the wildcard at the apex of gov.uk, because no record exists at that label. This is a synthesized answer from the zone's wildcard configuration, not a delegated record. This works at the namespace level, not just for specific registered domains. ### What this approach prevents The strategy closes the gap for spoofing attempts using non-existent subdomains. It also addresses the problem of abandoned or parked subdomains - labels that were once used but are no longer actively managed. If a subdomain isn't in DNS, it still carries a policy that receivers can evaluate. The key insight: most anti-spoofing controls protect domains you operate. This approach protects the surrounding namespace - every label that could be registered by someone else. Not all receivers interpret missing DMARC records the same way. Some walk the DNS tree (checking `randomstring._dmarc.gov.uk`, then `_dmarc.gov.uk`, then `gov.uk` until they find a record). Others stop at the subdomain label and apply no policy. Gov.uk's approach sidesteps this ambiguity by making every possible subdomain return a reject policy rather than nothing. The wildcard at the apex means the record exists at every label - receivers that walk the tree find it; receivers that stop early also find it. ### What other UK public sectors do differently The same pattern does not appear in nhs.uk or gov.scot. Querying non-existent subdomains under those namespaces returns no DNS response - no TXT records, no DMARC, nothing. The behavior appears to be specific to gov.uk and possibly related to how the .gov.uk zone is managed at the registrar level. This suggests it is a deliberate choice, not a default configuration. But neither GDS nor NCSC has published documentation describing this as an intentional anti-phishing control. The mechanism is observable; the intent is not officially confirmed. ### What organizations can learn from this The lesson is not "copy gov.uk's DNS configuration." It's narrower and more useful: if your organization has domain names that could be registered by attackers - and every organization with a recognizable brand does - you have a gap. The gap isn't that your active domains lack DMARC. It's that every label under your domain that you haven't explicitly claimed is available for abuse. Three practical steps: **Audit your namespace.** Know what subdomains exist in DNS. Include parked domains, old marketing labels, acquired subdomains from past mergers, and any label you registered once and no longer use. **Close orphaned labels.** If a subdomain has no active use, consider whether it should exist in DNS at all. Removing it means receivers see no record - which is better than a forgotten record with `p=none` that provides no protection. **Publish explicit wildcard records.** If you can't remove a subdomain from DNS (because you need it to exist but not be used for mail), an explicit wildcard DMARC record at `*._dmarc.yourdomain.com` with `p=reject` closes the gap. This is more reliable than relying on tree-walking behavior that varies by receiver. Monitoring aggregate reports across your full namespace matters here. If you don't know what subdomains are sending mail, you don't know what you need to protect. ### How to check your own DMARC coverage Run a DNS query against a subdomain you don't use - something random - and see what comes back. If you get a DMARC record back, you have wildcard coverage. If you get nothing, either your DNS is returning nxdomain or you simply haven't published anything at that label. For a more complete picture, aggregate DMARC reports over 30 to 90 days will show you every subdomain that receivers are seeing mail from. DMARCFlow collects and parses these reports across your entire domain portfolio - including subdomains that aren't actively monitored. That data is what lets you close gaps before attackers find them. --- ## FAQ **Does gov.uk's approach apply to private organizations?** Yes. Any organization that controls its own DNS zone can publish wildcard DMARC records. The mechanism is not restricted to government domains. **Is this documented by NIST, NCSC, or RFC?** No public documentation from GDS, NCSC, or IETF describes this as an intentional control. The behavior is observable and the intent is inferred from the pattern - not confirmed by official guidance. **Can a wildcard DMARC record break legitimate subdomains?** Yes, if a subdomain exists in DNS but has no mail-sending infrastructure and no explicit DMARC override, the wildcard record will apply and receivers will reject mail from that subdomain. Audit active mail-sending subdomains before publishing a wildcard `p=reject` policy. **How does this differ from subdomain-level DMARC policies?** Subdomain-level DMARC uses the `sp=` tag to set a policy for child domains. A wildcard record is different - it catches every label that has no explicit record, including labels that don't exist in DNS at all. Both approaches reduce spoofing, but the wildcard covers a broader surface.