Email authentication for government

12 May 2026 · 13 min read

When a citizen receives an email claiming to be from the tax authority, a benefits agency, a court service or a local council, they read it differently from a marketing message. A government sender carries the weight of obligation: a demand to pay, a threat of penalty, an instruction to "confirm your details to avoid losing your account". That authority is exactly what makes a public-sector domain such a valuable thing to forge. A criminal who can put noreply@hmrc.gov.uk or support@irs.gov in the From line of an inbox is borrowing the credibility of the state to commit fraud, and the people most likely to be hurt are the ones least equipped to spot the deception.

This article is specifically about email authentication in the public sector: why government domains are disproportionately targeted, what the mandates in the UK, US, Canada, Australia and the EU actually require, and the engineering realities that make compliance harder for a department than for a typical company. It is not a generic DMARC primer. Government estates have their own peculiar problems: hundreds of sub-domains nobody can fully inventory, mail sent by external bureaux on the department's behalf, statutory record-keeping requirements, and procurement cycles that make any change slow. Those constraints shape how authentication has to be rolled out.

Why public-sector domains are prime spoofing targets

Every domain that sends email is a potential spoofing target, but government domains sit in a category of their own for several compounding reasons.

The brand is trusted by default. People are conditioned to act on a message from a tax office or a health service. A spoofed email purporting to be a tax refund, a fine, a parcel-delivery fee from a postal service, or an immigration status update converts far better than the same scam wearing an unknown brand. The sender's authority does the social engineering for the attacker.

The audience is the entire population. A private company's spoofed domain reaches that company's customers. A government domain reaches everyone in the jurisdiction, including the elderly, the digitally inexperienced, non-native speakers and people in genuine distress about a real obligation. The pool of potential victims is enormous and disproportionately vulnerable.

The estates are sprawling and old. A central government department may own dozens of registered domains and hundreds or thousands of sub-domains accumulated over decades: agency sites, campaign micro-sites, legacy services, regional offices, contractor-run platforms. Many send no mail and are simply forgotten, and a forgotten domain with no DMARC record is an open invitation. Unused-but-spoofable domains are a classic government weakness.

Email is the primary channel to citizens. Departments cannot just switch to an app. Statutory notices, appointment reminders, benefit updates and tax correspondence go by email at massive volume, which means the legitimate baseline is noisy and the abuse blends in.

The payoff is data and money at scale. Government-themed phishing harvests national-insurance numbers, social-security numbers, passport and driving-licence details, and banking information, all of which feed identity theft and onward fraud. It also delivers direct payment scams: fake fines, fake refunds requiring a "processing fee", fake court summons.

The mechanics of the attack are the same as anywhere else. The Simple Mail Transfer Protocol lets any server put any address in the visible From header. Nothing in the basic act of sending mail proves the sender owns the domain it claims. Without published authentication, a receiving server has no way to tell a real message from gov.example apart from a forgery. You can see the principle in our explainer on email spoofing. The defence is the same three-letter stack as everywhere else, but the stakes and the scale are what push governments to mandate it.

The authentication stack, in government terms

Email authentication is not one control but a layered set, and a mandate that says "implement DMARC" really means "implement the whole stack so DMARC has something truthful to check".

• SPF (Sender Policy Framework) publishes, in DNS, the list of servers allowed to send for a domain's envelope address. For a department, that list is long: the internal mail platform, the gov-wide shared email service, the bulk-notification bureau, the case-management system that emails citizens, the CRM, and more. See what is SPF.
• DKIM (DomainKeys Identified Mail) attaches a cryptographic signature tied to the domain through the d= tag, so a receiver can verify the message was authorised by the domain owner and was not altered in transit. See what is DKIM.
• DMARC ties the two together. It tells receivers to check that an authenticated identity (SPF or DKIM) aligns with the domain shown in the From header, and it publishes a policy saying what to do when nothing aligns. Alignment is the heart of it, and it is worth reading DMARC alignment explained before any rollout.
• MTA-STS and TLS-RPT enforce encrypted transport so that mail to and from the domain cannot be silently downgraded to plaintext and intercepted, which matters acutely for correspondence containing citizens' personal data. See what MTA-STS does.
• BIMI lets a verified organisation display its logo next to authenticated mail, which for a recognisable government brand is a genuine trust signal, though it is the last step, not the first. See do you need BIMI.

