SPF, DKIM and DMARC explained for UAE firms: a staged rollout.

Why email authentication matters

Email was designed without a strong check that the sender is who they claim to be. Anyone can put your domain in the "From" line of a message. Three DNS records close much of that gap: SPF, DKIM and DMARC. Together they let a receiving mail server check whether a message really came from a source you authorised, and they give you a say in what happens when it did not. They protect your customers and suppliers from fake invoices and bank-detail change requests, and they protect your own mail from being treated as spam. Our guide to email security and payment fraud explains the wider threat. This page explains the records themselves and how to roll them out safely.

What each record does

• SPF (Sender Policy Framework) is a DNS record listing the servers and services allowed to send mail for your domain. A receiver checks the sending server against that list.
• DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing message. The receiver checks the signature against a public key in your DNS to confirm the message was not altered and was signed by the domain.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together. It checks that SPF or DKIM passes and matches the domain in the visible "From" address, then applies your chosen policy and sends you reports.

A useful way to remember it: SPF says who may send, DKIM proves the message is genuine, and DMARC says what to do when the checks fail.

Step 1: find every service that sends as your domain

The biggest cause of trouble is a sender you forgot. Make a list before changing any record.

• Your main mail platform, such as Microsoft 365 or Google Workspace.
• Accounting and invoicing tools, payroll, HR and recruitment systems.
• Marketing platforms, newsletter tools and web forms.
• Helpdesk, CRM and customer-support systems.
• Scanners, printers and applications that send alerts through a relay.
• Any branch, subsidiary or partner that sends under your domain.

Ask each department what sends mail for them, and use DMARC reports in the next steps to find those nobody mentioned.

Step 2: publish SPF carefully

Your SPF record should list your genuine senders and end with a clear instruction for everything else. Three habits avoid the usual problems.

1. Publish only one SPF record per domain. Two records cause failures.
2. Stay within the limit of ten DNS lookups that the standard allows. Each "include" for a third-party service uses lookups, so remove services you no longer use.
3. Review it whenever you add or retire a sending service.

Step 3: turn on DKIM for every sending service

Each service that sends as your domain needs its own signing set up, usually by adding records supplied by the service to your DNS. In Microsoft 365 this is enabled per domain in the security settings. Check each platform's current instructions, because the exact steps change. Rotate keys when the platform recommends it, and make sure your DNS provider keeps the long records intact.

Step 4: start DMARC in monitoring mode

A DMARC record has a policy that tells receivers what to do with failing mail. The usual sequence is:

1. Monitor (p=none). Nothing is blocked. You receive reports showing who sends mail as your domain and whether it passes.
2. Quarantine (p=quarantine). Failing mail is treated as suspicious, usually sent to junk.
3. Reject (p=reject). Failing mail is refused. This is the goal for the domains you use.

Stay in monitoring until the reports show every legitimate sender passing. Fix the stragglers, then move up one step at a time, leaving enough time at each to catch seasonal senders such as year-end invoicing. Many DMARC records also include an address for reports, and those reports are dense XML, so most firms use a reporting service or ask their provider to interpret them.

Domains you do not send from

Companies often hold extra domains for branding, defence or old trading names. These are attractive to fraudsters because nobody watches them. Publish a DMARC reject policy and an SPF record stating that no mail is sent from them, and keep a list of every domain you own. The same applies to subdomains.

Common mistakes

• Jumping straight to reject. Genuine invoices or password resets then disappear.
• Forgotten third-party senders, especially marketing and accounting tools.
• Misaligned domains. A tool signs with its own domain rather than yours, so DMARC fails even though SPF or DKIM technically passes.
• Ignoring the reports. A policy nobody reads cannot be improved.
• Setting and forgetting. New tools arrive and old records go stale.
• Treating DMARC as the whole answer. Lookalike domains and compromised accounts still need other controls.

Testing and ongoing care

Use our free email security checker to see which records your domain publishes today. After each change, send test messages from every platform to an outside mailbox and read the authentication results in the message headers. Put a regular review in the calendar, and add the records to your offboarding and onboarding steps for tools. Insurers and larger customers increasingly ask about these records, as we describe in the cyber insurance questionnaire guide, so keep a note of your current policy and the date of the last review.

Where to start

If your domain has no DMARC record, publishing one in monitoring mode is a low-risk first step. Missan's email security service can run the inventory, rollout and reporting for you, and the free IT health check reviews your email protection alongside the rest of your setup. Missan Global has supported UAE organisations since 2004 from its head office in Al Majaz, Sharjah.