How gov.uk Uses DMARC Reject Records to Protect Non-Existent Domains (And What You Can Learn From It)

Every few months, someone posts on a DNS or email security forum about a strange discovery: gov.uk has DMARC records published for subdomains that, as far as anyone can tell, don't exist. The natural conclusion is that someone misconfigured something.

That's wrong. The configuration is correct, and it's one of the more interesting anti-phishing patterns in practical use by a major government domain.

What the gov.uk pattern actually looks like

Query the DNS for any plausible but non-existent .gov.uk subdomain and you will often receive a v=DMARC1; p=reject response - even when that subdomain has no web presence, no mail servers, and no active owners on the register.

For example, if you check nonexistent-subdomain.gov.uk, you get a DMARC reject policy. The domain does not host email. It does not send mail. But an attacker who tried to set up sending infrastructure on that subdomain would find it already locked down at the authentication layer.

The gov.uk team publishes these records proactively, before the domains are registered or delegated. They are not waiting for a subdomain to be activated before applying DMARC protection.

Why this works as anti-phishing infrastructure

The threat model here is typosquatting and subdomain hijacking. An attacker who wants to impersonate a government entity might register my-agency.gov.uk or exploit a forgotten subdomain that was previously delegated but has since lapsed.

With a preemptive DMARC reject record, that attack fails at the authentication layer before it reaches any inbox. The attacker sets up mail servers, tries to send, and the receiving mail system checks DNS, finds p=reject, and rejects the message. No inbox delivery, no phishing payload, no reputation damage to the real domain.

This is not theoretical. Government domains are frequent impersonation targets in phishing campaigns precisely because they carry inherent trust. Locking down the namespace proactively denies attackers the ability to register or abuse subdomains that the government hasn't gotten around to using yet.

How attackers exploit unregistered subdomains

The conventional thinking on DMARC is that you publish a policy for domains you control and that are actively sending mail. The gov.uk pattern challenges that assumption by addressing a different attack surface: subdomains that no one has registered yet.

Unregistered subdomains can be exploited in several ways:

• Typosquatting: registering goverrnment.gov.uk or similar common misspellings and sending from it
• Expired delegation: a previously active subdomain that was allowed to lapse and can be re-registered by someone else
• Subdomain takeovers: cloud services or SaaS tools that leave orphaned DNS entries that can be claimed by a third party

When a domain has no DMARC record, a sender can claim any unclaimed subdomain and send mail that passes SPF - if the new owner's server IP is included in the published SPF record - or fails SPF without consequence. DMARC alignment does not apply if there is no policy to check.

With p=reject already in place, none of these attacks work - even on subdomains the government hasn't used yet.

What organizations can learn from this

The gov.uk pattern is not just for governments. Any organization with a large namespace - particularly one with many subdomains, legacy systems, or frequent provisioning of new services - should consider proactively publishing DMARC reject records for subdomains that are not yet active.

The principle is straightforward: if a subdomain exists in your namespace but is not authorized to send mail, it should have a DMARC reject policy. This prevents the subdomain from being weaponized before it is activated.

This approach requires some discipline:

• Namespace awareness: you need to know what subdomains exist in your DNS even if they don't send mail
• Proactive publication: the DMARC record should be published before the subdomain is activated for sending, not after
• Monitoring: aggregate reports will show when something tries to send from protected subdomains - which is useful signal

How to implement preemptive DMARC protection on your own namespace

The implementation approach depends on how your DNS is structured and how many subdomains you manage.

For small namespaces: manually audit your DNS to identify subdomains that are registered but not sending mail. Publish v=DMARC1; p=reject for each. Use a wildcard record if your DNS provider supports it and if you are confident no subdomains in that zone will ever need to send mail.

For large namespaces: treat DMARC policy publication as part of your DNS provisioning workflow. Any new subdomain should automatically receive a DMARC reject policy at creation, and that policy should be updated when the subdomain is activated for sending. DMARC aggregate reports become your audit trail - unexpected RUA reports on protected subdomains indicate attempted abuse.

For delegated or third-party subdomains: if you delegate subdomains to partners or customers, require them to publish their own DMARC records. Your namespace-level reject policy will protect against subdomain hijacking within your zone.

How DMARCFlow helps

Implementing the gov.uk pattern across a large or fast-changing namespace is not a one-time task - it is an ongoing operation. DMARCFlow handles the core workflow: it discovers which subdomains are missing DMARC records, lets you set default reject policies for new subdomains as they are provisioned, and surfaces aggregate report signals when something tries to send from a protected subdomain so you can investigate rather than having it disappear into a quarantine you never check.

The gov.uk pattern is essentially a best practice for domain hygiene. DMARCFlow makes it operational at scale.

FAQ

Does publishing DMARC on non-existent subdomains cause any deliverability problems?

No. Reject policies on subdomains that do not send mail have no impact on legitimate email. Receiving mail systems only check DMARC records when a message arrives from that domain. If no one is sending from unused-subdomain.example.com, nothing is checked and nothing fails.

Can I use a wildcard DMARC record to protect all non-existent subdomains at once?

Yes, if your DNS provider supports wildcard records and if you are certain no subdomain in that zone will ever send mail. If you expect any subdomain to send mail in the future, publish individual records as those subdomains are activated rather than relying on a wildcard.

How do I know which subdomains in my namespace are at risk?

Any subdomain that is delegated but not actively monitored is a potential vector. Legacy DNS entries, forgotten SaaS integrations, and expired cloud service delegations are the most common sources of risk. A DNS audit combined with DMARC aggregate report monitoring will reveal which subdomains are being probed or used for sending.

Does this pattern apply to commercial organizations or only governments?

Any organization that is a frequent impersonation target - financial institutions, healthcare providers, SaaS vendors, e-commerce platforms - benefits from this approach. Phishing campaigns commonly use lookalike domains and hijacked subdomains. Proactive DMARC rejection is one of the few controls that works before the attack reaches the inbox.

---