Skip to content
Security Beginner Tutorial

Stop Email Spoofing: Set Up SPF, DKIM, and DMARC for Your Domain

Publish the three DNS records that prove your email is yours and block phishers from spoofing your domain.

Ji-ho Choi
Ji-ho Choi
Security & Cloud Editor · Aug 19, 2026 · 4 min read
Stop Email Spoofing: Set Up SPF, DKIM, and DMARC for Your Domain

What you'll build

You'll publish the three DNS TXT records — SPF, DKIM, and DMARC — that let receiving mail servers prove email from your domain is really yours, then confirm all three show PASS in Gmail. Without them, anyone can put your domain in a phishing email's From: line, and since February 2024 Google and Yahoo reject unauthenticated mail outright.

Prerequisites

  • A domain you control, with access to edit its DNS records (Cloudflare, Route 53, your registrar's panel — anywhere you can add TXT records).
  • A mailbox provider for the domain. This tutorial uses Google Workspace (any plan) with super admin access; other providers work the same way, just with a different SPF include: and DKIM key generator.
  • dig, preinstalled on macOS and most Linux distros. On Windows, substitute nslookup -type=TXT <name>.
  • Verified against Google Workspace admin documentation as of August 2026. The records themselves are provider-neutral standards: SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489).

Throughout, replace example.com with your domain.

1. Publish the SPF record

SPF lists which servers may send mail for your domain. In your DNS panel, add:

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.google.com ~all

~all (softfail) tells receivers to distrust anything not on the list. If other services also send as your domain (e.g. Mailgun, SendGrid), add their include: to this same record — a domain must have exactly one SPF record, and it's limited to 10 DNS lookups total.

2. Generate and publish the DKIM key

DKIM cryptographically signs each outgoing message; the public key lives in DNS. In the Google Admin console:

  1. Go to Menu > Apps > Google Workspace > Gmail > Authenticate email.
  2. Select your domain, click Generate new record, keep the defaults (2048-bit key, selector prefix google), and click Generate.
  3. Copy the record into DNS:
Type:  TXT
Host:  google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkq...   (paste the full value from the console)
  1. Back in the Admin console, click Start authentication. DNS alone isn't enough — Gmail won't sign mail until you flip this switch. The status should change to Authenticating email with DKIM (allow up to 48 hours).

If Gmail on your domain is newer than ~72 hours, the Generate new record button may not appear yet — wait and retry.

3. Publish the DMARC record

DMARC tells receivers what to do when a message fails both SPF and DKIM alignment, and where to send reports. Google recommends waiting 48 hours after steps 1–2 so you don't quarantine your own mail. Then add:

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

p=none is monitor mode: nothing gets blocked yet, but receivers email daily aggregate reports to the rua address so you can find legitimate senders you forgot. Once reports look clean for a few weeks, tighten to p=quarantine, then p=reject — that's the setting that actually stops spoofing.

Verify it works

Check all three records resolved:

dig +short TXT example.com
dig +short TXT google._domainkey.example.com
dig +short TXT _dmarc.example.com

Expected output:

"v=spf1 include:_spf.google.com ~all"
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..." "...IDAQAB"
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The DKIM value printing as two quoted strings is normal — 2048-bit keys exceed the 255-character limit of a single TXT string, and receivers concatenate the parts.

Then send a message from your domain to any Gmail address, open it, and choose ⋮ > Show original. The summary table should read:

SPF:    PASS with IP 209.85.220.41
DKIM:   'PASS' with domain example.com
DMARC:  'PASS'

You can also run your domain through the Google Admin Toolbox Check MX tool (enter google as the DKIM selector) to catch config problems.

Troubleshooting

550-5.7.26 This mail is unauthenticated, which poses a security risk to the sender and Gmail users, and has been blocked. — Gmail's bounce when neither SPF nor DKIM passes. Usually the SPF record hasn't propagated (wait, up to 48 hours) or you sent through a server that isn't in your SPF record.

SPF shows permerror — Almost always two v=spf1 records on the same domain; the first dig above would show two lines. Merge every include: into a single record and delete the duplicate.

DNS host rejects the DKIM value as too long — Some panels cap TXT input at 255 characters. Either split the value into two quoted strings (most panels do this automatically) or regenerate the key as 1024-bit in the Admin console, which Google supports for exactly this case.

DKIM status stuck on "not authenticating" — You published the DNS record but never clicked Start authentication in the Admin console, or clicked it before DNS propagated. Click it again after dig returns the record.

Next steps

Read a few weeks of DMARC aggregate reports (they're XML; free parsers like Postmark's DMARC digests make them readable), add any missing senders to SPF and DKIM, then move p=nonep=quarantinep=reject. After that, look at BIMI to display your logo in inboxes — it requires an enforcing DMARC policy, so this tutorial is the prerequisite. If you send over 5,000 messages/day to Gmail, all three records are mandatory under Google's email sender guidelines, so finish the rollout before your volume grows.

Sources & further reading

  1. Set up SPF — knowledge.workspace.google.com
  2. Set up DKIM — knowledge.workspace.google.com
  3. Set up DMARC — knowledge.workspace.google.com
  4. Email sender guidelines — support.google.com
  5. Check MX - Google Admin Toolbox — toolbox.googleapps.com
Ji-ho Choi
Written by
Ji-ho Choi · Security & Cloud Editor

Ji-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept.

Discussion 0

Join the discussion

Sign in or create an account to comment and vote.

No comments yet

Be the first to weigh in.

Related Reading