Google Is Rejecting Your Emails. Here’s How to Set Up SPF, DKIM, and DMARC in One Afternoon

The ticket came in on a Tuesday morning. Subject line: “Emails to Gmail clients bouncing — URGENT.” It was from the head of business development. She’d been trying to reach a client for three days and assumed the client was ignoring her. They weren’t. Every email was being hard-rejected at the Gmail server before it ever reached an inbox.

I pulled the bounce message. “550-5.7.26 This message does not pass authentication checks (SPF and DKIM both missing).” Their domain had been sending completely unauthenticated email since they’d migrated to Microsoft 365 four months earlier. Nobody had set up SPF. DKIM had never been enabled. There was no DMARC record. For four months, every email they sent to a Gmail recipient was a coin flip — and recently Google had stopped flipping.

That afternoon cost the company a real client conversation. It also cost me several hours of remediation work that could have been done in a single afternoon six months earlier. This post is what that afternoon should have looked like.

What These Three Records Actually Do

Before the steps, a plain-English explanation — because I’ve had this conversation with enough non-technical founders and managers to know that understanding the why makes the setup stick.

SPF (Sender Policy Framework) is a DNS record that declares which mail servers are authorised to send email on behalf of your domain. When a receiving server gets an email from yourcompany.com, it checks the SPF record to verify the sending server is on the approved list. If it’s not, the email fails SPF. That’s it — SPF is a list of trusted senders.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The signature is generated using a private key held by your mail provider, and receiving servers verify it against a public key published in your DNS. If the email was tampered with in transit, the signature won’t match. DKIM doesn’t confirm the sender is authorised — it confirms the message arrived intact and unmodified.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that sits on top of both. It tells receiving servers what to do with email that fails SPF or DKIM — nothing, quarantine it, or reject it — and it gives you a reporting address where receiving servers send daily digests about what’s passing and failing. DMARC is also the only record that protects your domain from being spoofed by someone else entirely.

SPF says who can send. DKIM says the message wasn’t touched. DMARC says what to do when either check fails — and sends you the receipts.

You need all three. SPF alone doesn’t stop spoofing. DKIM alone gives receiving servers no enforcement policy. DMARC without SPF and DKIM has nothing to base its decisions on.

Why This Is Urgent Right Now

Google and Yahoo started enforcing authentication requirements for bulk senders in early 2024. Microsoft followed with enforcement from May 2025. As of now, all three major providers will hard-reject — not quietly spam-folder, but bounce with an error — email from domains that fail authentication checks.

The threshold that triggers enforcement is 5,000 emails per day to Gmail or Outlook recipients, but in practice the tightening has pulled smaller senders into the blast radius. I’ve seen rejections at organisations sending a few hundred emails a day. If you’re using a CRM, a marketing tool like Instantly.ai or Smartlead.ai, or any SaaS that sends on behalf of your domain, you almost certainly qualify.

The good news: the setup is a one-time task. Three DNS records. Done correctly, it holds indefinitely and you never have to touch it again unless you change mail providers.

Step 1: SPF

Log into your DNS provider (Cloudflare, GoDaddy, Namecheap, Route 53 — wherever your domain’s DNS lives). Create a new TXT record on the root domain (@ or left blank, depending on the interface).

If you’re on Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

If you’re on Google Workspace:

v=spf1 include:_spf.google.com -all

If you use both plus a transactional email provider like SendGrid:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Two things to get right: First, you can only have one SPF record on a domain. If there’s already one, edit it — don’t add a second. Second, the -all at the end means “hard fail anything not on this list.” Use it. The softer ~all (soft fail) is too permissive in 2026.

Once published, use MXToolbox SPF lookup to verify. It’ll confirm the record is live and parse any errors.

Step 2: DKIM

For Microsoft 365, go to the Microsoft 365 Defender portal → Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → DKIM tab. Select your domain and click “Enable.”

Microsoft will show you two CNAME records to publish in DNS. They look like this:

selector1._domainkey.yourdomain.com pointing to selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

selector2._domainkey.yourdomain.com pointing to a similar target

Publish both CNAMEs in your DNS provider. DNS propagation takes anywhere from a few minutes to a few hours. Once they’re live, go back to the M365 DKIM page and click “Enable” — it’ll verify the records and activate signing.

For Google Workspace, go to Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Select your domain, generate the DKIM key, and publish the TXT record it provides. Then click “Start Authentication.”

Verify DKIM is working by sending yourself a test email from the domain and checking the email headers — look for dkim=pass in the Authentication-Results header. Or use mail-tester.com for a full deliverability score.

Step 3: DMARC

This one is a TXT record on _dmarc.yourdomain.com. Start with monitoring mode:

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

The p=none policy means receiving servers will report failures but won’t do anything with the emails yet. The rua tag is where daily aggregate reports go — set it to a real inbox someone reads. I use a dedicated alias for this so reports don’t drown a primary inbox.

Leave it on p=none for roughly two to three weeks while the reports come in. Review them. You’re looking for legitimate email sources that are failing — marketing tools, helpdesk platforms, anything that sends on behalf of your domain that you haven’t added to SPF yet. Fix those first.

Once you’re confident everything legitimate is passing, tighten the policy in stages:

• p=quarantine — failing emails go to spam instead of being delivered normally
• p=reject — failing emails are hard-rejected at the server level

Most organisations land at p=quarantine within a month and reach p=reject after another few weeks. Don’t rush to reject. The monitoring period exists for a reason — I’ve seen companies skip it and block their own marketing emails on day two.

The Mistakes I See Most Often

A few patterns that come up repeatedly when I’m reviewing a domain’s email setup:

• Multiple SPF records on the same domain. DNS only processes one. If there are two, you effectively have none. Always edit the existing record rather than adding a new TXT.
• Publishing DMARC before DKIM is active. If DMARC is enforcing and DKIM isn’t signing, you’ll fail your own policy on legitimate email.
• Forgetting subdomains. If you send from mail.yourdomain.com or help.yourdomain.com, those subdomains need their own SPF and DKIM records. A DMARC record on the root domain covers subdomain policy only if you add sp=reject to it.
• Using a disposable inbox for DMARC reports. The reports are genuinely useful — they tell you which third-party tools are sending on your behalf and whether they’re passing. Route them somewhere real and check them monthly.
• Assuming migration preserves authentication settings. The company I mentioned at the top had moved to M365 from a legacy mail host. The migration team handled mailboxes and calendar data. Nobody touched DNS. SPF was pointing at the old mail server, DKIM had never been configured on M365, and DMARC didn’t exist. Always treat email auth as a separate checklist item on any mail migration.

How Long This Actually Takes

If you have DNS access and your mail provider is M365 or Google Workspace, the SPF and DMARC records take under thirty minutes. DKIM takes another thirty, mostly waiting for DNS propagation before you can activate it. The monitoring period — reviewing DMARC reports and adjusting SPF to capture any missing senders — is where most of the elapsed time goes, but it’s not active work. You’re waiting for data, not sitting in front of a terminal.

Total active time across the first month: roughly two to three hours. Total risk of not doing it: a client conversation that never happens because your email is sitting in a bounce queue they’ll never check.

I’ve set this up for enough teams now to know that the blocker is almost never complexity. It’s that nobody’s owned it. It doesn’t require a senior engineer — it requires someone with DNS access and thirty uninterrupted minutes. If that’s you, do it this week. If it’s sitting on someone else’s list and it’s been there a while, send them this post.

If you want a second set of eyes on your current email authentication setup or have questions about a specific mail stack, reach out — this is a thirty-minute conversation I’m always happy to have.