Nothing is more frustrating than a campaign that looks perfect and lands in spam anyway, or worse, gets rejected before it reaches anyone. Most of the time the problem isn’t your subject line or your list. It’s a broken authentication record sitting quietly in your DNS, failing every send while you stare at your open rates wondering what went wrong. The stakes went up sharply, too: Gmail, Yahoo, and Microsoft now reject unauthenticated bulk mail instead of just filtering it. Here are the seven SPF, DKIM, and DMARC errors that break bulk sends most often, what each one does to your deliverability, and how to fix it.
You don’t need to be a mail administrator to catch these. Most are visible in a free authentication checker or your DMARC reports, and the fixes are DNS edits you make once. Work down the list and rule out each one.
The Short Version
The errors that break bulk email most often are a missing SPF record, an SPF record that exceeds the 10 DNS lookup limit, more than one SPF record on the domain, DKIM that was never set up, a broken DKIM selector or key, a missing or invalid DMARC record, and DMARC alignment failures where SPF or DKIM technically pass but don’t match your From domain. Any one of these can send your mail to spam or get it rejected, especially now that major providers enforce authentication on bulk senders.
Why these errors hurt more in 2026
This used to be a deliverability nuisance. Now it’s a hard wall. Following rules that Google and Yahoo rolled out in 2024, senders of large volumes must authenticate with SPF, DKIM, and DMARC, and unauthenticated bulk mail is rejected rather than quietly filtered. Google’s sender guidelines spell out the requirements, which apply once you send around 5,000 messages a day to Gmail, along with a low spam-complaint rate and one-click unsubscribe. A broken record no longer just costs you the inbox. It can cost you the delivery entirely.
Common Authentication Errors at a Glance
| Error | What it breaks | The fix |
|---|---|---|
| No SPF record | Sender IPs can’t be verified | Publish one SPF record |
| Over 10 SPF lookups | SPF PermError, counts as fail | Consolidate includes |
| Multiple SPF records | Breaks SPF entirely | Merge into a single record |
| No DKIM | No cryptographic signature | Enable DKIM, publish the key |
| Broken DKIM key | Signature can’t be verified | Fix the selector and key |
| No DMARC record | Fails provider requirements | Publish a DMARC record |
| DMARC misalignment | Passes SPF/DKIM but fails DMARC | Align the From domain |
1. You have no SPF record at all
SPF, the Sender Policy Framework, is a DNS record listing the servers allowed to send email for your domain. Without one, a receiving server has no way to confirm that the machine sending your campaign is authorized, so the message looks suspect from the start. This is the most basic failure, and it’s common when a business starts using an email platform and never adds that platform to its SPF. The fix is to publish a single SPF TXT record that names your sending services, ending with a policy like ~all or -all. It’s the foundation everything else builds on.
2. Your SPF record exceeds the 10-lookup limit
SPF is capped at 10 DNS lookups when a receiver evaluates it, a hard limit set by the standard. Terms like include, a, mx, and redirect each count, and they nest, so pulling in a few email platforms can quietly push you over. When that happens, the receiver returns a PermError, and DMARC treats that permanent error as an SPF failure, per the SPF specification in RFC 7208. The maddening part is that your record can look completely valid while still failing. The fix is to trim it: remove services you no longer use, consolidate providers, and if you’re still over, use an SPF flattening service that replaces nested includes with the underlying IP addresses.
3. You have more than one SPF record
A domain is allowed exactly one SPF record, and this trips up more people than you’d expect. When you add a second email service, it’s easy to publish a second SPF record instead of editing the first. The result isn’t that both apply; it’s that authentication breaks entirely, returning a PermError for every message from the domain, even if each record is perfectly valid on its own. The fix is to combine all your sending sources into a single SPF record with multiple include statements, then delete the extras. Check your DNS for stray SPF entries whenever you add a new sender.
4. DKIM was never set up
DKIM, DomainKeys Identified Mail, adds a cryptographic signature to every message so the receiver can confirm it wasn’t tampered with and came from your domain. Plenty of senders configure SPF and stop there, leaving DKIM off, which now fails the major providers’ requirements for bulk mail. Setting it up means generating a key pair through your email platform, then publishing the public key as a TXT record at the selector your platform gives you. Once it’s live and signing, receivers can verify your mail cryptographically, which is a stronger signal than SPF alone and a required one for large sends.
5. Your DKIM selector or key is broken
Having DKIM configured isn’t enough if the record behind it is wrong. Each signature points to a selector, a label that tells the receiver which DNS record holds the public key. If the selector doesn’t match, the key was published incorrectly, or you rotated keys and never updated DNS, verification fails and the signature is worthless. Keys that are too short can be rejected too, so aim for a 2048-bit key. After any key rotation or platform change, confirm the published record matches what your service is signing with. A quick DKIM check after every change saves you from silent failures.
6. You have no DMARC record, or a broken one
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails. The major inbox providers now require a DMARC record for bulk senders, so having none means failing that requirement outright, and a record with a syntax mistake is ignored, which amounts to the same thing. The fix is to publish a valid DMARC record at _dmarc on your domain, starting with a policy of p=none plus a reporting address so you can see what’s passing and failing. Once your legitimate mail authenticates cleanly, you tighten the policy toward quarantine or reject. Starting at none keeps you from blocking your own mail before you’re ready.
7. Your DMARC alignment fails
This is the subtle one that catches careful senders. DMARC checks more than whether SPF or DKIM passed. It also requires that the domain they authenticate line up with the domain in your visible From address. An email platform often sends using its own return-path or signing domain, so SPF and DKIM can pass for that platform’s domain while failing to align with yours, and DMARC fails anyway. The result is a message that looks authenticated on paper but doesn’t satisfy DMARC. The fix is to set up a custom return-path and DKIM signing domain that match your From domain, a step most email platforms support and call domain authentication or a custom sending domain.
How We Chose These
We focused on the failures that most often break real bulk sends, rather than every possible misconfiguration, and on the ones that a marketer or small-business owner can find and fix without a mail engineer. Each error here maps to a specific, checkable cause in your DNS or your email platform, and each has a concrete fix. We weighted the list toward problems that the new provider rules turned from minor to serious, since those are the ones now costing senders actual delivery rather than just inbox placement.
The Bottom Line
When bulk email stops landing, resist the urge to blame the content first. Check authentication. Confirm you have one clean SPF record under the 10-lookup limit, DKIM signing with a matching key, and a valid DMARC record whose alignment holds against your From domain. Your DMARC reports will show you which piece is failing and for which mail, so you’re fixing the real problem instead of guessing. Spend an afternoon getting these right once, and your deliverability stops being a mystery. For more on running the operational side of a business, our business section has related guides, and the technology section covers the tools behind them.
Frequently Asked Questions
What are the most common SPF, DKIM, and DMARC errors?
The frequent ones are having no SPF record, an SPF record that exceeds the 10 DNS lookup limit, more than one SPF record on a domain, DKIM that was never enabled, a broken DKIM selector or key, a missing or malformed DMARC record, and DMARC alignment failures where SPF or DKIM pass but don’t match your From domain. Each can send bulk mail to spam or get it rejected, and most are visible in a free authentication checker or your DMARC reports.
Why does my SPF record fail with “too many DNS lookups”?
SPF is limited to 10 DNS lookups during evaluation, and terms like include, a, and mx each count, nesting as they resolve. Adding several email platforms can push you past the limit, which returns a PermError that DMARC treats as a failure, even though the record looks valid. Fix it by removing unused services, consolidating providers, or using an SPF flattening tool that replaces nested includes with their IP addresses to stay under the cap.
Can I have two SPF records for two email services?
No. A domain must have exactly one SPF record. Publishing a second one causes a PermError that breaks authentication for every message from the domain, even if each record is valid by itself. To authorize multiple services, combine them into a single SPF record using several include statements, then remove any extra SPF entries from your DNS. This is a common mistake when adding a new sending platform.
What does a DMARC alignment failure mean?
DMARC requires that the domain verified by SPF or DKIM match the domain in your visible From address. When an email platform sends using its own return-path or signing domain, SPF and DKIM can pass for that domain while failing to align with yours, so DMARC fails despite the passes. The fix is to configure a custom return-path and DKIM signing domain that match your From domain, often called domain authentication in your platform’s settings.
Do I really need DMARC to send bulk email?
For large volumes, yes. The major inbox providers now require SPF, DKIM, and a DMARC record from bulk senders, and mail that doesn’t meet the bar can be rejected outright. Beyond compliance, DMARC protects your domain from spoofing and gives you reports showing exactly how your mail authenticates. Start with a monitoring policy of p=none, confirm your legitimate mail passes, then tighten toward quarantine or reject over time.
