Rules
Part of The honest guide to email deliverability
8 email deliverability mistakes that hide the real problem
Eight email deliverability mistakes, from confusing acceptance with inbox placement to suppression gaps, plus containment, correction and authentication checks.
What to take away
- Most expensive mistakes hide the sender, recipient source, identity path, denominator, or recent change.
- Authentication supports identity; it does not prove permission, safety, relevance, or inbox placement.
- Rotating domains or infrastructure to evade filtering preserves the cause and creates new operational risk.
Email deliverability mistakes become expensive when teams react to a weak metric without identifying the provider, stream, and failure type. Preserve responses, dashboards, DNS, messages, list sources, versions, and timelines before changing production. Pause harmful or compromised traffic first.
1. Calling acceptance inbox placement
A high delivery rate is presented as inbox proof. Define attempted, accepted, deferred, rejected, bounced, inbox, and spam populations. State what the platform can and cannot observe.
2. Missing hidden senders
A forgotten sales, survey, support, or product tool affects a shared identity. Maintain a sender inventory with owners, domains, IPs, vendors, streams, permissions, and volume.
3. Treating authentication as permission
The Australian Cyber Security Centre's malicious-email mitigation guidance treats sender verification as one layer among attachment, body, filtering, logging, and operational controls, and warns that implementation can disrupt legitimate mail. Passing authentication is therefore not evidence that recipients requested a marketing message.
SPF, DKIM, and DMARC identify authorized or aligned mail; they do not prove recipients wanted it. Stop purchased, harvested, appended, deceptive, or repurposed audience practices.
4. Publishing DNS without path testing
The U.K. Government Security DMARC multiple-policy finding states that only one DMARC record is permitted for a domain and that multiple records cause the policy to be ignored. Test the exact published DNS result and live authenticated message path instead of assuming a saved configuration is effective.
Records appear valid while production signatures, alignment, forwarding, return paths, or vendor routes fail. Test representative messages end to end and monitor real results.
5. Mixing unrelated risk
Promotions, receipts, alerts, and user-generated mail share unmanaged infrastructure. Separate purpose and risk where useful, while keeping central ownership, suppression, and monitoring.
6. Changing volume abruptly
A launch, migration, or seasonal peak sends a sudden spike. Use expected traffic, monitored stages, response-based pacing, pause thresholds, and an accountable operator.
7. Allowing suppression gaps
Withdrawn, complained, invalid, or excluded addresses return through imports, backups, queues, or disconnected systems. Test one suppression truth across all promotional paths.
8. Rotating infrastructure to escape filters
New domains or IPs hide symptoms briefly and destroy evidence. Diagnose permission, security, identity, traffic, content, and operational causes; follow provider remediation and restart carefully.
After a failure, identify affected recipients and necessary communications, stop unsafe traffic, correct the root cause, secure access, reconcile suppression, and validate recovery on a small cohort. Document the decision and watch normal volume before declaring the incident resolved. Keep the previous configuration available for controlled comparison and rollback. Assign a named reviewer to approve the restart.
Mistake containment map
| Mistake | Early signal | Containment |
|---|---|---|
| Unknown sender | Unmapped From or return path | Pause and identify owner |
| Mixed traffic | One stream harms another | Separate by purpose and risk |
| Volume shock | Provider-specific deferral | Stabilize and verify demand |
| Suppression gap | Repeat mail after request | Stop affected sends |
Prove the correction
The GAO data reliability guide treats reliability as fitness for an intended use and requires documented assessment. Use that test for email deliverability mistakes; the federal guide does not certify the local data.
The FTC advertising substantiation policy requires a reasonable basis before objective advertising claims are disseminated. Apply that U.S. rule to public email deliverability mistakes performance statements, with advice for the actual facts.
Common questions
What is the most common measurement mistake?
Calling accepted messages inboxed messages. Preserve the exact event definition, provider scope, time window, numerator, denominator, and exclusions.
Can a new domain reset deliverability?
It can reset some history, but it does not create permission, relevance, secure operations, or trust. Evasion can also violate provider policies and fragment control.
When should sending stop?
Stop or narrow the affected stream when continued sending could worsen unwanted mail, security harm, suppression failure, customer impact, or an unexplained provider incident.
