SPF, DKIM, and DMARC Explained: The Complete DNS Guide for Cold Email

Outspun Team · 26 March 2026 · 13 min read

dns spf dkim dmarc authentication deliverability

Key Takeaways

SPF tells receiving servers which IPs can send email for your domain. It is a TXT record in your DNS.
DKIM attaches a cryptographic signature to every email, proving it was not tampered with and genuinely came from your domain.
DMARC ties SPF and DKIM together and tells receivers what to do when authentication fails. It also sends you reports.
All three are required. Missing any one of them significantly increases your chances of landing in spam.
Google and Microsoft both require SPF, DKIM, and DMARC for bulk senders as of their 2024/2025 policy updates.

Why Email Authentication Exists

Email was designed in the early 1980s without built-in authentication. The SMTP protocol lets anyone send an email claiming to be from any address. There is no verification at the protocol level. This design flaw is why phishing, spoofing, and spam exist at scale.

SPF, DKIM, and DMARC are the three protocols that were developed to retrofit authentication onto email. They work together as layers of verification, each solving a different part of the problem.

For cold email senders, these are not optional security features. They are deliverability requirements. Google, Microsoft, Yahoo, and every major email provider use authentication results as a primary signal when deciding whether to deliver an email to the inbox, spam, or reject it outright.

SPF: Sender Policy Framework

What SPF Does

SPF answers one question: “Is this IP address allowed to send email on behalf of this domain?”

When you send an email from your domain, the receiving server looks up your domain’s SPF record in DNS. That record contains a list of IP addresses and third-party services that are authorized senders. If the sending server’s IP matches the list, SPF passes. If it does not match, SPF fails.

How SPF Works Technically

You publish a TXT record in your domain’s DNS zone.
A receiving server gets an email claiming to be from your domain.
The server queries DNS for your SPF record.
It checks whether the sending server’s IP address is listed in your SPF record.
The result is Pass, Fail, SoftFail, or Neutral.

How to Set Up SPF

Your SPF record is a single TXT record added to your domain’s DNS. The format is:

v=spf1 [mechanisms] [qualifier]all

For Google Workspace:

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

For Microsoft 365:

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

For both Google Workspace and a third-party SMTP service (like Instantly or Smartlead):

v=spf1 include:_spf.google.com include:sendgrid.net ~all

The ~all at the end means “soft fail anything not in the list” — treat unauthenticated senders with suspicion but do not outright reject them. Once you are confident your SPF record is complete, you can tighten this to -all (hard fail).

Common SPF Mistakes

Mistake 1: Exceeding the 10-lookup limit. SPF allows a maximum of 10 DNS lookups. Each include: directive triggers one or more lookups. If you use Google Workspace, a CRM that sends email, a marketing tool, and a cold email platform, you can easily exceed 10 lookups. When you do, SPF fails for every email.

Fix: Audit your include: directives. Remove services you no longer use. If you genuinely need more than 10, use an SPF flattening service that resolves includes into IP addresses.

Mistake 2: Multiple SPF records. A domain must have exactly one SPF record. If you add a second TXT record starting with v=spf1, both records are invalid. This happens often when adding a new service — the admin creates a new record instead of modifying the existing one.

Fix: Always edit your existing SPF record to add new include: directives. Never create a second record.

Mistake 3: Forgetting to include your sending platform. If you use Instantly, Smartlead, or another cold email tool that sends via its own SMTP servers, those servers need to be in your SPF record.

Fix: Check your sending platform’s documentation for the correct SPF include value and add it to your record.

Testing SPF

Use Outspun’s SPF Checker to validate your record. You can also use the command line:

dig TXT yourdomain.com

Look for the TXT record starting with v=spf1 and verify it includes all your sending services.

DKIM: DomainKeys Identified Mail

What DKIM Does

DKIM answers a different question: “Was this email actually sent by the domain it claims to be from, and was it modified in transit?”

DKIM uses public-key cryptography. When you send an email, your email server signs it with a private key. The receiving server retrieves the corresponding public key from your DNS and uses it to verify the signature. If the signature is valid, the email is authentic and unmodified.

How DKIM Works Technically

