If you’ve spent any time researching email deliverability, you’ve almost certainly run into three acronyms that seem to appear everywhere: SPF, DKIM, and DMARC. They’re often mentioned together, frequently explained poorly, and treated as something only IT specialists need to understand. In reality, these three protocols are the backbone of email trust on the internet, and as of 2024, major providers like Gmail and Yahoo have made them mandatory for anyone sending bulk email.
The good news is that once you strip away the technical jargon, these concepts are genuinely straightforward. Each one solves a specific, understandable problem, and together they form a layered system that proves you are who you say you are when you send an email. This guide breaks down each protocol individually, explains why it exists, and walks through how they work together.
Why Email Needed These Protocols in the First Place
To understand why SPF, DKIM, and DMARC exist, it helps to understand a fundamental weakness in how email was originally designed. The core email protocol, SMTP, was built in an era of trust, without any built-in mechanism to verify that the sender listed in the “From” field is actually who sent the message.
This means, by default, anyone can technically send an email claiming to be from any address, including yours. This vulnerability is called email spoofing, and it’s the foundation of countless phishing scams, where attackers impersonate a trusted brand or person to trick recipients into clicking malicious links or handing over sensitive information.
SPF, DKIM, and DMARC were developed over time specifically to close this gap, giving mailbox providers a way to verify that an email genuinely came from an authorized source, and giving domain owners a way to specify what should happen to emails that fail that verification.
SPF: Sender Policy Framework
SPF is the oldest and most straightforward of the three protocols. At its core, SPF is a published list of servers that are authorized to send email on behalf of your domain.
Here’s how it works in practice. You add a specific type of DNS record, called a TXT record, to your domain’s settings. This record lists the IP addresses or sending services authorized to send email as your domain. When an email arrives claiming to be from your domain, the receiving mail server checks this SPF record and compares it against the actual server that sent the message. If it matches, the email passes SPF authentication. If it doesn’t, the email fails, and depending on your other settings, it may be rejected, filtered, or flagged as suspicious.
Think of it like a bouncer with a guest list at an exclusive venue. If your name is on the list, you’re let in without issue. If you show up claiming to be someone you’re not, and your name isn’t authorized on that list, you get turned away.
One important limitation of SPF is that it only checks the technical sending server, not the visible “From” address a recipient actually sees in their inbox. This means SPF alone doesn’t fully prevent spoofing of the display name or address a human sees, which is part of why it needs to work alongside DKIM and DMARC rather than standing alone.
SPF records also have a technical limit: they can only include up to ten DNS lookups. If your business uses many different third-party services to send email- your marketing platform, your CRM, your support software, your invoicing tool- it’s possible to exceed this limit, which causes SPF to fail entirely for all your sending sources. This is a common, but often overlooked technical pitfall businesses run into as they add more sending tools over time.
DKIM: DomainKeys Identified Mail
DKIM works differently from SPF. Instead of listing authorized servers, DKIM uses cryptographic signatures to verify that an email hasn’t been tampered with in transit and genuinely originated from your domain.
When you set up DKIM, your email sending service generates a pair of cryptographic keys: a private key and a public key. The private key stays secret and is used to create a unique digital signature attached to every email you send. The public key is published in your domain’s DNS records, where anyone, including receiving mail servers, can access it.
When an email arrives, the receiving server uses your published public key to verify the digital signature attached to the message. If the signature checks out, it confirms two things: the email genuinely came from your domain, and the content wasn’t altered somewhere along the way between leaving your server and arriving in the recipient’s inbox.
A useful analogy is a wax seal on a letter in the pre-digital era. The seal proves the letter came from the person whose seal it bears, and if the seal is broken or doesn’t match, you know something’s wrong: either the letter isn’t genuine, or it’s been tampered with after being sealed.
Unlike SPF, which is tied to the sending server, DKIM travels with the email itself, which makes it more resilient in situations involving email forwarding, where SPF often breaks down because the forwarding server isn’t on your original authorized list.
DMARC: Domain-based Message Authentication, Reporting, and Conformance
DMARC is the protocol that ties SPF and DKIM together, and it addresses a critical gap that neither of the other two solves on their own: what should actually happen when an email fails authentication.
Without DMARC, SPF and DKIM can each individually pass or fail, but there’s no unified policy telling receiving mail servers what to do about it. A mail server might see a failed SPF check and just quietly deliver the email anyway, defeating much of the purpose of having authentication in the first place.
DMARC solves this by letting domain owners publish a clear policy: what should happen to emails that fail SPF and DKIM checks. There are three policy levels. A “none” policy means take no action, just monitor and report. A “quarantine” policy means send failing emails to spam or a junk folder. A “reject” policy means block failing emails entirely, preventing them from being delivered at all.
DMARC also introduces an important additional check called alignment. It’s not enough for SPF or DKIM to simply pass; the domain used in those checks also needs to align with the domain visible in the “From” address the recipient actually sees. This closes a loophole where an email could technically pass SPF or DKIM using a completely different, unrelated domain while still displaying a spoofed “From” address to the recipient.
Finally, DMARC provides reporting. Domain owners can receive regular reports showing exactly who is sending email using their domain, including any unauthorized or spoofed attempts, giving valuable visibility into how your domain is being used or potentially abused across the internet.
How the Three Work Together
It helps to think of these three protocols as layered defenses, each covering a gap left by the others. SPF verifies the sending server is authorized. DKIM verifies the message content hasn’t been altered and genuinely originated from your domain. DMARC ties both checks together, enforces alignment with the visible “From” address, and defines what actually happens when something fails.
A properly configured domain has all three in place, working in concert. This is now considered the baseline standard for any business sending marketing or bulk email, not an advanced or optional setup.
Setting Up DMARC Gradually
One important piece of practical advice: don’t jump straight to a “reject” DMARC policy on day one, especially if you’re not fully confident every legitimate sending source tied to your domain is properly configured with SPF and DKIM. Doing so risks blocking legitimate emails you didn’t even realize were going out under your domain, invoices from your accounting software, notifications from a CRM, and so on.
The recommended approach is to start with a “none” policy, which allows you to collect reporting data without affecting deliverability. Review these reports over several weeks to identify every legitimate source sending email as your domain, and make sure each one is properly authenticated with SPF and DKIM. Once you’re confident everything legitimate is properly aligned, gradually move to “quarantine,” and eventually to “reject” once you’re fully confident in your setup.
This gradual rollout prevents the common mistake of accidentally blocking your own legitimate email while trying to lock down against spoofing.
What Happens If You Don’t Set These Up
As of 2024, Gmail and Yahoo both require SPF and DKIM authentication, along with a valid DMARC record, for any sender pushing more than 5,000 emails a day to their users. Falling short of these requirements can result in emails being outright rejected rather than simply filtered to spam, a much more severe consequence than in years past.
Even for smaller senders below these formal thresholds, missing or misconfigured authentication significantly damages your sender reputation and inbox placement rates. Mailbox providers increasingly treat unauthenticated email with suspicion by default, regardless of your actual sending volume.
Checking Your Own Setup
Verifying your current SPF, DKIM, and DMARC configuration doesn’t require deep technical expertise. Most email marketing platforms provide the exact DNS records you need to add for their specific sending infrastructure, along with instructions for where to add them depending on your domain registrar.
There are also numerous free online tools that let you check your domain’s current authentication status, showing you whether SPF, DKIM, and DMARC are properly configured and correctly aligned. Running one of these checks periodically, especially after adding a new email sending tool or service, is a good habit that catches configuration issues before they become deliverability problems.
The Bottom Line
SPF, DKIM, and DMARC can feel intimidating from the outside, three unfamiliar acronyms wrapped in technical DNS terminology. But conceptually, they’re solving a problem anyone can understand: proving that an email genuinely came from who it claims to be from, and defining what should happen when it doesn’t.
Getting these three protocols properly configured isn’t an optional technical nice-to-have anymore; it’s foundational infrastructure for anyone serious about email marketing or even routine business email. The setup takes an afternoon at most. The alternative, sending unauthenticated email into an increasingly strict filtering landscape, costs you deliverability every single day it goes unaddressed.
