SPF, DKIM, and DMARC

SPF (Sender Policy Framework) lists which servers are allowed to send email for your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature so mailbox providers can verify a message was not altered in transit. DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells providers what to do when SPF or DKIM fail, and reports back who is sending as your domain. Together, these three DNS records are what Gmail, Outlook, and Yahoo check before deciding whether your cold email reaches the inbox or gets quarantined on the way in.

If your cold emails suddenly start landing in spam, the fix is usually in DNS, not the subject line. One missing DKIM signature, an SPF record that forgot a sender, or a DMARC policy that does not match your From domain can turn a healthy outbound program into a week of throttling and bounces. This is table-stakes setup, not the whole deliverability picture: treat it as the DNS layer of the prep work that goes into our full email warmup guide, which covers the ramp-up schedule that comes after authentication is live.

Mailbox providers have made identity checks a baseline. Google and Yahoo's 2024 bulk sender requirements pushed authentication from best practice to a hard requirement for anyone sending meaningful volume, and Microsoft has tightened filtering in the same direction. As of 2026, Google's own guidance still requires SPF, DKIM, and DMARC for anyone sending meaningful bulk volume to Gmail addresses, alongside a spam complaint rate that stays under 0.3% and one-click unsubscribe on bulk mail (see Google's email sender guidelines). Domains with sloppy or misaligned SPF, DKIM, and DMARC get punished earlier and more consistently than they did a few years back. The official specs live at RFC 7208 (SPF), RFC 6376 (DKIM), and RFC 7489 (DMARC). You do not need to read them to set this up, but the definitions in this guide map directly to what mailbox providers enforce. Skip straight to the setup steps if you already know what each record does.

What do SPF, DKIM, and DMARC actually check?

Each record answers a different question, and mailbox providers check all three before they trust a message enough to place it in the inbox.

If you send cold email through Google Workspace, Microsoft 365, or a dedicated sending platform, you publish these three records in your domain's DNS, usually managed in Cloudflare, GoDaddy, Namecheap, or your hosting provider. The sending tool signs and routes the mail; mailbox providers evaluate the results against what you published.

What each one does not fix

• SPF prevents unauthorized sending, but does not protect the message body. Forwarding can break SPF, because the forwarding server is not listed in your SPF record.
• DKIM proves integrity and domain control, but does not decide how strict providers should be. You can pass DKIM and still land in spam if your domain reputation is weak or your list quality is poor.
• DMARC ties the two together through alignment, meaning the domain a recipient sees in the From header has to match, or align with, the domain validated by SPF or DKIM. Without DMARC, a message can technically pass SPF or DKIM and still look suspicious to a mailbox provider.

Most cold email stacks mix more than one tool: Google Workspace or Microsoft 365 for the mailbox, a sequencing platform for sending, and often a CRM or support tool that also emails on your behalf. Each of those has to be covered by SPF, and each one that sends as your domain should sign its own DKIM key. Missing even one is usually what turns a "clean" setup into a DMARC alignment failure later.

How do SPF, DKIM, and DMARC work together?

A single authenticated email goes through all three checks in sequence on the receiving end:

1. SPF check. The receiving server looks up the SPF record for the domain in the SMTP "MAIL FROM" (the Return-Path), and confirms the sending server's IP is authorized.
2. DKIM check. The receiving server reads the DKIM-Signature header, fetches the public key at selector._domainkey.yourdomain.com, and verifies the signature matches the message.
3. DMARC check. The receiving server confirms that SPF or DKIM passed and that the passing domain aligns with the visible From address. If alignment fails, DMARC applies your published policy: monitor, quarantine, or reject.

This is why a message can pass SPF and DKIM individually and still fail DMARC: alignment, not just a pass or fail, is what DMARC actually grades. Getting all three right, in order, is table stakes before volume, subject lines, or copy matter at all.

How do you set up SPF, DKIM, and DMARC step by step?

Set up authentication in this order: SPF first, DKIM second, DMARC last. Each step depends on the one before it being correct.

1. Publish one SPF record (and merge instead of stacking)

The most common SPF mistake is publishing multiple SPF TXT records on the same domain. Many receivers treat that as a permanent error, and SPF fails outright.

1. Inventory every sender that uses your From domain: Google Workspace or Microsoft 365, your cold email platform, and transactional tools like Stripe, HubSpot, or Intercom.
2. Find any existing SPF record in your DNS host. Look for a TXT value starting with v=spf1.
3. Merge into one record: keep a single v=spf1 line and add the include: mechanisms each vendor requires.
4. Choose the right qualifier: use ~all (softfail) while you confirm every sender is covered, then move to -all (hard fail) once you are confident.

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

Per RFC 7208, receivers stop after 10 DNS lookups when evaluating SPF. Each include, a, mx, exists, and redirect consumes a lookup, including nested includes inside a vendor's own SPF record. Cross that limit and SPF can fail even when the record looks correct on the surface.

2. Turn on DKIM signing in your provider

Most DKIM failures happen because a team publishes the DNS record but never enables signing, or signs with the wrong domain.

1. Pick the exact domain you send from. If your From address is user@outbound.yourdomain.com, enable DKIM for that subdomain, not just the root domain.
2. Generate DKIM keys in your provider. In Google Workspace, use the Admin console to generate a selector and enable "Start authentication." In Microsoft 365, enable DKIM signing in the Defender or Exchange admin center.
3. Publish the record(s) exactly as given. Some providers issue CNAMEs instead of TXT records; publish all of them and keep the selector unchanged.
4. Wait for DNS to propagate, then enable signing. Some providers will not start signing until they can successfully query the published key.

selector1._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

Per RFC 6376, use a 2048-bit key when your provider offers the option. Shorter keys are weaker and can raise questions during an incident review. To confirm signing is live, send a test email to a Gmail inbox, open "Show original," and check for DKIM: PASS with a d= value matching your sending domain.

3. Roll out DMARC in three stages

DMARC is the layer that turns "SPF and DKIM exist" into a policy providers actually enforce. Roll it out in stages, never straight to enforcement.

1. Start at p=none to monitor. Publish a DMARC record at _dmarc.yourdomain.com and route reports to a mailbox you control.
2. Move to p=quarantine once reports are clean. Ramp the enforced percentage gradually while you watch for new or unknown senders.
3. Enforce p=reject once pass rates hold steady with no unexplained senders showing up in reports.

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; pct=100"

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; pct=25"

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; pct=100"

Per RFC 7489, DMARC defines two report types. RUA (aggregate reports) show pass, fail, and alignment rates by source, and are what most teams actually use for monitoring. RUF (forensic reports) can include message-level detail, but many providers do not send them consistently, so prioritize setting up RUA first. For a brand-new sending domain, plan on roughly 7 to 14 days at p=none, then 1 to 3 weeks stepping pct up through quarantine, before moving to reject. A domain that already sends stable, legitimate mail daily can often move faster once its reports show consistent aligned passes.

What are the most common SPF, DKIM, DMARC mistakes?

These are the errors that break an otherwise correct-looking setup.

How do you verify your SPF, DKIM, and DMARC setup?

Prove authentication before you blame copy or lists for a deliverability problem. One broken DNS record can turn a clean sequence into spam placement overnight.

1. Confirm the DNS records exist in your DNS host: exactly one SPF TXT record, the DKIM record(s) at the right selector, and a DMARC TXT record at _dmarc.yourdomain.com.
2. Run an SPF parse check. MXToolbox's SPF lookup shows the parsed record and flags a permanent error or a lookup count near the 10-lookup ceiling.
3. Send a real test message from the exact mailbox and tool you plan to use, to a Gmail inbox and an Outlook inbox.
4. Inspect the headers. In Gmail, open "Show original." In Outlook, view the message source. You want SPF: PASS, DKIM: PASS, and DMARC: PASS, with the From domain aligned to the passing domain, not just a bare pass.
5. Test every sending path separately (Google Workspace, Microsoft 365, your sequencer, your CRM). One forgotten tool can fail DMARC once you move to p=quarantine or p=reject.

dig txt yourdomain.com +short
dig txt selector1._domainkey.yourdomain.com +short
dig txt _dmarc.yourdomain.com +short

For ongoing monitoring, route DMARC aggregate reports into a parser and watch three signals: new or unknown senders, DKIM pass-rate drops after a provider migration or key rotation, and SPF permanent errors from an extra TXT record. Pair that with Google Postmaster Tools for Gmail and Microsoft SNDS for Outlook, since authentication can stay green while domain reputation quietly turns red.

One more layer worth checking: reputation is not only a domain-level number. A single domain can host several sending mailboxes, and one account sending low-quality mail can get rate-limited while the rest of the domain stays fine. If you run multiple inboxes for outbound, track bounce and complaint signals per mailbox, not just per domain, so one bad sender does not quietly drag the others down. Authentication proves identity; keeping sending behavior consistent with that identity, through steady volume, clean lists, and real personalization, is what a tool like Overloop is built to help with once SPF, DKIM, and DMARC are already in place.

Check your SPF or DMARC record syntax

Paste a record below to catch a broken mechanism or an invalid tag before it goes live. The check runs entirely in your browser against the syntax rules in RFC 7208 (SPF) and RFC 7489 (DMARC). Syntax check only, no DNS lookup is made: run dig txt yourdomain.com +short to confirm what is actually published on your domain.