You've decided to authenticate your email with SPF, DKIM, and DMARC — good. But the first real hurdle isn't technical, it's sequencing: which one do you set up first? These three protocols work together, but they don't go live in whatever order is convenient. Each one depends on the ones before it, so getting the SPF, DKIM, and DMARC setup order wrong triggers a cascade of authentication failures that are far harder to untangle than they would have been to avoid. This guide walks through the correct sequence step by step — and explains why each protocol has to come exactly when it does.
Key Takeaways
• Set up email authentication in this order: check existing records → SPF → DKIM → DMARC → monitor and enforce. Each protocol builds on the one before it, so skipping ahead creates gaps.
• SPF goes first because it's the simplest to publish and gives you an immediate baseline — receiving servers can start verifying your authorized senders right away.
• DKIM goes second because it requires your sending platform to generate keys. Once SPF is in place, DKIM adds message integrity on top of sender authorization.
• DMARC goes last because it needs SPF and DKIM to work. Without both in place, DMARC has nothing to enforce — and you'll get reports full of failures you can't act on.
You Know You Need SPF, DKIM, and DMARC. But Where Do You Start?
Most businesses know they need email authentication. The harder question is where to begin. SPF, DKIM, and DMARC each handle a different piece of the problem, and setting them up out of order creates exactly the kind of confusing failures that make people give up halfway through.
The good news: there's a clear, proven sequence. Follow it, and each step builds naturally on the one before it. Skip steps, and you'll spend more time troubleshooting than you would have spent doing it right.
Why the Order Matters
Each protocol depends on the ones before it:
SPF tells receiving servers which IPs are allowed to send email for your domain. It's a DNS record — a published list of authorized senders. Without it, anyone can claim to be sending from your domain.
DKIM adds a cryptographic signature to each message, proving the email wasn't altered in transit. It requires your sending platform to generate a key pair and start signing — which means coordinating with every service that sends on your behalf.
DMARC connects SPF and DKIM to the visible "From" address and sets the enforcement policy — what happens when a message fails authentication. DMARC without SPF and DKIM is an empty policy with nothing to enforce.
Setting up DMARC before SPF and DKIM is like installing an alarm system before you've put in the locks. The alarm has nothing to trigger on, and the reports it generates will be useless noise.
Step 1: Check What's Already in Place
Before you add anything, find out what's live. Many businesses already have partial records from their email provider or IT setup — they just don't know what state they're in.
Run a check on your domain for existing SPF, DKIM, and DMARC records. You're looking for:
• Whether each record exists at all
• Whether there are errors (duplicate SPF records, expired DKIM keys, missing DMARC)
• What policy levels are set, if any
This baseline tells you what you're working with. You may discover you already have SPF from your email provider but no DKIM, or a DMARC record stuck at p=none that was set up and forgotten.
Check your records now: Free Email Authentication Record Checker
Step 2: Publish Your SPF Record
SPF goes first because it's the simplest to deploy and gives you immediate protection. You're publishing a single DNS TXT record that lists every service authorized to send email for your domain.
A basic SPF record looks like this:
v=spf1 a mx include:_spf.google.com -allThis says: my domain's own servers (a, mx) and Google Workspace (include:) are authorized senders. Everything else should be rejected (-all).
Key rules to follow:
• One SPF record per domain. Multiple records break validation entirely.
• Stay under 10 DNS lookups. Every include, a, and mx mechanism counts toward this limit. Exceeding it causes automatic failure.
• List all your sending services. Your email provider, marketing platform, CRM, help desk — anything that sends email using your domain needs to be in the record.
Once published, test it. A quick SPF check confirms your syntax is correct and your lookup count is safe.
For detailed setup instructions, including platform-specific examples: SPF Setup Guide → (Coming Soon)
Step 3: Generate and Publish DKIM Keys
With SPF handling sender authorization, DKIM adds message integrity. Your sending platform generates a private/public key pair. The private key signs each outgoing message; the public key goes into DNS so receivers can verify the signature.
The process:
Generate the key pair in your sending platform (Google Workspace, Microsoft 365, or your ESP).
Publish the public key as a DNS TXT record. It looks something like:
plaintext s1._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=PUBLICKEYSTRING"Verify signing is active — send a test message and confirm the DKIM signature passes.
Do this for every service that sends on your behalf. Each service gets its own selector (the s1 part), so you can manage and rotate keys independently.
After publishing, run a DKIM check to confirm your DNS records are reachable and your signatures verify.
For setup walkthroughs by platform: DKIM Setup Guide → (Coming Soon)
Step 4: Add Your DMARC Policy
Now that SPF and DKIM are in place, DMARC ties them together. It tells receiving servers: "Check whether the From domain aligns with the domain that passed SPF or DKIM. If it doesn't, here's what to do."
Start with monitoring — don't jump straight to enforcement:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comThis tells receivers to deliver everything but send you reports about what passed and what failed. Those reports are the roadmap for tightening your policy.
The progression:
p=none— monitor. See what's happening. Identify any legitimate services that aren't aligned yet.p=quarantine— start sending failures to spam. Use pct= to roll this out gradually (e.g., pct=25 applies quarantine to 25% of failing messages).p=reject— full enforcement. Failing messages get blocked outright. This is the goal.
Moving to reject too early — before you've confirmed all legitimate senders are aligned — will break real email. The monitoring phase exists specifically to prevent that.
Check your DMARC record: DMARC Checker →
For the full setup walkthrough, including tag-by-tag reference: DMARC Setup Guide → (Coming Soon)
Step 5: Monitor, Enforce, and Maintain
Publishing records isn't the finish line — it's the starting point. Email authentication is infrastructure, and infrastructure needs maintenance.
Weekly (during rollout):
• Review DMARC aggregate reports. Look for legitimate senders that are failing alignment.
• Fix SPF and DKIM gaps as they surface.
• Advance your DMARC policy as pass rates stabilize.
Monthly (once enforced):
• Check that all sending services are still in your SPF record. Vendors change IPs; cancelled services leave stale entries.
• Verify DKIM keys are current. Rotate them on a schedule.
• Watch inbox placement and complaint rates — they're early warning signals.
When things change:
• Adding a new sending platform? Update SPF and set up DKIM before it starts sending.
• Switching email providers? Don't remove the old provider's entries until migration is complete.
• Domain changes? SPF, DKIM, and DMARC all need to be set up on the new domain from day one.
Ready to Check Where You Stand?
Run a free check on your domain right now to see what's in place and what's missing. You'll get results for SPF, DKIM, and DMARC in one scan.
Check your email authentication
If the results show gaps — or if you'd rather hand the whole thing off — iO™ DMARC sets up and monitors your email authentication so you don't have to manage DNS records and reports yourself.