SPF, DKIM, and DMARC Setup: A Practical Guide

SPF, DKIM, and DMARC setup means publishing three DNS records that prove your email is legitimate: SPF authorizes which servers may send for your domain, DKIM cryptographically signs each message, and DMARC ties them together and tells receivers what to do when a message fails. Configured correctly, the three records let inbox providers like Gmail, Yahoo, and Outlook trust your domain and deliver your mail.

This guide gives you the exact records to publish, the order to publish them in, how to verify each one, and a safe roadmap from monitoring to full enforcement. It is written for anyone running real outreach or marketing mail from a custom domain in 2026, when authentication is no longer optional.

What are SPF, DKIM, and DMARC?

SPF, DKIM, and DMARC are three complementary email authentication standards, each published as a DNS record on your sending domain. Together they let a receiving mail server answer one question: "Is this message really from who it claims to be from?"

• SPF (Sender Policy Framework) lists the servers and IP addresses authorized to send mail for your domain. The receiver checks the sending IP against this list.
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message header. The receiver fetches your public key from DNS and verifies the message was not altered in transit.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It requires alignment (the visible From domain must match the authenticated domain), tells receivers how to treat failures, and requests reports.

You need all three. SPF and DKIM alone authenticate the transport, but only DMARC enforces that the address your recipient actually sees is the one that passed.

Why does email authentication matter in 2026?

Email authentication matters because the major inbox providers now reject unauthenticated mail outright. Gmail began enforcement in February 2024 with temporary deferrals, and as of November 2025 non-compliant messages receive permanent 550 rejections. Yahoo and Microsoft Outlook apply equivalent rules. If your domain sends 5,000 or more messages per day to any of these providers, SPF, DKIM, and DMARC are mandatory.

Even below that threshold, authentication shapes deliverability. Providers treat properly authenticated domains as more trustworthy, which improves inbox placement and reduces the chance of landing in spam. The 2026 baseline expectation is also tighter on policy: a DMARC record stuck permanently at p=none now reads as a domain that collects data but never acts on it, which weakens trust over time.

For teams running outreach across email and other channels, deliverability is the foundation everything else sits on. If you are sending cold email, getting authentication right is the first prerequisite before sequence content or timing matters at all. See our cold email outreach use case for how authenticated sending fits into a full program.

How do I set up SPF?

To set up SPF, publish a single TXT record on your root domain that lists every service authorized to send mail for you. The record starts with v=spf1 and ends with an all mechanism that decides how strictly to treat anything not listed.

A typical record for a domain using Google Workspace looks like this:

• Host / Name: @ (your root domain)
• Type: TXT
• Value: v=spf1 include:_spf.google.com ~all

Each sending platform you use gets its own include:. If you also send through a marketing tool, you might publish v=spf1 include:_spf.google.com include:spf.example-esp.com ~all. Use ~all (soft fail) while testing and -all (hard fail) once you are confident every legitimate source is listed.

Two hard rules: publish only one SPF record per domain (multiple records cause a permanent error), and stay under the 10 DNS lookup limit. Each include, a, mx, and redirect counts toward that limit; exceeding it produces a PermError and SPF stops passing. Flattening tools or consolidating senders help if you bump against the ceiling.

How do I set up DKIM?

To set up DKIM, generate a public/private key pair in your sending platform, publish the public key as a DNS TXT record under a named selector, and let the platform sign outbound mail with the private key. The receiver fetches the public key at selector._domainkey.yourdomain.com and verifies the signature.

Most providers generate the key for you. In Google Workspace, you enable DKIM in the Admin console under Apps then Gmail then Authenticate email, which produces a record like this:

• Host / Name: google._domainkey (the selector is google)
• Type: TXT
• Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh... (the long public key string)

Follow these DKIM best practices:

1. Use a 2048-bit key rather than the older 1024-bit default for stronger security.
2. Give each sending system its own selector and key, for example google._domainkey for Workspace and esp._domainkey for a marketing tool, so you can rotate one without breaking the others.
3. Rotate keys periodically (roughly every six months) and sign every outbound message, including the From header.

After publishing, send a test message to a Gmail address, open the message, and use "Show original" to confirm DKIM shows PASS.

How do I set up DMARC?

To set up DMARC, publish a TXT record at _dmarc.yourdomain.com that declares a policy and a reporting address. DMARC only passes when SPF or DKIM passes and aligns with the visible From domain, so set it up after SPF and DKIM are working.

Start in monitoring mode so you can observe traffic without affecting delivery:

• Host / Name: _dmarc
• Type: TXT
• Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

Key tags explained:

• p is the policy: none (monitor), quarantine (send failures to spam), or reject (block failures entirely).
• rua is the address that receives daily aggregate XML reports summarizing which messages passed and failed. This is how you find every legitimate sender before you enforce.
• adkim / aspf control alignment strictness: r (relaxed) allows subdomains, s (strict) requires an exact match.