A DMARC record at full enforcement, the thing every government mandate is ultimately aiming at, looks like this:

v=DMARC1; p=reject; rua=mailto:dmarc-rua@gov.example; ruf=mailto:dmarc-ruf@gov.example; fo=1; adkim=s; aspf=s

p=reject instructs conformant receivers to refuse mail that claims to be from the domain but fails authentication and alignment. That is the state at which exact-domain spoofing of the department actually stops. Anything short of it leaves a hole, which is the single most important point in this whole subject and the one the mandates exist to force.

The mandates pushing the public sector to p=reject

Governments have not left this to good intentions. Across several countries there are now binding requirements that public-sector domains reach enforcement. The details differ, but the direction is identical: get to p=reject.

United States: CISA Binding Operational Directive 18-01

The landmark mandate is the US Department of Homeland Security's Binding Operational Directive 18-01, issued by what is now CISA in October 2017. It required federal civilian executive-branch agencies to:

• Publish a DMARC record on every second-level .gov domain within 90 days, starting at p=none for monitoring.
• Move every domain to p=reject within one year.
• Ensure STARTTLS was enabled so mail could be sent encrypted, and that web and mail services used valid, modern TLS.

BOD 18-01 is the template the rest of the world has broadly followed: start in monitoring, discover your senders, then ratchet the policy to reject on a deadline. It also drove the practice of publishing DMARC at the registry level for .gov, so that even domains an agency forgot about inherit a protective posture. The directive is the reason US federal p=reject adoption went from a tiny minority of domains to the overwhelming majority within roughly two years, one of the clearest demonstrations anywhere that a deadline plus reporting changes behaviour.

United Kingdom: GOV.UK and NCSC guidance

In the UK, the approach has been guidance-and-platform rather than a single dated legal order, but it is no less firm in practice. The Government Digital Service and the National Cyber Security Centre set out that public-sector organisations using gov.uk and equivalent domains should implement SPF, DKIM and DMARC and reach an enforcing policy. The NCSC's Mail Check service is the linchpin: it is a free platform that ingests DMARC aggregate reports for public-sector domains, shows each organisation its sending sources and authentication results, and chases progress towards p=reject. Use of gov.uk domains comes with the expectation that you are on Mail Check and moving to enforcement, and the NCSC's Active Cyber Defence programme reports on aggregate progress across the sector. The model is the same as BOD 18-01 in substance: visibility through aggregate reporting, then enforcement.

Canada: ITSP.40.065 and the Government of Canada

The Canadian Centre for Cyber Security publishes ITSP.40.065, guidance on email domain protection that recommends SPF, DKIM and DMARC with a target policy of p=reject. The Government of Canada's own direction to departments has required moving GC domains to an enforcing DMARC posture, again starting in monitoring and progressing to reject. The pattern, by now, will be familiar.

Australia and New Zealand

The Australian Cyber Security Centre, through the Australian Signals Directorate, publishes guidance recommending SPF, DKIM and DMARC for government and critical-infrastructure domains, with DMARC moving to an enforcing policy. New Zealand's guidance through the NCSC and DIA's Secure Government Email work points the same way. Across the Five Eyes nations the consensus is settled: public-sector email must authenticate and must reach enforcement.

European Union

The EU's NIS2 Directive raises baseline cyber-security obligations across essential and important entities, which includes much of the public sector, and email authentication falls naturally within the technical measures organisations are expected to adopt. Several member states' national cyber agencies, including in the Netherlands and the Nordics, have published their own DMARC-to-reject expectations for government. The mechanism is less a single directive and more a thickening web of national requirements all converging on the same technical baseline.

