SPF, DKIM, and DMARC sound technical — but they're the foundation of email security for any business. Without them, anyone can send email that looks like it came from your domain. Here's what they do and how to set them up.
The problem: your domain can be spoofed
If you haven't configured email authentication for your domain, anyone on the internet can send an email that appears to come from your address. It will show your name, your domain, and look completely legitimate to the recipient. No password required. No account access needed.
This is how most business email compromise attacks work. An attacker doesn't need to hack your email account — they just need to send an email that looks like it came from you. Your bank contacts, your clients, your vendors, your employees — all of them can receive convincing fake emails that appear to be from your business.
SPF, DKIM, and DMARC are the three DNS-based standards that prevent this. They tell the internet who is authorized to send email on behalf of your domain — and what to do when someone else tries.
SPF: who is allowed to send from your domain
SPF (Sender Policy Framework) is a DNS record that lists the mail servers authorized to send email on behalf of your domain. When an email arrives claiming to be from your domain, the receiving mail server checks your SPF record to see if the sending server is on the approved list.
For a Microsoft 365 business, your SPF record tells the world that Microsoft's mail servers are authorized to send for your domain. If someone tries to send email from your domain through a random server, the SPF check fails.
SPF alone has a limitation: it only checks the technical sender (the "envelope from"), not the visible "From" header that recipients see. That's where DKIM comes in.
DKIM: a digital signature that proves the email is genuine
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email sent from your domain. The signature is generated using a private key you control and can be verified by anyone using the public key you publish in DNS.
When a receiving mail server gets an email claiming to be from your domain, it retrieves your public DKIM key from DNS and uses it to verify the signature. If the signature is valid, the email genuinely came from an authorized sender. If it's missing or invalid, the email may be spoofed or tampered with.
Microsoft 365 handles DKIM signing automatically for your domain once you enable and configure it. The setup involves adding two CNAME records to your domain's DNS — something your IT provider or domain registrar can help with.
DMARC: the policy that ties it all together
SPF and DKIM tell you whether an email is legitimate. DMARC (Domain-based Message Authentication, Reporting & Conformance) tells receiving mail servers what to do when an email fails those checks — and sends you reports so you can see what's happening.
A DMARC policy has three options for what to do with emails that fail authentication: none (do nothing, just monitor), quarantine (send to spam), or reject (block the email entirely).
Most businesses start with p=none to monitor what's being sent on their behalf without risking legitimate email being blocked. Once you understand your email sending sources and have confirmed SPF and DKIM are working correctly, you move to p=quarantine, then p=reject.
DMARC also delivers aggregate reports — XML summaries from major mail providers showing you every email sent claiming to be from your domain, whether it passed authentication, and what server sent it. This visibility is genuinely useful for finding unauthorized senders or misconfigured mail systems.
How to check and fix your current configuration
You can check your current SPF, DKIM, and DMARC records using free tools like MXToolbox or DMARC Analyzer. Enter your domain name and they'll show you what's currently published — and highlight obvious problems.
Common issues we find: no DMARC record at all (the most common gap); SPF record that includes too many sending sources and hits the DNS lookup limit; DKIM not enabled for Microsoft 365; DMARC policy set to p=none and never reviewed or progressed to p=quarantine or p=reject.
Setting up these records correctly requires understanding all the services that send email on your behalf — Microsoft 365, your CRM, your marketing platform, your accounting software, any automated notifications from business applications. Each legitimate sender needs to be included in SPF or configured to sign with DKIM before you tighten your DMARC policy.
Intragreat reviews and corrects email authentication configuration as part of our Microsoft 365 security assessments. If you're not sure what your current setup looks like, the free security review is a good place to start — we check SPF, DKIM, and DMARC as part of every engagement.