In January 2026, a Dubai-based company lost AED 2.3 million to a business email compromise attack. The finance manager processed a wire transfer to an account provided in what appeared to be a direct instruction from the CEO. By the time the fraud was identified, the funds had already cleared and were moving through the banking chain.
There’s no malware in a BEC attack. No suspicious attachment, no link to click, nothing for endpoint security to flag. It arrives as an email that appears to come from someone the recipient trusts, asking them to do something routine. Pay a supplier. Update bank details. Approve a transfer. The only thing wrong is the sender.
The attacker in the Dubai case registered a domain, wrote a convincing email, and waited. The cost to run the attack was a few dollars. The return was AED 2.3 million.
Business email compromise is the highest-value cybercrime category in the world by dollar loss. The FBI’s Internet Crime Complaint Center recorded $3.05 billion in global BEC losses in 2025. The UAE is a documented target in this pattern. The Cyber Security Council reported over 200,000 breach attempts against UAE organisations every day in 2025, rising to between 600,000 and 800,000 per day in early 2026. More than 75% of breaches originate from phishing or fraudulent messages. BEC is the financially motivated version of that ecosystem: simple execution, high return.
Dubai’s transaction volume, cross-border payments, and fast-moving finance processes make it a strong target environment. Attackers design campaigns around that speed.
The AED 2.3 million was gone. What followed cost considerably more.
BEC attacks begin long before the email is sent.
Attackers map the organisation using public data. LinkedIn reveals finance roles and reporting lines. Company websites expose executive names and email formats. Press releases expose transactions, acquisitions, or payment cycles that can be used to create believable urgency.
They then register a domain that closely resembles the real one. The email is sent from that domain, with the executive’s name shown as the sender. On mobile devices, the actual address is often hidden unless explicitly expanded.
Timing is deliberate. Messages arrive when verification is least likely. The content creates urgency, references real context, and often includes confidentiality pressure to reduce the chance of verification.
What makes this effective is the economics. Setup costs are minimal, but a single successful payment can return millions. That imbalance is what keeps BEC at the top of global cybercrime losses by reported value.
The transfer amount is only the visible loss.
After an incident is confirmed, organisations typically bring in external incident response teams to determine how the email chain was compromised, how long attackers may have had access, and whether other accounts were affected. That process pulls in internal IT, finance, and legal teams for weeks.
If personal data was exposed, UAE PDPL obligations may require reporting to regulators, adding legal exposure beyond the fraud itself.
Recovery is time-sensitive. Once funds move through multiple banks and jurisdictions, retrieval becomes unlikely. Early intervention can sometimes freeze transfers, but after the initial window, outcomes are usually limited to legal escalation.
Broader cost research reflects this. IBM’s 2025 report places average breach costs in the Middle East at $7.29 million once investigation, response, compliance, and internal disruption are included.
The largest documented UAE-related case reached AED 185 million over several years, showing how sustained access combined with email impersonation can escalate far beyond a single transaction.
The UAE environment matches the conditions BEC relies on: high-value cross-border payments, international counterparties, and fast execution cycles in finance teams.
This is reflected in real campaigns. Research has documented attackers targeting UAE-linked energy supply chains by registering lookalike domains tied to contractors and waiting for invoice cycles to trigger payments.
Real estate introduces another layer of exposure. High-value transactions move quickly, and payment instructions are expected near completion, creating ideal conditions for impersonation of agents, developers, or legal intermediaries.
Global fraud routing patterns identified by the FBI IC3 show fraudulent wire transfers frequently passing through jurisdictions with high international payment volume, including the UAE.
One common BEC pattern is direct domain spoofing, where an attacker sends email pretending to be your exact domain using external infrastructure.
With DMARC set to p=reject, those messages fail authentication checks and are blocked before delivery.
This depends on correct SPF and DKIM alignment for all legitimate email sources. Without that visibility, organisations often delay enforcement.
DMARC does not stop all BEC variants. Lookalike domains operate outside your domain entirely, while compromised mailboxes send authenticated email from real accounts. Both require separate controls.
What p=reject does eliminate is the cheapest version of impersonation: sending mail that appears to come from your domain without owning it.
You set p=reject on your main domain months ago. SPF is clean, DKIM signs everything, and your DMARC reports look quiet. As far as you’re concerned, nobody can send mail as your brand.
Then a customer forwards you a phishing email. It came from promo.yourbrand.com . It passed SPF. It passed DKIM. It passed DMARC. And you have no idea who sent it, because that subdomain has been dead for three years.
This is the gap almost nobody checks. Your organisational domain can be locked down perfectly and still leave an open door, because a subdomain you forgot about is pointing at infrastructure an attacker now controls. The technique has a name, SubdoMailing, and it has been running at scale since 2022.
Every organisation accumulates subdomains. A marketing campaign needs landing.yourbrand.com . A vendor sets up support.yourbrand.com and points it at their SaaS. Someone spins up blog.yourbrand.com on a hosting platform for a product launch. The campaign ends, the contract lapses, the launch is over. The service gets cancelled.
What almost never happens is the DNS cleanup. The CNAME record stays. It still points to the third-party service that no longer exists. That is a dangling DNS record, and it is the raw material for a takeover.
Here is the chain. Your DNS has a CNAME like this:
promo.yourbrand.com. CNAME yourbrand.marketingvendor.io.
The marketing vendor shuts down. The contract for yourbrand.marketingvendor.io lapses and the name becomes available to register. An attacker scanning for exactly this pattern finds your dangling CNAME, registers yourbrand.marketingvendor.io themselves, and now controls whatever promo.yourbrand.com resolves to. From that moment, promo.yourbrand.com is theirs. They can stand up a phishing page on it, or worse, they can send email from it.
This is the part that catches people out. The whole point of DMARC is to stop unauthorised mail claiming to be from your domain. So how does mail from a hijacked subdomain sail through?
Two ways, and both abuse trust you set up yourself.
The first is the SPF include. SPF records chain to other domains using the include: mechanism, which pulls in the allowed senders defined by a third party. A record might look like this:
v=spf1 include:_spf.yourbrand.com include:mail.oldvendor.net -all
If oldvendor.net expires and an attacker registers it, they now control the SPF record that your domain imports. They point it at their own mail servers. Your SPF record, unchanged, now authorises the attacker to send on your behalf. The mail passes SPF cleanly, because as far as the receiving server is concerned, you told it to trust that source.
The second is the dangling CNAME itself. Once an attacker owns the resource promo.yourbrand.com points to, they can configure mail and DNS for that hostname. Mail sent from promo.yourbrand.com is genuinely sent from a subdomain of your organisational domain. SPF passes. If they can get DKIM signing in place, that passes too. And because the From header is a real subdomain of your domain, DMARC alignment succeeds.
That last point is what makes this dangerous. The mail is not spoofed in the technical sense. It is authenticated. Your security stack waves it through, your customers see your brand in the sender, and the DMARC report shows a pass. Guardio Labs, who first documented the campaign at scale, found attackers running roughly five million emails a day through more than 8,000 hijacked domains, all passing the authentication checks the victim domains had configured.
The original SubdoMailing campaign hijacked subdomains belonging to MSN, VMware, McAfee, The Economist, and Marvel, among others. Big brands with mature security teams, all sending phishing because of forgotten DNS entries.
It is still happening. In April 2026, researchers confirmed a coordinated subdomain takeover campaign hitting MIT, Harvard, Stanford, UC Berkeley, Columbia, Johns Hopkins, and more than 25 other universities, attributed to a threat actor tracked as Hazy Hawk, the same group previously seen hijacking CDC subdomains. The hijacked .edu subdomains were serving spam that Google was actively indexing under trusted university names.
There is a regional edge to this too. CloudSEK documented phishing campaigns targeting major UAE organisations including ADNOC, SNOC, and ENOC, using domains built on naming schemes close to the real ones. Around 90% of the malicious domains in that campaign were hosted in North America, deliberately, because takedown requests to providers in that region take longer to process. Slow takedowns mean a hijacked or lookalike domain stays live longer, and a live domain sends more mail.
The UAE Cyber Security Council put out an advisory in April 2026 stating that more than 75% of cyberattacks now begin with phishing. Authenticated phishing from your own subdomains is about the most effective version of that there is.
The fix splits into two jobs: subdomains you don’t use, and subdomains you do.
For subdomains you never send mail from, publish an explicit reject policy. DMARC has a dedicated tag for this. On your organisational domain’s _dmarc record, the sp tag sets the policy for every subdomain that does not have its own record:
v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourbrand.com
A common and dangerous mistake is to assume the main domain’s p=reject automatically protects subdomains in every case. It covers subdomains that inherit, but if a subdomain publishes its own DMARC record, that record wins and overrides the parent entirely. A hijacked subdomain can publish its own p=none . So sp=reject on the parent is the floor, not the ceiling, and you still need to know what records exist below it.
If you genuinely don’t use subdomains for email, there’s no reason to wait. You can hold the main domain at p=none while you’re still watching traffic and publish sp=reject immediately, locking subdomains shut before you’ve finished the rollout on the parent.
For the harder job, the dangling records, no policy tag helps. You have to find them and remove them. That means auditing your DNS for CNAMEs pointing at services you no longer use, and walking every include: in your SPF chain to confirm each referenced domain is still registered and still yours. Then you build a habit: whenever a project ends, a vendor contract lapses, or a service gets cancelled, DNS cleanup is part of decommissioning, not an afterthought.
The audit is straightforward once. The problem is that DNS keeps changing, vendors keep coming and going, and a manual review is a snapshot that’s stale the moment someone adds a new CNAME. Researchers who warned over a thousand organisations about exposed subdomains found that 98% of them did nothing. Not because the fix is hard, but because nobody was watching the right place.
This is where continuous monitoring earns its place. DMARCS has a SubdoMailing Guard and a Subdomain Monitor built for exactly this: tracking your subdomains and their DNS dependencies, and flagging dangling records and takeover exposure before an attacker finds them first. Alongside that, the Forensic Analysis view turns your RUF failure reports into readable detail, so when an unfamiliar subdomain shows up sending mail, you see it and can attribute it rather than scrolling through raw XML hoping to spot the anomaly. Because DMARCS was built in the UAE, that reporting data stays in the jurisdiction you choose, which matters if you’re answering to PDPL or sector rules on where authentication data can live.
Start by running your domain through the free DMARC Analyzer. It will show you your current policy and whether your subdomains are actually covered or just look like they are. If you find dangling records or want continuous monitoring across every subdomain you own, start a trial and we’ll walk the cleanup with you.
Tell us where your domains stand today and we will take it from there.
