SPF, DKIM and DMARC for cold email: a setup guide with example records

For cold email, publish one SPF record, turn on DKIM signing and add a DMARC record at p=none with a report address, all on the domain you send from. Then move DMARC to p=quarantine after about a month of clean reports.

This guide gives example records for Google Workspace and Microsoft 365, the mistakes that break them and a DMARC rollout that starts with no effect on delivery. We checked it against the RFCs and the providers' own documentation on October 17, 2026, and we say where they disagree.

What SPF, DKIM and DMARC each do

The idea people miss is alignment. SPF checks the envelope sender, not the From address a person sees. DKIM checks the domain in the signature (the d= tag). DMARC passes when at least one of the two passes and its domain matches the visible From domain. One aligned pass is enough.

Relaxed alignment is the default, so a signature from mail.example.com aligns with a From address at example.com. Strict mode needs an exact match.

The DMARC standard changed this year. RFC 7489 (2015, Informational) is obsolete. RFC 9989 (May 2026, Standards Track) replaces it, with RFC 9990 for aggregate reports and RFC 9991 for failure reports. The p, rua and alignment tags carry over. The pct tag does not, which matters in the rollout.

Do you need all three? What Google and Microsoft require

Yes, set up all three. Google and Microsoft make all three mandatory only above a volume line, but the records are cheap and DMARC reports show who else sends as your domain.

• Google: every sender to personal Gmail addresses needs SPF or DKIM. Bulk senders need SPF, DKIM and DMARC at p=none or stronger, with the From domain aligned. Google's requirements page defines bulk as more than 5,000 messages a day to personal Gmail addresses; its FAQ says close to 5,000 or more. Bulk status never expires, mail from subdomains counts toward the primary domain, and Google Workspace recipients are not covered.
• Microsoft: domains sending more than 5,000 emails a day to consumer Outlook.com addresses (outlook.com, hotmail.com, live.com) need SPF and DKIM passing and DMARC at p=none or stronger, aligned. Microsoft says non-compliant mail goes to the junk folder first and may later be rejected with error 550 5.7.515, so watch your bounce logs.

If you send far fewer than 5,000 messages a day, you are below these lines. Set up all three anyway. Google's bulk status is permanent once you reach it, and Microsoft strongly recommends all three for every sender.

Authentication proves which domain sent a message, not that anyone wanted it. Google's guidelines also ask senders to keep the user-reported spam rate in Postmaster Tools below 0.10% and never let it reach 0.30%. Bounces are worth controlling too (see catch-all emails). Our deliverability guide has the full rules.

Step 1: Publish one SPF record

An SPF record is one TXT line on your sending domain. Publish exactly one per domain and put every sender in it. These are Google's and Microsoft's own recommended records for a domain that sends only through that provider (example.com is a placeholder).

Some DNS hosts want the full domain name instead of @, and some append your domain automatically, so typing the full name can create example.com.example.com. Check the saved record.

The providers disagree on the ending. Google recommends ~all (softfail). Microsoft recommends -all (hard fail) because it also recommends DKIM and DMARC. RFC 7208 calls softfail a weak statement, and DMARC treats both as failures. Follow your provider's advice. One record and a working DKIM key matter more than the ending.

Fix an SPF record with too many lookups

RFC 7208 section 4.6.4 allows 10 DNS-querying terms per evaluation: the include, a, mx, ptr and exists mechanisms and the redirect modifier. The ip4, ip6 and all terms are free. Go over 10 and the result is permerror, which counts as an SPF failure. Nested includes count: an include that points at a record holding three more includes costs four.

An illustration: a Workspace domain that also authorizes three other tools, counted from the vendors' public DNS records on October 17, 2026.

That record fails. Evaluation stops at the first match, so mail from Google may pass while mail matched later fails, which makes the error look intermittent (Microsoft notes this). The fixes:

• Delete senders you no longer use, and drop mx and a unless that server really sends your mail.
• Move other tools to a subdomain with its own record and its own 10-lookup budget.
• Swap an include for ip4 ranges only if the vendor publishes stable ones. Microsoft says not to flatten its own.

Google's help page says a record can have up to 10 include tags. That counts only the includes you write. Nested includes, a and mx count toward the RFC's limit of 10 as well, so count lookups, not tags. Google's and Microsoft's own includes were flat (one lookup each) when we queried them, but vendors change records, so check live values with an SPF checker.

