DNSVerdictAll toolsGuidesHow it works

Set up SPF, DKIM and DMARC for Google Workspace

Published · Updated

Publish four records for a domain on Google Workspace: one MX record (1 smtp.google.com), one SPF TXT record at the root (v=spf1 include:_spf.google.com ~all), one DKIM TXT record at google._domainkey whose value Google generates for you, and one DMARC TXT record at _dmarc that starts with p=none. Only the DKIM value cannot be written from memory: you copy it from the Admin console, then return there and click Start authentication. Allow up to 48 hours for DNS changes to take effect, and do not move DMARC beyond p=none until reports show that all your legitimate mail passes.

Before you start

You need super administrator access to the Google Admin console and access to the DNS zone that actually answers for your domain (the registrar’s DNS, Cloudflare, or another host). Records added at a registrar that does not host your name servers are ignored. Query the NS record type in the DNS lookup if you are unsure which servers answer.

If Gmail was only just turned on for the domain, Google’s DKIM page says to wait 24 to 72 hours before generating a key, or you may get a “DKIM record was not created” error.

Step 1: MX record

Google’s MX page lists a single record. Remove every other MX record on the domain: Google warns that old or incorrect MX records can stop mail working correctly.

FieldValue
TypeMX
Host@ (or blank)
Valuesmtp.google.com
Priority1
TTLregistrar default, or 1

Some registrars need a trailing period (smtp.google.com.). If you started using Google Workspace before 2023, your domain may use older aspmx-style hosts; Google states that if mail works you do not need to change them and that those values remain supported. Google quotes up to 72 hours for MX changes. Confirm what the world sees with the MX lookup.

Step 2: SPF record

Add one TXT record at the root of the domain:

@   TXT   "v=spf1 include:_spf.google.com ~all"

Google’s documentation recommends ending with ~all and states that each domain, and each subdomain that sends mail, needs its own SPF record. Some DNS hosts require the quotation marks; others add them for you.

Combine senders into one record. A domain may publish only one SPF record; two v=spf1 records produce a permanent error (permerror) and SPF fails for every message. If you also send through another service, add its include to the existing record, using the value from that service’s documentation. Google’s own example for Workspace plus Microsoft 365 is:

@   TXT   "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Mind the 10-lookup limit. RFC 7208 section 4.6.4 limits evaluation to 10 DNS-querying terms (include, a, mx, ptr, exists, redirect), counting nested ones. Each extra sender spends part of that budget, and the include for Google already uses several. If you add many senders, read SPF has too many DNS lookups and verify the total with the SPF checker.

Step 3: DKIM

DKIM for your own domain is a separate step in the Admin console: you generate the key, publish it, and then switch signing on.

  1. In the Admin console, go to Menu > Apps > Google Workspace > Gmail, then Authenticate email.
  2. Select your domain and click Generate New Record.
  3. Choose a key length. Google’s page says to use 2048 if your domain provider supports it, and 1024 if it does not.
  4. Keep the default selector prefix google. Enter a different prefix only if your domain already uses google.
  5. Click Generate and copy the TXT record name and value.
  6. At your DNS host, create a TXT record. The host is the selector plus ._domainkey, and the value begins v=DKIM1; k=rsa; p= followed by the key:
google._domainkey   TXT   "v=DKIM1; k=rsa; p=<key from the Admin console>"

Some DNS hosts limit the length of a TXT string. A 2048-bit key exceeds 255 characters, so the record must be split into several quoted strings; if your host rejects the record, check its documentation or fall back to 1024 bits as Google suggests.

Wait, then turn signing on. Google says DKIM can take up to 48 hours to start working and that the console may show “You must update the DNS records” in the meantime. Only after the record is visible in DNS, return to Authenticate email, select the domain and click Start authentication. The status should change to “Authenticating email with DKIM”.

To test, send a message to a Gmail or Workspace address that is not yourself (Google notes you cannot verify by mailing yourself), open More > Show original, and look for dkim=pass in Authentication-Results.

Step 4: DMARC

Google’s prerequisites: SPF and/or DKIM must already be on, and you should wait at least 48 hours after setting them up before publishing DMARC. Create a group or dedicated mailbox for reports, because aggregate reports arrive in volume. Nothing changes in the Admin console.

Start in monitoring mode:

_dmarc   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Replace example.com with your domain. Some DNS hosts append the domain automatically, so enter _dmarc only and check the result afterwards. If the report address is on a different domain, that domain needs its own authorization record (see Google’s DMARC reports page).

Then move in stages, as Google recommends: p=none, then p=quarantine, then p=reject, once the reports show that your legitimate mail passes. You can raise enforcement gradually with pct, for example p=quarantine; pct=25, then 50, then 100.

The trade-off is real. At p=reject, any legitimate message that fails both aligned SPF and aligned DKIM is refused by receivers: a newsletter tool, a CRM or a billing system you forgot. Check every sender in the reports first. If a third-party service passes SPF and DKIM but still shows dmarc=fail, the cause is alignment, covered in DMARC fails even though SPF and DKIM pass. Leave adkim and aspf at their relaxed defaults unless you have a specific reason; Google says relaxed usually gives sufficient protection.

Step 5: Verify with our tools

  1. MX lookup: shows only 1 smtp.google.com (or your legacy hosts), with no leftover provider.
  2. SPF checker: one record, ends in ~all, lookup count at or under 10.
  3. DMARC checker: one record at _dmarc, policy and rua parsed.
  4. Send a real message to an external mailbox, copy its full headers into the email header analyzer, and confirm SPF, DKIM and DMARC all pass with your domain in header.d and header.from.

All records at a glance

HostTypeValue
@MX1 smtp.google.com
@TXTv=spf1 include:_spf.google.com ~all
google._domainkeyTXTv=DKIM1; k=rsa; p=<generated in Admin console>
_dmarcTXTv=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Common mistakes

FAQ

Do I need all three records? SPF and DKIM authenticate the message; DMARC tells receivers what to do when both fail to align with your From domain and sends you reports. Google’s DMARC page says that without SPF or DKIM, messages from your domain will likely have delivery problems.

Should SPF end in ~all or -all? Google’s documentation recommends ~all. With DKIM aligned and DMARC published, the DMARC policy, not the SPF qualifier, decides what happens to failures.

How long until it all works? Plan for up to 48 hours for SPF and DKIM, up to 72 hours for MX, then wait another 48 hours before DMARC, per Google’s pages.

Sources

Tools used

SPF Record CheckerDMARC Record CheckerMX LookupEmail Header AnalyzerEmail Provider Setup Check