How to set up SPF, DKIM and DMARC for Google Workspace

If your company uses Google Workspace for email, three DNS records decide whether criminals can send email that looks like it came from you. This guide sets them up in the safe order, then adds the extras that earn an A on our checker.

Before you start

• Admin access to the Google Admin console (admin.google.com).
• Access to your DNS host, wherever your domain's DNS records are managed (Cloudflare, GoDaddy, your registrar or your website host).
• A list of everything that sends email as your domain. Think newsletters, invoicing and accounting, CRM, help desk, website forms, payroll and HR systems, and scanners or copiers. Most problems at go-live come from a sender someone forgot.
• Time: about an hour of hands-on work, spread across 2–4 weeks of watching reports before full enforcement.

In the examples below, replace yourdomain.com with your domain.

Step 1: SPF (who may send as you)

SPF is one TXT record at the root of your domain (host @) that lists the services allowed to send your email. For Google Workspace alone:

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

If other services send as you, add the include: value each one documents, before the ~all. For example: v=spf1 include:_spf.google.com include:other-service.example ~all

• Only one SPF record. Two v=spf1 records make SPF fail everywhere. Merge them.
• Ten lookups maximum. Each include:, a and mx counts, including the ones inside other includes. Remove services you no longer use.
• ~all now, -all later. Start with soft-fail. Switch to -all once DMARC reports show every legitimate sender passing.

Step 2: DKIM (signed email)

DKIM adds a cryptographic signature to every message, so receivers can tell it really came from you and wasn't altered.

1. In the Google Admin console, go to Apps → Google Workspace → Gmail → Authenticate email.
2. Select your domain and click Generate new record. Choose a 2048-bit key and keep the prefix selector google.
3. Add a TXT record at your DNS host with host google._domainkey and the value Google shows. If your DNS host rejects long TXT values, generate a 1024-bit key instead.
4. Wait for DNS to update (up to 48 hours, usually much less), then click Start authentication. The status should change to "Authenticating email".

Every third-party service that sends as you should also sign with DKIM for your domain. Look for "domain authentication" or "custom sending domain" in each service's settings.

Step 3: DMARC in monitoring mode

DMARC tells receivers what to do with mail that fails SPF and DKIM, and sends you reports about who is sending as your domain. Start in monitoring mode. Add a TXT record with host _dmarc:

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

Create that mailbox first (a shared mailbox or group works well). Reports arrive daily as zipped XML files that are hard to read raw, so most teams forward them to a DMARC report service; several have free tiers for small domains.

For 2–4 weeks, look for legitimate services that fail. Fix each one by adding it to SPF or setting up its DKIM. Ignore unknown senders you don't recognize: that's usually spoofing, which is exactly what enforcement will block.

Step 4: Enforce DMARC

When the reports show your real senders passing, tighten the policy in two steps:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Leave quarantine in place for 1–2 weeks. Failing mail goes to spam rather than disappearing, so mistakes are recoverable. Then move to full enforcement:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Now change SPF from ~all to -all. At this point, email forged from your domain is blocked by Gmail, Outlook, Yahoo and most business mail systems. Large mailbox providers already require SPF, DKIM and DMARC from bulk senders, so this also protects your deliverability.

Step 5: Extras for an A

MTA-STS (forces encrypted delivery to you)

Two parts. A TXT record with host _mta-sts:

v=STSv1; id=20261112

And a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: smtp.google.com
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 86400

Newer Google Workspace domains use a single MX record, smtp.google.com; older ones use aspmx.l.google.com and its alternates. Listing all three covers both. After a few weeks of clean TLS reports, change mode to enforce, raise max_age to 604800, and change the id in the TXT record (any new value, such as today's date) so senders fetch the new policy.

TLS reporting

TXT record with host _smtp._tls:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

DNSSEC

Turn on DNSSEC at your DNS host. If your registrar is a different company, copy the DS record it gives you into your registrar's DNSSEC settings. With Cloudflare, it's one click plus that one copy.

CAA

CAA records limit which certificate authorities can issue HTTPS certificates for your domain. Add one CAA record (host @) for each authority you actually use, for example 0 issue "letsencrypt.org". Check which ones your website host uses first.

Domains that never send email

Parked and redirect-only domains get spoofed too. Lock them down with SPF v=spf1 -all, DMARC v=DMARC1; p=reject; and a "null MX" record (MX priority 0, host .).

Common mistakes