SPF, DKIM and DMARC for Cold Email: Google’s 48-Hour Order, with Workspace and Microsoft 365 Steps

On this page 11 sections

This is how to set up SPF, DKIM and DMARC on a cold email domain, the secondary domain you send outreach from, before you connect its Google Workspace or Microsoft 365 mailbox to a sending tool.

The mistake to avoid first is a second SPF record on the domain: keep one v=spf1 line. lemlist’s authentication guide²¹ (updated April 1, 2026) names duplicate SPF records first in its sentence on “the most common mistakes.”

What do you need before you start, and how long does it take?

Adding up Google’s own numbers (its DKIM² and DMARC⁴ setup pages, read October 25 and 27, 2026), a brand-new Workspace tenant takes at least three days, and a week if every wait runs to its published figure, nearly all of it waiting.

You need admin access to Google Workspace or Microsoft 365 and to the domain’s DNS; the records themselves cost nothing.

The waits: 24–72 hours after Gmail is turned on before the DKIM key is available, up to 48 hours for DKIM to start authenticating, then at least 48 hours of SPF and DKIM passing before DMARC.

Three days is the key’s 24 hours plus the 48-hour minimum before DMARC, with DKIM authenticating at once; a week is the key’s 72 hours, DKIM’s full 48 and the same 48-hour minimum, which Google states as a floor, not a limit. Neither is a measurement.

On Microsoft 365 the DKIM step takes “a few minutes (or possibly longer)” and Microsoft sets no wait before DMARC, so the 48 hours apply only if you follow Google’s rule there too.

Do you need all three? Gmail⁶ and Yahoo¹³ require SPF or DKIM from every sender, and SPF, DKIM and DMARC (p=none is enough, with the From domain aligned) from bulk senders (both pages checked October 18 and 27, 2026).

Outlook.com¹² requires the same three from domains sending “more than 5,000 emails per day” to its consumer addresses (Microsoft’s post of April 2, 2025, read October 18 and 27, 2026).

Google’s sender guidelines FAQ⁷ defines a bulk sender as one that “sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period,” counting all mail from the same primary domain.

Yahoo’s FAQ¹⁴ says “We will not specify a volume threshold” (both pages checked October 18 and 27, 2026).

The other rules, and how far they reach B2B prospects, are in our deliverability guide’s sender-requirements section.

The records differ by provider only in SPF’s ending and DKIM’s form:

Phones show the Microsoft column after a sideways scroll.

Record values from Google Workspace Admin Help (SPF¹, DKIM² and DMARC⁴ pages, last updated October 22, 2026).

Microsoft Learn (SPF⁹ and DKIM¹⁰ pages updated July 3, 2026; DMARC¹¹ page updated July 17, 2026), checked October 18, 22, 25 and 27, 2026.

The SPF endings are each vendor’s recommendation, not a rule: Google’s page says “Google recommends you use ~all,” and Microsoft’s says “For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain.”

Vendors change console paths and wording; the Sources list the exact pages.

Per Google’s setup pages (read October 25 and 27, 2026), an SPF record “lists all the servers that send email for your domain,” DKIM authenticates each message “with a DKIM signature” that receivers check against your public key, and DMARC “tells receiving email servers what action to take” on messages that fail SPF or DKIM.

Per Google’s and Microsoft’s DMARC pages (read October 18 and 27, 2026), each record checks a different domain, and DMARC is the one that ties them to the address your prospect sees:

From the alignment tables on Google’s Set up DMARC⁴ page and Microsoft’s DMARC page¹¹, checked October 18 and 27, 2026.

DMARC passes when SPF or DKIM passes and that record’s domain matches the From domain, and fails only if both fail; “matches” means relaxed alignment, the default, which also accepts subdomains.

Google’s Troubleshoot DKIM issues³ page (updated October 22, 2026) adds that forwarded messages can fail DKIM even when the record is right, because of how the forwarding server handles the message. Our deliverability guide explains the three records plainly.

Quoted from the vendors’ help pages, re-read October 22, 25 and 27, 2026. The SPF and DKIM rows are maximums (“up to”); the DMARC and p=none rows are minimums (“at least”), and Google’s DMARC page puts the first as “at least 48 hours”.

