How to Set Up DMARC, DKIM, and SPF: The Complete Email Authentication Guide
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Without email authentication, any mail server on the internet can send email that claims to be from your domain. This enables phishing attacks that impersonate your company to customers and business email compromise that impersonates your executives to finance staff. Pair DMARC enforcement with a phishing simulation program to test whether your users can recognize the spoofing attempts that do get through.
SPF, DKIM, and DMARC are three DNS records that, together, prevent this. They are free to implement. The only cost is the time to deploy them correctly: and the risk of blocking legitimate mail if the deployment sequence is wrong.
Step 1: SPF: Authorize Your Mail Servers
An SPF record is a DNS TXT record that lists the mail servers authorized to send email for your domain. Receiving mail servers check this record when they receive an email claiming to be from your domain.
Check if an SPF record already exists:
dig TXT yourdomain.com | grep spf
# Or:
nslookup -type=TXT yourdomain.com | grep spf
SPF record for Microsoft 365 only:
v=spf1 include:spf.protection.outlook.com -all
SPF record for Google Workspace only:
v=spf1 include:_spf.google.com -all
SPF record if you use both Microsoft 365 and a third-party email service (e.g., Mailchimp for marketing):
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all
The -all vs ~all vs ?all difference:
-all(hard fail): Mail failing SPF should be rejected. This is the correct setting for a production SPF record.~all(soft fail): Mail failing SPF should be marked but not rejected. Use this only during testing/transition.?all(neutral): No policy: SPF check provides no enforcement. Do not use this in production.
SPF limitations:
- One SPF record per domain only: multiple SPF records cause lookup failures
- Maximum 10 DNS lookups allowed: each
include:counts toward the limit. If you use many email services, you may need to flatten the record using a tool like dmarcian SPF surveyor - SPF does not protect against
From:header spoofing: a message can pass SPF while still showing a spoofed display name. DMARC alignment closes this gap.
Step 2: DKIM: Sign Outbound Messages
DKIM adds a cryptographic signature to outbound messages. The receiving server retrieves your DKIM public key from DNS and verifies the signature: confirming the message was sent by a server with the corresponding private key and has not been tampered with in transit.
Enable DKIM for Microsoft 365:
In the Microsoft 365 Defender portal (security.microsoft.com):
- Email and collaboration > Policies and rules > Threat policies > Email authentication settings
- Select DKIM
- Click your domain > Enable
- Microsoft generates the key pair and prompts you to add two CNAME records to DNS:
selector1._domainkey.yourdomain.com CNAME selector1-yourdomain-com._domainkey.youronmicrosoft.com
selector2._domainkey.yourdomain.com CNAME selector2-yourdomain-com._domainkey.youronmicrosoft.com
Add these records to your DNS provider, wait for propagation, then click Enable in the portal.
Enable DKIM for Google Workspace:
In Google Admin console (admin.google.com):
- Apps > Google Workspace > Gmail > Authenticate email
- Generate new record
- Add the provided TXT record to DNS:
google._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
- After DNS propagation, return to Admin console and click Start Authentication.
Verify DKIM is working:
# Check DKIM DNS record
dig TXT selector1._domainkey.yourdomain.com
# Send a test email and check headers
# In the received email, look for:
# DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector1;
# Authentication-Results: dkim=pass header.d=yourdomain.com
For third-party email services: Any service that sends email on your behalf (Mailchimp, HubSpot, Salesforce, Zendesk) needs its own DKIM configuration. Each service provides specific CNAME or TXT records to add to DNS: follow each vendor's DKIM setup guide. Without DKIM on third-party senders, DMARC alignment will fail for those email streams.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Step 3: DMARC: Define Enforcement Policy and Reporting
DMARC ties SPF and DKIM together and adds reporting. The critical concept is DMARC alignment: a message passes DMARC only if it passes SPF and the SPF-authenticated domain aligns with the From: domain, OR passes DKIM and the DKIM signing domain aligns with the From: domain.
The correct DMARC deployment sequence:
Phase 1: Monitor (p=none): Start here. This generates DMARC reports without affecting delivery.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; fo=1
Add this as a DNS TXT record at _dmarc.yourdomain.com.
What the rua and ruf tags mean:
rua: aggregate report destination: daily XML reports showing every server that sent email claiming to be your domainruf: forensic report destination: per-message reports for messages that fail DMARC (not all mail providers send these)fo=1: generate forensic reports on any authentication failure (not just DMARC failures)
Phase 2: Review reports (2-4 weeks): Use a DMARC report analyzer to read the aggregate reports (the XML format is not human-readable). Free options: dmarcian free tier, MXToolbox DMARC analyzer, or Google's Postmaster Tools. The reports show:
- All servers sending email as your domain
- Which are passing SPF and DKIM
- Which are failing (these need to be fixed before tightening policy)
Common sources of legitimate email failing DMARC: marketing platforms (Mailchimp, HubSpot), CRM systems (Salesforce), transactional email services (SendGrid, Postmark), and third-party helpdesk systems (Zendesk, Intercom). Ensure DKIM and SPF are configured for each.
Phase 3: Quarantine (p=quarantine): After all legitimate email sources pass authentication, move to quarantine. Failing messages go to spam rather than inbox.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1
The pct=25 tag applies the policy to only 25% of failing messages: a rollout approach. Increase to 50, 75, then 100 over several weeks while monitoring reports.
Phase 4: Reject (p=reject): The goal state. Receiving servers should reject messages that fail DMARC.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1
Do not skip the monitor phase. Moving directly to p=reject before identifying all legitimate email sources will cause legitimate mail to be rejected: a potentially serious deliverability problem.
Verifying the Complete Setup
Check all three records via DNS:
# SPF
dig TXT yourdomain.com | grep spf
# DKIM (adjust selector name for your provider)
dig TXT selector1._domainkey.yourdomain.com # Microsoft 365
dig TXT google._domainkey.yourdomain.com # Google Workspace
# DMARC
dig TXT _dmarc.yourdomain.com
Send a test email and verify headers: Send an email from your domain to a Gmail or Google Workspace account. In Gmail, click the three-dot menu > Show original. Look for:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of user@yourdomain.com designates x.x.x.x as permitted sender)
dkim=pass header.i=@yourdomain.com header.s=selector1
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com
All three showing pass confirms the full stack is working.
MXToolbox Email Health check:
https://mxtoolbox.com/emailhealth/yourdomain.com
This free tool runs automated checks on SPF, DKIM, DMARC, MX records, blacklist status, and several other email health indicators: useful for a comprehensive status check.
The bottom line
DMARC, DKIM, and SPF deploy in a specific sequence: SPF first (authorize your mail servers), DKIM second (enable signing in your email platform and add DNS records), then DMARC starting at p=none to monitor for 2-4 weeks before moving to p=quarantine and finally p=reject. Never skip the monitor phase: it reveals legitimate email sources that will be blocked if you move directly to rejection. Use DMARC aggregate reports to identify all services sending email on your behalf and ensure each has DKIM configured. An email security gateway provides an additional inbound filtering layer that catches spoofed messages from domains without DMARC enforcement. Protect email accounts themselves with MFA to prevent account takeover even when spoofing controls are in place.
Frequently asked questions
What is the correct order to set up SPF, DKIM, and DMARC?
Set up SPF first (add a TXT record authorizing your mail servers), then DKIM (enable signing in your email platform and add the CNAME or TXT records it generates), then DMARC starting at p=none to collect reports for 2-4 weeks. Review reports to identify all legitimate email sources, ensure each passes authentication, then progress to p=quarantine and finally p=reject.
What does DMARC p=reject do?
DMARC p=reject instructs receiving mail servers to reject (not deliver, not quarantine) messages that fail DMARC alignment: where the From: domain does not match the domain authenticated by SPF or DKIM. This prevents spoofed emails claiming to be from your domain from reaching recipients' inboxes.
What is DMARC alignment and why does it matter?
DMARC alignment means the domain in the email's From: header must match the domain authenticated by SPF or DKIM. Without alignment, a phisher could send email with From: ceo@yourcompany.com while authenticating via SPF or DKIM using a different domain they control — technically passing SPF/DKIM checks while still spoofing your domain. DMARC alignment closes this gap by requiring the authenticated domain to match the visible From: address. Strict alignment requires an exact match; relaxed alignment allows subdomain matches (default). Most DMARC implementations use relaxed alignment for DKIM and strict alignment for SPF.
What are DMARC aggregate reports and how do I read them?
DMARC aggregate reports (RUA reports) are XML files sent daily by receiving mail servers to the address specified in your DMARC record. They show every IP address that sent email claiming to be from your domain, with pass/fail results for SPF and DKIM. Reading them manually is impractical: use a DMARC report analyzer (Postmark DMARC, Dmarcian, Valimail, or the free MXToolbox DMARC Analyzer) that parses the XML and shows human-readable dashboards. The reports are essential during DMARC rollout: they identify all legitimate mail streams you need to authenticate before switching from p=none to p=quarantine or p=reject.
How long does it take to go from SPF to full DMARC p=reject?
Allow 4-8 weeks minimum. Week 1-2: implement SPF and DKIM for your primary mail stream and publish DMARC at p=none with RUA reporting. Weeks 3-4: analyze DMARC aggregate reports to find all legitimate mail streams sending from your domain (marketing tools, CRMs, help desks, HR systems). Authenticate each stream with DKIM or add their sending IPs to your SPF record. Weeks 5-6: once aggregate reports show 95%+ of legitimate mail passing, move to p=quarantine (failed messages go to spam instead of being rejected). Week 7-8: if quarantine generates no legitimate mail complaints, move to p=reject. Organizations with complex mail environments (many SaaS tools, multiple ESPs) typically need 8-16 weeks.
What breaks when you add a third-party email sender without configuring DKIM for it?
When a third-party sender (Mailchimp, HubSpot, Salesforce, Zendesk) sends email on your behalf without DKIM configured, those messages fail DMARC alignment. Under p=none, this only affects your aggregate report data and shows the sender as failing. Under p=quarantine or p=reject, those messages will be sent to spam or rejected outright at receiving mail servers. This is the most common cause of legitimate mail deliverability problems after organizations tighten DMARC policy: they moved to enforcement before authenticating all senders. Each third-party email service provides its own DKIM setup instructions, typically requiring you to add one or more CNAME or TXT records to your DNS zone. Some services (HubSpot, Salesforce) also support SPF alignment by sending from your domain rather than their own. During your p=none monitoring period, the aggregate reports will identify every third-party sender that is failing authentication so you can configure DKIM for each before moving to enforcement.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.