Antoine Duno
Founder of ZeriFlow · 10 years fullstack engineering · About the author
Key Takeaways
- Missing email authentication records are one of the most common findings on security audits and the primary reason domains get spoofed for phishing. Setting up SPF, DKIM, and DMARC takes under an hour and dramatically reduces the risk of your domain being used in attacks.
- Includes copy-paste code examples and step-by-step instructions.
- Free automated scan available to verify your implementation.
How to Set Up SPF, DKIM, and DMARC for Your Domain (Step by Step)
SPF, DKIM, and DMARC setup is one of the most-neglected security configurations for SaaS products and developer tools. If your domain is missing these records, anyone can send email that appears to come from you@yourdomain.com — which means your customers can receive convincing phishing emails that look like they came from you.
This is not theoretical. Email spoofing is the delivery mechanism for the majority of business email compromise (BEC) attacks, which cost businesses billions of dollars per year.
The good news: all three records are DNS TXT entries. No server configuration, no code deployment. You can have all three set up in under an hour.
What Each Record Does
SPF (Sender Policy Framework)
SPF is a DNS record that lists which IP addresses and mail servers are authorized to send email for your domain. When a receiving mail server gets an email claiming to be from user@yourdomain.com, it checks your domain''s SPF record. If the sending server is not on the authorized list, the email fails SPF.
What it protects against: Spoofed emails sent from unauthorized servers
What it does not protect against: An attacker who uses an authorized mail server (like a compromised account on your ESP)
DKIM (DomainKeys Identified Mail)
DKIM uses public/private key cryptography to sign outgoing emails. Your email provider signs each outgoing email with a private key. Receiving servers look up the corresponding public key in your DNS and verify the signature. If the email was modified in transit, the signature is invalid.
What it protects against: Email tampering in transit and some spoofing scenarios
What it does not protect against: The "From" display name being spoofed if the actual sending address is on a different domain
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC builds on top of SPF and DKIM. It tells receiving mail servers what to do with messages that fail both SPF and DKIM alignment — nothing (none), send to spam (quarantine), or reject outright (reject). It also provides a reporting mechanism so you get daily digests of all email sent using your domain.
What it protects against: Direct domain spoofing (the "From:" address matching your domain)
What makes it powerful: It closes the gap between having SPF/DKIM records and actually using them for protection.
Step 1: Set Up SPF
Find your authorized sending sources
Before writing your SPF record, list every service that sends email on behalf of your domain: - Your primary email provider (Google Workspace, Microsoft 365) - Your transactional email service (SendGrid, Postmark, Mailgun, Amazon SES) - Your marketing email tool (Mailchimp, HubSpot, Brevo) - Any self-hosted mail server
Build your SPF record
SPF records are TXT records published at your root domain:
Type: TXT
Name: @ (or yourdomain.com)
Value: v=spf1 [mechanisms] [qualifier]Common mechanisms:
| Mechanism | Meaning |
|---|---|
include:_spf.google.com | Authorize all Google Workspace IPs |
include:sendgrid.net | Authorize SendGrid IPs |
include:spf.protection.outlook.com | Authorize Microsoft 365 |
include:amazonses.com | Authorize Amazon SES |
ip4:1.2.3.4 | Authorize a specific IPv4 address |
a | Authorize the domain''s own A record IP |
mx | Authorize the domain''s MX record IPs |
The final qualifier:
- -all — Fail (reject) all senders not on the list (recommended)
- ~all — SoftFail (mark as suspicious) — good starting point
- ?all — Neutral — effectively no policy
Example SPF records
Google Workspace + SendGrid:
v=spf1 include:_spf.google.com include:sendgrid.net -allMicrosoft 365 + Postmark:
v=spf1 include:spf.protection.outlook.com include:spf.mtasv.net -allAmazon SES in us-east-1:
v=spf1 include:amazonses.com -allSPF limitations
- SPF checks the envelope sender (Return-Path), not the visible From address
- Maximum 10 DNS lookups in your SPF chain — if you have many
include:entries, you may hit this limit - SPF breaks for forwarded emails (the forwarding server is not on your authorized list)
Step 2: Set Up DKIM
DKIM setup is done in two parts: your email provider generates a key pair and gives you a public key to publish in DNS. They handle the private key and signing.
Google Workspace
- 1Go to Google Admin → Apps → Google Workspace → Gmail → Authenticate email
- 2Click "Generate new record"
- 3Copy the CNAME or TXT record values
- 4Add them to your DNS as instructed
Google Workspace DKIM records look like:
Type: TXT
Name: google._domainkey.yourdomain.com
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...SendGrid
- 1Go to Settings → Sender Authentication
- 2Click "Authenticate a Domain"
- 3Follow the wizard — SendGrid generates three CNAME records to add
- 4Verify in SendGrid once DNS propagates
Amazon SES
- 1In the SES console, go to Verified Identities
- 2Select your domain
- 3The DKIM section shows three CNAME records to add to your DNS
Postmark
- 1Go to Sender Signatures in your Postmark account
- 2Add your domain
- 3Copy the DKIM TXT record
General DKIM DNS record format
Type: TXT
Name: [selector]._domainkey.yourdomain.com
Value: v=DKIM1; k=rsa; p=[public key]The selector is a label (often google, mail, s1, s2, etc.) that allows a domain to have multiple DKIM keys for different services.
Step 3: Set Up DMARC
DMARC is a TXT record published at _dmarc.yourdomain.com.
Start with p=none (monitoring mode)
Never start with p=reject. If your SPF or DKIM is misconfigured, you will block legitimate email. Start with p=none to collect reports without affecting deliverability:
Type: TXT
Name: _dmarc.yourdomain.com
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; sp=none; adkim=r; aspf=r| Tag | Meaning |
|---|---|
p=none | Policy: take no action on failing emails |
rua=mailto:... | Send aggregate reports to this address (daily summaries) |
ruf=mailto:... | Send forensic reports to this address (per-message details) |
sp=none | Policy for subdomains |
adkim=r | DKIM alignment mode: relaxed |
aspf=r | SPF alignment mode: relaxed |
DMARC alignment modes
- Relaxed (`r`): The organizational domain matches.
mail.yourdomain.compasses alignment foryourdomain.com. - Strict (`s`): The domains must match exactly. Only
yourdomain.compasses foryourdomain.com.
Start with relaxed mode and move to strict only after you have analyzed your report data.
The progression: none → quarantine → reject
| Stage | DMARC policy | When to use |
|---|---|---|
| 1 - Monitoring | p=none | First 2–4 weeks — collect reports, identify all sending sources |
| 2 - Soft enforcement | p=quarantine | After verifying all legitimate senders are authenticated |
| 3 - Full enforcement | p=reject | When confident that all legitimate email passes SPF/DKIM |
# Stage 1 — Monitoring
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100
# Stage 2 — Quarantine (mark as spam)
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100
# Stage 3 — Full rejection
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100How to Verify Your Records Are Working
Check propagation
DNS changes can take up to 48 hours to propagate, though they usually take 5–30 minutes.
# Check SPF
dig TXT yourdomain.com | grep spf
# Check DKIM (replace ''google'' with your selector)
dig TXT google._domainkey.yourdomain.com
# Check DMARC
dig TXT _dmarc.yourdomain.comFree online verification tools
- MXToolbox (mxtoolbox.com/SuperTool) — check SPF, DKIM, DMARC, MX records
- DMARC Analyzer (dmarcanalyzer.com) — test and analyze DMARC records
- Mail-tester (mail-tester.com) — send a real email and get a full authentication report
- ZeriFlow — run a free scan at zeriflow.com/free-scan to check all email authentication records alongside all other security checks in one pass
Send a test email
The most reliable test: send an email from your domain to a Gmail or Outlook account, then check the email headers:
In Gmail: Open the email → More (three dots) → Show original
Look for:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of you@yourdomain.com designates X.X.X.X as permitted sender)
dkim=pass header.i=@yourdomain.com
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.comAll three should show pass.
Common Mistakes
Mistake 1: Multiple SPF records
You can only have one SPF TXT record on your root domain. If your DNS has two v=spf1 records, SPF will fail. Merge them into a single record.
# Wrong — two separate records
v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net -all
# Correct — one combined record
v=spf1 include:_spf.google.com include:sendgrid.net -allMistake 2: Exceeding 10 DNS lookups in SPF
Each include:, a:, mx:, and exists: mechanism counts as one DNS lookup. Exceeding 10 causes SPF to "permerror" — which DMARC treats as a failure. Use ip4: directly for static IPs to reduce lookups.
Mistake 3: Jumping to p=reject without monitoring
Moving to p=reject without analyzing DMARC reports first will block legitimate email if any sending service is not properly configured. Always monitor for at least two weeks first.
Mistake 4: DMARC record on the wrong subdomain
DMARC must be published at _dmarc.yourdomain.com, not at yourdomain.com or dmarc.yourdomain.com. The underscore prefix is required.
Mistake 5: Not covering subdomains
Your DMARC policy covers your root domain. To cover subdomains as well, add the sp= tag:
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.comIf sp= is not set, subdomains inherit the parent policy.
Reading DMARC Reports
DMARC aggregate reports (rua) are XML files sent daily. They can be difficult to read directly. Use a DMARC report analyzer:
- Postmark''s free DMARC analyzer
- DMARC Digests (dmarcdigests.com)
- Valimail Monitor (free tier available)
Look for:
- Any fail results that identify unauthorized senders
- Passes that confirm your legitimate services are authenticated
- Volume from unknown sources that indicates spoofing attempts
Summary
Setting up SPF, DKIM, and DMARC protects your domain from being spoofed in phishing attacks and improves email deliverability. Publish an SPF TXT record that lists all your authorized sending services, add the DKIM public key records provided by each email service, and start DMARC with p=none to collect reports before moving to p=quarantine and p=reject. Use MXToolbox and DMARC report analyzers to validate and monitor your configuration. Run a free scan at zeriflow.com/free-scan to see your email security posture alongside all other security checks in a single report.