SPF, DKIM, and DMARC: Email Security Setup Guide

Overviewsection

SPF, DKIM, and DMARC are three DNS-based email authentication protocols that work together to prevent attackers from sending emails that appear to come from your domain. Without them, anyone can send an email that looks like it came from ceo@yourdomain.com — and most recipients will not be able to tell the difference.

These protocols are:

• SPF (Sender Policy Framework) — specifies which mail servers are allowed to send email for your domain
• DKIM (DomainKeys Identified Mail) — adds a cryptographic signature to outgoing emails proving they have not been tampered with
• DMARC (Domain-based Message Authentication, Reporting & Conformance) — tells receiving servers what to do when SPF or DKIM fails, and sends you reports

Why This Matterssection

• 89% of email-based attacks use spoofed sender addresses
• Google and Yahoo require DMARC for bulk senders (enforced since February 2024)
• Emails without proper authentication are more likely to land in spam folders
• Compliance frameworks (CMMC, NIST, Cyber Essentials) require email authentication

Step 1: Set Up SPFsection

SPF is a DNS TXT record that lists the IP addresses and services authorised to send email for your domain.

For Microsoft 365section

v=spf1 include:spf.protection.outlook.com -all

For Google Workspacesection

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

With additional servicessection

If you also send email through a marketing platform (Mailchimp, HubSpot, etc.), include their SPF record:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

Key rulessection

Verify your SPF recordsection

Resolve-DnsName -Name "yourdomain.com" -Type TXT | Where-Object { $_.Strings -match "v=spf1" }

Step 2: Set Up DKIMsection

DKIM signs outgoing emails with a private key. The receiving server checks the signature against a public key published in your DNS.

For Microsoft 365section

1. Go to Microsoft Defender XDR (security.microsoft.com) > Email & collaboration > Policies & rules > Threat policies > DKIM. Alternatively, you can configure DKIM in the Exchange admin center > Mail flow > DKIM.
2. Select your domain
3. Toggle Sign messages for this domain with DKIM signatures to Enabled
4. Microsoft will provide two CNAME records to add to your DNS:

Host: selector1._domainkey
Points to: selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Host: selector2._domainkey
Points to: selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

5. Add both CNAME records, then click Enable in the portal

For Google Workspacesection

1. Go to Google Admin Console > Apps > Google Workspace > Gmail > Authenticate email
2. Click Generate new record
3. Add the TXT record to your DNS:

Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGS... (your public key)

4. Click Start authentication after the DNS record propagates

Verify DKIMsection

Resolve-DnsName -Name "selector1._domainkey.yourdomain.com" -Type CNAME

Step 3: Set Up DMARCsection

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails.

Start with monitoring (recommended)section

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

This record:

• p=none — do not block anything yet, just monitor
• rua= — send aggregate reports to this address (daily XML summaries)
• ruf= — send forensic reports for individual failures
• fo=1 — send a forensic report if either SPF or DKIM fails

Add as a DNS TXT recordsection

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

Progress to enforcementsection

After 2-4 weeks of monitoring with no unexpected failures:

Quarantine (move suspicious emails to spam):

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

Increase pct gradually from 25 to 50 to 100.

Reject (block spoofed emails entirely):

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

DMARC policy optionssection

Reading DMARC Reportssection

Aggregate reports are XML files sent daily by receiving servers. They show:

• How many emails were sent from your domain
• Which passed/failed SPF and DKIM
• Which IP addresses sent those emails

Raw XML reports are hard to read. Use a free report analyser:

• DMARC Analyzer (dmarcanalyzer.com)
• Postmark DMARC (dmarc.postmarkapp.com)
• EasyDMARC (easydmarc.com)

These tools ingest the reports and show you a dashboard of passing vs. failing sources.

Verification Checklistsection

Run these checks after configuring all three records:

# Check SPF
Resolve-DnsName -Name "yourdomain.com" -Type TXT | Where-Object { $_.Strings -match "v=spf1" }

# Check DKIM (Microsoft 365)
Resolve-DnsName -Name "selector1._domainkey.yourdomain.com" -Type CNAME

# Check DMARC
Resolve-DnsName -Name "_dmarc.yourdomain.com" -Type TXT

All three should return valid records. You can also use online tools like MXToolbox to verify the full chain.

Common Mistakessection

A Note on ARC (Authenticated Received Chain)section

Many email providers now also check for ARC (Authenticated Received Chain) headers. ARC preserves email authentication results across intermediate mail servers that modify messages (such as mailing lists, forwarding services, and security gateways). Without ARC, forwarded emails often fail DKIM and SPF checks even though they are legitimate.

You do not need to configure ARC in DNS. It is handled automatically by mail servers that support it (Microsoft 365 and Google Workspace both support ARC). However, it is worth knowing about because:

• If you use mailing lists or email forwarding, ARC helps receiving servers trust your messages even when SPF/DKIM break due to forwarding
• When investigating DMARC failures, ARC headers in the email source can help you determine whether a failure was caused by legitimate forwarding

Summarysection

The goal is to reach p=reject with both SPF and DKIM passing for all legitimate email. This blocks virtually all email spoofing attacks against your domain.