Microsoft’s detection sentence gives no bound (“or possibly longer”), but the same DKIM page says DNS propagation “can take a few minutes to 48 hours” and treats a status still CnameMissing after 48 hours as a record error.

How we researched this. Based on the Google, Microsoft, Yahoo, Instantly and lemlist pages and the two RFCs listed in Sources, read on October 1–2, 2026 and again on October 18, 22, 25 and 27, 2026.

The notes under the Google Workspace steps are a setup record on our own test domain; we have sent nothing to prospects from it.

Instantly’s warmup on that mailbox was switched on October 1, 2026 by Claude, an AI assistant working in the owner’s account, after the owner approved it.

The counters Claude read there (Japan time; October 3: health score 100%, 3 warmup emails sent and 18 received in 7 days; October 14, the trial’s last day: 100%, 59 sent, 179 received, 0 in spam) are warmup counters, not a deliverability result, and none were taken after the trial ended.

Researched and drafted with an AI assistant, with sources re-read in raw text; see our editorial policy.

How do you set up SPF, DKIM and DMARC on Google Workspace?

On Google Workspace (its setup pages read October 18, 22, 25 and 27, 2026), SPF is one TXT record, DKIM is a key you generate under Apps > Google Workspace > Gmail > Authenticate email, and DMARC is a _dmarc TXT record you add after both are working.

The values come from Google’s SPF, DKIM and DMARC setup pages, last updated October 22, 2026.

1. Add the SPF record. At your DNS host, create a TXT record named @ with the value v=spf1 include:_spf.google.com ~all; Google recommends ~all. Other services that send for this domain go in the same record as extra include: tags (Google allows up to 10 include: tags; Microsoft’s SPF page adds that nested include: statements add lookups toward the 10-lookup limit, see mistake 1).

   Check: dig TXT yourdomain.com +short shows exactly one line starting v=spf1.

2. Generate the DKIM key. Signed in as a super administrator, go to Menu > Apps > Google Workspace > Gmail > Authenticate email, pick the domain and click Generate New Record. Keep the default selector google. Choose 2048 bits “if your domain provider supports 2048-bit keys,” otherwise 1024. Google says that within 24–72 hours of turning Gmail on “you might get an error that the DKIM record was not created.”

   Check: the page shows the TXT record value and the message “DKIM authentication settings updated.”

3. Publish the key as a TXT record. Name google._domainkey, value the v=DKIM1; k=rsa; p=… string the console shows. A 2048-bit key is longer than the 255 characters many hosts allow per TXT string; see mistake 2.

   Check: dig TXT google._domainkey.yourdomain.com +short returns the key.

4. Click Start authentication. Google says the status then changes to “Authenticating email with DKIM” once DKIM works, which can take up to 48 hours.

   Check: the status line, then the message headers of a real send (see checking the records).

5. Wait at least 48 hours, then add DMARC. Create a TXT record named _dmarc with v=DMARC1; p=none; rua=mailto:[email protected]. Leave out ruf: Google says Gmail doesn’t support it.

   Check: dig TXT _dmarc.yourdomain.com +short returns the record once.

How do you set up SPF, DKIM and DMARC on Microsoft 365?

On Microsoft 365 (Microsoft Learn pages read October 18 and 27, 2026), SPF is the TXT record enrollment already required you to create, DKIM is two CNAME records plus a toggle in the Microsoft Defender portal, and DMARC is the same _dmarc TXT record as on Google.

The values come from Microsoft Learn’s SPF⁹ and DKIM pages (updated July 3, 2026) and its DMARC page (updated July 17, 2026).

1. Confirm the SPF record. Enrollment already had you create it at your DNS host; Microsoft 365 has no SPF setting of its own. For a domain that sends only through Microsoft 365: v=spf1 include:spf.protection.outlook.com -all.

   Microsoft recommends -all because “the DMARC policy is effectively ignored for SPF ~all failures if the messages don’t also contain DKIM signatures.”

   Check: dig TXT yourdomain.com +short returns one v=spf1 line.

