Email security is the combination of authentication controls (SPF, DKIM, DMARC), inbound filtering, and user behaviour that decides whether a spoofed invoice or a credential-harvesting link ever reaches an inbox with the power to act on it. In most GCC organisations the technology is not the gap. The rollout is.
- DMARC left at monitor-only (p=none) is the most common authentication gap on GCC domains, and it blocks nothing on its own
- Business email compromise, not malware, drives the largest email-related losses, because it needs no attachment or link to defeat a sandbox
- A secure email gateway and native cloud filtering solve overlapping but different problems; many enterprises need both, not one instead of the other
- Assessors increasingly ask for DMARC enforcement evidence and phishing simulation completion rates, not a purchase order for a filtering product
Why GCC organisations carry more email risk than the average
A few structural factors make this region a more efficient target for an attacker running the same playbook everywhere.
The workforce is genuinely multilingual, and English is a second or third language for a large share of staff who process invoices and wire approvals. The old advice to check for grammatical errors is close to useless here, since an odd phrasing does not stand out the way it would in a native-English office. An attacker who localises a lure into clean English or Arabic removes one of the few remaining tells.
The economy runs on large, routine wire transfers: trade finance, real estate escrow, remittance, and cross-border supplier payments. A request to change payment details before a handover does not look unusual here, it looks like Tuesday, which makes business email compromise structurally more profitable than where large one-off transfers are rare.
Vendor and managed SOC support that often runs on a different regional clock creates real coverage gaps: a lure sent late in the week sits longer before a human looks at it.
Cloud migration to Microsoft 365 has also outpaced identity hardening in a lot of environments: mailboxes moved to the cloud years before conditional access and sign-in risk policies caught up, leaving a gap between what the platform can do and what is switched on.
The threats worth building a programme around
Bulk spam and commodity malware attachments are the largest volume by count, but the easiest to filter and least likely to cause a material loss alone. The threats worth designing a programme around succeed without ever tripping a malware signature.
Credential phishing harvests a username and password through a page that mimics a real login portal, usually Microsoft 365. It beats multi-factor authentication too, when the kit is a real-time proxy relaying the session token rather than just the password (adversary-in-the-middle phishing). A push-approval or SMS second factor does not stop this; phishing-resistant methods like FIDO2 keys do.
Business email compromise impersonates a real counterparty, a vendor, an executive, or a law firm involved in a transaction, to redirect a payment or extract data. It carries no payload, so it defeats attachment scanning and sandboxing by design, and relies entirely on the request looking plausible at a moment when verification is inconvenient.
Business email compromise: the one that moves money
The mechanics are almost always the same: a thread is hijacked or spoofed, a payment detail changes mid-conversation, and the request carries urgency and a reason verification would be awkward. Real estate and trade finance are common targets because large transfers between parties who have not worked together long are routine, so a changed bank account does not automatically read as suspicious.
The control that stops this is not a filtering product. It is a callback verification procedure for any change to payment instructions, using a phone number sourced independently of the email thread, applied without exception regardless of seniority. DMARC, external-sender banners, and training reduce how often the lure lands. The callback rule is what stops the loss when one gets through anyway.
Email authentication: SPF, DKIM, and DMARC, and where they break
SPF publishes a DNS record listing which mail servers may send for a domain. It breaks two common ways: exceeding the ten DNS lookup limit once enough third-party senders get added, and failing on forwarded mail, since the forwarding server is not on the original list.
DKIM attaches a cryptographic signature to outbound mail, tied to a key pair and a selector published in DNS. It breaks when an intermediary rewrites the message body or headers, which some mailing lists and gateways do by default.
DMARC sits on top of both and does the part that matters operationally: it declares what should happen when a message fails alignment (none, quarantine, or reject), and generates aggregate reports showing every server sending mail as your domain, including ones you never authorised. A domain published at p=none is reporting only. It blocks nothing. Moving to quarantine and then reject is the only way DMARC does protective work, and it requires reviewing those reports first so enforcement does not silently drop real mail from an HR platform or invoicing tool.
Why so many domains sit at p=none forever
Almost always the same three reasons: nobody owns the DNS record as an ongoing responsibility, nobody reviews the aggregate reports so unauthorised senders never get identified, and there is a lingering fear that moving to reject will break some SaaS tool nobody remembers configuring. All three are solvable with a few hours a month of attention, which is why a record stuck at p=none for years is a rollout failure, not a technology limitation.
Choosing an architecture: native filtering, a gateway, or both
Organisations on Microsoft 365 get a filtering baseline for free (Exchange Online Protection) and can add Defender for Office 365 for safe links, attachment detonation, and impersonation detection tied into the same identity signals as conditional access. The advantage is integration: one console, one identity graph, no MX record change.
A dedicated secure email gateway such as Mimecast sits in front of or alongside that native layer as a separate inbound mail path. The case for adding one: an independent detection engine that catches what the native layer misses, more granular quarantine workflows for a large helpdesk team, or a requirement for a second, vendor-independent control. The case against: cost, and a console that gets tuned badly, usually with over-broad allow lists that undo most of the benefit.
Neither choice is wrong. The mistake is picking based on which vendor a peer uses rather than actual mail flow complexity and whether BEC or bulk malware is the bigger measured problem.
Where the rollout fails after the contract is signed
The product rarely fails a proof of concept. What fails is the following twelve months.
Quarantine digests get ignored once the novelty wears off, so users start asking IT to whitelist entire domains, which quietly guts the filtering policy one exception at a time. Phishing simulation runs once as a project and never repeats on a cadence, so nobody knows whether click rates are improving or drifting back up. Nobody has a written procedure for a compromised mailbox: revoking active sessions, killing any auto-forwarding rule the attacker planted (the step most incident responses skip, and how attackers keep visibility after a password reset), and checking for OAuth grants approved under pressure. DLP policies get set at go-live and never revisited as the business adds new SaaS tools, so a customer record export leaves as an attachment through a rule nobody updated.
What assessors and auditors actually check
Walkthroughs increasingly ask for evidence, not a claim: the DMARC record itself, showing enforcement rather than monitor-only. Phishing simulation completion rates and, more usefully, what happens to repeat clickers. A documented procedure for a compromised mailbox and a suspected wire fraud attempt, including the bank recall process, since a fraudulent transfer can usually only be clawed back within a narrow window. Mail log retention long enough to support an investigation opened weeks later, not just the last few days. And whether MFA on mail access is phishing-resistant or just present, since a push-approval factor does not stop an adversary-in-the-middle kit.
None of this is exotic. It is the difference between an assessor accepting a claim and a screenshot of the actual DNS record.
Sequencing this correctly
Get DMARC to reject before spending on anything new. It costs nothing but attention and closes the gap that makes every other control's job harder.
Decide between native filtering, a dedicated gateway, or both based on actual mail flow and helpdesk capacity, not on which platform a competitor uses.
Write the compromised-mailbox runbook and the wire-fraud callback procedure before you need them; neither takes more than a few hours to draft, and both are useless written for the first time during an incident.
Track phishing simulation results as an ongoing metric with a process for repeat clickers, not a project that produced one report. See the email security FAQ for the questions that come up most once a programme like this is running.
