Every email you send is making a claim: "I am who I say I am, and this message came from where I say it came from." Without SPF, DKIM, and DMARC, mailbox providers have no way to verify that claim — and they won't give you the benefit of the doubt.
These three protocols are not optional extras for technical teams to worry about later. They are the prerequisite for serious email sending. Get them wrong and your deliverability suffers. Skip them entirely and you're essentially anonymous — which, in the modern inbox, means suspect.
The good news is that setting them up is more straightforward than the acronyms suggest. Here's how each one works and what you need to do.
Want your authentication handled for you?
Taildove walks you through the exact DNS records you need for your domain and monitors your setup automatically. Try Taildove for free.
SPF: The Authorised Sender List
SPF stands for Sender Policy Framework. It's a TXT record you add to your domain's DNS that tells the world which mail servers are allowed to send email on your behalf.
When an email from your domain arrives at Gmail or Outlook, the provider checks your SPF record against the IP address of the server that actually sent the message. If the IP matches an authorised entry, the email passes SPF. If it doesn't, the email fails — and depending on your DMARC policy, it may be quarantined or rejected.
Your SPF record lives in your DNS and looks something like this: v=spf1 include:taildove.com ~all. The include: part authorises your email service provider's servers. The ~all at the end means "treat anything not listed as a soft fail." Once you're confident in your setup, you can move to -all for a hard fail, which is stricter and more protective.
One critical rule: you can only have one SPF record per domain. If you use multiple email services — say, a marketing platform and a transactional email tool — you need to combine them into a single record rather than creating separate ones. Multiple SPF records cause the check to fail.
DKIM: The Digital Signature
DKIM — DomainKeys Identified Mail — goes a step further than SPF. Instead of just verifying where the email came from, it verifies that the email hasn't been changed between when you sent it and when it arrived.
Your email server signs every outgoing message using a private cryptographic key. A corresponding public key is published in your DNS. When the receiving provider gets your email, they look up your public key and use it to verify the signature. If the signature checks out, the message is intact and genuinely from you. If it doesn't, something tampered with it.
Your email provider will give you a CNAME or TXT record to add to your DNS — this is your public key. The exact value comes from your provider's settings panel. Once it's added and propagated, your emails are signed automatically on every send.
DMARC: The Policy That Ties It Together
DMARC — Domain-based Message Authentication, Reporting, and Conformance — is the layer that makes SPF and DKIM actionable. Without DMARC, providers check SPF and DKIM but don't necessarily know what to do when an email fails those checks. DMARC tells them explicitly.
You set DMARC by adding a TXT record to your DNS at _dmarc.yourdomain.com. A basic monitoring policy looks like this: v=DMARC1; p=none; rua=mailto:[email protected].
The p= field is your policy. There are three options: none means monitor only — you'll receive reports but no enforcement action is taken. quarantine means emails that fail authentication should be sent to the spam folder. reject means they should be blocked entirely.
Most people start with p=none to gather baseline data before enforcing anything. That's reasonable — but it's a starting point, not a destination. The goal is to understand your email landscape through the reports, confirm that all your legitimate sending sources are properly authenticated, and then move toward quarantine or reject. A permanent none policy gives you intelligence without protection.
Three Mistakes That Undermine Everything
-
Multiple SPF records. This is the most common error and it silently breaks your authentication. If you have two TXT records starting with
v=spf1, the SPF check fails by definition. Merge all your authorised senders into a single record. -
A missing underscore in your DMARC record name. The record must be at
_dmarc.yourdomain.com— with the underscore. Without it, the record either gets ignored or ends up in the wrong place entirely. It's a small character with a significant consequence. -
Setting up DMARC but never reading the reports. DMARC reports are the mechanism that makes the whole system valuable. They show you every sending source claiming your domain — legitimate ones you authorise and illegitimate ones you didn't. If you're not reviewing those reports, you're not using DMARC for what it's built for. Route reports to a dedicated address and check them at least weekly.
Authentication Is the Floor, Not the Ceiling
These three records don't guarantee inbox placement. They guarantee that you're being evaluated as a legitimate sender instead of an anonymous one. Everything else — your content quality, your list hygiene, your engagement rates — builds on top of this foundation.
Get this right first. Then build everything else on top of it.
[!IMPORTANT]
Verify Your Setup Is Actually Working
A configuration error in your DNS can silently break your authentication without any obvious symptoms. Start your free trial with Taildove today and get instant visibility into whether your SPF, DKIM, and DMARC are set up correctly. Try Taildove for free today.