Step 2: Turn on DKIM

Your mail provider signs each outgoing message with a private key, and you publish the matching public key in DNS. The selector is a label that lets a domain publish several keys: a signature carrying d=example.com and s=google sends the receiver to google._domainkey.example.com (RFC 6376). The host you publish must match the selector the provider signs with.

DKIM for Google Workspace: generate, publish, start

1. Wait 24 to 72 hours after turning on Gmail. Generating a key earlier can fail.
2. In the Admin console, open Apps, Google Workspace, Gmail, then Authenticate email, pick your domain and click Generate new record. Choose 2048 bits if your DNS host supports it and keep the default selector prefix, google.
3. Add a TXT record at the host google._domainkey with the value Google shows. It starts v=DKIM1; k=rsa; p= and then the key.
4. Click Start authentication once the record is published. Google says DKIM can take up to 48 hours to start working after you add the key.

Each domain needs its own key, including a separate sending domain. Google requires at least 1024 bits for personal Gmail and recommends 2048.

DKIM on Microsoft 365

Microsoft 365 uses two CNAME records instead of one TXT record. Microsoft's guide says no DKIM signing occurs for outbound mail from a custom domain until you configure it.

1. Copy the two CNAME targets for your domain from the Defender portal (Email authentication settings, DKIM tab) or from Get-DkimSigningConfig in Exchange Online PowerShell. Copy them rather than typing them: the targets are unique to your tenant, and the format changed for new custom domains in May 2025.
2. At your DNS host, create CNAME records at selector1._domainkey and selector2._domainkey pointing at those targets.
3. Switch signing on for the domain.

One selector signs at a time and the other waits for key rotation. Microsoft lists 1024 bits as the PowerShell default (a 2048 option exists), and Google recommends 2048, so choose 2048.

Set up DMARC for cold email: p=none, then quarantine

DMARC is one TXT record at the _dmarc host. Publish it after SPF and DKIM are working. Google advises letting them authenticate for 48 hours first. Send reports (the rua tag) to a dedicated mailbox or group, not your own inbox, because daily XML reports add up.

DMARC p=none is monitoring mode: it asks receivers for no action. In the reports, look for the classic problem Microsoft describes, where SPF or DKIM passes but alignment fails, so a sender is authorized but uses its own domain. High volume from servers you do not recognize may be someone else sending as you, which is what enforcement is for.

How long should DMARC stay at p=none?

Plan on at least a month. The Google and Microsoft guides give no minimum. RFC 9989 (section 7.4) tells domains that want p=reject to publish p=none for at least a month and then p=quarantine for an equally long period. We treat a month as a cautious default for quarantine too. That is our judgment, not a standard.

Why wait before quarantine?

p=none already meets Google's and Microsoft's bulk rules, so quarantine is about stopping spoofing, and it costs you if your setup is wrong. Microsoft routes outbound mail from Microsoft 365 domains that fails DMARC at the receiving end through a high-risk delivery pool under quarantine or reject, with no override. Microsoft 365 recipients that honor DMARC policy (Microsoft recommends this) send failing quarantine mail to Junk. Enforce only after clean reports.

Should you use p=reject?

Microsoft's rollout guide ends at p=reject, and its Outlook.com policy page calls p=reject recommended. RFC 9989 (section 7.4 and appendix C.6) says domains for general-purpose email should not use p=reject, because it can break indirect mail flows such as forwarders, role aliases and mailing lists.

Forwarding usually breaks SPF while DKIM generally survives, so RFC 9989 says a domain that publishes p=reject must not rely on SPF alone and must sign with DKIM. A sending-only domain is a narrower case. We would still stop at quarantine as the lower-risk choice. That is a judgment, and reject is a legitimate choice once reports are clean and DKIM aligns.

What happened to the pct tag?

RFC 7489 and the Google and Microsoft guides use pct for a gradual ramp (pct=25, then 50, and so on). RFC 9989 removed it because it was usually not applied accurately except at 0 or 100, and added t=y, which asks receivers to treat failures one level softer. The pages we read do not say which receivers honor t. With one or two senders, skip both and go to full quarantine once reports are clean.