Your email server generates a key pair (private + public).
The private key stays on your email server.
The public key is published as a TXT or CNAME record in your DNS.
When you send an email, your server creates a hash of specific email headers and the body, then encrypts this hash with the private key.
This encrypted hash is added to the email as a DKIM-Signature header.
The receiving server looks up your public key in DNS, decrypts the hash, and compares it to its own hash of the email.
If the hashes match, DKIM passes.

How to Set Up DKIM

DKIM setup varies by email provider because each provider generates its own key pairs.

Google Workspace:

Go to Google Admin Console > Apps > Google Workspace > Gmail > Authenticate email.
Select your domain and click “Generate new record.”
Google gives you a TXT record value (it will look like a long string of characters).
Add this as a TXT record in your DNS with the hostname google._domainkey.yourdomain.com.
Return to Google Admin and click “Start authentication.”

Microsoft 365:

Go to Microsoft 365 Defender > Email & collaboration > Policies > Threat policies > Email authentication > DKIM.
Select your domain.
Microsoft provides two CNAME records.
Add both CNAME records to your DNS.
Return to Microsoft and enable DKIM signing.

Common DKIM Mistakes

Mistake 1: Not enabling DKIM. Many email providers generate the DNS records for you but do not enable DKIM signing by default. You must explicitly turn it on after adding the DNS records.

Mistake 2: Key rotation. DKIM keys should be rotated periodically (every 6-12 months per M3AAWG best practices). Old keys that have been compromised can be used to forge DKIM signatures for your domain.

Mistake 3: Incorrect DNS record type. Some providers expect a TXT record, others expect a CNAME record. Using the wrong type causes DKIM to fail silently — the record exists in DNS but is not in the format the receiving server expects.

Testing DKIM

Use Outspun’s DKIM Checker. You will need to know your DKIM selector (the prefix before ._domainkey.yourdomain.com). For Google Workspace, the default selector is google. For Microsoft 365, it is typically selector1 and selector2.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

What DMARC Does

DMARC answers the final question: “What should happen when SPF or DKIM fails, and who should be notified?”

DMARC is the policy layer. Without it, SPF and DKIM provide authentication data but do not instruct receiving servers on what to do with that data. DMARC closes this gap by specifying a policy (none, quarantine, or reject) and providing a reporting mechanism.

How DMARC Works Technically

You publish a DMARC TXT record in your DNS at _dmarc.yourdomain.com.
When a receiving server gets an email from your domain, it checks SPF and DKIM results.
DMARC then checks “alignment” — does the domain in the From header match the domain that passed SPF or DKIM?
If authentication fails or does not align, the receiving server follows your DMARC policy.
The receiving server sends aggregate reports to the email address specified in your DMARC record.

DMARC Policies

p=none: Monitor only. Failed emails are still delivered normally. Use this when you are first setting up DMARC and want to see reports before enforcing.

p=quarantine: Failed emails are sent to spam/junk. Use this as an intermediate step once you are confident your legitimate emails pass authentication.

p=reject: Failed emails are outright rejected — they are not delivered at all. This is the strongest policy and provides the best protection against spoofing.

How to Set Up DMARC

Add a TXT record to your DNS:

Record name: _dmarc.yourdomain.com

Starting policy (monitoring only):

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

Intermediate policy (quarantine):

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

Full enforcement (reject):

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

The Recommended DMARC Progression for Cold Email

Week 1-4: p=none. Collect reports. Identify any legitimate sending services that are not properly authenticated.
Week 5-8: p=quarantine with pct=25. Apply quarantine to 25% of failing emails. Monitor for any impact on legitimate delivery.
Week 9-12: p=quarantine with pct=100. Quarantine all failing emails.
Week 13+: p=reject. Full enforcement. Only move here when you are certain all legitimate email sources are properly authenticated.

For cold email specifically, many operators stay at p=quarantine rather than moving to p=reject. The risk with p=reject is that a misconfiguration in your sending platform could cause legitimate cold emails to be rejected entirely, with no fallback to spam.

Common DMARC Mistakes

Mistake 1: Skipping DMARC entirely. Some operators set up SPF and DKIM but never add a DMARC record. Without DMARC, there is no policy instructing receivers on what to do with authentication failures, and you receive no reports about your domain’s authentication health.

Mistake 2: Jumping straight to p=reject. Going from no DMARC to p=reject without a monitoring period risks blocking your own legitimate email. Always start with p=none.