The rua tag is the most valuable part of early setup. Aggregate reports tell you exactly which IPs and services send under your domain, so you do not break a forgotten newsletter or invoicing system when you tighten the policy.

How do I move from p=none to p=reject safely?

Move from p=none to p=reject in stages, spending at least 90 days at each step and reading your aggregate reports before advancing. Moving all the way to reject typically takes 9 to 18 months when done carefully, because the goal is to authenticate every legitimate mail stream before you start blocking failures.

1. Monitor (p=none): publish the record, collect aggregate reports, and identify every source sending under your domain. Fix any legitimate source that is failing SPF or DKIM.
2. Quarantine (p=quarantine): once reports show your real mail passing, move failures to spam. Many teams stay here as a safety net. You can ramp with pct=25 and increase gradually.
3. Reject (p=reject): when you are confident no legitimate mail fails, block unauthenticated messages outright. This is the strongest protection against spoofing and the policy that fully satisfies bulk-sender requirements.

If you want a BIMI brand logo to appear next to your mail in supporting inboxes, you must reach p=quarantine or p=reject with pct=100; BIMI will not display under a p=none policy.

How do I verify SPF, DKIM, and DMARC are working?

Verify your setup with both a live test message and DNS lookup tools, because a record can exist in DNS yet still fail alignment. Do not assume publishing equals passing.

1. Send a test to Gmail, open the message, click "Show original," and confirm SPF, DKIM, and DMARC each read PASS.
2. Check DNS propagation with a lookup tool (for example mxtoolbox or a DMARC checker) for your SPF, selector._domainkey, and _dmarc records.
3. Confirm SPF lookups are under 10 so you are not silently hitting a PermError.
4. Read your first aggregate reports after 24 to 72 hours to see real-world pass and fail data across every sender.

Common failure points: more than one SPF record on the domain, a DKIM selector that does not match what your platform signs with, a missing rua so you get no reports, or alignment failures where mail passes SPF on a different domain than the one in the From header. Each shows up clearly in either the message headers or the aggregate reports.

How does authentication fit into a multi-channel outreach program?

Authentication is the deliverability layer beneath email, but most modern outreach is not email-only, so it pays to think about channels together. SPF, DKIM, and DMARC govern the email leg; LinkedIn, WhatsApp, Instagram DM, and Telegram have their own delivery mechanics and reach prospects who never open a cold email.

Klovis runs sequenced outreach across all of these channels from your team's own connected accounts, so an authenticated domain handles your email steps while other steps reach the same prospect where they are most responsive. You build a sequence once and each step declares its channel. See multi-channel sequences for how a single campaign spans email and messaging.

The payoff after a clean setup is replies, and replies need a home. Every response from every channel lands in one place in the Klovis unified inbox, attributed to the right campaign and ready to action, while the self-updating CRM keeps contacts and deals current. Authentication gets your email delivered; the rest of the stack turns delivered messages into booked meetings and pipeline. If you are weighing tools for that workflow, our comparisons break down how the options differ.

SPF, DKIM, and DMARC setup checklist

Use this checklist to confirm a complete setup before you start sending at volume:

• One SPF TXT record on the root domain, every sender included, under 10 DNS lookups, ending in ~all or -all.
• A 2048-bit DKIM key per sending system, each with its own selector, published and signing outbound mail.
• A DMARC record at _dmarc with a policy and a working rua reporting address.
• A live test to Gmail showing SPF, DKIM, and DMARC all PASS.
• A documented plan to advance from p=none to p=quarantine to p=reject, reviewing aggregate reports at each stage.

Frequently asked questions

Do I need all three of SPF, DKIM, and DMARC?

Yes. SPF and DKIM authenticate the message transport, but DMARC is what enforces that the From address your recipient sees actually matches an authenticated domain, and it is what the major inbox providers explicitly require. Publishing only one or two leaves gaps that cause failures and spoofing risk.

How long does DNS take to propagate after I publish the records?

DNS changes usually take effect within minutes to a few hours, though full global propagation can take up to 24 to 48 hours depending on your record's TTL. Wait at least a day before assuming a record is not working, and verify with a lookup tool rather than guessing.

What is the SPF 10 DNS lookup limit and why does it matter?

SPF evaluation is capped at 10 DNS lookups; each include, a, mx, and redirect counts toward it. Exceed the limit and SPF returns a PermError and stops passing, even if your record is otherwise correct. Consolidate senders or flatten the record if you approach the ceiling.

Should I start DMARC at p=reject?

No. Start at p=none so you can collect aggregate reports and confirm every legitimate sender passes first. Jumping straight to reject risks silently blocking real mail from a forgotten service. Advance to quarantine, then reject, over weeks or months as the reports come back clean.

Does authentication guarantee my email reaches the inbox?

No. Authentication is a prerequisite for good deliverability, not a guarantee of inbox placement. Content, sending reputation, recipient engagement, and complaint rates all still matter. SPF, DKIM, and DMARC get you trusted at the door; what you send after that determines whether you stay welcome.