SPF, DKIM, and DMARC Explained for Non-Technical Founders
Nine times out of ten, when cold emails don't reach the inbox, the problem isn't the copy — it's the infrastructure. Here's the SPF, DKIM, and DMARC playbook every founder and SDR needs in 2026.
The three letters standing between you and the inbox
You've written the perfect cold email. Your subject line is punchy, your offer is clear, your call to action is tight. You hit send. And it lands in spam.
Sound familiar?
Nine times out of ten, when cold emails don't reach the inbox, the problem isn't the copy. It's the infrastructure. And at the heart of cold email infrastructure are three acronyms that every founder, SDR, and sales team needs to understand: SPF, DKIM, and DMARC.
These aren't optional. As of February 2024, Google and Yahoo made SPF, DKIM, and DMARC mandatory for bulk senders — and Microsoft followed suit in May 2025. Miss any one of them and your emails either land in spam or get rejected entirely before they even arrive.
This guide breaks down what each protocol does, why it matters for cold email deliverability, and how to set each one up — without needing a developer on call.
Why email authentication exists (a 2-minute history lesson)
When email was invented in the early 1980s, the internet was small and collegial. SMTP — Simple Mail Transfer Protocol — was built on trust. Any server could claim to send mail from any address. There was no way to verify who was actually sending.
That worked fine for a tiny academic network. It became a catastrophic problem for an internet sending over 300 billion emails per day, where bad actors routinely forge sender addresses to run phishing scams and fraud.
The solution? Three authentication standards developed over two decades: SPF, DKIM, and DMARC. Each one solves a different piece of the same problem — proving that you are who you say you are when you send an email.
Think of it this way:
- SPF is the bouncer checking if you're on the guest list
- DKIM is the wax seal on an envelope proving it wasn't tampered with
- DMARC is the venue manager deciding what to do if either check fails
What is SPF? (Sender Policy Framework)
SPF — Sender Policy Framework — is an email authentication protocol that tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain.
It works by publishing a simple DNS TXT record. When someone receives an email from you@yourdomain.com, their mail server looks up your domain's SPF record and asks: "Is the server that just sent this email on the approved list?"
If the answer is yes, the email passes SPF. If no, it fails — and depending on other settings, it may get flagged as spam or rejected outright.
What an SPF record looks like
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Breaking this down:
v=spf1— declares this is an SPF recordinclude:_spf.google.com— authorizes Google's mail serversinclude:sendgrid.net— authorizes SendGrid to send on your behalf~all— "soft fail" any server not listed (it may be flagged but not outright rejected)
SPF's one big limitation
SPF breaks when email is forwarded. If someone forwards your email to another address, the forwarding server isn't on your SPF list, so the check fails even for legitimate mail. This is why SPF alone isn't enough — you need DKIM too.
What is DKIM? (DomainKeys Identified Mail)
DKIM — DomainKeys Identified Mail — adds a cryptographic digital signature to every email you send. Think of it as a tamper-evident seal. If anyone alters your email in transit, the signature breaks and the receiving server knows something's wrong.
Here's how it works:
- When you set up DKIM, two cryptographic keys are generated: a private key (kept secret on your sending server) and a public key (published in your DNS records).
- Every time you send an email, your mail server signs it with the private key.
- When the email arrives, the recipient's server retrieves your public key from DNS and uses it to verify the signature.
If the signature matches, DKIM passes. If it doesn't, the email may have been modified in transit.
Why DKIM matters more than SPF for cold email
Unlike SPF, DKIM survives email forwarding because the signature travels with the message itself, not the sending server. Many deliverability experts recommend a DKIM-first approach for this reason. A valid DKIM signature is often the stronger signal to inbox providers that your cold email is legitimate.
For cold email infrastructure, use a 2048-bit DKIM key rather than the older 1024-bit standard. Yahoo has been known to reject mail from domains using shorter key lengths.
What is DMARC? (Domain-based Message Authentication, Reporting, and Conformance)
DMARC is the policy layer that sits on top of SPF and DKIM. It does two things:
- Tells receiving servers what to do when an email fails SPF or DKIM checks
- Sends you reports on who is sending email using your domain — including any bad actors trying to impersonate you
DMARC introduces a concept called alignment — it checks whether the domain in the visible "From" address matches the domain used in SPF and DKIM authentication. Without DMARC, an attacker could pass SPF on one domain while displaying a different "From" address to trick recipients.
The three DMARC policy levels
| Policy | What it does | When to use it |
|---|---|---|
p=none | Monitor only — take no action on failures | Starting out; learning your sending sources |
p=quarantine | Send failing emails to spam folder | Intermediate — once you trust your setup |
p=reject | Block failing emails entirely | Full protection — after verifying all senders |
What a DMARC record looks like
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
The rua= tag is where DMARC reports get sent. These reports show every source sending email claiming to be from your domain — valuable whether you're troubleshooting email deliverability or watching for impersonators.
How SPF, DKIM, and DMARC work together
Here's the key insight most guides miss: SPF and DKIM work independently, but DMARC needs both to make sense of everything.
When an email arrives at Gmail or Outlook, the receiving server runs three checks in sequence:
- SPF check — Is the sending server authorized to send for this domain?
- DKIM check — Is the cryptographic signature valid and unmodified?
- DMARC check — Do the domains align? And what should we do if they don't?
An email passes DMARC if at least one of SPF or DKIM passes and is aligned with the visible "From" domain. Missing any one of these creates a gap that spammers and phishers can exploit — and that inbox providers will penalize you for, hurting your cold email deliverability.
The 2024–2025 mandate: this is no longer optional
In February 2024, Google and Yahoo changed the rules for bulk email senders. Anyone sending more than 5,000 emails per day to Gmail or Yahoo addresses was required to have SPF, DKIM, and DMARC properly configured — with at minimum a DMARC policy of p=none. Microsoft followed with its own mandate taking effect May 5, 2025, requiring the same for senders to Outlook, Hotmail, and Live addresses.
What happens if you don't comply? Your emails don't just go to spam. They get rejected at the SMTP level with an explicit error code. As of November 2025, Gmail tightened enforcement further — non-compliant emails now face both temporary and permanent rejections.
One additional requirement: one-click unsubscribe. Bulk senders must include a List-Unsubscribe header so recipients can opt out without friction, and you must honor those requests within two days.
Step-by-step: how to set up SPF, DKIM, and DMARC
Step 1: Set up SPF
- Log into your domain's DNS settings (GoDaddy, Cloudflare, Namecheap, etc.)
- Create a new TXT record at your root domain (
@) - Add your SPF record — for Google Workspace:
v=spf1 include:_spf.google.com ~all - If you use multiple sending services, combine them into one record
- Save and wait for DNS propagation (usually 15 minutes to 48 hours)
Important: You can only have one SPF record per domain. If you have multiple sending tools, combine them into a single record.
Step 2: Set up DKIM
DKIM setup is handled through your email sending platform:
- Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate Email
- Microsoft 365: Admin Center → Settings → Domains → your domain → DKIM
- Cold email tools (Instantly, Smartlead, etc.): Domain authentication settings within each platform
Each platform will give you a CNAME or TXT record to add to your DNS. Add it exactly as provided. Use a 2048-bit key for maximum compatibility.
Step 3: Set up DMARC
Create a new TXT record in DNS at _dmarc.yourdomain.com. Start with a monitoring-only policy:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1
Monitor your DMARC reports for 2–4 weeks. Once you confirm all legitimate sending sources pass, move to p=quarantine. After another clean 2–4 weeks, move to p=reject.
Don't skip the gradual rollout. Moving directly to
p=rejectwithout verifying your setup first can block legitimate emails.
Cold email infrastructure: the secondary domain strategy
Here's something many SDRs and founders overlook: never send cold email from your main company domain.
If your cold email campaigns damage your domain reputation — and it can happen even with best practices — you don't want that affecting your company's transactional emails, customer communications, or executive correspondence.
The standard practice is to register secondary "sending domains" — variations of your main domain specifically for cold outreach. For example, if your company domain is acmecorp.com, you might register mail.acmecorp.com or hiacme.com for cold outreach.
Each of these secondary domains needs its own complete SPF, DKIM, and DMARC setup.
At Mailflo, this is exactly what our cold email infrastructure handles — complete domain setup, authentication configuration, and warmup, so your team can focus on writing great emails and closing deals.
Common SPF, DKIM, and DMARC mistakes to avoid
- Multiple SPF records — You can only have one SPF record per domain. Having two causes unpredictable failures. Combine all your authorized senders into a single record.
- Too many DNS lookups — SPF has a hard limit of 10 DNS lookups. Exceeding this causes SPF to fail regardless of your configuration. Use SPF flattening tools if you send through many services.
- Skipping DMARC entirely — Some teams set up SPF and DKIM but skip DMARC. Without DMARC, you have no policy enforcement and no deliverability visibility. You need at least
p=noneto meet current Google and Yahoo requirements. - Using a 1024-bit DKIM key — Older setups default to 1024-bit keys. Yahoo is stricter about key length. Use 2048-bit to be safe.
- Not monitoring DMARC reports — DMARC reports show if a third-party tool is sending email from your domain without proper authentication — which damages your sender reputation.
Tools to test your email authentication setup
- Google Admin Toolbox (
toolbox.googleapps.com/apps/checkmx) — checks MX, SPF, and DKIM records - MXToolbox (
mxtoolbox.com) — comprehensive DNS and email record lookup - Mail-Tester (
mail-tester.com) — send a test email and get a full authentication score - DMARC Analyzer — parse and visualize your DMARC reports
TL;DR summary
| Protocol | What it does | Minimum requirement |
|---|---|---|
| SPF | Authorizes which servers can send for your domain | One TXT record listing all sending servers |
| DKIM | Signs emails with a cryptographic key to prove authenticity | 2048-bit key via your sending platform |
| DMARC | Enforces policy when SPF/DKIM fail; sends reports | At minimum p=none; aim for p=reject |
References
- Cloudflare. What are DMARC, DKIM, and SPF?
- Valimail. SPF, DKIM, and DMARC Made Simple (January 2026)
- Microsoft Learn. Email Authentication — Microsoft Defender for Office 365
- Microsoft Learn. Use DMARC to Validate Email
- Mimecast. SPF vs. DKIM vs. DMARC: A Guide
- Higher Logic. SPF, DKIM, DMARC: The 3 Pillars of Email Authentication (July 2025)
- Mailtrap. Email Authentication Explained: SPF, DKIM, DMARC, BIMI (September 2025)
- Valimail Help Center. Google & Yahoo Email Authentication Requirements for Bulk Senders
- Security Boulevard / PowerDMARC. Google and Yahoo Updated Email Authentication Requirements for 2025 (November 2025)
- Mailgun / Sinch. Yahoogle: New Bulk Sender Requirements in 2024
- dmarcian. Understanding Gmail and Yahoo DMARC Requirements (November 2025)
- Unboxd. Google, Yahoo & Microsoft Bulk Sender Requirements: The Complete 2026 Guide
- InboxKit. SPF vs DKIM vs DMARC: Email Authentication Explained Simply (2026)
- EmailCloud. SPF, DKIM, and DMARC Explained: Email Authentication Demystified (March 2026)
Ready to set up your cold email infrastructure the right way? Mailflo handles complete domain setup, SPF/DKIM/DMARC configuration, email warmup, and sending account management — so you can start hitting inboxes from day one.
Frequently Asked Questions
- SPF specifies which mail servers are allowed to send email on behalf of your domain. DKIM adds a cryptographic signature to each email to prove it hasn't been tampered with in transit. DMARC is the policy layer that tells receiving servers what to do when SPF or DKIM checks fail, and sends you reports on who is sending email from your domain. All three work together: SPF and DKIM authenticate the email, and DMARC enforces the rules and provides visibility.
- Yes. Since February 2024, Google and Yahoo require SPF, DKIM, and at minimum a DMARC policy of p=none for bulk senders. Microsoft added the same requirements in May 2025. Missing any one of the three can result in emails being rejected or filtered to spam before they reach a single prospect.
- No. You can only have one SPF record per domain. If you use multiple email sending services, combine all their authorized servers into a single SPF TXT record. Having two separate SPF records causes unpredictable failures because receiving servers will stop looking after they find the first one.
- Start with p=none. This is the monitoring-only policy — it takes no action on failing emails but begins sending you DMARC reports. Review those reports for two to four weeks to confirm all your legitimate sending sources pass, then move to p=quarantine, and eventually p=reject for maximum protection.
- Always use a 2048-bit DKIM key. Older setups default to 1024-bit, but Yahoo has been known to reject mail signed with shorter key lengths. When setting up DKIM through Google Workspace, Microsoft 365, or any cold email platform, select the 2048-bit key option if given a choice.
- Yes. Every domain you send cold email from — including secondary sending domains registered specifically for outreach — must have its own complete SPF, DKIM, and DMARC configuration. The authentication requirements apply per domain, not per company.
Written by
The Mailflo Team
The Mailflo team helps B2B sales teams land in the inbox and book more meetings through bulletproof email deliverability and smart automation.
LinkedIn