Mistake 3: Ignoring DMARC reports. The rua tag in your DMARC record sends aggregate reports to the specified email address. These reports tell you exactly which IPs are sending email as your domain and whether they are passing authentication. Ignoring these reports means you are flying blind.

Mistake 4: DMARC alignment failures. DMARC requires “alignment” — the domain in the visible From header must match the domain that passed SPF or DKIM. If your cold email tool sends from you@yourdomain.com but the actual sending IP belongs to a different domain that is not aligned, DMARC will fail even if SPF passes for the sending service.

Testing DMARC

Use Outspun’s DMARC Checker to verify your record syntax and policy. For ongoing monitoring, use a DMARC reporting service that aggregates and visualizes the XML reports (they are not human-readable in raw form).

How SPF, DKIM, and DMARC Work Together

Think of the three protocols as layers:

Protocol	Question Answered	Mechanism
SPF	Is this server allowed to send for this domain?	IP allowlist in DNS
DKIM	Was this email genuinely sent by this domain and not tampered with?	Cryptographic signature
DMARC	What happens when authentication fails?	Policy + reporting

A fully authenticated email passes all three checks. The receiving server sees:

The sending IP is in the SPF record (SPF Pass).
The DKIM signature is valid (DKIM Pass).
Both are aligned with the From domain (DMARC Pass).

This triple pass is the gold standard. It does not guarantee inbox placement — content, engagement history, and sender reputation still matter — but it removes the single biggest technical barrier to deliverability.

Frequently Asked Questions

Do I need all three, or is one enough?

You need all three. Google’s bulk sender requirements (effective February 2024, enforced through 2026) explicitly require SPF, DKIM, and DMARC for anyone sending more than 5,000 emails per day to Gmail. Microsoft has similar requirements. Even below the 5,000 threshold, missing any one protocol significantly hurts deliverability.

How long does DNS propagation take?

DNS changes typically propagate within 1-48 hours, depending on TTL settings and the DNS provider. Most changes are visible within 1-4 hours. Always verify your records after making changes and before sending email.

Can I use the same SPF/DKIM/DMARC setup across all my sending domains?

SPF and DMARC records need to be set up individually for each domain. DKIM keys are also per-domain (and per-provider). If you have 10 sending domains, you need 10 SPF records, 10 sets of DKIM keys, and 10 DMARC records. This is one area where managed infrastructure services save significant time — Outspun configures all DNS records for every domain in your plan.

What is the difference between ~all and -all in SPF?

~all (tilde) is a “soft fail” — unauthenticated senders are treated with suspicion but not outright rejected. -all (hyphen) is a “hard fail” — unauthenticated senders are rejected. Start with ~all and move to -all once you are confident your SPF record is complete and all legitimate senders are included.

My emails pass SPF and DKIM but still go to spam. Why?

Authentication is necessary but not sufficient. Passing SPF, DKIM, and DMARC means your emails are technically legitimate. But if your domain reputation is low, your content triggers spam filters, your bounce rate is high, or your engagement metrics are poor, you can still land in spam despite perfect authentication. Think of authentication as the entry ticket — it gets you through the door, but reputation and content determine which room you end up in.

Quick Reference: DNS Records Cheat Sheet

SPF Record

Type: TXT
Host: @ (root domain)
Value: v=spf1 include:[provider] ~all
One per domain: Yes (exactly one)

DKIM Record

Type: TXT or CNAME (depends on provider)
Host: [selector]._domainkey (e.g., google._domainkey)
Value: Public key from your email provider
One per selector: Yes

DMARC Record

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
One per domain: Yes (exactly one)

MX Record

Type: MX
Host: @ (root domain)
Value: Your email provider’s mail servers
Priority: Follow provider’s recommended priority values

Next Steps

Run a full DNS Audit on every domain you use for cold email.
Fix any missing or misconfigured records.
Set DMARC to p=none and monitor reports for 4 weeks.
Review our deliverability checklist to ensure the rest of your infrastructure is sound.
Gradually tighten your DMARC policy as confidence grows.

DNS authentication is the technical foundation of cold email deliverability. Get it right once, monitor it continuously, and it will never be the reason your emails hit spam.