2. Get the DKIM CNAME values. In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, open the DKIM tab, and try to slide the domain’s toggle to Enabled. A “Client error” dialog then shows the two CNAME values, which also appear in the domain’s flyout under Publish CNAMEs.

   Check: the flyout lists both hostnames, selector1._domainkey and selector2._domainkey, with their CNAME targets.

3. Publish the two CNAMEs. Hosts selector1._domainkey and selector2._domainkey, pointing to selector1-<yourdomain-with-dashes>._domainkey.<initial-domain-prefix>.<letter>-v1.dkim.mail.microsoft and the matching selector2 value. The letter is assigned by Microsoft, and the format applies to custom domains added since May 2025: copy your values from the portal.

   Check: dig CNAME selector1._domainkey.yourdomain.com +short returns the target.

4. Turn signing on. Microsoft says it “takes a few minutes (or possibly longer)” to detect the CNAMEs. Then switch on “Sign messages for this domain with DKIM signatures” in the same flyout.

   Check: the status reads “Signing DKIM signatures for this domain.”

   On key size, Microsoft’s page documents PowerShell only: New-DkimSigningConfig uses 1024 bits unless you add -KeySize 2048.

   For a domain that already has keys, Rotate-DkimSigningConfig -KeySize 2048 updates the next active selector at the first rotation and the other selector at the second; each rotation takes “four days (96 hours).”

5. Add DMARC after SPF and DKIM. Microsoft says to finish SPF and DKIM first, then add the same _dmarc record as above, with rua going to a shared mailbox or Microsoft 365 Group (“don’t deliver the reports to a user’s mailbox”).

   Check: nslookup -type=TXT _dmarc.yourdomain.com, and make sure only one _dmarc record exists.

Does your sending tool need anything else?

For a mailbox you connect, Instantly and lemlist add no SPF, DKIM or DMARC record of their own: lemlist’s guide says it “doesn’t host these records,” and Instantly’s DNS article sends you to your email provider for the values (both read October 18 and 27, 2026).

The three records above still do the work; only Instantly’s Done-For-You and pre-warmed domains have “DNS records are configured automatically,” its article says.

What each adds is a custom tracking domain, a CNAME on a subdomain you own (lemlist also asks for a verification TXT record at host @, and Instantly can ask for one when it shows “Your domain needs additional verification”).

The tracking domain makes the links in your emails point at your own subdomain and is not one of the three authentication records.

That TXT record is not a second SPF record: RFC 7208¹⁵ (April 2014, section 4.5) tells receivers to discard TXT records that don’t begin with exactly v=spf1, so add it as its own record and leave your SPF line alone.

Set the tracking domain up after you connect the mailbox, from the values your tool shows you: lemlist’s tracking-domain article¹⁹ lists “an email address connected in lemlist” among its prerequisites, and Instantly’s setting sits under each email account.

Both tools check your records for you once the mailbox is connected. Instantly’s DNS setup article¹⁷ (updated October 9, 2026) says to click “Test domain setup” on the Email Accounts dashboard and review the results.

Its account-readiness article²⁴ (updated October 15, 2026) says the test should show that “MX, SPF, DKIM, and DMARC are all configured.”

The DNS health article²⁰ from lemlist (Paid link) (updated October 2, 2026) describes a DNS health tab under Settings > Account health: pick an email account, click Refresh checks, and read the SPF, DKIM and DMARC results.

When a tool sends through the Google or Microsoft mailbox you connected and the envelope sender is your own domain, that is the SPF alignment Google’s DMARC page describes (the Return-Path domain matching the From domain); check it in the same Authentication-Results header.

A service that sends from its own servers under your From address needs a DKIM key signed with your domain, or an envelope sender (MAIL FROM) on your domain that your SPF record authorizes.

Google’s DMARC page says to “make sure the provider’s envelope sender domain matches your domain.”

Adding the service’s include: to your SPF record isn’t enough on its own: Microsoft’s troubleshooting table shows the case where the service’s MAIL FROM uses its own domain and nothing signs DKIM with yours as “SPF passes for adatum.com but DMARC fails.”

Where the sending layer fits in the whole setup is in our cold outreach stack guide.

How do you check that the records are live?

