SPF / DKIM / DMARC
Also known as: SPF, DKIM, DMARC, email authentication, email spoofing protection
SPF, DKIM, and DMARC are three DNS-based settings that authenticate your business email.
Together they let receiving mail servers verify that a message really came from your domain, improving your deliverability and, crucially, making it much harder for scammers to send fraudulent email that appears to come from you.
SPF / DKIM / DMARC, explained at three levels
At home
Anyone can write any return address on an envelope, and the original email system works the same way. SPF, DKIM, and DMARC add checks. SPF is a guest list of servers allowed to send your mail. DKIM is a wax seal proving the letter wasn't altered or forged. DMARC is your instruction to the receiving post office about what to do with letters that fail.
At work
SPF, DKIM, and DMARC are DNS-based email authentication standards. Together, they let receiving mail servers verify that a message claiming to come from your domain was actually sent by you. For a business, they block criminals from spoofing your exact domain to customers and staff, and they improve deliverability, since Google, Yahoo, and Microsoft now require authentication from bulk senders.
At home
Each is a text record published in your domain's DNS. SPF lists the servers and services allowed to send mail for your domain, such as Microsoft 365 or Mailchimp. DKIM has the sending server sign each message with a private key, and receivers check the signature against a public key published in DNS. DMARC tells receivers what to do when checks fail, and asks them to send you reports.
At work
In a business, setup starts with an inventory of every service that sends as your domain: Microsoft 365 or Google Workspace, the CRM, the invoicing tool, the website form. Each must be added to SPF and given DKIM signing. DMARC is then published, and its daily aggregate reports show who is sending as you. Since 2024, Google and Yahoo require SPF, DKIM, and DMARC from bulk senders, and Microsoft followed for Outlook.com in 2025.
At home
The key idea is alignment. SPF checks the hidden envelope sender and DKIM checks the signing domain, but neither looks at the From address you actually see. DMARC passes only if SPF or DKIM passes and its domain matches that visible From address. Policies go from p=none to quarantine to reject. While setup is fiddly, in my view every business domain should end up at reject.
At work
A proper rollout inventories sending sources, aligns SPF and DKIM for each, publishes DMARC at p=none with reporting turned on, reviews aggregate reports for several weeks, then moves to quarantine and finally reject. Pitfalls include SPF's limit of ten DNS lookups, forwarding that breaks SPF, and mailing lists that break DKIM, which ARC partly addresses. BIMI can show a verified logo once DMARC is enforced. DMARC doesn't stop look-alike domains, so filtering still matters.
Real-world examples
At home
Sophie learned that scammers were sending fake invoices to her clients using her exact email domain. Her MSP configured SPF, DKIM, and DMARC with a reject policy, and the spoofed messages stopped reaching anyone: receiving servers now rejected mail that wasn't genuinely hers.
At work
Thomas's firm noticed important emails landing in customers' spam folders. After his MSP set up full email authentication and moved DMARC to enforcement, deliverability improved markedly and impersonation attempts using their domain were rejected before delivery.
How it compares
| feature | SPF | DKIM | DMARC |
|---|---|---|---|
| What it does | Lists allowed sending servers | Signs messages cryptographically | Sets policy + reporting |
| Prevents spoofing | Partially | Partially | Yes, for your exact domain (SPF or DKIM must pass and align) |
| Provides reports | No | No | Yes |
| Set up where | DNS record | DNS + mail server | DNS record |
For analysts
SPF, DKIM, and DMARC protect your brand and your customers from being scammed in your name, and they're now often required for reliable delivery. Have your MSP roll out DMARC carefully: monitor reports first, then move to enforcement so you don't block your own legitimate senders.
History & origin
The original email protocol had no way to verify who a message was really from, making spoofing trivial. SPF (2006) let domains list authorized sending servers; DKIM (2007) added cryptographic signatures; DMARC (2012) tied them together with a policy telling receivers what to do with failures, plus reporting. As phishing and BEC exploded, major mailbox providers began requiring these standards, pushing them from optional to essential.