How to Fix Failing Email Authentication in Cold Email (Step-by-Step)
You set up your domain, loaded your sequence, and pressed send. Then the only replies were bounce notices, or worse, nothing came back at all because the messages quietly went to spam. Knowing how to fix email authentication failing is usually the difference between those two outcomes. When SPF, DKIM, or DMARC fails, mailbox providers either reject your message at the door or file it in junk before a human ever sees it.
The good news: failing authentication is one of the most fixable deliverability problems there is. It lives entirely in your DNS records, so you can diagnose it precisely and repair it in an afternoon. This guide covers what each record does, how to find which one is broken, and the exact fix for SPF, DKIM, and DMARC.
SPF, DKIM, and DMARC in Plain English
Think of authentication as three checks a mailbox provider runs before deciding whether to trust your message. Each answers a different question, and "failing" means something specific for each.
SPF (Sender Policy Framework) answers: is this server allowed to send for this domain? You publish a list of approved sending servers in a DNS TXT record, and the receiver checks whether the sending IP is on it. A "soft fail" (marked `~all`) means treat it with suspicion. A "hard fail" (`-all`) means reject it. A "permerror" means your record is broken and could not be evaluated, which modern receivers treat as a failure.
DKIM (DomainKeys Identified Mail) answers: was this message tampered with, and was it really signed by the domain? Your system attaches a cryptographic signature to each email using a private key. The matching public key lives in your DNS at a named "selector." If the key is missing, wrong, or the message was altered, DKIM fails.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that ties the first two together. It answers: what should the receiver do when SPF or DKIM fails, and do the passing checks actually match the visible From address? That last part is alignment, and it is where most DMARC failures live. A message can have a valid SPF and DKIM pass and still fail DMARC if neither aligns with the domain in your From line.
| Record | What it proves | Common failure | How to fix |
|---|---|---|---|
| SPF | The sending server is authorized | PermError from exceeding 10 DNS lookups, or a missing include | Consolidate includes, flatten the record, stay under 10 lookups |
| DKIM | The message was signed and untampered | Public key not published at the selector, or wrong selector | Publish the exact key your provider gives you at the named selector |
| DMARC | SPF or DKIM passes AND aligns with the From domain | No DMARC record, or passing checks do not align with From | Publish a DMARC record, send from an aligned domain |
The insight most senders miss: DMARC does not care that SPF or DKIM passed in isolation. It only counts a pass when the authenticated domain matches the domain a human sees in the From field.
How to Diagnose Which One Is Failing
Before you change a single record, find out exactly what is broken. Guessing leads to stacked fixes that create new problems. There are three reliable ways to diagnose this.
Read the Authentication-Results header. Send a test email from your cold email setup to a personal Gmail or Outlook account, open it, view the original or full headers (in Gmail, "Show original"), and find the `Authentication-Results` line. It spells out each verdict in plain text, something like `spf=pass`, `dkim=fail`, `dmarc=fail (p=none)`. This is the most honest source of truth because it is the actual verdict the receiver rendered on your real message.
Run a checker against your domain. Tools like MXToolbox let you look up your SPF, DKIM, and DMARC records straight from DNS and flag syntax errors, lookup-count problems, and missing records. Pair the checker with the header read: the checker tells you what is in DNS, the header tells you how a real receiver judged it.
Use a seed or test inbox. Send a fresh message to a free authentication test address (Google's Postmaster Tools and many deliverability platforms offer one) and read the full report. This catches selector mismatches and alignment failures a static DNS lookup can miss.
Once the header tells you which of the three is failing, jump to the matching fix below.
Fixing SPF
SPF lives in a single TXT record on your sending domain. A clean record looks like `v=spf1 include:_spf.google.com ~all`. It fails most often from syntax mistakes, a missing include for your sending platform, and, by a wide margin, the 10-lookup limit.
The 10-DNS-lookup limit is the silent killer. Per RFC 7208, evaluating your SPF record may trigger at most 10 DNS lookups. Every `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` counts, including the ones nested inside other includes. Cross the line and the receiver returns a PermError, meaning it could not evaluate your record and treats SPF as failed. This bites cold email senders hard because each tool you add (a sending platform, a CRM, a tracking provider) often adds its own include, and the count climbs invisibly.
To fix SPF:
- Confirm you have exactly one SPF record. Two `v=spf1` records is itself a permerror. Merge them.
- List only the includes you actually send from. Remove leftovers from tools you no longer use.
- Count your lookups. If you are near or over 10, "flatten" the record by replacing some includes with the IP ranges they resolve to, or use an SPF management service that keeps you under the cap automatically.
- End with `~all` (soft fail) while you stabilize. Move to `-all` (hard fail) once every legitimate source is listed.
Fixing DKIM
DKIM failure is almost always a publishing problem, not a signing problem. Your platform signs every message with a private key and expects the matching public key to be live at a named selector. If that public key is missing, malformed, or published at the wrong selector, every message fails DKIM.
To fix DKIM:
- Get the exact public key and selector from your provider. The selector is a short label (for example `google` or `s1`) that tells receivers where to look. The record lives at `selector._domainkey.yourdomain.com`.
- Publish the key as a TXT (or CNAME, if your provider uses delegated DKIM) record at that exact selector. Copy it character for character. A single truncated or wrapped key breaks verification.
- Confirm the published selector matches the one your provider is actually signing with. A mismatch here is the most common DKIM failure of all.
- Use a 2048-bit key. It is the current recommendation over the older 1024-bit standard, which is now viewed as weak.
If you run multiple sending tools on one domain, each needs its own selector and published key. Rotating keys periodically is good hygiene, but only rotate when your provider supports a clean handoff, and verify the new selector is live before retiring the old one.
Fixing DMARC
DMARC is a TXT record published at `_dmarc.yourdomain.com`. A starter record looks like `v=DMARC1; p=none; rua=mailto:reports@yourdomain.com`. Two things make it fail: not having a record at all, and alignment.
Alignment is the part people miss. For DMARC to pass, either SPF or DKIM must pass AND the domain it authenticated must match the domain in your visible From address. You can have a green SPF pass and a green DKIM pass and still fail DMARC because both authenticated a different domain than the one in your From line. If your setup sends from a subdomain or a different sending domain than your From header shows, alignment breaks.
Roll DMARC out in stages rather than jumping straight to enforcement:
- Start at `p=none`. Monitoring mode. Receivers take no action on failing mail but send you aggregate reports via the `rua` address. Use this phase to see every source sending as your domain and confirm SPF and DKIM align.
- Move to `p=quarantine`. Failing messages go to spam. Start with the `pct=` tag low (for example `pct=10`) so only a fraction of failing mail is affected, then raise it as reports stay clean.
- Advance to `p=reject`. Full enforcement. Failing mail is rejected outright. Only get here once your reports confirm every legitimate message passes and aligns.
The reporting address matters as much as the policy. Without `rua` you are enforcing blind. The aggregate reports are XML summaries with no message content or personal data, so they are safe to collect, and they are the only reliable way to confirm you can tighten policy without blocking your own mail.
Why Google and Yahoo Made DMARC Mandatory
Since February 2024, Google and Yahoo enforce shared bulk sender requirements, and they reshaped what failing authentication costs you. If you send roughly 5,000 or more messages a day to personal Gmail accounts in a 24-hour window, you are classified as a bulk sender and must meet all of the following.
| Requirement | What it means |
|---|---|
| SPF and DKIM | Both configured, and at least one must pass in an aligned way |
| DMARC | A published DMARC record is required, with `p=none` accepted as the minimum |
| Alignment | Your From domain must align with the passing SPF or DKIM domain |
| One-click unsubscribe | Bulk senders must honor list-unsubscribe and process opt-outs within two days |
| Spam complaint rate | Keep complaints below 0.3 percent, ideally under 0.1 percent |
The practical consequence is that DMARC went from optional to required. Before 2024 you could limp along on SPF and DKIM alone. Now a missing DMARC record means a bulk sender's mail can be throttled or rejected, and as of late 2025 those rejections are enforced rather than just warned about. For cold email this is the entry ticket to the inbox. For the deeper version, our SPF, DKIM, and DMARC setup guide for cold email walks through the records line by line.
Authentication is not a setting you flip once. It is the foundation the whole sending operation stands on, and if it cracks, nothing you write in the email body matters.
Verify and Test Your Fix
After you change a record, two things work against you: DNS propagation and your own assumptions. Confirm both before you scale back up.
DNS changes take time to spread. Most updates resolve within an hour, but some take 24 to 48 hours. Do not declare victory the second you save the record. Re-run your checker, then send a fresh test message and read the Authentication-Results header again. You want `spf=pass`, `dkim=pass`, and `dmarc=pass` on a real message, not just a clean DNS lookup.
Then watch your DMARC aggregate reports for a few days. They will tell you whether any legitimate source is still failing alignment before you tighten policy. Only after the reports come back clean should you move SPF to `-all` or DMARC to a stricter policy.
If your domain was already burned before the records were fixed, repairing authentication is necessary but not sufficient. You will likely need to rebuild sender reputation through warm-up, and our guide on fixing emails going to spam covers that recovery path.
Common Mistakes That Keep Authentication Failing
These are the errors we see most often, and each one quietly undoes an otherwise correct setup.
Two SPF records. Only one `v=spf1` record is allowed per domain. A second is an instant permerror, usually because one tool added its own record instead of editing the existing one.
DKIM at the wrong selector. The key is correct, but it sits at a selector your provider is not signing with. Match the selector exactly.
Assuming SPF alone satisfies DMARC. SPF can pass and DMARC can still fail if the SPF domain does not align with your From address. DKIM alignment is often more durable because DKIM survives forwarding, which SPF does not.
Forwarding that breaks SPF. When mail is auto-forwarded, the forwarding server becomes the sender and SPF fails. That is exactly why DMARC accepts a DKIM pass as an alternative, and why you want DKIM aligned, not just SPF.
Setting `p=reject` too early. Enforcement before your reports are clean blocks your own legitimate mail. Stage it.
Ignoring the lookup count. A record that worked yesterday can permerror today because a nested include grew past the 10-lookup ceiling. Recount periodically.
For cold email, none of this stays static. You add domains, rotate mailboxes, and swap tools, and each change can crack a record that was fine the week before. That is why we treat authentication as something to monitor, not set and forget. You can see how it fits the wider picture in our email deliverability checklist.
This is also where most cold email programs quietly bleed. The setup looks fine, but a single failing record sends a chunk of every campaign straight to spam, and nobody notices because we deliberately do not track open rates (the tracking pixel hurts deliverability). The signal you do get is a creeping bounce rate and replies drying up. When we run outbound for a client, we build and own the entire authenticated sending setup, domains, mailboxes, SPF, DKIM, and DMARC, all configured and verified before the first email goes out, and monitored so a vendor change never silently breaks alignment. The client keeps every piece of it. You can see the full scope on our services page.
Ready to send from infrastructure that passes authentication every time?
Failing SPF, DKIM, or DMARC is fixable, but it should never have broken in the first place. We build, verify, and own the authenticated sending system for our clients so your cold email reaches the inbox instead of the spam folder, with a hard bounce target under 2 percent.
Frequently Asked Questions
A strong positive reply rate for B2B cold email is 1.5–3%. Top-performing campaigns with tight targeting and personalized copy can hit 4–5%. If you're below 1%, it usually signals a deliverability or messaging problem — not a volume problem.
The safe range is 30–50 emails per inbox per day for warmed inboxes. That's why outbound systems use multiple inboxes (we use 80) — to reach 40,000+ monthly sends while keeping each inbox well within safe limits. Sending more than 50/day from a single inbox risks spam folder placement.
Yes. The CAN-SPAM Act permits unsolicited commercial email as long as you include a physical address, an unsubscribe mechanism, accurate headers, and non-deceptive subject lines. Unlike GDPR in Europe, the US does not require prior opt-in consent for B2B cold outreach.
Domain warm-up typically takes 2–3 weeks. During this period, sending volume gradually increases while the email warm-up tool generates positive engagement signals (opens, replies) to build sender reputation. Skipping or rushing warm-up is the most common cause of deliverability problems.
Cold email is targeted, relevant outreach to a specific person based on their role, industry, or company — with a clear business reason. Spam is untargeted mass messaging with no personalization or relevance. The distinction matters legally (CAN-SPAM compliance) and practically (deliverability depends on relevance signals).
Dimitar Petkov
Co-Founder of LeadHaste. Builds outbound systems that compound. 4x founder, Smartlead Certified Partner, Clay Solutions Partner.