Look up the three records with dig (or, for MX, SPF and DKIM, in the browser with Google’s free Check MX).

Then send one email to someone on Gmail or Google Workspace, as Google’s Set up DKIM² page (updated October 22, 2026) says, and read its Authentication-Results header for spf=pass, dkim=pass and dmarc=pass.

Do the lookups before you connect anything; from a Mac or Linux terminal:

dig TXT yourdomain.com +short                       # SPF: exactly one v=spf1 line
dig TXT google._domainkey.yourdomain.com +short     # DKIM on Google Workspace
dig CNAME selector1._domainkey.yourdomain.com +short  # DKIM on Microsoft 365 (and selector2)
dig TXT _dmarc.yourdomain.com +short                # DMARC: exactly one v=DMARC1 line

Add @1.1.1.1 or @8.8.8.8 after dig to ask a specific public resolver, as in our setup log. On Windows, use nslookup -type=TXT.

Without a terminal, Check MX⁸, in Google’s Admin Toolbox, takes a domain name and an optional DKIM selector (google for Workspace, selector1 for Microsoft 365); its title reads “Check MX and SPF Records,” and the selector field covers the DKIM key. It’s free.

DNS shows the records exist; whether they pass shows only on a delivered message. Send one email from the new mailbox to someone on Gmail or Google Workspace; Google’s DKIM page notes that “you can’t verify DKIM is on by sending yourself a test message.”

Open the received message’s headers (in Gmail, More next to Reply, then Show original) and find the Authentication-Results header.

Google says the DKIM result should read something like DKIM=pass or DKIM=OK.

Microsoft’s DMARC page walks through the same header’s spf=, dkim= and dmarc= results; on mail Microsoft 365 receives, dmarc=bestguesspass means “no DMARC record published for the From domain,” so your _dmarc record isn’t resolving yet.

For monitoring over time, see our deliverability guide’s Postmaster Tools section.

When should you move from p=none to quarantine or reject?

Google, Microsoft and the DMARC standard all say (pages read October 18 and 27, 2026) to start at p=none with a rua address and move to quarantine or reject only after you’ve read the reports. Not every vendor agrees on whether to stay there:

• Google’s recommended rollout⁵: none “for one week” with daily report reviews, then quarantine for a small share of mail (its example is pct=5), raised gradually; it adds that “you can use reject instead of the quarantine if required.”
• Microsoft’s DMARC page: a “gradual approach” from none to quarantine to reject in pct= steps of 10, 25, 50, 75 and 100, reviewing aggregate reports “weekly during initial deployment; monthly once stable.”

  Outbound Microsoft 365 mail that fails DMARC goes through Microsoft’s high-risk delivery pool when your policy is quarantine or reject.

• RFC 9989¹⁶, the DMARC standard published in May 2026 that obsoletes RFC 7489: “Domain Owners usually start with ‘p=none’,” which it calls Monitoring Mode. It drops the pct tag, which “was usually not accurately applied” except at 0 or 100.

  In its place is a test flag, t=y, which asks receivers not to apply the policy while you test, with the expectation that failing mail gets the policy one level below the one you publish.

• lemlist’s authentication guide²¹ (updated April 1, 2026) disagrees with staying at p=none: it says p=none “often provides little real protection” and recommends “at least p=quarantine as a practical baseline.”

Gmail’s, Yahoo’s and Outlook.com’s rules all accept p=none (see above).

Even so, Microsoft’s Outlook.com post¹² calls p=reject “the most effective at thwarting domain spoofing” once your legitimate senders are aligned, and advises moving “gradually (none → quarantine → reject) to avoid unintended mail loss.”

Either way, read the p=none reports first so you know every service that sends as your domain, and if you follow Google’s or Microsoft’s percentage stages, judge each stage by what those reports show.

What mistakes break SPF, DKIM or DMARC?

The first mistake to rule out is a second SPF record on the domain, which makes SPF return permerror (Microsoft’s SPF page); lemlist’s guide puts duplicate records at the head of its common-mistakes sentence.

Google’s and Microsoft’s troubleshooting pages, and for the last one lemlist’s help, name the symptom each error leaves in the console or the Authentication-Results header, so here are six mistakes with what you’d see:

