SPF, DKIM, and DMARC: Complete Setup Guide
Set up all three email authentication protocols — SPF, DKIM, and DMARC — in the right order. A practical guide to complete email authentication.
SPF alone isn't enough. Neither is DKIM by itself, or DMARC without the other two. Email authentication works as a system — three protocols that each do something different but together form a complete defense against email spoofing and phishing.
This guide walks you through setting up all three, in the right order, with practical steps for each one.
Why You Need All Three
Each protocol solves a different piece of the email authentication puzzle:
- SPF verifies that the sending server is authorized to send email for your domain
- DKIM verifies that the message content hasn't been altered in transit
- DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails
Without all three, you have gaps. SPF without DKIM means a forwarded email fails authentication. DKIM without SPF means anyone can send from any server as long as they don't modify the message. And without DMARC, receiving servers have no policy to follow when checks fail — they make their own decisions, which are unpredictable.
| Protocol | What It Checks | What It Prevents | DNS Record Type |
|---|---|---|---|
| SPF | Sending server IP address | Unauthorized servers sending as your domain | TXT on root domain |
| DKIM | Cryptographic message signature | Message tampering in transit | TXT on selector subdomain |
| DMARC | SPF and DKIM alignment + policy | Spoofing with no consequence | TXT on _dmarc subdomain |
Google, Yahoo, and Microsoft all require SPF, DKIM, and DMARC for bulk senders. Even if you're not sending at high volume, having all three significantly improves your deliverability and domain reputation.
The Right Order: SPF, Then DKIM, Then DMARC
Order matters. DMARC depends on SPF and DKIM being in place first. And DKIM key generation takes slightly more effort than SPF, so starting with SPF gives you an early win while you set up the rest.
Here's the recommended sequence:
Step 1: Set Up SPF
SPF tells receiving mail servers which IP addresses and servers are authorized to send email on behalf of your domain. It's a single TXT record in your DNS.
Build Your SPF Record
List every service that sends email as your domain
This includes your email provider (Google Workspace, Microsoft 365), marketing tools (Mailchimp, HubSpot), transactional email services (SendGrid, Postmark), helpdesk software (Zendesk, Freshdesk), and any server with direct SMTP sending.
Find each service's SPF include value
Every email service publishes an SPF include in their documentation. For example, Google Workspace uses include:_spf.google.com and SendGrid uses include:sendgrid.net.
Assemble the record
Combine everything into a single line: start with v=spf1, add each include, add any direct ip4 addresses for your own servers, and end with -all (or ~all while testing).
Add the TXT record to DNS
Create a TXT record on your root domain (@) with your SPF string as the value. Set the TTL to 3600 (1 hour).
Verify with an SPF checker
Use SPF Record Check to confirm your record is published, syntactically valid, and under the 10 DNS lookup limit.
For a detailed walkthrough with examples for popular providers, see our How to Create an SPF Record guide.
Start with ~all during setup
Use ~all (softfail) while you're getting everything in place. Once SPF, DKIM, and DMARC are all live and verified, switch to -all (hardfail) for maximum protection.
Step 2: Set Up DKIM
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. The receiving server uses a public key published in your DNS to verify that the message hasn't been altered and genuinely came from your domain.
How DKIM Works
- You generate a public/private key pair
- The private key lives on your email server (or your email service provider holds it)
- The public key is published as a DNS TXT record
- Your server signs every outgoing email with the private key
- Receiving servers look up the public key and verify the signature
Generate and Publish DKIM Keys
Generate your DKIM key pair
Use DKIM Creator to generate a DKIM key pair. You'll choose a selector name (like google, s1, or default) and a key size (2048-bit is recommended).
Add the public key to DNS
Create a TXT record at selector._domainkey.yourdomain.com (replacing selector with your chosen selector name). The value is the public key string that DKIM Creator generates for you.
Configure your email service to sign with DKIM
Most email providers have a DKIM settings page where you either paste your private key or enable their built-in DKIM signing. For Google Workspace, go to Admin > Apps > Google Workspace > Gmail > Authenticate email. For Microsoft 365, it's in the Defender portal under Email Authentication.
Send a test email and verify the signature
Send an email and check the headers on the receiving end. Look for dkim=pass in the Authentication-Results header. If you see dkim=fail, double-check that the public key in DNS matches and the selector name is correct.
DKIM for Multiple Services
If you use multiple email services, each one needs its own DKIM configuration. Most services provide their own DKIM keys with their own selectors, so they don't conflict. For example:
- Google Workspace: selector
google, record atgoogle._domainkey.yourdomain.com - SendGrid: selector
s1, record ats1._domainkey.yourdomain.com - Mailchimp: selector
k1, record atk1._domainkey.yourdomain.com
Unlike SPF (which must be a single record), you can have multiple DKIM TXT records — one per selector. Each service signs with its own key and its own selector.
Track all three protocols in one place
Monitor your SPF, DKIM, DMARC, and MX records daily. Get alerted when any of them break.
Step 3: Set Up DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer. It tells receiving servers two things: how to handle messages that fail SPF and DKIM, and where to send reports about authentication results.
DMARC Policy Options
DMARC has three policy levels, from least to most strict:
| Policy | What It Does | When to Use It |
|---|---|---|
| p=none | Monitor only — no action on failures | Start here. Collect data before enforcing. |
| p=quarantine | Send failing messages to spam/junk | After verifying all legitimate sources pass |
| p=reject | Block failing messages entirely | Full enforcement — maximum protection |
Build Your DMARC Record
Start with p=none
Use DMARC Creator to generate your initial DMARC record. Set the policy to p=none so you can monitor without affecting email delivery. A basic record looks like: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;
Add the TXT record to DNS
Create a TXT record at _dmarc.yourdomain.com with your DMARC string as the value. Note: this is a specific subdomain (_dmarc), not the root domain.
Set up a reporting address
The rua tag specifies where aggregate reports are sent. These reports tell you which IPs are sending email as your domain and whether they pass or fail SPF and DKIM. Use a dedicated email address or a DMARC reporting service.
Wait and analyze reports
Give it 2-4 weeks to collect data. Review the aggregate reports to identify all legitimate senders and any that are failing authentication. Fix any issues before moving to enforcement.
Gradually increase enforcement
Move from p=none to p=quarantine, then to p=reject as you gain confidence that all legitimate email passes authentication.
Do not start with p=reject. If you have any legitimate email sources that aren't properly authenticated with SPF and DKIM, their messages will be silently dropped. Always start with p=none, analyze reports, then escalate.
How the Three Protocols Work Together
Here's what happens when a receiving server gets an email from your domain:
- SPF check: The server looks up your SPF record and checks if the sending server's IP is authorized. Result: pass or fail.
- DKIM check: The server finds the DKIM signature in the email header, looks up the public key in DNS, and verifies the signature. Result: pass or fail.
- DMARC evaluation: The server checks your DMARC record. DMARC passes if either SPF or DKIM passes and is aligned with the From domain. The server then applies your DMARC policy to failures.
The key insight: DMARC requires alignment, meaning the domain checked by SPF or DKIM must match (or be a subdomain of) the domain in the From header. This prevents attackers from passing SPF with their own domain while spoofing yours in the From field.
SPF protects the envelope
SPF validates the Return-Path (envelope sender) domain. It ensures that only authorized servers can claim to send mail from your domain at the SMTP level.
DKIM protects the message
DKIM validates that the email content (headers and body) haven't been modified since the sender signed it. It works even when email is forwarded, unlike SPF.
DMARC enforces the policy
DMARC checks that SPF and/or DKIM results align with the visible From address, then tells the receiving server what to do with failures. It also provides reporting so you can see what's happening.
Recommended Rollout Timeline
Don't try to do everything in a day. A phased rollout minimizes risk and gives you time to catch problems before they affect delivery.
| Timeframe | Action | Expected Result |
|---|---|---|
| Week 1 | Publish SPF record with ~all | SPF passes for known senders, softfails for unknown |
| Week 2 | Set up DKIM for all sending services | DKIM passes for all legitimate email |
| Week 3 | Publish DMARC with p=none | Start receiving aggregate reports, no delivery impact |
| Week 4-6 | Analyze DMARC reports, fix gaps | All legitimate senders passing SPF and/or DKIM |
| Month 2 | Move DMARC to p=quarantine | Failing email goes to spam instead of inbox |
| Month 3+ | Move DMARC to p=reject, SPF to -all | Full enforcement — spoofed email is blocked |
Don't rush to p=reject
The jump from p=none to p=reject should take at least 6-8 weeks. Use that time to identify every legitimate email source and make sure it passes authentication. A premature p=reject can block real email from reaching your customers.
Common Mistakes
Setting Up DMARC Before SPF and DKIM
DMARC evaluates SPF and DKIM results. If neither is configured, DMARC has nothing to work with and every email fails the DMARC check. Always set up SPF and DKIM first.
Forgetting a Sending Service
This is the most common cause of authentication failures after setup. You set up SPF for Google Workspace and SendGrid but forgot that your invoicing software also sends email as your domain. Audit every service before tightening your DMARC policy.
Using p=reject Too Early
Starting with p=reject means any email that fails both SPF and DKIM is immediately blocked. If you haven't identified all legitimate senders, real email gets dropped with no fallback.
Not Monitoring DMARC Reports
DMARC reports are the only way to see what's happening across all your email streams. If you publish a DMARC record without monitoring reports, you're flying blind.
Having Multiple SPF Records
You can only have one SPF TXT record per domain. If different team members added separate SPF records, both will fail. Merge them into a single record. (You can have multiple DKIM records — one per selector — so this is only an issue with SPF.)
Ignoring Subdomain Authentication
If you send email from subdomains (marketing.example.com, support.example.com), each subdomain needs its own SPF record. DMARC can cover subdomains with the sp tag, but SPF and DKIM must be configured per subdomain.
Verification Checklist
After setup, verify everything is working:
SPF record is published and valid
Check with SPF Record Check. Confirm one record, valid syntax, under 10 lookups.
DKIM keys are published and signing
Send a test email and verify dkim=pass in the Authentication-Results header. Check each sending service separately.
DMARC record is published
Verify a TXT record exists at _dmarc.yourdomain.com. Use DMARC Creator to validate the syntax.
DMARC reports are being received
Wait 24-48 hours after publishing DMARC and check the email address in your rua tag for aggregate reports.
All sending services pass authentication
Send test emails from every service and confirm spf=pass and dkim=pass for each one.
Related Articles
Monitor Your New SPF Record
You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.
Never miss an SPF issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring