New Zapier CRM sync is live — push every reply straight into your pipeline. See what's new

September 7, 2026 · LegalBriefsUSA

SPF, DKIM and DMARC Setup for Cold Email: The Whole Job in 40 Minutes

SPF, DKIM and DMARC setup for cold email takes about 40 minutes of DNS work per sending domain, and then up to 48 hours before the records start authenticating. Google publishes that 48-hour window for both SPF and DKIM. The work itself is three DNS records, and the only part that is easy to get wrong is SPF, because it has a hard limit of 10 DNS lookups and blowing past it silently invalidates the record.

This is the second article in our deliverability series. If you are here because mail stopped landing, read the eleven causes of cold email going to spam first, since authentication is only the top four of them. Everything below comes from the published documentation of Google, Microsoft and the IETF specifications, checked on 7 September 2026, with every source linked at the end. LeadButton builds this setup on every new sending domain we run.

What does each of the three records actually do?

SPF says which servers are allowed to send for your domain. DKIM cryptographically signs the message so the receiver can prove it was not altered and came from a server holding your private key. DMARC tells the receiver what to do when the visible From: domain does not line up with the SPF or DKIM domain, and asks for reports on what is being sent in your name.

The word that matters in that last sentence is alignment. SPF passing on its own is not sufficient. Google requires that the domain in the sender’s From: header align with either the SPF domain or the DKIM domain. Under RFC 7489 both alignment modes default to relaxed, which means the organizational domains have to match rather than the full hostnames. Strict mode requires an exact match of the fully qualified domain.

What records do I publish, and what goes in them?

Three records per sending domain: one SPF TXT record at the root, one DKIM TXT or CNAME record at a selector host, and one DMARC TXT record at _dmarc. The values below are the ones Google and Microsoft publish in their own setup documentation. Replace the domain placeholders and nothing else.

Record Host Value (Google Workspace) Value (Microsoft 365)
SPF @ v=spf1 include:_spf.google.com ~all v=spf1 include:spf.protection.outlook.com -all
DKIM google._domainkey (Google) or selector1._domainkey and selector2._domainkey (Microsoft) TXT key generated in the Admin console, 2048-bit Two CNAMEs pointing at Microsoft’s selector hosts
DMARC _dmarc v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Record values as published by Google and Microsoft, checked 7 September 2026. Microsoft’s DKIM CNAME targets are generated per tenant and differ for domains added after May 2025.

One record of each type per domain. Google is explicit that each domain needs its own SPF record, and RFC 7489 places the DMARC record in a subdomain named _dmarc. If you run twelve sending domains, that is thirty-six records, which is the real reason this work gets skipped rather than any single step being hard.

How do I set up SPF without breaking it?

Publish one TXT record at the root of the domain containing one include: for every service that sends as you, and end it with ~all on Google or -all on Microsoft, which is the terminal mechanism each vendor publishes for a domain it is the only sender for. Google’s own guidance recommends ~all, which tells receivers to mark unlisted senders as spam rather than reject outright. The trap is the lookup budget: RFC 7208 states that implementations MUST limit the total number of DNS-querying terms to 10 during evaluation, and that if the limit is exceeded the implementation MUST return permerror.

A permerror is not a soft failure. It means the record did not evaluate, so SPF neither passed nor failed, and at a receiver enforcing DMARC that leaves DKIM as the only thing standing between you and the junk folder. Each include:, a, mx, ptr, exists and redirect term costs one lookup, and nested includes inside a vendor’s record cost more that you cannot see from your own DNS. RFC 7208 also says void lookups should be limited to two, and that no single mx or ptr evaluation may query more than 10 address records.

Three rules keep you inside the budget. Do not add includes for services that never send from that domain, which for a dedicated cold email domain means the mailbox provider and nothing else. Never put two SPF records on one domain, which produces a permanent error rather than a merge. And keep each character string in the record under 255 octets, the maximum length RFC 7208 names for a single character-string in a TXT record.

How do I set up DKIM, and what key length should I use?

Generate a 2048-bit key. Google recommends 2048 bits where the domain provider supports it and offers 1024 only as a fallback for hosts that do not, and Gmail’s sender guidelines set the floor at 1024 bits or longer for mail to personal Gmail accounts. In Google Workspace the default selector prefix is google, so the record goes at google._domainkey on the sending domain.

Microsoft 365 works differently. Instead of a TXT key you publish two CNAMEs, at selector1._domainkey and selector2._domainkey, pointing at tenant-specific targets Microsoft generates for you. Domains added after May 2025 get targets on dkim.mail.microsoft; older domains point at the tenant’s onmicrosoft.com host. Microsoft’s default key size is 1024 bits, and 2048 is available by specifying the key size when the signing configuration is created.

