The problem: an email that looks like it came from you
Imagine a client receives an email from accounts@yourcompany.com asking them to pay the next invoice into a new bank account. The address looks right and the signature looks right, but the message was sent by an attacker. This is called email spoofing, and it is a common starting point for invoice fraud and phishing.
It works because, by default, email does not verify that the sender is allowed to use the domain shown in the From address. Unless your domain publishes rules that say otherwise, the receiving server has little to go on.
Why it matters now
- Major mailbox providers now expect it. Since February 2024, Gmail has required senders of about 5,000 or more messages a day to personal Gmail accounts to authenticate with SPF and DKIM and to publish a DMARC record; Yahoo introduced similar rules for bulk senders. Since May 2025, Microsoft has applied similar requirements to high-volume senders to Outlook.com, Hotmail and Live addresses. Most companies send far less, but these records are widely seen as basic good practice for any domain that sends email.
- Saudi cybersecurity controls name them explicitly. The National Cybersecurity Authority's Essential Cybersecurity Controls (ECC-2:2024) list validating an organization's email domains with SPF, DKIM and DMARC among the minimum email protection requirements (control 2-4-3-5). The ECC applies to government entities and to organizations that own, operate or host critical national infrastructure, and the NCA encourages other organizations to adopt them.
- It protects your name, not just your inbox. Spoofed email can hurt your clients and your reputation even if your own systems are never touched.
Three records, three jobs
- SPF: the guest list
- A DNS record that lists the services allowed to send email for your domain, for example Microsoft 365 and your invoicing system. Mail from any other server fails the check.
- DKIM: the official seal
- Your mail service signs every outgoing message; receivers check the signature against a public key published in your DNS. A valid signature shows the message came from an authorized service and was not changed on the way.
- DMARC: instructions for the guard
- Tells receivers what to do with mail that fails these checks: nothing yet (p=none), send it to spam (p=quarantine) or refuse it (p=reject). It can also ask receivers to send you reports, so you can see who is sending email in your name.
A safe rollout in three steps
- List everything that sends email as you: Microsoft 365 or Google Workspace, website forms, invoicing, marketing, HR and support systems.
- Publish SPF and turn on DKIM for each of those services, then add DMARC with p=none and a reporting address. Review the reports for a few weeks and fix any legitimate service that fails.
- Tighten the policy: move to p=quarantine, then to p=reject once the reports show only legitimate senders.
Common mistakes
- Two SPF records on the same domain. Only one is allowed; with two, the SPF check fails.
- An SPF record ending in +all, which allows any server on the internet to send as you.
- Too many lookups in SPF. The standard allows at most 10, a limit that is easy to pass after adding several services.
- Leaving DMARC at p=none forever. It gives visibility, but it does not stop spoofed mail.
- Forgetting a service, such as a newsletter tool, whose mail then lands in spam once the policy is tightened.
Two extra protections for your website
- CAA: a DNS record that names the only certificate authorities allowed to issue HTTPS certificates for your domain.
- HSTS: a website header that tells browsers to always connect to your site over HTTPS.