The Email Security Mistake Most GCC Government Agencies Make

Buying a secure email gateway and enabling multi-factor authentication does not stop someone from sending mail that claims to be from your domain. That is a separate problem, solved by a separate mechanism, and it is the one most GCC government and enterprise domains still get wrong.

Filtering and authentication solve different problems

A secure email gateway inspects content: attachments, links, language patterns, sender reputation. It decides whether an email looks dangerous. Authentication answers a narrower question: is this email actually from the domain it claims to be from. A gateway can be excellent at catching malware and still wave through a perfectly clean-looking email from a spoofed domain, because there is nothing malicious in the content to flag. The message just lies about who sent it.

That is why an organisation can run Defender for Office 365 or a comparable gateway, run quarterly phishing simulations, and still be exposed to a wire-fraud email that impersonates its own finance department. No attachment, no link, just a spoofed sender and a request to update payment details. Content filtering has nothing to inspect. Only sender authentication can catch it, and only if it is set to actually do something about a failure.

How SPF, DKIM, and DMARC fit together

SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are authorised to send for a domain. A receiving server checks the connecting IP against that list.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail, tied to a selector and a public key published in DNS. The receiving server verifies the signature to confirm the message was not altered in transit and genuinely originated from a system holding the private key.

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits above both. It does not authenticate anything itself. It tells receiving servers what to do when SPF and DKIM checks fail, and it asks those servers to send back aggregate reports on every message claiming to be from the domain, pass or fail.

Alignment is where deployments actually break

SPF and DKIM can both pass and DMARC can still fail, because DMARC also checks alignment.

SPF alignment compares the domain in the SMTP envelope (the "return path") to the domain in the visible From header. If a marketing platform sends on your behalf using its own return path, SPF passes for the platform's domain, not yours, and SPF alignment fails.

DKIM alignment compares the "d=" domain in the DKIM signature to the From header domain. A third-party sender that signs with its own domain, rather than being handed a subdomain and a key to sign as you, will pass DKIM for itself and fail alignment against your domain.

DMARC passes if either SPF or DKIM passes and is aligned. This is the detail that catches most implementations out: an agency sees "SPF: pass, DKIM: pass" in a header and assumes DMARC is fine, without checking which domain each check actually passed against.

The third-party sender problem

Government agencies increasingly route citizen notifications, HR communications, and procurement updates through outside platforms. This is the single biggest reason enforcement stalls.

A typical case: an appointment-reminder platform sends mail with "Ministry of Health" as the display name but a message that originates from the vendor's own infrastructure and is DKIM-signed with the vendor's domain. The display name matches the brand; the underlying domain does not. That is not a DMARC failure by design, since the sender was never asking DMARC to treat it as first-party mail, but it is exactly the pattern a spoofing attacker imitates, and it trains recipients to trust display names over domains.

The fix is contractual before it is technical: any vendor sending on an agency's behalf should either be given a subdomain and a DKIM key to sign as that subdomain, or use the agency's SPF-included infrastructure with proper alignment. Vendors that cannot support this, and plenty still cannot, are a reason to push back in procurement, not a reason to leave DMARC at monitor-only indefinitely.

Moving from monitor to reject without breaking mail

The safe path is staged, and skipping stages is the most common cause of self-inflicted outages.

1. Publish DMARC at p=none first. This changes nothing about delivery. It only turns on reporting, which is the only way to see what is actually sending mail as your domain today, including systems nobody remembers configuring.


2. Read the aggregate reports, not just the record. Aggregate (RUA) reports arrive as XML from every major receiver and list every sending source, whether it passed alignment, and its volume. A DMARC management platform or a dedicated DMARC vendor turns this into something reviewable; parsing raw XML by hand does not scale past a handful of domains.


3. Fix alignment for every legitimate sender identified. This is nearly always the longest phase, because it touches vendor contracts and DNS changes outside the security team's direct control.


4. Move to p=quarantine before p=reject. Quarantine routes failing mail to spam instead of dropping it, which gives a recovery path if something was missed. Watch for user complaints about legitimate mail landing in spam during this window.


5. Move to p=reject once quarantine has run clean. This is enforcement. Failing mail is refused at the receiving server. There is no safe way to skip to this stage from p=none on a domain that sends any volume of mail through third parties.

Each stage needs weeks, not days, of clean reporting before moving on, and the review has to repeat: new vendors get onboarded, marketing tools change providers, and a domain that reached p=reject two years ago can quietly develop a new unaligned sender that nobody notices until reports are reviewed again.

What assessors actually check for

A NESA-aligned or CBUAE-aligned review of email controls does not stop at confirming a DMARC TXT record exists. Expect it to ask for the policy value (none, quarantine, or reject), a sample of aggregate reports showing what is actually sending as the domain, evidence that failing sources have been triaged, and a documented timeline for reaching enforcement if the domain has not yet. A record parked at p=none with no review history reads, correctly, as a checkbox exercise rather than a control.

For subdomains, ask the same questions again. Many domains enforce DMARC on the apex domain while leaving every subdomain inheriting a permissive default, and subdomains are exactly where forgotten marketing tools and legacy systems tend to send from.

What DMARC does not fix

DMARC stops exact-domain spoofing. It does not stop a lookalike domain registered one character off from the real one, because that is a different domain with its own (attacker-controlled) authentication records that pass cleanly. It does not stop phishing from a genuinely compromised mailbox, since the mail really did originate from an authorised sender; DMARC reporting can surface unusual sending patterns after the fact, but it will not block the message. It also does nothing for AI-written phishing content: a well-authenticated domain with a badly written phishing email still fails DMARC and gets blocked, and a lookalike domain with a beautifully written one still gets through, because DMARC never reads the words. Content inspection, a secure email gateway, and brand and domain monitoring cover the gaps DMARC leaves open; treat them as complementary layers, not competing ones.

A working checklist

Run a DNS check across every domain and subdomain the organisation controls, not just the primary one. Publish SPF and DKIM everywhere mail is sent from, and DMARC at p=none as the starting point if nothing exists yet. Give every third-party sender a proper alignment path or drop it. Review aggregate reports on a schedule, monthly at minimum, using a dedicated DMARC management platform once the domain count or mail volume makes manual XML review impractical. Move to quarantine, then reject, only after each stage runs clean. Treat this as a standing operational task inside the wider email security programme, not a one-time project closed out after the auditor signs off, and check the email security FAQ for the specific configuration questions that come up most often during rollout.