What if the reason your emails land in spam has nothing to do with your content, and everything to do with a single misplaced character in a DNS record?
That scenario plays out more often than most senders realize. Email authentication (SPF, DKIM, and DMARC) is the technical backbone that tells receiving servers whether a message really came from you. When it’s configured correctly, it’s invisible. When it’s wrong, legitimate mail gets filtered, spoofed mail gets through, and marketing teams spend weeks blaming subject lines for a problem buried in a TXT record.
This guide walks through the mistakes that trip up everyone from solo newsletter writers to IT teams at mid-size companies. It covers what goes wrong, why it matters, and what actually fixes it.
Why Authentication Errors Are So Easy to Miss
Authentication failures rarely announce themselves. A misconfigured SPF record doesn’t throw an error in your inbox. It quietly causes a handful of messages to fail at Gmail or Microsoft 365, and you only notice when open rates dip or a customer says “I never got your invoice.”
The stakes are higher than most people assume. Major mailbox providers now use authentication results as a primary filtering signal. According to the RFC 7208 specification for SPF, receivers evaluate sender IPs against published records, and a failed check often means rejection or spam placement. Meanwhile, the DMARC specification in RFC 7489 gives domain owners a way to publish policy, but only if the underlying SPF and DKIM checks actually align.
Here’s the uncomfortable truth: most authentication mistakes come from copying a record from a blog post, adding a new sending tool, and never revisiting the setup. Records drift out of date fast.
SPF Mistakes That Break Legitimate Mail
SPF is the oldest of the three protocols, and it’s also the one people break most casually.
The Ten-Lookup Limit Nobody Reads About
SPF evaluation allows a maximum of 10 DNS lookups. Every `include:`, `a`, `mx`, `ptr`, and `exists` mechanism counts toward that ceiling. Once you exceed it, receivers return a `permerror`, which most treat as a fail.
The classic failure mode: a company signs up for a CRM, a transactional email provider, a survey tool, and a helpdesk. Each one adds an `include:` statement. By the fifth vendor, the record is over the limit and all mail starts failing. The fix is to flatten the record, consolidate providers, or use a service that resolves includes into static IPs.
Using `+all` or a Bare `all`
An SPF record ending in `+all` authorizes every server on the internet to send mail as your domain. It’s the equivalent of leaving your front door open with a sign that says “welcome.” A bare `all` does the same thing.
The safer pattern is `~all` (softfail) during rollout and `-all` (hardfail) once you’re confident. Many teams leave `~all` in place forever, which is a reasonable compromise, but `+all` is never acceptable.
Forgetting That Forwarding Breaks SPF
SPF checks the envelope sender and the connecting IP. When a recipient forwards mail, the forwarding server’s IP no longer matches your record. This is a structural limitation, not a configuration bug, but it explains a huge share of “why is my mail failing?” tickets. DKIM is the mitigation here, since a signed message survives forwarding if the body isn’t altered.
DKIM Mistakes That Silently Invalidate Signatures
DKIM attaches a cryptographic signature to each message. If anything in the signed content changes in transit, the signature breaks. That’s by design, but it creates traps.
Signing With `simple` Canonicalization
DKIM offers two canonicalization modes: `simple` and `relaxed`. The `simple` mode is strict, meaning any whitespace change or header rewrite invalidates the signature. Since almost every mail system rewrites headers (adding `Received` lines, modifying `Subject`), `simple/simple` signatures break constantly.
The practical fix is `relaxed/relaxed`, which tolerates benign modifications. As documented in RFC 6376, canonicalization determines exactly which parts of the message are hashed, so choosing the wrong mode is a guaranteed source of failures.
Weak Keys and Stale Crypto
RFC 8301 raised the minimum DKIM key size to 1024 bits and recommended 2048 bits, while deprecating SHA-1 for signing. Plenty of domains still run 1024-bit keys or SHA-1 signatures because nobody rotated them. Rotating keys annually and using 2048-bit RSA (or Ed25519 where supported) is the standard practice now.
Signing the Wrong Domain
DKIM signatures must align with the From domain for DMARC to pass. If your ESP signs with its own bounce domain instead of yours, DKIM technically passes but DMARC alignment fails. Always confirm that your provider signs as your domain, not theirs.
DMARC Mistakes That Leave the Door Open
DMARC is the policy layer. It tells receivers what to do when SPF and DKIM both fail or fail to align. It’s also where the most consequential mistakes live.
Leaving `p=none` Forever
The `p=none` policy means “monitor only, don’t act.” It’s the correct starting point, because it lets you collect reports without risking legitimate mail. The mistake is never moving past it. Organizations that stay on `p=none` for years remain fully spoofable, which defeats the purpose of deploying DMARC at all.
A sane progression looks like this:
- Start at `p=none` and collect aggregate reports for four to six weeks.
- Identify every legitimate sending source from the reports.
- Move to `p=quarantine` with a low percentage, such as `pct=25`.
- Increase gradually to `pct=100`.
- Move to `p=reject` once reports show clean alignment.
| Policy | Effect | When to use |
|---|---|---|
| `p=none` | Monitor only | Initial rollout, discovery phase |
| `p=quarantine` | Send failing mail to spam | After sources are mapped |
| `p=reject` | Block failing mail outright | Once alignment is stable |
Misunderstanding Alignment
This trips up nearly everyone. DMARC requires that either SPF or DKIM align with the From domain. Passing SPF on `bounce.yourprovider.com` does nothing for `yourcompany.com`. Alignment can be relaxed (organizational domain match) or strict (exact match), and the default is relaxed.
If your reports show SPF passing but DMARC still failing, alignment is almost always the culprit.
Broken or Missing Reporting Addresses
DMARC records use `rua` for aggregate reports and `ruf` for forensic reports. A common error is pointing `rua` at an address that doesn’t exist or rejects mail. You get zero visibility and never know it. Aggregate reports arrive as XML attachments, which are unreadable without a parser, so many teams collect them and never look.
Publishing the Record in the Wrong Place
The DMARC record belongs at `_dmarc.yourdomain.com` as a TXT record. Publishing it at the root, or at a subdomain when you meant the parent, produces no effect. A quick DNS lookup confirms whether the record is live and syntactically valid.
Mistakes That Span All Three Protocols
Some errors don’t belong to one protocol. They come from how teams manage authentication overall.
Adding a New Sender and Forgetting the Records
The most common real-world failure: marketing signs a contract with a new email platform on Monday, campaigns launch Wednesday, and nobody updates SPF or DKIM. Mail fails silently for weeks. The fix is a process, not a technical tweak. Any new sending tool should trigger a checklist item: add SPF include, configure DKIM signing, verify alignment in DMARC reports.
No Inventory of Sending Sources
You cannot authenticate what you don’t know exists. Subdomains, legacy apps, developer laptops sending via SMTP, and forgotten form handlers all send mail as your domain. A sending-source inventory is boring work and prevents most surprises.
Skipping the Human Layer
Technical controls only go so far. Attackers still spoof display names, and employees still click things. Pairing authentication with multi factor authentication on mail accounts and admin consoles closes a different gap: account takeover. If an attacker logs into your actual mailbox, SPF and DMARC won’t save you, because the mail is genuinely from you.
Teaching staff to spot suspicious messages matters too. A short internal guide on how to identify a scam email reduces the chance that a spoofed message gets acted on before anyone checks headers. For teams rolling out stronger login controls, how to enable two factor authentication covers the practical steps. (Email authentication)
Ignoring Subdomain Policy
DMARC’s `sp` tag sets policy for subdomains. If you leave it unset, subdomains inherit the main policy, which is usually what you want. But many organizations have subdomains sending mail that was never authenticated, so a strict main policy suddenly breaks them. Audit subdomains before tightening.
Practical Tips That Actually Work in the Field
After enough broken deployments, patterns emerge. These are the habits that separate clean setups from chronic problems.
Check records before you change them. Run a lookup on your SPF and DMARC records first. Half of “fixes” introduce new errors because nobody recorded the starting state.
Use `pct` to stage DMARC changes. Ramping from 25 to 50 to 100 percent catches problems without blocking all mail at once.
Test with real sends, not validators alone. Online SPF checkers confirm syntax. They don’t confirm that your CRM’s actual sending IP is covered. Send a real message to a Gmail address and inspect the full headers.
Document every sender. A shared spreadsheet listing each tool, its sending domain, and its authentication method saves hours during the next audit.
Rotate DKIM keys on a schedule. Annual rotation with overlapping validity prevents the “old key still in DNS” problem.
Watch for screenshot-worthy errors in support tickets. When a user reports a missing email, ask for the full headers. Learning how to take a screenshot on windows or how to take a screenshot on a mac makes that exchange faster for everyone involved.
Don’t neglect the login side. Strong authentication on the accounts that control DNS and email admin panels is part of the same defense. Biometric authentication is increasingly available on admin devices and adds a layer that passwords alone can’t provide.
How Authentication Fits Into a Broader Defense
Email authentication is necessary but not sufficient. It stops domain spoofing, which is a large category of phishing, but it doesn’t stop lookalike domains, display-name spoofing, or compromised legitimate accounts.
Government guidance reflects this layered view. The U.S. Cybersecurity and Infrastructure Security Agency has pushed federal agencies toward strict DMARC enforcement through binding operational directives, and the broader pattern is clear: authentication is table stakes, not a complete solution. Pair it with employee training, account monitoring, and a reporting channel for suspicious mail.
The organizations that get this right treat authentication as a living system. Records get reviewed quarterly. New tools trigger a checklist. Reports get parsed by a tool rather than ignored in a mailbox. None of that is glamorous, and all of it works.
Conclusion
Most email authentication failures aren’t exotic. They’re a `+all` that should have been `-all`, an SPF record three includes past the limit, a DKIM signature using `simple` canonicalization, or a DMARC policy stuck on `p=none` since 2019. Each one is fixable in an afternoon once you know where to look.
The pattern behind all of them is the same: authentication gets configured once and then forgotten while the sending environment changes around it. Treat SPF, DKIM, and DMARC as records that need maintenance, not a one-time setup task. Audit your sources, stage your policy changes, parse your reports, and keep the human layer strong with multi-factor authentication and basic phishing awareness.
Do that, and the question stops being “why is my email in spam?” and starts being “why did we wait so long to fix this?”
Frequently Asked Questions
What is the most common email authentication mistake?
The single most common mistake is exceeding the 10-DNS-lookup limit in SPF by stacking too many `include:` statements. It happens gradually as teams add sending tools, and it causes a `permerror` that receivers treat as a failure, so legitimate mail starts getting filtered without any obvious warning.
Does DMARC work if SPF and DKIM both pass on a different domain?
No. DMARC requires alignment between the From domain and the domain that passed SPF or DKIM. If your provider passes SPF on its own bounce domain, DMARC still fails. Either configure DKIM signing on your own domain or adjust your setup so at least one check aligns.
How long should a domain stay on `p=none`?
Long enough to collect meaningful aggregate reports, typically four to six weeks, and no longer. Once you’ve identified all legitimate sending sources, move to `p=quarantine` with a low `pct` value and ramp up. Staying on `p=none` indefinitely leaves the domain fully spoofable.
Why does my DKIM signature fail after forwarding?
Forwarding often modifies message headers or body content, which breaks the hash the signature covers. Using `relaxed/relaxed` canonicalization reduces the problem, but some forwarders still alter content. This is why DMARC accepts a pass from either SPF or DKIM rather than requiring both.
Can I use a 1024-bit DKIM key?
Technically yes, but it’s below current best practice. RFC 8301 set 1024 bits as the minimum and recommended 2048 bits, and it deprecated SHA-1 for signing. Rotating to a 2048-bit key with SHA-256 is the standard approach and avoids interoperability issues with strict receivers.
What happens if my DMARC reporting address is broken?
Nothing visible, which is the problem. Aggregate reports simply bounce or get discarded, so you lose all visibility into who is sending as your domain and whether alignment is working. Verify that your `rua` address accepts mail and use a parser to actually read the XML reports.
