SPF, DKIM, and DMARC are the three DNS-based email authentication protocols that inbox providers use to verify that an email was legitimately sent from the domain it claims to be from. As of February 2024, Google requires all bulk senders (5,000+ emails/day) to have all three correctly configured — and email providers broadly treat missing authentication as a spam signal regardless of volume. Setting up all three takes 30–60 minutes and is the single most important technical step before any cold outreach campaign.
Why You Need a Dedicated Sending Domain First
Before setting up authentication, consider your domain strategy. Running cold email from your primary business domain (company.com) puts all your email infrastructure at risk — if cold campaigns damage your sender reputation, it affects transactional and relationship emails too.
Best practice: Set up a dedicated sending domain before configuring authentication.
Related guide: cold email tool with high deliverability US
Dedicated domain examples:
outreach.company.com(subdomain)getcompany.com(separate domain variant)hellocompany.io(separate domain with different TLD)
Create the new domain, configure all three protocols on it, warm it up for 4–6 weeks, then run cold campaigns from the dedicated domain only. Your primary domain is protected.
What Each Protocol Does
SPF — Sender Policy Framework
SPF is a DNS TXT record that tells receiving mail servers which IP addresses and mail services are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from yourdomain.com, it checks the SPF record to see if the sending IP is on the approved list.
Related guide: email outreach personalization tool
DKIM — DomainKeys Identified Mail
DKIM adds a cryptographic digital signature to every outgoing email. Your sending platform generates a public/private key pair. The private key signs each outgoing email; the public key is published in DNS. When a receiving server gets your email, it retrieves your public key and uses it to verify the signature — confirming the email came from you and hasn't been modified in transit.
DMARC — Domain-based Message Authentication, Reporting & Conformance
DMARC ties SPF and DKIM together. It tells receiving servers what to do with emails that fail SPF or DKIM checks (monitor, quarantine, or reject), and provides a reporting mechanism so you can see what's failing and where. It also enforces alignment — the "From" domain must match the domain authenticated by SPF or DKIM.
Why All Three Matter
SPF alone is insufficient because it checks the sending IP but not whether the message was modified in transit. DKIM alone is insufficient because it doesn't tell receiving servers what to do with failures. DMARC alone without SPF and DKIM has nothing to enforce.
Related guide: how to improve cold outreach tool
Together, they form a complete authentication chain:
- SPF: "This IP is authorized to send for this domain"
- DKIM: "This message was signed by this domain and hasn't been altered"
- DMARC: "If either of the above fails, here's what to do with the message"
Without all three, phishing attacks using your domain are possible (your domain can be spoofed), deliverability is impaired, and compliance with Google's 2024 bulk sender requirements is incomplete.
How to Set Up SPF
Step 1: Identify all services that send email from your domain
Common senders: Google Workspace (or Microsoft 365), your cold email platform (SalesOutreach, Instantly, etc.), your CRM (HubSpot, Salesforce), transactional email (SendGrid, Mailchimp, Postmark).
Related guide: best cold email service guide by SalesOutreach
Step 2: Build your SPF record
Add a TXT record to your DNS with the following structure:
v=spf1 include:[service1] include:[service2] ~all
Real examples:
- Google Workspace:
include:_spf.google.com - Microsoft 365:
include:spf.protection.outlook.com - SendGrid:
include:sendgrid.net
Full example record:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
The ~all vs -all decision:
~all(soft fail): Unauthorized IPs are allowed but flagged. Safer to start with.-all(hard fail): Unauthorized IPs are rejected. Stricter — move here after confirming all legitimate senders are included.?all(neutral): No assertion. Avoid this — it provides no protection.
Step 3: Add the TXT record to DNS
Log in to your domain registrar (GoDaddy, Namecheap, Cloudflare, etc.). Navigate to DNS settings. Add a TXT record for @ (or the subdomain you're using) with the SPF string as the value. TTL of 3600 (1 hour) is standard.
Important: You can only have one SPF record per domain. If you have multiple sending services, combine them into a single record — do not create multiple SPF TXT records.
How to Set Up DKIM
Step 1: Generate your DKIM key pair through your email platform
Every email sending platform has a DKIM setup wizard. In Google Workspace: Admin Console → Apps → Gmail → Authenticate Email → Generate New Record. In SalesOutreach: follow the deliverability setup flow. The platform generates a TXT record value for you — a long alphanumeric string.
Step 2: Add the DKIM TXT record to DNS
Add a TXT record with the selector hostname the platform specifies (typically something like google._domainkey for Google Workspace or a custom selector for your ESP) and the public key string as the value.
Example DKIM record:
Host: google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B....[long key string]
Step 3: Enable DKIM signing in your email platform
After adding the DNS record, return to your email platform and enable DKIM signing. The platform will verify that the DNS record is live before activating.
DNS propagation note: DNS changes can take up to 48 hours to propagate globally, though most propagate within 1–4 hours. Verify after 1 hour; if the record isn't showing, check for typos in the DNS entry.
How to Set Up DMARC
Step 1: Start in monitor mode
Add a DMARC TXT record to DNS at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1
p=none— Monitor mode; reports failures but doesn't block any mailrua=— Aggregate report destination (daily XML reports of authentication results)ruf=— Forensic report destination (individual failure reports, if supported by providers)fo=1— Generate forensic reports for any authentication failure
Step 2: Review DMARC reports for 2–4 weeks
Aggregate reports arrive daily as XML files. Use a free DMARC reporting tool (Postmark's DMARC Digests, MXToolbox, Dmarcian) to parse them into readable format. Look for:
- Which IPs are sending email claiming to be from your domain
- Which emails are failing SPF or DKIM alignment
- Any third-party services sending on your behalf that aren't yet authenticated
Step 3: Fix authentication gaps
If DMARC reports show emails from legitimate services failing SPF or DKIM, add those services to your SPF record and/or configure DKIM for them before moving to enforcement.
Step 4: Move to quarantine, then reject
After 2–4 weeks of clean reports with no unexpected failures:
Move to quarantine:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com
pct=25 applies the policy to 25% of failing emails initially. Increase to 100 over 1–2 weeks.
Move to reject (strongest protection):
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
Never jump directly from p=none to p=reject without the intermediate quarantine step — you risk blocking legitimate email if any sending source is misconfigured.
Verifying Your Setup
Run all three verification tools after implementing each protocol:
MXToolbox (mxtoolbox.com/SuperTool)
- SPF Lookup:
mxtoolbox.com/spf.aspx - DKIM Lookup:
mxtoolbox.com/dkim.aspx - DMARC Lookup:
mxtoolbox.com/dmarc.aspx
Google Admin Toolbox (toolbox.googleapps.com)
"Check MX" tool checks DNS records and highlights errors.
Mail-Tester (mail-tester.com)
Send a test email to the provided address; returns a 1–10 score with itemized authentication results. This is the most comprehensive quick-check — it simulates exactly what a receiving server sees.
Common Setup Mistakes
Mistake 1: Multiple SPF records
You can only have one SPF TXT record per domain. Creating two breaks SPF validation. Combine all include: directives into one record.
Mistake 2: Exceeding the SPF 10 DNS lookup limit
SPF allows a maximum of 10 DNS lookups in a single record. Too many include: directives can exceed this. Use tools like MXToolbox's SPF analyzer to check your lookup count; use SPF flattening services if you're close to the limit.
Mistake 3: DKIM key length below 1024 bits
Use 2048-bit DKIM keys for all new setups. 1024-bit keys are considered insufficient by current security standards and may not be accepted by some receiving servers.
Mistake 4: Moving to DMARC p=reject too quickly
Skipping the p=none monitoring period often results in blocking legitimate email from services you forgot to authenticate. Always spend 2–4 weeks in monitor mode first.
Mistake 5: Not checking DNS propagation after changes
DNS changes can take up to 48 hours to propagate. Using your verification tools immediately after making a change may show the old record. Wait 1–2 hours before verifying.
Mistake 6: Setting DMARC on the wrong subdomain
The DMARC record must be at _dmarc.yourdomain.com (or _dmarc.subdomain.yourdomain.com for subdomain policies). Adding it at the wrong level means it won't be found by receiving servers.
Frequently Asked Questions
Q: Do I need SPF, DKIM, and DMARC for cold email?
Yes. All three are required for high-volume cold email senders per Google's 2024 bulk sender requirements, and inbox providers treat missing authentication as a spam signal even for low-volume senders. SPF tells receiving servers which IPs are authorized to send for your domain. DKIM adds a cryptographic signature to verify email integrity. DMARC tells receiving servers what to do with emails that fail SPF or DKIM checks.
Q: What is the difference between SPF and DKIM?
SPF (Sender Policy Framework) is a DNS record that specifies which mail servers are authorized to send email on behalf of your domain — it verifies the sending source. DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing email that the receiving server uses to verify the message hasn't been tampered with in transit. Both verify different aspects of email legitimacy; both are required for strong deliverability.
Q: What DMARC policy should I start with?
Start with p=none (monitor mode), which reports on authentication failures without blocking any mail. After reviewing DMARC reports for 2–4 weeks to confirm legitimate sending sources are all authenticated, move to p=quarantine (sends failing emails to spam), and eventually to p=reject (blocks failing emails entirely). Moving too fast to p=reject before authentication is fully configured can block your own legitimate emails.
Q: How do I verify that SPF, DKIM, and DMARC are set up correctly?
Use three free tools: MXToolbox (mxtoolbox.com) checks SPF and DMARC record syntax and reports errors. Google's Admin Toolbox (toolbox.googleapps.com) checks DKIM. Mail-Tester (mail-tester.com) sends a test email and scores your authentication setup, content, and spam likelihood in a single report.
Q: How long does DNS propagation take after setting up these records?
Most DNS changes propagate within 1–4 hours, though full global propagation can take up to 48 hours. Use MXToolbox to verify your records have propagated before assuming the setup is complete. If records aren't showing after 4 hours, check for typos in the DNS entry — particularly in the DKIM public key string, which is very long and prone to copy-paste errors.