How to Set Up SPF, DKIM, and DMARC (Step by Step)

Email authentication is the price of admission to the inbox. Since Google and Yahoo formalized their sender requirements in 2024, unauthenticated mail doesn't get judged on its merits — it gets rejected or dumped into spam before content or reputation even enter the picture.

The good news: setting up SPF, DKIM, and DMARC is a one-time job that takes about 30 minutes, and every record lives in the same place — your domain's DNS. This guide walks through all three, with exact syntax for the major providers.

What each record actually does

The three records answer three different questions a receiving server asks:

They're complementary, not redundant. SPF breaks when mail is forwarded; DKIM survives forwarding but says nothing about the visible From address; DMARC ties both back to the domain the recipient actually sees.

Step 1: SPF

SPF is a single TXT record on your root domain that lists who may send mail on its behalf.

Google Workspace:

Type:  TXT
Host:  @ (or yourdomain.com)
Value: v=spf1 include:_spf.google.com ~all

Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Zoho Mail:

v=spf1 include:zohomail.com ~all

If you send from multiple services (say, Google Workspace plus a transactional provider), combine them into one record:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

The ~all at the end means "soft fail anything not listed" — receivers treat unlisted sources as suspicious. -all is a hard fail, which is stricter and fine once you're confident the record is complete. Never use +all; it authorizes the entire internet to send as you, and some filters treat it as a spam signal in itself.

Step 2: DKIM

DKIM is generated by your email provider, not written by hand. You enable it in the provider's admin console, and it gives you a record (or a pair of CNAMEs) to publish.

• Google Workspace: Admin console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record. You'll get a TXT record on the host google._domainkey. Publish it, wait for DNS to propagate, then click Start authentication. Choose the 2048-bit key if your DNS host supports it.
• Microsoft 365: Defender portal → Email authentication settings → DKIM → enable for your domain. Microsoft gives you two CNAME records (selector1._domainkey and selector2._domainkey) pointing at their infrastructure.
• Zoho Mail: Admin console → Domains → your domain → Email Configuration → DKIM. Zoho generates a TXT record on a selector host such as zmail._domainkey.

The part before ._domainkey is called the selector — it lets one domain hold multiple DKIM keys, so signing for Google and a marketing tool can coexist without conflict.

Step 3: DMARC

DMARC is a TXT record on the host _dmarc that tells receivers what to do with mail that fails authentication — and, crucially, requires alignment: the domain that passes SPF or DKIM must match the domain in the visible From header.

Start here:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]

p=none enforces nothing — it's monitoring mode. The rua tag asks receivers to send you aggregate XML reports showing every source sending mail as your domain and whether it passed. Watch these for a few weeks; they routinely surface forgotten senders (a billing system, an old newsletter tool) that would break under enforcement.

The policy progression: none → quarantine → reject

Move up only when the reports show your legitimate mail passing:

1. p=none — collect data, fix any legitimate sources that fail.
2. p=quarantine — failing mail goes to spam. You can phase in with pct=25 to apply the policy to a quarter of failing mail first.
3. p=reject — failing mail is refused outright. This is the end state that actually stops domain spoofing.

Rushing to p=reject before your own mail aligns is the classic self-inflicted outage: your invoices and password resets start bouncing. Give each stage a couple of weeks of clean reports.

Adding records at your registrar

Wherever your domain's DNS is hosted (Cloudflare, Namecheap, GoDaddy, Route 53...), the process is the same: DNS management → add record → choose TXT (or CNAME for Microsoft's DKIM) → paste the host and value → save. Two things trip people up:

• Host field conventions. Some dashboards want the bare host (_dmarc), others want the full name (_dmarc.yourdomain.com). If a lookup shows _dmarc.yourdomain.com.yourdomain.com, you doubled it.
• Propagation. Changes usually appear within minutes but can take up to 48 hours depending on TTLs. Don't enable enforcement or flip provider switches until a lookup confirms the record is live.

Common mistakes

• Multiple SPF records. Two TXT records starting with v=spf1 is an automatic permerror — SPF fails entirely. Merge every service into one record.
• The 10-DNS-lookup limit. Each include: (and the includes it pulls in) costs DNS lookups, and SPF allows at most 10. Stack enough services and the record silently breaks. Remove unused includes or use a flattening service.
• +all or a missing all. Both leave the record effectively open. End with ~all or -all.
• DKIM enabled at the provider but the DNS record never published (or vice versa). Both halves must exist.
• DMARC without alignment. Mail can pass SPF for the bounce domain of a sending tool and still fail DMARC, because the passing domain doesn't match your From. Check the alignment columns in your reports, not just raw pass/fail.
• Setting p=reject on day one. Monitor first. Always.

Verify your setup

Don't trust the provider's green checkmark — look up the records yourself. Our free SPF/DKIM/DMARC checker queries your live DNS and flags duplicate SPF records, lookup-limit problems, weak DMARC policies, and missing records in one pass. No signup required.

Authentication is necessary but not sufficient: it proves who you are, while sender reputation decides where your mail lands. Once your records pass, that's the next thing to build.

If you're setting up a new mailbox anyway, EmailWarmer's free plan warms one mailbox forever at no cost — see what's included.