What are SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC are three DNS-based email authentication protocols that prove you are who you claim to be when you send email. Together, they answer the same question receiving mail servers ask about every inbound message: is this sender actually authorized to send on behalf of this domain?
Before these standards existed, anyone could forge a From address and send emails appearing to come from your domain. Authentication records stored in your DNS make that forgery detectable - and increasingly, email providers like Gmail and Outlook will reject or spam-folder messages that fail these checks. For a broader look at how authentication fits into overall inbox placement, read our complete cold email deliverability guide.
A DNS TXT record that lists every mail server IP address authorized to send email from your domain. When a receiving server gets a message claiming to be from you, it checks your SPF record to verify the sending IP is on the approved list. Think of it as a guest list - if the IP isn't on it, the message is suspect.
Adds a cryptographic digital signature to every outgoing email. Your mail server signs the message with a private key, and a matching public key published in your DNS lets receiving servers verify the signature. This confirms the email was not tampered with in transit and genuinely originated from your infrastructure.
Sits on top of SPF and DKIM and tells receiving servers what to do when authentication fails: monitor only (p=none), send to spam (p=quarantine), or block entirely (p=reject). It also enables aggregate reports so you can see who is sending email on your domain's behalf.
None of these protocols require code changes or server access. Each one is a simple DNS TXT record you add through your domain registrar (GoDaddy, Namecheap, Cloudflare, Google Domains) or DNS provider. The entire setup for all three typically takes under 30 minutes.
Why do cold emails need authentication?
In February 2024, Google announced mandatory SPF and DKIM requirements for all senders sending more than 5,000 emails per day to Gmail addresses. Yahoo followed with identical requirements on the same day. Senders without proper authentication now see their messages bounced or spam-foldered at scale - there is no longer any gray area.
But even below that 5,000/day threshold, unauthenticated cold email is a losing strategy. Gmail's spam filters have become dramatically more aggressive since 2023. Sending without SPF and DKIM signals to every receiving server that your domain is unverified - and unverified domains land in spam at a much higher rate than authenticated ones, regardless of how good your copy is. Once authentication is in place, the next question is how many cold emails per day you can safely send without hurting deliverability.
Cold email is uniquely vulnerable because you are contacting people who have never heard of you. You have no existing engagement history, no prior opens or replies to signal trustworthiness - authentication is the baseline that lets you even get a fair shot at the inbox. Without it, you are fighting against the spam filter before the recipient ever reads a word. This is why our email warmup guide always lists authentication setup as step zero - warmup does nothing if authentication is broken.
How do you set up SPF step by step?
SPF is a single DNS TXT record added to the root of your sending domain. For Google Workspace users, this is straightforward - Google provides the exact record value. For other providers, the value will differ slightly, but the process is identical.
Step 1: Check if an SPF record already exists
Before adding anything, check whether your domain already has an SPF record. You can only have one SPF record per domain - adding a second one will break both. Use MXToolbox SPF Lookup or run this command in your terminal:
nslookup -type=TXT yourdomain.comLook for a result that starts with v=spf1. If one exists, you will need to edit it rather than add a new one.
Step 2: Create your SPF record
For Google Workspace, use the following record exactly as shown. This is the officially recommended SPF record from Google:
TXT@ (or leave blank - represents your root domain)v=spf1 include:_spf.google.com ~all3600 (1 hour)If you use Outlook / Microsoft 365 instead of Google Workspace, the value is:
v=spf1 include:spf.protection.outlook.com ~allThe ~all at the end is a soft fail - emails from unauthorized IPs are marked suspicious but not outright rejected. Using -all (hard fail) is more strict and preferred once you have confirmed all your senders are listed. If you send through additional tools like a CRM or outreach platform, you need to add their include: mechanism to the same record before switching to -all.
Step 3: Add the record to your DNS
Log in to wherever your domain's DNS is managed (Cloudflare, GoDaddy, Namecheap, Route 53, Google Domains, etc.) and add a new TXT record with the values above. The interface varies by provider but the fields are the same: type, name/host, and value.
v=spf1 already exists, edit it - do not add a new one. Multiple SPF records on the same domain will cause a PermError and your SPF will fail for every email.How do you set up DKIM step by step?
DKIM requires generating a key pair through your email provider, then publishing the public key as a DNS TXT record. Unlike SPF, the DKIM record goes on a subdomain (a selector), not the root domain - so multiple DKIM records can coexist without conflict.
Step 1: Generate your DKIM key in Google Workspace
Follow Google's official DKIM setup guide to generate your key:
Step 2: Add the DKIM TXT record to your DNS
Google will give you a hostname like google._domainkey.yourdomain.com and a value that starts with v=DKIM1; k=rsa; p=.... The format looks like this:
TXTgoogle._domainkeyv=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B... (your full key from Google Admin)3600 (1 hour)Step 3: Start DKIM signing in Google Admin
After adding the DNS record, return to Google Admin Console > Apps > Gmail > Authenticate email, select your domain, and click Start authentication. Google will verify the DNS record is in place and begin signing outgoing emails. This usually takes a few minutes after DNS propagation - allow up to 48 hours for full propagation.
How do you set up DMARC step by step?
DMARC is added as a TXT record on the _dmarc subdomain of your sending domain. It ties together your SPF and DKIM results and tells receiving servers how to handle failures. DMARC.org's overview is the authoritative reference for the full specification.
The standard approach is to start with a monitoring-only policy (p=none), review the reports for 2-4 weeks, and then escalate to enforcement once you are confident all legitimate sending is passing SPF and DKIM. Skipping the monitoring phase and jumping straight to p=reject is one of the most common ways to accidentally block your own email.
Step 1: Add a DMARC record at p=none (monitoring)
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com3600 (1 hour)Replace dmarc@yourdomain.com with a real email address where you want to receive aggregate reports. You can create a dedicated address like dmarc-reports@yourdomain.com or use an existing inbox.
Step 2: Review DMARC reports for 2-4 weeks
DMARC aggregate reports (RUA) are sent daily as XML files. They show every source that sent email claiming to be from your domain, along with pass/fail results. Use a free tool like Postmark's free DMARC analyzer or dmarcian to parse the reports into a readable format.
Look for any legitimate sending sources that are failing SPF or DKIM. Common culprits include marketing automation tools, CRMs, help desk software, and third-party services that send on your behalf. Every source that sends your email needs to either be added to your SPF record or configured to sign with DKIM.
Step 3: Escalate to p=quarantine, then p=reject
Once your DMARC reports show 100% pass rates for all legitimate senders, update the record value to increase enforcement:
| Phase | Policy Value | What Happens on Failure | When to Use |
|---|---|---|---|
| Phase 1 | p=none | Deliver normally, send report | Immediately - start here |
| Phase 2 | p=quarantine | Send to spam/junk folder | After 2-4 weeks of clean reports |
| Phase 3 | p=reject | Block the message entirely | After p=quarantine looks clean |
A complete p=reject DMARC record for a fully locked-down domain looks like this:
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; pct=100How do you verify your setup is working?
DNS propagation can take anywhere from 15 minutes to 48 hours. Once enough time has passed, use the following methods and tools to confirm that SPF, DKIM, and DMARC are all passing correctly before launching any cold email campaigns. You can also use our free SPF/DKIM/DMARC checker to run all three checks in one place.
Method 1: Send a test email and check headers
Send an email from your sending domain to a personal Gmail account. In Gmail, click the three-dot menu in the top right of the email and select Show original. Look for the Authentication-Results header near the top. A fully passing setup looks like this:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of you@yourdomain.com
designates 209.85.220.41 as permitted sender)
dkim=pass header.i=@yourdomain.com
dmarc=pass (p=NONE sp=NONE dis=NONE)
header.from=yourdomain.comMethod 2: Use free verification tools
| Tool | What It Checks | Free? |
|---|---|---|
| MXToolbox SPF/DKIM/DMARC | Lookup and validation of all three records | Yes |
| Google Admin Toolbox | Full MX, SPF, DKIM check for Google Workspace | Yes |
| Mail-Tester | Sends actual email score including auth, content, IP | 3 tests/day |
| DMARC Analyzer (Postmark) | DMARC record parser + report reader | Yes |
| Prospi DNS Checker | All three records in one check, cold-email focused | Yes |
What are common authentication mistakes?
After helping 300+ companies configure their sending infrastructure through Prospi, these are the authentication mistakes we see most frequently - and the ones that cost the most in deliverability.
The single most common mistake. When a domain has two records starting with v=spf1, receiving servers perform an RFC 7208 lookup and return a PermError - which is treated as a hard failure. Every legitimate email from that domain will fail SPF. If you need to add another sending service, combine everything into one record.
The SPF specification limits evaluation to 10 DNS lookups. Each include: mechanism counts as a lookup. If your SPF record includes Salesforce, Mailchimp, Marketo, HubSpot, and a few others, you can easily exceed this limit and trigger a PermError. Use tools like MXToolbox's SPF checker to count your lookups and flatten your record if needed.
Jumping directly to p=reject DMARC will block any legitimate email from sources you haven't authorized yet - including your own newsletters, transactional emails from SaaS tools, or forwarded messages. Always spend 2-4 weeks at p=none reading DMARC reports before enforcing any policy.
If you send cold email from a subdomain (e.g., mail.yourdomain.com or outreach.yourdomain.com), you need SPF and DKIM configured for that subdomain separately. Many teams set up authentication on their root domain but neglect the sending subdomain they actually use for cold outreach. Check your From address and make sure authentication is on the right domain.
A newly authenticated domain still has zero sending reputation. Launching cold campaigns immediately after setting up DNS records without first warming up the account is a fast path to the spam folder. See our complete breakdown in the cold email deliverability guide.
If your website is on yourbusiness.com but your cold email goes out from outreach-yourbusiness.com, authentication needs to be on outreach-yourbusiness.com - not your main domain. Many senders use a separate domain for cold email to protect their primary domain's reputation. Both domains need their own complete authentication setup.
If you are setting up multiple sending domains at once - which is common for cold email at scale - the manual process above needs to be repeated for every domain. Prospi handles this automatically during onboarding: connect a domain, and the platform walks you through each record, checks propagation, and confirms all three protocols are passing before your first send. See how we handle this on the product page, or compare it to doing everything manually in our deliverability guide. You can also look at pricing to see what is included.
Frequently asked questions
Do I need SPF, DKIM, and DMARC for cold email?
Yes. As of February 2024, Google and Yahoo require SPF and DKIM for all bulk senders sending more than 5,000 emails per day. DMARC is strongly recommended for all senders. Without these records, your emails will almost certainly land in spam or be rejected entirely - regardless of the quality of your copy or how well you have warmed up your account.
How long does it take for DNS records to propagate?
DNS propagation typically takes 15 minutes to 48 hours, depending on your DNS provider and the TTL (time-to-live) value set on your records. Most records go live within 1-4 hours. You can monitor propagation status in real time using MXToolbox or Google Admin Toolbox - just re-run the lookup every 30 minutes after adding a record.
Can I have multiple SPF records on one domain?
No. You can only have one SPF TXT record per domain. If you have multiple email providers (for example, Google Workspace for outreach plus HubSpot for marketing emails), you must combine all authorized senders into a single SPF record using multiple include: mechanisms. Adding a second SPF record will cause a PermError and break authentication entirely.
What DMARC policy should I start with?
Start with p=none to monitor your email traffic without affecting deliverability. After 2-4 weeks of reviewing DMARC aggregate reports to confirm all legitimate senders are passing SPF and DKIM, move to p=quarantine. Once you are confident everything is clean, escalate to p=reject for maximum domain protection. Never skip the monitoring phase.
How do I know if my SPF, DKIM, and DMARC are working?
Send a test email to a Gmail account and inspect the raw headers (three-dot menu > Show original). Look for spf=pass, dkim=pass, and dmarc=pass in the Authentication-Results header. You can also use free tools like MXToolbox or our free DNS checker to validate all three records at once.