1. A second SPF record, a syntax slip, or more than 10 lookups. Symptom: for a second record, more than 10 lookups or an include: that doesn’t resolve, SPF returns permerror (Microsoft’s SPF page; for the lookup limit the bounce can read “The message required too many lookups”); for a syntax slip, Microsoft says that “SPF validation fails.” RFC 7208 (section 3.2) says a domain “MUST NOT have multiple records” an SPF check could select, and section 4.6.4 caps the DNS-querying terms at 10 per check.

   Microsoft’s table of common syntax mistakes lists three: a trailing period after the include domain, include= instead of include:, and a space after the colon.

   The unresolved include: is a separate sentence on the same page (“doesn’t resolve or has no SPF record”), and it is the permerror case above.

   Nested includes count toward the 10; ip4: and ip6: entries don’t. Keep one record and extend it with another include:; copying a main domain’s long record onto the new domain is one way to hit the limit.

   lemlist’s guide separately names “copied DNS values that don’t match the actual provider” among the common mistakes.

2. A 2048-bit DKIM key pasted into a 255-character field. Symptom (Google’s DKIM troubleshooting page³): “Your DKIM key might be truncated, or your DKIM records might be sent out of order.”

   The page’s “Verify TXT record character limits” section says to “Split the key characters into multiple text strings” and “Put each string inside quotes”; a 1024-bit key is the alternative.

3. DKIM CNAMEs Microsoft can’t see. Symptom: the Defender portal’s toggle won’t enable and the status “remains CnameMissing.” Microsoft’s DKIM page names these causes, among others: the hostname entered with the full domain appended, a TXT record instead of a CNAME, a wrong domain format in the target, and a missing or extra trailing dot on the CNAME target.

   The same page allows up to 48 hours for DNS propagation; a status still CnameMissing after 48 hours points to a wrong or misplaced record.

   Two more show differently: with a missing selector2 record “DKIM signing enables successfully, but key rotation fails later,” and a TTL below Microsoft’s recommended 3600-second minimum can show as intermittent dkim=temperror.

4. Publishing the key but never turning signing on. Symptom on Google: a “Not authenticating” error, which its troubleshooting page answers with “click Start authentication.” On Microsoft, the toggle stays Disabled.

   Google adds that forwarded mail can fail DKIM: body hash did not verify next to the dkim entry means the message was changed in transit, so test with a direct send.

5. Adding DMARC the same hour as SPF and DKIM, or twice. Until SPF or DKIM passes with alignment, every message fails DMARC, and even at p=none that shows in the reports; Google asks for at least 48 hours.

   Microsoft’s DMARC page reads dmarc=temperror or dmarc=permerror as a DNS problem and says to “ensure only one _dmarc TXT record exists”; dmarc=bestguesspass (on mail Microsoft receives) means no record was found.

6. Turning on open or click tracking without a tracking domain. Not an authentication failure, but lemlist’s help says “sending will be blocked” if tracking is on without a configured tracking domain; Instantly documents it as a setup step, not a block.

FAQ

What records go on domains I own but never send from?

Records that say no mail should come from them: Microsoft’s SPF page gives v=spf1 -all and its DMARC page v=DMARC1; p=reject; at _dmarc for parked domains, with reporting addresses “arguably not needed” there.

Microsoft doesn’t recommend DKIM CNAMEs for parked domains.

Why set this up on a secondary domain rather than your main one?

Reputation. Microsoft’s SPF page recommends a subdomain for mail services outside your direct control so that their problems don’t “affect the reputation of mail sent by employees in your main email domain” (read October 18 and 27, 2026).

Our deliverability guide applies the same logic to cold email: one or two secondary domains that redirect to your main site, each with the three records above.

Do subdomains need their own SPF, DKIM and DMARC records?

SPF, yes: Google’s SPF page says “If you use subdomains, you must add an SPF record for each subdomain,” and Microsoft’s says each subdomain you send from “requires its own SPF TXT record.”

DKIM: a subdomain you send from can have its own key (Google’s DKIM page: “check with your domain provider to find out how to add a TXT record for subdomains”); under relaxed alignment, a signature whose d= is the parent domain also aligns for mail from the subdomain.

