SPF, DKIM, DMARC explained
SPF, DKIM, and DMARC are the three pillars of email authentication. Together, they prove to receiving mail servers that your emails are legitimate and have not been tampered with. Without them, your cold emails are far more likely to be flagged as spam or rejected outright.
This chapter explains what each protocol does in plain language, walks you through setting them up step by step for Google Workspace and Microsoft 365, and covers the verification tools you should use to confirm everything is working.
SPF: Sender Policy Framework
What it does
SPF tells receiving mail servers which servers are authorized to send email on behalf of your domain. It is a DNS record that lists the IP addresses and services allowed to send as [email protected].
When a receiving server gets an email claiming to be from your domain, it checks the SPF record. If the sending server is on the list, it passes. If not, it fails — and the email is more likely to be marked as spam or rejected.
How to set it up
SPF is a TXT record in your domain's DNS settings. The format looks like this:
v=spf1 include:_spf.google.com ~all Let's break that down:
- v=spf1 — Declares this is an SPF record (version 1)
- include:_spf.google.com — Authorizes Google's mail servers to send on your behalf. For Microsoft 365, use
include:spf.protection.outlook.com - ~all — Soft fail for any server not listed. This means unlisted servers will be treated with suspicion but not outright rejected. You can use
-all(hard fail) for stricter enforcement once you are confident your setup is correct.
For Google Workspace:
- Go to your domain registrar's DNS management panel
- Add a new TXT record with host
@ - Set the value to
v=spf1 include:_spf.google.com ~all - Save and wait for DNS propagation (up to 48 hours, usually much faster)
For Microsoft 365:
- Go to your domain registrar's DNS management panel
- Add a new TXT record with host
@ - Set the value to
v=spf1 include:spf.protection.outlook.com ~all - Save and wait for DNS propagation
Watch out
You can only have one SPF record per domain. If you use multiple email services (e.g., Google Workspace and a cold email tool), combine them into a single record: v=spf1 include:_spf.google.com include:other-service.com ~all. Multiple SPF records will cause both to fail.
DKIM: DomainKeys Identified Mail
What it does
DKIM adds a digital signature to every email you send. The signature is created using a private key stored on your email server and verified using a public key published in your DNS. This proves two things: the email actually came from your domain, and it was not altered in transit.
Think of it as a wax seal on a letter. The recipient can verify the seal is authentic (using the public key) and that the letter has not been opened and resealed (the content has not been modified).
How to set it up
For Google Workspace:
- Go to Google Admin Console > Apps > Google Workspace > Gmail > Authenticate email
- Click "Generate new record." Select your domain and key length (2048-bit recommended)
- Google will give you a TXT record hostname (e.g.,
google._domainkey) and a value (a long string of characters) - Add this as a TXT record in your DNS settings
- Wait for propagation, then click "Start authentication" in Google Admin
For Microsoft 365:
- Go to Microsoft 365 Defender > Policies & rules > Threat policies > Email authentication settings > DKIM
- Select your domain
- Microsoft will provide two CNAME records to add to your DNS
- Add both CNAME records in your domain's DNS
- After propagation, enable DKIM signing in the Microsoft 365 portal
Key insight
Always use 2048-bit DKIM keys when given the option. Some registrars with limited TXT record length may require 1024-bit keys, but 2048-bit is the current best practice for security and is increasingly expected by major email providers.
DMARC: Domain-based Message Authentication, Reporting, and Conformance
What it does
DMARC sits on top of SPF and DKIM. It tells receiving servers what to do when an email fails SPF or DKIM checks, and it provides reporting so you can monitor authentication results across all emails sent from your domain.
DMARC has three policy levels:
- p=none — Monitor only. Failed emails are still delivered, but you receive reports. Start here.
- p=quarantine — Failed emails go to spam. Use this after confirming your SPF and DKIM are working correctly.
- p=reject — Failed emails are rejected entirely. The strictest setting, reserved for when you are fully confident in your setup.
How to set it up
DMARC is a TXT record added to your DNS. Here is the recommended starting configuration:
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100 Breaking it down:
- v=DMARC1 — Declares this is a DMARC record
- p=none — Start with monitoring only. No emails will be blocked based on DMARC.
- rua=mailto:[email protected] — Where to send aggregate reports. You will receive reports showing authentication results.
- pct=100 — Apply the policy to 100% of emails
Steps for both Google Workspace and Microsoft 365:
- Go to your domain registrar's DNS management
- Add a TXT record with host
_dmarc - Set the value to the DMARC record above (replace the email with your actual monitoring address)
- Save and wait for propagation
- After 2–4 weeks of monitoring reports, upgrade to
p=quarantine - After another 2–4 weeks with no issues, consider upgrading to
p=reject
Verification: confirming your setup works
After setting up all three records, you need to verify they are working. Here are the tools to use:
- MXToolbox (mxtoolbox.com): Enter your domain and check SPF, DKIM, and DMARC records. It will flag any errors or misconfigurations.
- mail-tester.com: Send a test email to the address provided, and it gives you a deliverability score out of 10. Aim for 9+ before launching any campaign.
- Google Admin Toolbox: Use the "Check MX" tool to verify your DNS records for Google Workspace domains.
- Email headers: Send yourself an email and inspect the headers. Look for "spf=pass," "dkim=pass," and "dmarc=pass" in the authentication results.
Common mistakes with authentication
- Multiple SPF records. Only one SPF record per domain. Combine all includes into one record.
- Forgetting to add your outreach tool. If you use a cold email platform that sends through its own servers, you need to include their SPF and configure their DKIM. Check the platform's documentation.
- Jumping straight to DMARC reject. Start with
p=noneto monitor before enforcing. Going straight to reject can block legitimate emails if your configuration has any issues. - SPF record too long. SPF has a 10 DNS lookup limit. Too many includes will cause SPF to fail. Use SPF flattening tools if you hit this limit.
- Not checking after setup. DNS propagation takes time, and typos happen. Always verify with the tools listed above before sending any emails.
The authentication checklist
Before moving to the next chapter, confirm each of these:
- SPF record is published with the correct includes for your email provider
- DKIM is generated and enabled for your domain
- DMARC is set to p=none with a reporting email address
- MXToolbox shows green for all three records
- A test email to mail-tester.com scores 9/10 or higher
- Email headers show spf=pass, dkim=pass, dmarc=pass
With authentication in place, your emails have a verified identity. The next chapter covers domain setup — choosing, registering, and configuring the domains you will use for cold outreach.