SPF, DKIM and DMARC explained: the complete setup guide

Email was invented in the 1970s, long before anyone worried about spam or phishing. The original protocol (SMTP) has no built-in way to verify that a message actually came from the domain it claims to come from. That means anyone can send an email pretending to be you@yourdomain.com — and without authentication, mailbox providers have no way to tell the difference.

SPF, DKIM, and DMARC were created to fix this. Together, they answer three critical questions: Is the sending server authorized? (SPF), Has the message been tampered with? (DKIM), and What should happen if authentication fails? (DMARC). When you configure all three correctly, you get several major benefits for your email deliverability.

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which IP addresses and servers are allowed to send email on behalf of your domain. Think of it as a guest list for your email — if the sending server isn't on the list, the email is treated as suspicious.

When someone receives an email from you@yourdomain.com, the receiving server checks your domain's DNS for an SPF record. It then compares the IP address of the server that actually sent the email against the list of authorized senders. If there's a match, SPF passes. If not, SPF fails — and the email is more likely to be flagged as spam or rejected entirely.

An SPF record is a TXT record added to your domain's DNS. Here's what a typical SPF record looks like:

Let's break down each part:

DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing email. This signature is generated using a private key that only your email server knows, and verified by a public key published in your DNS. It proves two things: the email genuinely came from your domain, and it hasn't been altered in transit.

If SPF is the guest list, DKIM is the wax seal on the envelope. Even if someone intercepts the message, any tampering with the headers or body will break the signature, and the receiving server will know.

The DKIM public key is published as a TXT record at a specific subdomain. The subdomain follows the format selector._domainkey.yourdomain.com, where the selector is a name chosen by your email provider:

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication — and gives you visibility into who's sending email using your domain.

Without DMARC, even if SPF or DKIM fails, the receiving server makes its own judgment call (which varies wildly between providers). DMARC lets you, the domain owner, set an explicit policy: let it through, quarantine it, or reject it outright.

Each protocol handles a different piece of the puzzle. SPF verifies the sending server, DKIM verifies the message integrity, and DMARC enforces the policy. Here's the full flow when a receiving server processes your email:

The critical concept here is alignment. DMARC requires that the domain in SPF or DKIM matches (aligns with) the domain in the email's From: header. This prevents attackers from passing SPF with their own domain while spoofing yours in the From address. For DMARC to pass, at least one of SPF or DKIM must both pass and align.

This is why having all three protocols is essential. SPF alone doesn't prevent From-header spoofing. DKIM alone doesn't tell the receiver what to do with failures. DMARC ties them together into a complete solution. For a deeper dive into how authentication impacts your overall sending reputation, see our email deliverability guide.

Google Workspace handles DKIM signing automatically once you publish the key. Here's how to configure all three records. You'll need access to your DNS provider (Cloudflare, Namecheap, GoDaddy, Route 53, etc.) and your Google Admin console.

Microsoft 365 (Exchange Online) requires a slightly different approach, especially for DKIM. The SPF and DMARC setup is similar to Google Workspace, but the DKIM configuration uses CNAME records instead of TXT records.

Microsoft uses CNAME records for DKIM instead of TXT records. This allows Microsoft to rotate DKIM keys automatically without you needing to update your DNS each time.

DMARC setup is identical regardless of your email provider — it's a DNS record on your domain. Follow the same steps as Google Workspace: start with p=none, monitor, then tighten.

Setting up the DNS records is only half the job. You need to confirm everything is working correctly. Here are the best ways to verify your SPF, DKIM, and DMARC configuration. Proper verification is especially important if you're running a warm-up process for a new domain.

Several free tools let you check your records without sending test emails:

Even experienced teams make these mistakes. Each one can silently tank your email deliverability without obvious error messages. Here are the most common issues we see:

Email authentication isn't set-and-forget. Your sending infrastructure changes over time — you'll add new marketing tools, switch CRMs, onboard transactional email services, or expand to new domains. Each change requires an update to your DNS records.

Here's a maintenance checklist to keep your authentication healthy. This is especially important if you're managing multiple domains or running cold email follow-up sequences across different sending infrastructure.

When onboarding a new sending service, always follow this process: (1) add the service's include: to your SPF record, (2) publish the service's DKIM key in your DNS, (3) send a test email and verify authentication passes, and (4) only then start sending production email through the new service. This prevents authentication failures that could temporarily damage your domain reputation.

For teams managing multiple domains, consider creating a central authentication inventory — a simple spreadsheet listing every domain, every authorized sending service, and the current DMARC policy level. Review it quarterly to catch any drift.