Fixing this for a Google Workspace domain

New to any of these words? Start here

Your domain

The part of your email address after the @, and usually your website address too. For fundraising@example.org the domain is example.org.

DNS

The internet's address book. It answers questions about your domain: which server hosts the website, where email should be delivered, and who is allowed to send email as you. Anyone can look up your DNS, which is why this check needs nothing from you but the domain name.

Nameservers

The machines that hold your domain's address book and answer those questions. Whoever runs them is where you make the changes below. It is often not the company you bought the domain from — the check tells you which one it is.

A DNS record

One entry in that address book: a name, a type, and a value. You add them through a web form at whoever runs your nameservers. Nothing is installed and nothing runs on your computer.

TXT and CNAME records

Two of the types. A TXT record holds a line of text, which is how SPF and DMARC are published. A CNAME points one name at another, which is how Microsoft publishes DKIM.

SPF

Lists the servers allowed to send email using your domain.

DKIM

Adds a signature to your outgoing mail, so a receiving server can tell the message really came from you and has not been altered on the way.

DMARC

Ties the other two to the name your reader actually sees, and tells receiving servers what to do when a message fails: nothing, send it to spam, or refuse it.

Publish SPF and DMARC at your DNS provider, which the check identifies. This may differ from your domain registrar. DKIM also needs enabling with your email provider.

1. Turn on DKIM

In the Google Admin console, go to Apps → Google Workspace → Gmail → Authenticate email. Pick your domain and generate a TXT record. Publish it at your DNS provider using the host Google gives you, usually google._domainkey.

Once it is live, return to Google and click Start authentication to enable signing. Google can take up to 48 hours to recognize the record. Don't generate another key while waiting: it would no longer match the one you published.

2. Check SPF

Use one TXT record at the domain root (host blank or @). If you already have an SPF record, edit that one. A second record breaks SPF, and replacing the first can drop existing senders.

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

Follow each sending service's instructions to keep its SPF entries in the same record. Some services use DKIM and need no SPF change.

~all is a reasonable place to stay. Forwarding changes the sending server, so SPF can fail. The stricter -all can cause refusal during delivery, before DKIM is checked; those refusals need not appear in your DMARC reports. ~all avoids requesting that refusal. Both endings fail SPF for DMARC purposes; an aligned DKIM pass can still pass DMARC.

Consider -all only if every legitimate sender is listed and nobody forwards your mail, such as a domain used only for bulk sending. It takes effect immediately.

3. Add DMARC, then tighten it

If you already have a DMARC record, keep its policy and other settings. Add or repair its reporting address. Only use the monitoring example below when no policy is in force for this name.

If this exact name is already inheriting quarantine or reject, a weaker policy here replaces that protection: you don't want this record. Go by the effective policy in your result; a parent with sp=none is a different case.

For a first policy, add a TXT record at _dmarc:

v=DMARC1; p=none; rua=mailto:REPORTS@EXAMPLE.ORG;

Replace the address with a working mailbox or one from a reporting service. With no DMARC policy in force, p=none changes nothing about delivery. Reports come only from receivers that choose to send them; external addresses need authorization on their domain. If none arrive, check the address and authorization. See making DMARC reports readable.

Once the reports show every legitimate sender passing, move to p=quarantine. Ask who uses the domain first: quarterly or annual senders may be missing from the reports.

Quarantine is far enough for most organizations. It asks receivers to send failing mail to spam; they decide how to handle it. p=reject asks them to refuse it. Mailing lists can fail despite a correct setup: they relay from their own servers while leaving your address in the From line, and footers or subject tags can break DKIM. If your organization uses listservs, stay at quarantine.

If another organization sends email as you

A fiscal sponsor or management company signing with its own domain does not establish DKIM alignment with yours. Ask them to set up signing with your domain, and check their mail during monitoring. Failing mail can go to spam under p=quarantine or be refused under p=reject.

Re-check your domain