The mailbox providers turned everyone's recommendation into a hard floor

Even where a government has no explicit national mandate, the 2024 sender requirements from Gmail, Yahoo and Microsoft mean that any domain sending meaningful volume must at minimum publish a valid DMARC record and align its mail, or watch deliverability collapse. For a department sending millions of citizen notifications, that is not optional. See the Gmail, Yahoo and Microsoft requirements. The combination of national mandates and mailbox-provider enforcement means there is no longer a defensible "we'll get to it" position for a public-sector sender.

Why p=none is the trap that catches government estates

Every mandate above starts at p=none, and that is correct: you cannot safely block mail you have not yet inventoried. But p=none is a monitoring state, not a protective one. With p=none published, a forged message claiming to be from the department still lands in citizens' inboxes, because the policy explicitly tells receivers to deliver despite the failure. We have a dedicated piece on this, the false security of p=none, because it is the single most common way public bodies end up exposed for years.

The danger is specific to large government estates. A department publishes p=none to satisfy the initial deadline, the aggregate reports start flowing, and then the project stalls. The sending inventory is genuinely hard to complete: there are external bureaux nobody documented, a legacy case-management system whose mail nobody can attribute, a regional office running its own server. Completing alignment for every one of those senders is real work, and so the domain sits at p=none, technically compliant with the first step of the mandate and fully spoofable the entire time. The mandates set reject deadlines precisely to stop this drift. The protection only begins at p=quarantine (forged mail diverted to spam) and is only complete at p=reject (forged mail refused outright). If you do not know where your domain sits today, the fastest check is the DMARC checker.

The engineering realities that make government harder

The mandate says "reach reject". The difficulty is in the journey, and government estates carry obstacles a typical company does not.

Sender sprawl and the SPF lookup ceiling

A department's legitimate senders are numerous: the gov-wide email platform, one or more notification bureaux, a payments provider, a CRM, a survey tool, a case-management system, plus per-agency services. Each one wants its own include: in the SPF record. But SPF imposes a hard limit of ten DNS lookups during evaluation; exceed it and SPF returns permerror, which counts as a failure under DMARC and can cause legitimate citizen mail to be rejected once you reach enforcement. Large estates blow past ten lookups routinely. The fixes are real engineering: consolidate senders, remove dead includes, and where necessary flatten the record. We cover this in the SPF 10-lookup limit and how SPF flattening works, and you can measure your current count with the SPF checker.

Mail sent on the department's behalf by third parties

Much government mail is generated by external bureaux: a print-and-post supplier that also emails, a notifications platform, a contractor running a citizen-facing service. For that mail to pass DMARC, it must align with the department's domain, which means the third party has to sign with a DKIM key published under the department's DNS (ideally on a dedicated sub-domain) and send from an envelope domain that aligns. Coordinating that across multiple suppliers, each on their own timeline and contract, is the part of the project that consumes the most calendar time. The pattern to insist on is per-vendor DKIM delegation on a sub-domain, so each supplier is independently verifiable and revocable. Our DKIM selectors explained guide covers the mechanics, and the DKIM checker confirms each key resolves.

Sub-domains and the inheritance trap

DMARC policy on the organisational domain applies to sub-domains too, via the sp (sub-domain policy) tag, unless a sub-domain publishes its own record. For a sprawling estate this cuts both ways. Set sp=reject and you protect every forgotten sub-domain at once, which is exactly what you want for security; but if some live service quietly sends unaligned mail from a sub-domain, enforcement will break it. The discipline is to inventory sub-domain senders, publish explicit records where a sub-domain has its own legitimate mail stream, and then set a strict sp to lock down everything else. See the sub-domain policy tag and sub-domain DMARC records.