DMARC is inherited: Google’s DMARC page describes the sp tag, which “sets the policy for messages from subdomains of your primary domain,” and relaxed alignment accepts subdomains (pages read October 18 and 27, 2026).

Do I need a paid DMARC monitoring service?

Not to publish the records or to run a few cold email domains at p=none; no receiver requires one.

Microsoft’s DMARC page says the aggregate report “can be vast and difficult to parse” and lists “Use an external service” beside PowerShell or Power BI automation.

Its SPF page calls a DMARC reporting service “very helpful for identifying email sources and SPF failures” in complex organizations. With a handful of domains and one sending tool, you can read the XML by hand.

Sources

1. Set up SPF — Google Workspace Admin Help, last updated October 22, 2026, accessed October 18, 22, 25 and 27, 2026
2. Set up DKIM — Google Workspace Admin Help, last updated October 22, 2026, accessed October 18, 22, 25 and 27, 2026
3. Troubleshoot DKIM issues — Google Workspace Admin Help, last updated October 22, 2026, accessed October 18, 22, 25 and 27, 2026
4. Set up DMARC — Google Workspace Admin Help, last updated October 22, 2026, accessed October 18, 22, 25 and 27, 2026
5. Recommended DMARC rollout — Google Workspace Admin Help, last updated October 22, 2026, accessed October 18, 22, 25 and 27, 2026
6. Email sender guidelines — Gmail Help, accessed October 18 and 27, 2026
7. Email sender guidelines FAQ — Gmail Help, accessed October 18 and 27, 2026
8. Check MX — Google Admin Toolbox, accessed October 1, 22 and 27, 2026
9. Set up SPF to identify valid email sources for your custom cloud domains — Microsoft Learn, last updated July 3, 2026, accessed October 1, 18, 22, 25 and 27, 2026
10. Set up DKIM to sign mail from your cloud domain — Microsoft Learn, last updated July 3, 2026, accessed October 18, 22, 25 and 27, 2026
11. Set up DMARC to validate the From address domain for cloud senders — Microsoft Learn, last updated July 17, 2026, accessed October 18, 22, 25 and 27, 2026
12. Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders — Microsoft Tech Community (Microsoft Defender for Office 365 Blog), April 2, 2025, updated April 30, 2025, accessed October 2, 18 and 27, 2026
13. Sender Best Practices — Yahoo Sender Hub, accessed October 18 and 27, 2026
14. FAQs — Yahoo Sender Hub, accessed October 18 and 27, 2026
15. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — IETF, April 2014, sections 3.2, 4.5 and 4.6.4, accessed October 1, 18 and 27, 2026
16. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF, May 2026 (obsoletes RFC 7489 and RFC 9091), sections 3.2.12, 4.7, 5.1 and 5.3.8, appendix A.6, accessed October 2, 18 and 27, 2026
17. How to Set Up DNS Records (MX, SPF, DKIM, DMARC) and Domain Forwarding — Instantly Help Center, updated October 9, 2026, accessed October 18, 22, 25 and 27, 2026
18. Custom Tracking Domain (CTD) — Instantly Help Center, updated October 9, 2026, accessed October 18 and 27, 2026
19. Set up a custom tracking domain — lemlist Help Center, updated October 2, 2026, accessed October 18 and 27, 2026
20. Find the DNS health section — lemlist Help Center, updated October 2, 2026, accessed October 18 and 27, 2026
21. DKIM, SPF, and DMARC: how email authentication affects your outreach — lemlist Help Center, updated April 1, 2026, accessed October 1, 18 and 27, 2026
22. Instantly Free Trial — Instantly Help Center, updated October 23, 2026, accessed October 18, 25 and 27, 2026
23. lemlist free trial: what’s included and how it works — lemlist Help Center, updated October 2, 2026, accessed October 18, 25 and 27, 2026
24. When Your Email Account Is Ready for Campaigns — Instantly Help Center, updated October 15, 2026, accessed October 25 and 27, 2026
25. How to set up and use lemwarm — lemlist Help Center, updated October 8, 2026, accessed October 25 and 27, 2026