Most Workspace inboxes that land in spam are not failing on copy. They are failing on paperwork. Someone created the inboxes, connected them to a sending tool, and started sending, and the authentication records underneath were never finished. SPF is half published, DKIM was never switched on, DMARC does not exist. Receivers see an unauthenticated sender and treat it accordingly. This checklist is the order we finish those records in, on every Workspace sending domain, before a single cold email goes out.
1. SPF: one record, Google included
SPF is a single TXT record at the root of the sending domain that lists who is allowed to send for it. For a Workspace domain the line that matters is include:_spf.google.com. Two rules cause most of the damage. First, there can only ever be one SPF record: if your sending tool or CRM also sends for the domain, their senders go into that same record, never into a second one, because receivers treat two records as a broken setup. Second, the record belongs on the domain that actually sends, which for cold email is the secondary domain, not the company homepage domain. Check yours with the SPF Checker for Google Workspace, which reads the record with the Google include front and center.
2. DKIM: turn it on in Google Admin and publish the key
DKIM signs each message so receivers can verify it was sent by an authorized system and not altered on the way. In Google Workspace this is a two step job. In the Google Admin console, under Apps, Google Workspace, Gmail, Authenticate email, you generate the key for the domain, then publish the value Google gives you as a TXT record at the host name it names, usually google._domainkey. Only after the record is live do you go back and start signing in that same screen.
One choice appears while you generate: key length. Google offers 1024 and 2048 bit keys. Pick 2048 where your DNS host accepts it: it is the stronger key, and the only practical downside is a longer record value to paste carefully. A 1024 bit key that is actually published beats a 2048 bit key that was generated and forgotten.
3. DMARC: start at p=none, then move up
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails. Publish a first record at the _dmarc name with p=none, which enforces nothing and only reports, so you can watch who sends as your domain without risking real mail. Once the reports show your real senders passing, step up to quarantine and finally to reject. The full reasoning, and why jumping straight to reject breaks legitimate mail, is in our guide to DMARC for cold email domains, and the DMARC Generator and Checker builds the exact record value for each stage.
4. Check the sending domain, not the root domain
Every check above belongs to the exact domain in the From address. Cold email almost always sends from secondary domains, and those are separate domains with their own records. A main company domain with perfect authentication does nothing for a secondary sending domain with none, and this mismatch is the most common reason a setup that looks finished still lands in spam. Run the Email Authentication Checker on the sending domain itself and read all three results there before you send anything.
5. Warm the inboxes and keep volume sane
Authentication gets you judged fairly; it does not get you trusted instantly. New Workspace inboxes on a fresh secondary domain have no sending history, so start with warmup and low volume per inbox, reply to real conversations, and raise volume gradually instead of pushing hard from day one. If replies dry up or bounces climb, slow down rather than forcing it: a domain that ramps patiently stays usable, and one that gets flagged early rarely recovers its reputation on the same name.
Check yours in five minutes
You can verify the whole setup faster than it took to read this. Run your sending domain through the SPF Checker for Google Workspace, then the authentication checker linked above, and fix whatever they flag before your next send. If you run an agency, a newsletter or a community and your readers fight the same problem, you can also put this checker on your own site for free from our embed page; we host and maintain it, you just paste one snippet.
FAQ
Do I need all three records, or is SPF enough on its own?
You need all three. SPF says who may send, DKIM proves the message was signed and unaltered, and DMARC is what receivers use to decide what a failure means and whether the sending identity lines up. Passing one and missing the others still reads as unfinished.
How long should a domain stay at p=none?
Long enough to see every real sender show up in the aggregate reports under normal sending, and to fix any that fail alignment. Moving up on a calendar instead of on that evidence is how legitimate mail gets blocked by surprise.
Everything passes and mail still lands in spam. What is left?
Reputation and behavior: warmup history, volume per inbox, list quality, bounce rate, and whether recipients reply or mark spam. Authentication is the entry requirement, not the whole result. Work through those in that order before rewriting the copy.