Google tightened sender requirements in 2024 with the bulk sender rules, and quietly kept ratcheting through 2025. In 2026 the practical setup for cold email from a Workspace domain has five moving parts, and if any one of them is wrong the mail lands in Promotions on a good day and spam on a bad one. This is the RFC and Postmaster reading, applied.
The five part setup
- 01
Turn on DKIM signing in Workspace admin
Under Apps, Google Workspace, Gmail, Authenticate email. Generate a 2048 bit key, publish the TXT record at google._domainkey.{{yourdomain}}, wait for propagation, and then click Start authentication. Without DKIM, RFC 6376 signature verification fails and every downstream reputation check runs on a weaker signal.
- 02
Publish an SPF record that aligns with google.com
The TXT at the apex should be exactly v=spf1 include:_spf.google.com ~all. RFC 7208 defines alignment via the Return-Path domain, and Gmail evaluates SPF pass on _spf.google.com being in the include chain. Do not add third party ESPs to this record unless they actually send from the domain. Every extra include is a DNS lookup, and SPF caps at ten.
- 03
Verify MX records point at Google
Five MX records at 1, 5, 5, 10, 10, all under aspmx.l.google.com and alt*.aspmx.l.google.com. If a legacy Postini or third party MX is still in the record set, inbound will route incorrectly and DMARC reports will look wrong even when your outbound is fine.
- 04
Enable Postmaster Tools for the domain
Add and verify the domain at postmaster.google.com. It will not show useful data until you cross about 100 messages a day to Gmail addresses, but the account has to exist before the data starts. Watch the domain reputation, IP reputation, spam rate, and authentication panels.
- 05
Cap sending at 200 per day for the first four weeks
Google Workspace has a hard cap around 2,000 per day per account, but the soft cap for a new sender is closer to 200 per day, with reputation scoring pulling that ceiling up or down. Volume above 200 in week one, from a fresh sender, is the fastest way to land in spam for the next three months.
DKIM: what actually has to be right
DKIM is defined in RFC 6376 and it signs a set of headers plus the body with a private key held by the sender. The public key lives at the DNS selector, in your case google._domainkey.{{yourdomain}}. Gmail on the receiving side fetches that key, verifies the signature, and passes the DKIM=pass result into DMARC evaluation.
Common failure: the key is published but Workspace was never toggled to Start authentication. The record exists, the signature is not generated, and every message goes out DKIM=none. Verify by sending yourself a test from the domain and reading the Authentication-Results header in the raw source. It should say dkim=pass header.d={{yourdomain}}.
SPF alignment: the RFC 7208 detail people miss
SPF checks the envelope sender, not the From header. When you send from Workspace, the envelope sender is under google.com, and _spf.google.com covers it. That is why the include is required and why third party senders you are not using should not be in the record.
For DMARC alignment (RFC 7489), the SPF domain in the envelope must align with the domain in the From header. Because Google rewrites the envelope, this works out of the box when you use _spf.google.com and send From your own domain. The place teams break it is by relaying through a third party that does not align, at which point DMARC treats it as SPF=fail even though the raw SPF check passed.
Do not stack includes
Every include: in your SPF adds DNS lookups. SPF caps at 10 lookups. Adding your ESP, your marketing tool, your transactional tool, and your support tool blows past the cap and the whole record fails permerror. Keep the record minimal and rely on DKIM alignment for anything sending from a subdomain.
MX record verification
The five Google MX records are documented in the Workspace setup guide. If you have any others, remove them. Legacy MX entries from a migration are the most common inbound routing problem, and they also confuse DMARC report aggregators, which show up as ghost failures in your reports.
Verify from a shell with dig MX {{yourdomain}}. If you see anything not under aspmx.l.google.com, that is your first fix, not your last.
Postmaster Tools: what to actually watch
Once the domain is verified in Postmaster, four panels matter.
- Domain reputation. Should read High or Medium. Low is a warning. Bad means you are in spam and it will take weeks of low volume high engagement mail to climb out.
- Spam rate. Google publishes a 0.3% threshold in the bulk sender rules. Practical target for cold email is under 0.1%. Above 0.3% at any volume and reputation collapses.
- Authentication results. DKIM, SPF, and DMARC should all trend at or near 100% pass. Anything under 95% is a config bug, not a receiver decision.
- Encryption. TLS should be at 100%. If it is not, you have a mail routing bug somewhere upstream.
Postmaster Tools Reference.
The 200 per day soft cap in practice
Google does not publish the exact reputation scoring formula. What is observable, across a large sample of new senders, is that volumes above 200 per day from a domain with no sender history correlate strongly with Promotions placement in week one and spam placement in week two. Under 200 with strong engagement (opens where you have a legitimate reason to measure them, replies, no complaints) keeps you out of that trap.
The right ramp is 20 per day in week one, 50 in week two, 100 in week three, 200 in week four, and only then climbing toward 500. Skip a step and the domain reputation dips. Once it dips, the recovery is measured in weeks, not days.
Use a subdomain for cold email
Do the cold sending from mail.{{yourdomain}} or reach.{{yourdomain}}, not from the apex. If the sending domain reputation dips, your primary marketing and product domain is not on the same reputation account, and you keep the ability to send transactional mail from the apex without collateral damage.
Common failures and their fixes
- DKIM record published but authentication never enabled in Workspace admin. Fix: click Start authentication.
- Multiple SPF records at the apex. RFC 7208 says only one is allowed. Fix: merge into one v=spf1 record.
- DMARC policy set to p=none forever. Move to p=quarantine once alignment is stable, then to p=reject once report volume is clean.
- Sending From a look alike domain that is not the same as the reply to. Every Gmail heuristic treats this as a phishing signal.
- A single account sending to 800 addresses on day one of a new Workspace. Domain reputation collapses within 72 hours.
What to do when you are already in spam
Stop sending for a week. Fix any authentication or SPF issue you find. Restart at 20 per day, only to addresses that have engaged with the domain before (previous customers, warm inbound, personal contacts) so early engagement is high. Climb the ramp again. Expect four to six weeks to fully recover, longer if the spam rate ever crossed 0.3%.
Does BIMI matter for cold email?
Only after DMARC is at p=reject and reputation is stable. BIMI is a trust badge on the receiving side. It does not repair a broken sender, and setting it up on a broken sender is wasted work.
What about ARC signing?
ARC (RFC 8617) matters when your mail is forwarded through an intermediary that re signs. For a direct Workspace send to Gmail, ARC is not the fix. If your mail is going through a security gateway or a mailing list on the way to Gmail, then yes.
Should I warm up with a third party warmup tool?
Not in 2026. Google publicly deprecated the reputation benefit of automated warmup exchanges, and Gmail can detect the pattern. Warm up with real correspondence: reply to your existing threads, send personal notes to actual humans, and ramp real volume slowly.
Deliverability is a checklist, not a mystery
DKIM on, SPF minimal and aligned, MX clean, Postmaster verified, volume ramp under 200 for the first month. Get those five right and you are in the inbox on merit. Miss any one of them and the rest of your cold email strategy is a rounding error, because the mail never gets read.