Forwarding, mailing lists and the parliamentary inbox

Government correspondence is forwarded constantly: constituents forwarding to representatives, shared role mailboxes, mailing lists for consultations. Forwarding breaks SPF alignment and can break DKIM if the forwarder modifies the message. This is not a reason to avoid enforcement, because DMARC is designed to pass if either SPF or DKIM aligns, and a stable DKIM signature usually survives forwarding. But it does mean DKIM must be solid before you enforce. Read forwarding and DMARC and DKIM alignment when mail is forwarded for the failure modes to expect in your aggregate reports.

Record-keeping, residency and report handling

Aggregate (rua) reports are the telemetry that makes the whole project tractable: they show every IP sending as your domain, whether it passed SPF and DKIM, and whether it aligned. For a public body there are two extra considerations. First, the volume is large, and raw XML from dozens of receivers is unreadable by hand, so it must be parsed and analysed; the DMARC report analyzer turns it into something a team can act on, and reading your first DMARC report explains the fields. Second, data-residency and retention rules may govern where those reports can be sent and stored, which matters when choosing where the rua mailbox lives. Forensic (ruf) reports can contain message content and citizen data, so many public bodies enable them sparingly or not at all and rely on aggregate data plus careful handling.

A realistic deployment sequence for a department

The mandates set the destination; this is the order of operations that gets a public-sector estate there without cutting off legitimate citizen mail.

1. Inventory the domains. Every registered domain and every active sub-domain, including the ones nobody sends from. The dormant ones are spoofing risks and should get a locked-down DMARC record of their own.
2. Publish p=none with rua reporting on each. This is the monitoring step every mandate begins with. It changes nothing for recipients but starts the flow of evidence.
3. Read the reports and build the true sender list. Expect surprises: bureaux you forgot, a legacy server, a contractor's platform. Resolve every legitimate source. Unexpected sources in your reports is the common case here.
4. Fix SPF and DKIM for each legitimate sender. Get every real source aligning, keep SPF under ten lookups, and delegate per-vendor DKIM on sub-domains. This is the bulk of the work and the bulk of the calendar.
5. Move to p=quarantine, then p=reject. Step up gradually, optionally using the pct tag to sample, watching reports at each stage. Reach p=reject without breaking email and the enforcement journey lay out the ratchet.
6. Lock down dormant domains and sub-domains at reject outright. A domain that sends no mail can go straight to p=reject; sp=reject because there is nothing to break.
7. Add MTA-STS and consider BIMI. Enforce encrypted transport, then, once at p=reject, a verified logo on authenticated citizen mail. Check transport readiness with the MTA-STS checker.
8. Keep monitoring permanently. Senders change, suppliers are added, configurations drift. Continuous monitoring with change alerts is what stops a domain silently falling out of compliance after the project closes.

The practical takeaway

Government domains are spoofed because the state's authority is the most valuable brand a fraudster can wear, the audience is the whole population, and the estates are large enough to hide forgotten, unprotected domains. The mandates, CISA's BOD 18-01 in the US, the NCSC's Mail Check expectations in the UK, ITSP.40.065 in Canada, the ASD's guidance in Australia, and NIS2-driven requirements across the EU, all converge on the same destination: every public-sector domain at p=reject, with SPF and DKIM aligned for every legitimate sender, dormant domains locked down, and aggregate reporting watched continuously. The hard part is never publishing the record; it is completing the sender inventory and alignment across a sprawling estate of bureaux, sub-domains and legacy services without cutting off mail that citizens depend on.

If you run a public-sector domain, start by checking exactly where you stand today with the DMARC checker and the SPF checker, and review the binding requirements summarised on our requirements page. If the obstacle is the sender inventory and the long tail of suppliers rather than the policy itself, that is precisely the work our done-for-you DMARC service exists to carry: we take the domain from p=none to p=reject safely, with continuous monitoring and change alerts so it stays there long after the deadline has passed.