How to Configure SPF, DKIM and DMARC (Step-by-Step)

SPF, DKIM and DMARC are three DNS records that prove an email really came from your domain. Since Gmail and Yahoo started enforcing sender requirements in 2024 — and Microsoft followed for Outlook.com in 2025 — they are no longer optional for anyone sending at volume. Bulk senders need all three.

This guide shows what each record does, the exact values to publish, and the mistakes we see most often.

The 30-second version

Record	Where it lives	What it proves
SPF	TXT on yourdomain.com	Which servers may send for your domain
DKIM	TXT on selector._domainkey.yourdomain.com	The message was signed by your domain and not altered
DMARC	TXT on _dmarc.yourdomain.com	What receivers should do when SPF/DKIM fail, and where to send reports

Want to see where you stand right now? Run your domain through the Domain Health Check before you change anything.

Step 1: Publish one SPF record

SPF is a single TXT record on the root of your domain. It lists every service allowed to send as you.

Google Workspace:

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

Microsoft 365:

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

If you also send through other tools (a CRM, a helpdesk, a transactional email service), add their include: to the same record:

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

SPF rules that trip people up

• One record only. Two v=spf1 records on the same domain is a permanent error, and SPF fails for every message.
• Ten DNS lookups maximum. Every include, a, mx, exists and redirect counts — including the lookups nested inside each include. Go over 10 and SPF fails. Our SPF Checker expands the whole tree and counts them for you.
• Use ~all or -all. Never +all, which authorizes the entire internet.

Step 2: Turn on DKIM

DKIM adds a cryptographic signature to every message. You generate the key in your email provider, then publish the public half in DNS.

Google Workspace: Admin console → Apps → Google Workspace → Gmail → Authenticate email. Generate a 2048-bit key, publish the TXT record it gives you at google._domainkey, wait for DNS to update, then click Start authentication.

Microsoft 365: Microsoft Defender portal → Email authentication settings → DKIM. Microsoft gives you two CNAME records (selector1._domainkey and selector2._domainkey). Publish both, then enable signing.

Publishing the DNS record is only half the job. Until you click “Start authentication” (Google) or enable signing (Microsoft), your mail is not DKIM-signed with your domain.

Verify it with the DKIM Checker — enter your domain and selector, or let it auto-discover common selectors.

Step 3: Add DMARC

DMARC ties SPF and DKIM to the domain in the visible From address (this is called alignment) and tells receivers what to do when checks fail.

Start in monitoring mode:

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

Then tighten over a few weeks:

1. Weeks 1–4: p=none — collect reports, find every legitimate service sending as you, and fix their SPF/DKIM.
2. Next: p=quarantine — failing mail goes to spam. You can use pct=25 to roll it out gradually.
3. Finally: p=reject — failing mail is blocked outright.

Use the DMARC Generator to build the record without syntax errors.

Cold email domains: what’s different

If a domain exists only for outreach, the same records apply, with a few practical notes:

• Point the root domain somewhere sensible (a redirect to your main site) and keep MX records in place so the domain can receive replies.
• p=none with a rua address is common for secondary outreach domains; what matters most is that SPF and DKIM pass and align.
• Every new domain needs the full setup. A single domain missing DKIM can drag down a whole campaign — which is exactly the kind of thing FeedPipeline Monitor is built to catch across hundreds of domains.

Checklist

• Exactly one SPF record, under 10 lookups, ending in ~all or -all
• DKIM key published (2048-bit) and signing enabled in your provider
• DMARC record at _dmarc with a rua reporting address
• Re-checked after DNS propagation with the Domain Health Check