Anyone can spoof your Google Workspace email right now. Here is the 30-minute fix.

TL;DR. Google Workspace ships with three email-authentication gaps that let anyone spoof your domain. The defaults are SPF set to ~all (too permissive), DKIM off, and DMARC absent. Closing all three takes about 30 minutes of admin clicks plus a 12-week DMARC rollout. Cross-references to the full Academy guides for SPF, DKIM, and DMARC are linked in each section.

You bought Google Workspace, pointed your domain at it, and started sending email. Done? Almost. The default config protects Google's reputation more than your domain's. Anyone on the internet can still send mail claiming to be from you@yourcompany.com, and most receivers will deliver it. Possibly to spam, possibly straight to the inbox.

This post walks through the three records Google Workspace doesn't fix for you, what each one actually does, and the admin clicks to lock them down. Total time: about 30 minutes. Prerequisite: you're a Google Workspace super admin and you can edit DNS records at your registrar.

What Google Workspace email security misses by default

When you connect a custom domain to Google Workspace, the setup wizard asks you to publish three records: an MX record (for receiving mail), an SPF include (so Google's servers can send as you), and an optional DKIM toggle (off until you flip it). It does not publish DMARC, and the SPF it suggests is intentionally permissive.

Concretely, after a default Workspace setup, your domain looks like this:

None of these are bugs in Google's setup. They're cautious defaults. SPF ~all means "we're not sure we listed every legitimate sender, don't reject yet." DKIM off means "the admin can flip this on once they're ready." DMARC absent means "this is your call, not ours." Reasonable for Google. Wrong for any production domain.

Fix 1: Switch Google Workspace SPF from soft-fail to strict

SPF (Sender Policy Framework) tells receivers which servers can send email as your domain. Google publishes their fragment via include:_spf.google.com; you control the closing rule. ~all says "soft fail" so receivers usually quarantine but may still deliver. -all says "reject anything that didn't match." That's the goal.

Before flipping it, list every other service that sends mail as your domain (Mailchimp, Postmark, SendGrid, Customer.io, your invoicing tool, your support desk). Each one publishes its own SPF fragment. You merge them into a single record:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org -all

Publish this as a single TXT record at the root of your domain, replacing the Google-suggested one. Do not publish two SPF records. Receivers see permerror and treat your domain as unauthenticated. Merge into one.

One subtlety worth knowing before you tighten: when a message fails SPF and has no DKIM signature, DMARC's behaviour differs between -all (hard fail, DMARC acts) and ~all (soft fail, DMARC effectively ignores the result). Microsoft spells this out: "We recommend -all so DMARC can act on messages that fail SPF if the messages also lack DKIM signatures." Another argument for moving off the default.

For the full mechanic (the 10-lookup ceiling, soft-fail versus strict-fail outcomes, how to spot a bloated record), see the SPF guide in the Academy. Google's canonical reference is Set up SPF for Google Workspace.

Fix 2: Enable DKIM in the Google Workspace admin console

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing email. Receivers fetch your public key from DNS, re-hash the message, and verify. Tampering breaks the signature; forgery never produces one in the first place. It's free, it works on every modern receiver, and Google has it ready behind one toggle.

The path:

1. Open the Google Workspace admin console
2. Apps → Google Workspace → Gmail → Authenticate email
3. Pick your domain, click Generate new record, and choose 2048-bit (do not accept 1024)
4. Copy the TXT record value Google shows you
5. Publish it at google._domainkey.yourdomain.com in your DNS
6. Wait for propagation (usually a few minutes), come back to the admin console, click Start authentication

Verify in a test email's headers. You should see DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google; …. If you have other senders (Postmark, SendGrid, Mailchimp), each one needs its own DKIM key published under a different selector. The DKIM guide covers selector hunting and what each signature tag means. Google's canonical walkthrough is Turn on DKIM for your domain.

Fix 3: Publish DMARC and ramp from monitor to reject

SPF says who can send. DKIM proves what was sent. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receivers what to do when either fails. Without DMARC, receivers run those checks and throw the result away. Your strict SPF and signed DKIM accomplish nothing for inbound spoof protection on your domain.

Don't jump to p=reject. Walk it up over a few weeks while you watch reports for legitimate senders you missed:

1. Week 1 to 4: observe. Publish at _dmarc.yourdomain.com:

   v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

   p=none changes nothing about delivery. The rua= address gets daily aggregate reports listing every IP that sent mail claiming to be you. Read them. Find every legitimate sender, make sure each is covered by SPF or DKIM. Point rua= at a dedicated mailbox or distribution list, not a user's personal inbox; report volume on an active domain is easily hundreds per day.
2. Week 5 to 8: soft enforce. Move to p=quarantine; pct=10. 10% of failing mail gets quarantined; the rest is monitored. Low blast radius.
3. Week 9 to 12: ramp. Raise pct through 50, then 100. Reports should be quiet by the end.
4. Week 13 onward: lock. Switch to p=reject; sp=reject. Subdomains inherit. Done.

The DMARC guide has the full rollout chart, the alignment story (strict versus relaxed), and what each tag means. Google publishes a recommended DMARC rollout of its own; the cadence lines up with the four-phase plan above.

The 30-minute Google Workspace email security checklist

If you don't have time for a 12-week DMARC rollout right now and want immediate improvement:

1. Tighten SPF to -all (5 min, assuming you know your senders)
2. Turn on DKIM in admin console (10 min including DNS propagation)
3. Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com (2 min)

That's the immediate stop-the-bleeding move. SPF blocks unauthorised senders, DKIM proves outbound authenticity, and the DMARC reports give you the data to safely tighten to p=reject over the following weeks.

Beyond email: other Google Workspace defaults to harden

Email auth is the loudest gap, but Google Workspace ships with other defaults worth a look:

• 2-Step Verification not enforced. Available, defaults to "user can opt in." Switch to "enforced for all users" in Security → Authentication.
• OAuth third-party app review off. Any user can grant any third-party app access to their mail or drive. Set "Trust internal apps" and require admin approval for external scopes.
• S/MIME off. If your industry requires signed or encrypted mail (legal, finance, healthcare), Workspace Enterprise can do it but it's not on by default.
• Context-Aware Access not configured. Login is allowed from anywhere on any device. Tighten via Admin → Security → Context-Aware Access.

Future posts will dig into each of those. Email auth first because the consequences of doing nothing are most visible: phishers spoofing your domain to your customers, your support desk, your finance team.

Frequently asked questions

Want to know where you currently stand? Scan your domain. Sudory checks SPF, DKIM, DMARC, and 17 other DNS or HTTP controls in one pass. No login, no setup, about 3 seconds.