How a phishing email gets past your gateway in the first place
Every secure email gateway, from a stock Microsoft 365 tenant to a dedicated Mimecast or Proofpoint deployment, runs the same three checks: reputation (has this sender sent spam before), content (does this message match known phishing patterns or carry a flagged link), and authentication (do SPF, DKIM and DMARC agree the sender is who it claims to be). Attackers get through by defeating one, not all.
The most common bypass in the region is not a clever exploit. It is a freshly registered lookalike domain (mlcrosoft-support.com, hdb-bank-uae.com) with clean SPF and DKIM records of its own, sending from infrastructure with no reputation history yet. The message authenticates perfectly against its own domain; it just is not the domain the recipient thinks it is. A gateway that only checks whether SPF, DKIM and DMARC pass waves it straight through. Catching it needs impersonation detection, comparing the display name and sending pattern against your own executives and known partners, which is a different feature from authentication and is often licensed separately.
The second common bypass is a compromised account at a genuine third party: a freight forwarder, a law firm, an outsourced accounting provider. That mail authenticates cleanly because it really was sent from that domain's real infrastructure. No SPF or DKIM check catches it, because the sender genuinely is who they claim to be. Only content analysis, anomaly detection on the third party's usual sending pattern, or the recipient's own scepticism will.
Why GCC banks and government entities see a disproportionate share
Three factors compound here. Digital banking adoption in the UAE and wider GCC is high, so a spoofed bank notification about a blocked card or a failed transfer lands in an inbox primed to expect exactly that message. Trade finance and remittance volumes are large, so invoice-redirection fraud pays out more per successful attempt than in markets with smaller average wire values. And legitimate customer and vendor contact already happens over WhatsApp and SMS alongside email, which normalises the out-of-band, urgency-driven pattern a convincing phishing or smishing message imitates.
Business email compromise is a different problem from bulk phishing
Bulk phishing is a volume game: send enough lookalike login pages and a percentage of recipients enter credentials. Business email compromise is targeted and patient. The attacker compromises or spoofs a real vendor or executive mailbox, studies an actual invoice in progress, and inserts a bank account change at the point in the conversation where it looks routine. There is often no malicious attachment and no link to sandbox, which is why gateway-only defences miss it. Catching BEC needs payment-process controls, a callback to a known number before any bank detail change, more than it needs a better filter.
The controls that actually decide the outcome
DMARC is the control most organisations get partway to and then stop. A record at p=none gives visibility into who is sending mail claiming to be your domain, but it blocks nothing. Moving to p=quarantine and then p=reject is what actually stops your own domain being spoofed, and it is the step most organisations stall on, because it means finding and fixing every legitimate system and third-party sender that has been sending as your domain without proper authentication. That inventory work, not the DNS record, is the real project.
Attachment and link handling is where Microsoft Defender for Office 365, Mimecast and Proofpoint genuinely differ, and it is worth testing rather than taking on the datasheet. Detonation sandboxes vary in how long they hold a message before delivery, and a slow verdict on a link means the user has already clicked by the time the system flags it malicious. Time-of-click link rewriting, which re-checks a link's destination every time it is clicked rather than only at delivery, closes that gap and is worth confirming is actually switched on rather than assumed.
Conditional access and MFA matter more than they get credit for in an email security conversation, because the real damage from a successful phishing attempt usually happens after credential theft, not during it. An attacker with a stolen password but no way past MFA cannot do much. One who also captures a session token through a real-time phishing proxy can, which is why phishing-resistant authentication (FIDO2 keys, certificate-based login) is displacing SMS and push-based MFA on security roadmaps.
Where these deployments actually fail
The recurring pattern is over-broad allowlisting. Someone senior complains that a legitimate email got quarantined, and rather than fixing the specific false positive, an administrator allowlists the sender's entire domain or turns off impersonation checks for that person's name. That exception usually outlives whoever requested it and quietly widens the attack surface for years.
The second recurring failure is nobody reviewing inbox rules. A compromised mailbox almost always gets a forwarding or auto-delete rule added by the attacker, to hide replies from the real owner and route sensitive threads elsewhere. Most tenants have no alerting on new forwarding rules, so a compromise can sit undetected for months after the original email is long forgotten.
What a phishing simulation programme is actually for
A simulation programme that exists to catch and name the employees who click is measuring the wrong thing, and it trains people to hide mistakes rather than report them. The metric that matters is report rate, not click rate: how many recipients forwarded the simulated email to security before or instead of clicking. Click rate falls as awareness improves; report rate is the leading indicator that the human layer is functioning as a sensor rather than a target.
Cadence and realism matter more than the platform used to run the simulations, whether a dedicated tool such as KnowBe4 or a gateway's built-in feature. Quarterly campaigns with templates that mirror your actual threat pattern, invoice-style BEC lures for finance teams, credential pages that mimic your own sign-in screen, teach more than generic templates run monthly. The follow-up matters as much as the send: anyone who clicks needs a short, specific explanation of what gave the email away, delivered close to the moment they clicked, not an annual video months later.
What an assessor or auditor actually checks
A VAPT or compliance review of email security in this region typically asks for four things regardless of framework: the DMARC record and its enforcement policy, not just its existence; evidence that simulation results are tracked over time and used to target training; a documented runbook for a compromised mailbox; and a sample of mail flow and transport rules, checked for undisclosed forwarding or bypass exceptions. Produce those four with real data behind them and you clear most of what gets asked in practice.
Building the response that matters once someone clicks
The plan needs an owner named in advance, and it runs in this order: disable the account's ability to sign in, revoke all active session tokens (a password reset alone does not do this), search the mailbox for rules or delegates the attacker added, check sent items and mail flow logs for anything sent during the compromise window, and only then reset the password and re-enable access. Skipping token revocation is the most common mistake, because a session token survives a password reset and lets the attacker keep working while the user believes the problem is solved.
Where to start if you are behind
Move DMARC from monitoring to enforcement first: it is the cheapest control on this list and the one most often left half-finished. Confirm your email security stack actually does time-of-click link rewriting and impersonation detection, not just spam and malware filtering, since those sit in separate licence tiers more often than the sales deck suggests. Put MFA everywhere it matters and start moving toward phishing-resistant methods for anyone with financial approval authority. Then run simulations that measure reporting, not shaming, and review inbox forwarding rules on a schedule rather than only after an incident. None of this needs a new vendor; it needs finishing the deployment already paid for.
