Fixing this for a Google Workspace domain

Worth knowing before you start: most of this is not done in Google Workspace. Two of the three records live purely in DNS, wherever your nameservers point, which may be a completely different company. Only DKIM starts in the Workspace admin console.

Where each change is made

• SPF — a TXT record at your DNS provider. Nothing to do in Workspace.
• DMARC — a TXT record at your DNS provider. Nothing to do in Workspace.
• DKIM — generated in the Google Admin console, then the record it gives you is published at your DNS provider, and finally you go back to Workspace to switch signing on.

The check tells you who hosts your DNS. It's often not the company you bought the domain from.

1. Turn on DKIM

In the Google Admin console, go to Apps → Google Workspace → Gmail → Authenticate email. Pick your domain and choose to generate a new record. Google gives you a TXT record to publish with the host google._domainkey.

Add that record at your DNS provider, wait for it to go live, then come back and click Start authentication. This step is what makes your mail signed as your own domain, which is what DMARC needs.

It's first for a reason. When a message is forwarded on — by a role address like finance@ that points at whoever currently holds the job, or an old alumni address that redirects — SPF generally breaks, because the message now reaches the recipient from the forwarder's server rather than from Google's, while a DKIM signature survives that trip intact. So DKIM is what keeps that mail passing once you tighten the policy, and a domain relying on SPF alone has nothing protecting it.

Mailing lists are the harder case, and DKIM does not rescue them: most lists add a footer or tag the subject, which invalidates the signature as well. That is why list software rewrites the From: header, and why the advice further down is to stop at quarantine.

2. Check SPF

You want a single TXT record at your domain root. If you already have one, edit it rather than adding a second — and don't paste over it wholesale, or you'll drop whatever senders were already listed in it.

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

If you send email through anything else as well, such as a newsletter tool, a CRM or a donation platform, each one needs adding to this same record. Most give you an include: to paste, though some give an ip4: range instead, and some need no SPF change at all because they sign with DKIM. Follow what the provider tells you. Two separate SPF records break SPF completely.

The record above ends ~all, which tells receivers that mail from anywhere unlisted is suspect without asking them to refuse it. There is a stricter ending, -all, which does ask them to refuse it.

~all is a perfectly reasonable place to stay. The reason is forwarding again: when a message is forwarded on, SPF fails because it now arrives from the forwarder's server, and a receiver can act on an SPF hard fail during delivery — before it ever looks at the DKIM signature that survived the trip. Those refusals don't appear in your DMARC reports either, so you wouldn't find out. With ~all that mail still gets through on DKIM, which is what you set up in step 1. Your protection against forgery comes from the DMARC policy below, and DMARC treats a soft fail and a hard fail identically.

-all is worth it if you are confident every legitimate sender is listed and nobody forwards your mail — a domain used only for bulk sending, say. It also takes effect the moment you publish it, with no monitoring stage of the kind DMARC gives you.

3. Add DMARC, then tighten it

Start here, as a TXT record with the host _dmarc:

v=DMARC1; p=none; rua=mailto:[email protected];

Replace that address with a mailbox that exists, or with an address given to you by a reporting service. On a domain with no DMARC policy in force, p=none changes nothing about how your mail is delivered.

One thing to check before publishing it. If the check says this exact name is already inheriting quarantine or reject from a parent domain, then publishing a weaker policy here replaces that inherited protection — and you don't want this record. p=none turns it off entirely; p=quarantine weakens inherited reject. Inheriting a parent's p=none, or a parent whose sp= already sets none for its subdomains, is a different case — there is nothing to lose and the record is fine to add. Go by the effective policy the check reports for this name, not by what the parent's record says on its own.

A warning about what comes next. Reports arrive only from receivers that choose to send them, and if the address is on someone else's domain that domain has to authorise it first — so a quiet period means "check the address" rather than "nobody is forging you". The ones that do arrive are zipped XML files meant for software, which you won't make sense of in a normal inbox. See making DMARC reports readable for free and nonprofit-priced ways to turn them into a summary.

Then, once the reports show every legitimate sender passing, move to quarantine:

v=DMARC1; p=quarantine; rua=mailto:[email protected];

A short clean window can still miss senders that only go out quarterly or once a year — ask who uses the domain before you tighten.

Quarantine is the right place to stop for most organisations. Forged mail goes to the spam folder, which is what stops someone impersonating you.

There is a stricter setting, p=reject, which refuses forged mail outright. The current DMARC standard advises against it for ordinary organisations, because a mailing list relays your message from its own servers while leaving your address in the From line, so genuine mail sent that way is refused alongside the forgeries. People can then be dropped from the list without noticing. If anyone at your organisation emails listservs, stay at quarantine.

The mistake to avoid

Do not jump straight to p=reject. If any legitimate service sends email as your domain without being set up properly, that mail will start bouncing. The staged approach exists so you find those senders before they break — and quarantine without report coverage has the same risk for anything the window never saw.

Mailing lists are the usual culprit. They relay your message from their own servers while leaving your address in the From line, and many add a subject tag or a footer, which breaks your DKIM signature. So list mail can fail DMARC even when your own setup is correct. The monitoring period is there to catch cases like that.

If another organisation sends email as you

This is common where a management company or fiscal sponsor handles some of your mail. Their DKIM signs as their domain, which fails DMARC alignment even though their own setup is fine.

The fix is on their side: they add your domain and publish DKIM for it, so the signature carries your domain rather than theirs. Find those senders during the monitoring period — under p=quarantine their mail goes to spam, and under p=reject it is refused, until their DKIM is aligned to your domain.

Re-check your domain