Email spoofing lets attackers send messages that look like they come from your domain, without ever breaking into your systems. It works because standard email protocols were never built to verify sender identity. The fix is three DNS records working together: SPF, DKIM, and DMARC. Set up correctly, they stop most spoofed emails before they ever reach an inbox.
Introduction
An attacker doesn’t need to hack your email account to damage your business. They just need to send a message that looks like it came from you.
This is email spoofing, and it’s behind a growing share of the fraud hitting businesses across the UAE. More than 75% of cyber breaches in the country now start with a phishing email or a fraudulent message, according to the UAE Cybersecurity Council. Many of those start with a spoofed sender address that slips past a basic spam filter.
The good news is that spoofing has a well-defined technical fix. Three email authentication protocols, SPF, DKIM, and DMARC, close the gap that makes spoofing possible in the first place. This guide breaks down exactly how each one works, why you need all three together, and how to roll them out without breaking your legitimate email flow.
What Is Email Spoofing?
Email spoofing is when an attacker forges the “From” address on an email so it appears to come from a trusted domain, even though it was sent from somewhere else entirely. The recipient sees a familiar name and address, but the message never touched the real sender’s mail server.
This works because of a flaw baked into how email was originally designed. The core protocol that moves email across the internet, SMTP, was built in an era when trust wasn’t a concern. It has no built-in way to check whether the sender is really who they claim to be. Anyone with basic technical knowledge can type any address into the “From” field and send a message that looks completely genuine.
That’s different from a hacked account. In spoofing, your domain and inbox are never breached. The attacker simply borrows your identity for a single message, which is what makes it so hard to catch with traditional security tools.
Why Email Spoofing Is So Effective Against UAE Businesses
Spoofing works because it exploits trust, not technology. A finance employee who sees an email from “the CEO” or “a regular supplier” is far less likely to question it than one from a stranger.
The financial impact backs this up. Business Email Compromise, which almost always relies on spoofed or impersonated addresses, cost victims more than $3 billion in reported losses in a single year in the US alone, with the average incident costing over $120,000. In the UAE, a typical pattern looks like this: an attacker spoofs a company’s CEO address, then emails the finance team asking for an urgent payment to a “new” supplier account. Single incidents have cost UAE SMEs more than AED 500,000.
AI has made this worse. Generative tools now let attackers write flawless, context-aware emails in minutes, without the typos and awkward phrasing that used to give spoofed messages away. This is one reason the UAE has pushed businesses toward mandatory cyber resilience standards, since basic spam filtering alone is no longer enough.
Native filtering also has a real gap. Microsoft 365’s built-in protection catches most phishing attempts, but the remaining share still represents millions of unfiltered emails reaching inboxes every day across users worldwide. If your organization relies only on the default settings in Microsoft 365, spoofed mail can and does get through.
What Are SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC are three DNS-based email authentication protocols that work together to verify a sender’s identity and tell receiving mail servers what to do when a message fails that check. On their own, each one solves a different part of the problem. Together, they close the loophole that makes spoofing possible.
Here’s what each one actually checks:
SPF (Sender Policy Framework) is a list, published in your DNS, of every mail server allowed to send email on behalf of your domain. When a message arrives, the receiving server checks whether it came from an IP address on that list. If it didn’t, SPF fails.
SPF’s weakness is that it only checks the hidden technical sender address, not the “From” address a human actually sees. It also breaks when a message gets forwarded through an intermediary server, since the forwarding server usually isn’t on the approved list.
DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing email, generated using a private key that only your mail server holds. The receiving server checks that signature against a public key published in your DNS. If the message was altered in transit, or wasn’t really signed by you, the DKIM check fails.
Unlike SPF, DKIM signatures survive forwarding, since they’re part of the message itself rather than the delivery envelope. But DKIM has its own gap: it doesn’t require the signing domain to match the visible “From” address, which means a technically valid DKIM signature can still sit on top of a spoofed sender name.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer that ties the other two together. It checks whether the domain in the visible “From” address actually aligns with the domains verified by SPF and DKIM. If it doesn’t, DMARC tells the receiving server exactly what to do: deliver it, quarantine it, or reject it outright. It also sends you regular reports showing who is sending email using your domain, including anyone trying to spoof it.
Why You Need All Three Together (Not Just One)
A common mistake is assuming one protocol is enough. It isn’t, and this is where most spoofing slips through.
SPF and DKIM each check a different part of an email, but neither one protects the actual “From:” address a recipient sees. An attacker can pass SPF and DKIM checks using their own infrastructure, while still setting the visible “From” field to your domain. Both underlying checks come back clean, and the spoofed email still lands in the inbox looking legitimate.
DMARC is the only protocol that closes this specific gap, because it forces alignment between what SPF and DKIM verify and what the recipient actually sees. Without DMARC, SPF and DKIM are running in the background with no enforcement mechanism attached. Without SPF or DKIM configured correctly first, DMARC has nothing reliable to check alignment against.
This is why the three have to be deployed as a set, not treated as separate options.
How Do You Set Up SPF, DKIM, and DMARC?
Setting up SPF, DKIM, and DMARC means publishing specific DNS records and rolling them out in stages, starting with monitoring before moving to enforcement. Rushing straight to a strict policy without monitoring first is the most common cause of legitimate email getting blocked.
Here’s the practical rollout most IT teams follow:
- Inventory every system that sends email as your domain. This includes your mail server, marketing platforms, invoicing software, HR systems, and any third-party tool that sends on your behalf. Missing one is the most common cause of disruption later.
- Publish your SPF record. Add a DNS TXT record listing every authorized sending source you identified. Keep the list tight. Long chains of included services increase the risk of hitting SPF’s 10-lookup limit, which causes the entire check to fail.
- Enable DKIM signing. Most email platforms, including Microsoft 365, let you generate and publish DKIM keys directly from the admin portal. This usually takes a handful of DNS record additions.
- Publish a DMARC record in monitoring mode. Start with a policy of
p=none, which collects data without blocking anything. This gives you visibility into every source sending mail as your domain, including any spoofing attempts already happening. - Review the reports. DMARC sends aggregate reports showing which senders pass and which fail. Use this period to fix any legitimate service that isn’t authenticating correctly.
- Move to enforcement gradually. Once your reports show all legitimate senders passing cleanly, shift to
p=quarantine, then finallyp=reject. At that point, spoofed emails using your exact domain get blocked before they ever reach an inbox.
This process typically takes several weeks from monitoring to full enforcement, and it’s worth doing properly rather than rushing. A misconfigured DMARC record set straight to reject can silently block real customer emails, invoices, or newsletters.
Beyond DNS Records: Other Ways to Stop Spoofing
SPF, DKIM, and DMARC stop attackers from using your exact domain, but spoofing and impersonation attacks take other forms too. A well-rounded defense adds a few more layers:
Multi-factor authentication protects against the follow-on risk of spoofing, which is account takeover. Even if an attacker gets hold of a password through a spoofed login page, MFA stops them from actually accessing the mailbox.
Anti-impersonation policies in platforms like Microsoft 365 can flag emails that mimic an executive’s display name or use a lookalike domain, even when the exact domain is authenticated correctly. This closes the gap left by attackers using near-identical domains instead of the real one.
Zero Trust principles extend this protection beyond email. A Zero Trust approach to access control treats every request for sensitive access or a payment change as unverified until proven otherwise, regardless of where the email appears to come from.
Callback verification is the simplest and often most effective control. Any request involving a payment, bank detail change, or sensitive data should be confirmed by phone, using a number you already have on file, not one included in the email itself.
Conclusion
Email spoofing works because it exploits a design flaw in how email was built, not because your team made a mistake. SPF, DKIM, and DMARC directly address that flaw, and deployed together, they stop the vast majority of domain spoofing before it reaches an inbox.
But DNS records alone aren’t a complete strategy. They need to be monitored, maintained, and paired with layered defenses like MFA and impersonation detection to hold up against attackers who keep adapting. If your business handles client data, you’ll also want this covered as part of your broader UAE PDPL compliance obligations.
If you’re not sure whether your domain is properly protected, or if you’ve never checked your DMARC reports, it’s worth finding out before an attacker does. Book a free email security assessment and we’ll show you exactly where the gaps are.
Can I set up SPF, DKIM, and DMARC myself?
Yes, if you’re comfortable editing DNS records and have access to your domain registrar and email platform admin settings. The technical steps are well documented, but mistakes like overly strict policies or missing senders can block legitimate email, so many businesses have their IT provider handle the rollout and monitoring.
Does DMARC stop phishing too, or just spoofing?
DMARC specifically stops attackers from using your exact domain to send fraudulent email. It won’t stop phishing sent from lookalike domains or compromised third-party accounts, which is why it needs to be paired with anti-phishing filters and employee awareness.
What’s the difference between email spoofing and phishing?
Spoofing is a technique, faking the sender address. Phishing is the goal, tricking someone into clicking a link, sharing credentials, or making a payment. Most phishing emails use spoofing to look more convincing, but not all spoofed emails are phishing attempts.
How long does a full DMARC rollout take?
Most organizations spend two to four weeks in monitoring mode before moving to enforcement, though this depends on how many sending sources you have. Rushing straight to a reject policy without this monitoring period is the most common cause of blocked legitimate email.
Is DMARC mandatory for businesses in the UAE?
There’s no single blanket mandate covering every business, but UAE regulators have been pushing sectors toward stronger cyber resilience standards, and major mailbox providers like Google and Microsoft increasingly require DMARC for bulk senders. Treating it as mandatory is the safer approach either way.