Check that SPF, DKIM and DMARC pass

Send a message from the sending mailbox to a different Gmail or Outlook.com address you control. Google notes that a test sent to yourself does not verify DKIM.

Open the full headers (Show original in Gmail) and find Authentication-Results. You want spf=pass, dkim=pass and dmarc=pass, with matching domains in smtp.mailfrom, header.d and header.from.

Mistakes that break authentication

• A second SPF record. RFC 7208 says a domain must not publish multiple records a receiver could select, and the result is permerror. It happens when you add a new tool's TXT line instead of editing the existing record.
• More than 10 lookups. It can appear months later, when someone adds a tool. See the lookup table above.
• DKIM published but not switched on. Google needs Start authentication and Microsoft needs signing enabled. Until then your domain may have no signature of its own, and DMARC has only SPF to lean on.
• A selector or host typo. The host is the selector plus ._domainkey. A doubled domain name or a record on the wrong subdomain means no key is found.
• Alignment failures. A third-party tool can pass SPF and sign DKIM under its own domain, so DMARC fails for yours. Have it sign with your domain or use your domain in its return path. Mail from your own Workspace or Microsoft 365 mailbox normally uses your domain for both. Leave the relaxed default, because Google and Microsoft both warn that strict alignment can break subdomain senders.
• DMARC record problems. It must sit at _dmarc, and there must be only one. If rua points at an address on another domain, that domain must publish a TXT record named after yours, such as example.com._report._dmarc.example.net, with the value v=DMARC1. Without it, receivers will not send the reports (RFC 9990 section 4 and Microsoft describe this).

Should cold email use a separate sending domain?

Usually yes, and a separate registered domain beats a subdomain. This is our judgment: no RFC or provider document requires it, and opinions differ.

The case for it. Reputation attaches to what a domain sends. If outreach draws complaints or bounces, you want that to land on a domain with no invoices, support threads or customer replies. Microsoft recommends a subdomain for bulk email services you do not directly control, so their problems do not reach the main domain. Your own mailboxes are a different case, but the same reasoning may apply.

Why not a subdomain. Google counts bulk volume at the primary domain, so a subdomain does not hide it, and the pages we read do not say how much reputation a subdomain shares with its parent. A different registered domain avoids the question.

The costs. A registration fee, a second full setup of everything above, and a domain with no sending history, so ramp slowly (see how many cold emails per day). Mailboxes on the new domain are ordinary users on your Workspace or Microsoft 365 plan, so check the cost. Keep mailboxes per domain modest: FoxKnock, for example, asks for confirmation before more than three share a domain.

Stay honest. The FTC's CAN-SPAM guide says header information, including the originating domain name and email address, must be accurate and identify the person or business that sent the message. Choose a domain name that plainly points to your business and put a short page on it that links to your main site. For the wider rules on who you may email, see our GDPR cold email guide. This is general technical information, not legal advice.

How FoxKnock handles this

FoxKnock sends only from your own mailboxes, so your mail provider does the signing and the records in this guide are the ones that count.

It connects Google Workspace, or any SMTP and IMAP mail server, with an app password. Microsoft 365 is limited. Microsoft no longer accepts passwords (Basic authentication) for IMAP in Exchange Online and is retiring it for SMTP AUTH, so a Microsoft 365 mailbox may not connect or may not sync replies. FoxKnock does not offer Microsoft sign-in. The Microsoft 365 steps above still apply to your domain's DNS.

For each mailbox, FoxKnock checks SPF, DKIM, DMARC and MX and explains problems in plain English with a suggested fix, which you apply at your DNS host. For DKIM it tries six common selector names (google, selector1, selector2, default, k1 and s1), so a custom selector can show as missing even when it is set up. It does not count SPF lookups.

Passing these checks is not an inbox-placement test, and FoxKnock has no inbox-placement testing or warm-up network. What it adds is send discipline: 25 sends a day per mailbox by default, a ramp from 8 a day to the limit over 21 days, and an automatic pause when bounces go above 2% of the last 100 sends. See cold email sending.

If you would like to see the DNS check on your own domain, the Free plan has 500 one-time credits (granted after you verify your email), one mailbox and needs no card. You can create a free account and connect a Google Workspace or other SMTP and IMAP mailbox.