Two practical notes. A 2048-bit key is long enough that some registrars will not accept it as a single string, which is why Google warns that some domain providers limit TXT record length; splitting the value into quoted strings is the normal fix. And after the key is published, Google says it can take up to 48 hours for DKIM authentication to start working, during which the Admin console may keep telling you to update DNS you have already updated.

What DMARC record should a cold email domain start with?

Start at p=none with a reporting address, and nothing else. Both Google and Microsoft document that sequence, and both bulk sender programs accept p=none as compliant: Gmail’s requirements for senders above 5,000 messages a day state that the DMARC enforcement policy can be set to none. Publishing p=reject on day one, before you have read a single aggregate report, is how legitimate mail from a tool you forgot about gets refused.

Under RFC 7489 the v and p tags are required and must appear in that order. The pct tag defaults to 100 and the reporting interval ri defaults to 86400 seconds, so daily aggregate reports arrive without you asking for them by anything other than rua. Microsoft’s documentation shows the same three-stage progression with pct stepped through 10, 25, 50, 75 and 100 as a way to move slowly.

Stage Record What it does Our operating window
1. Monitor v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com Nothing is blocked; you receive daily aggregate reports 14 days
2. Quarantine v=DMARC1; p=quarantine; pct=100; rua=... Unaligned mail is delivered to spam 14 days
3. Reject v=DMARC1; p=reject; pct=100; rua=... Unaligned mail is refused at the server Ongoing
The three stages and the record syntax come from Google’s and Microsoft’s published guidance. Neither vendor publishes a number of days; the 14-day windows are our operating practice, not a standard.

One more thing worth knowing before you get to stage three: a DMARC record automatically covers subdomains that do not have their own record. That is Microsoft’s stated behaviour, and it is why a p=reject on a parent domain can break mail from a subdomain nobody remembered was sending.

How long does the whole setup actually take?

About 40 minutes of hands-on work per domain, then a wait. Google publishes the same figure for both records that need it: up to 48 hours for SPF authentication to start working, and up to 48 hours for DKIM. Google’s DMARC guidance is to wait 48 hours after SPF and DKIM are in place before turning DMARC on, which makes the honest end-to-end answer three days, not 40 minutes.

Step Hands-on time Then you wait
Publish the SPF TXT record 5 min Up to 48 hours (Google)
Generate the 2048-bit DKIM key and publish it 10 min Up to 48 hours (Google)
Create the rua mailbox or point it at a report processor 5 min None
Publish the DMARC record at p=none 5 min First reports within 24 hours (ri default 86400s)
Send a test message and read the raw headers 15 min None
Total 40 min About 3 days to full DMARC
Wait times are Google’s published figures. Hands-on times are our estimate from doing this on new client domains.

How do I verify it is actually working?

Send one message to a mailbox you control at a different provider and read the raw headers. You are looking for three passes and one alignment: spf=pass, dkim=pass, dmarc=pass, and a DKIM signing domain (d=) that matches the domain in the From: header. A dkim=pass with a d= pointing at your sending tool’s domain rather than yours is the single most common way a setup looks finished and is not.

Then set up Google Postmaster Tools on the sending domain. It is free, and it reports authentication pass rates, domain reputation and your spam rate against the 0.30% ceiling Gmail publishes, with 0.10% as the level Google advises staying under. If mail is being refused outright, the SMTP response tells you which layer failed: Outlook.com returns 550 5.7.515 for authentication failures, and Microsoft has enforced authentication for senders above 5,000 messages a day since 5 May 2025.

What breaks this setup after it is working?

Four things, in order of how often we see them. A new tool gets added to the stack and someone appends another include:, pushing the record past 10 lookups into permerror. A new sending domain is bought and pointed at the site but never gets its own three records. A DKIM key is rotated in the provider console but the DNS side is never updated, so signing fails silently. And a parent domain moves to p=reject while a subdomain is still sending unaligned mail under the inherited policy.

All four are invisible from inside the sending tool, which will happily report a delivered message that a receiver quietly filtered. The check that catches them is the same one that verified the setup in the first place: a monthly test send from each domain, headers read, plus the DMARC aggregate reports you are already receiving at the rua address.

How LeadButton handles this

Every sending domain we run gets all three records before a single prospect is contacted, with 2048-bit DKIM, an SPF record carrying only the mailbox provider’s include, and DMARC published at p=none with reports flowing to an address we monitor. Alignment is verified by header inspection on a live test send, not assumed from a green checkmark in a tool. Domains stay at p=none for two weeks before we tighten, and the records are re-checked monthly for the four failure modes above. Launch is $1,500 a month for email, and Growth is $3,500 a month for email plus LinkedIn. The infrastructure is included in both, not billed as setup. Full pricing is on the LeadButton pricing page.

Sources

Leave a Reply

Back home

Discover more from leadbutton.io

Subscribe now to keep reading and get access to the full archive.

Continue reading