The postmortem was uncomfortable. A senior engineer had pushed code that sent password reset emails to the wrong users. Not random users—the previous user in the database query. A missing WHERE clause meant each reset email went to the user before the one who requested it. Thousands of emails, all to the wrong people.
The fix took five minutes. The incident response took five days. The trust recovery took months.
Email mistakes are uniquely painful because they're visible to users, often irreversible, and can have legal or security implications. These are the mistakes that keep showing up in postmortems, support tickets, and late-night debugging sessions.
Authentication mistakes
1. Forgetting to update SPF when adding new services. You add a new marketing tool, it starts sending email, and suddenly your emails fail SPF. Every service that sends email as your domain needs to be in your SPF record. Maintain a list of authorized senders and update SPF when it changes.
2. Using ~all instead of -all in SPF. Soft fail (~all) tells receiving servers "this might not be authorized, but don't reject it." It provides monitoring but not protection. Use hard fail (-all) once you've verified all legitimate senders are authorized.
3. Not monitoring DMARC reports. You set up DMARC with p=none to collect reports, then never look at them. The reports show authentication failures and unauthorized senders—valuable information that's useless if ignored. Use a DMARC analyzer service to make reports actionable.
4. Exceeding the SPF 10-lookup limit. Each include in your SPF record triggers DNS lookups. Exceed 10, and your entire SPF record is invalid. As you add services, you hit this limit faster than expected. Use SPF flattening or subdomains to stay under the limit.
Sending mistakes
5. Sending to the wrong recipients. The classic mistake: a test email goes to production users, or a segment filter is wrong, or a database query returns unexpected results. Always verify recipient lists before sending, especially for large campaigns. Use seed lists and spot-checks.
6. Not handling bounces. Hard bounces mean the address is permanently invalid. Continuing to send to bounced addresses hurts your reputation and wastes resources. Implement bounce handling that removes hard bounces immediately and tracks soft bounces for eventual removal.
7. Ignoring rate limits. ESPs and receiving servers have rate limits. Exceed them, and your emails get throttled or rejected. Implement proper queuing and respect rate limits. Sudden volume spikes also trigger spam filters—ramp up gradually.
8. Sending from a no-reply address. [email protected] tells recipients you don't want to hear from them. It prevents replies that might contain valuable feedback or indicate delivery problems. Use a monitored address, even if you route replies to a ticketing system.
Content mistakes
9. Broken personalization. When merge tags fail, recipients see {{first_name}} or worse, another user's data. Always set fallback values for personalization. Test with missing data to see what recipients actually receive.
10. Untested HTML rendering. Your email looks perfect in Gmail. It's broken in Outlook. Email HTML is not web HTML—it requires tables for layout, inline styles, and careful testing across clients. Use preview tools before sending.
11. Missing plain text version. Some recipients prefer plain text. Some spam filters penalize HTML-only emails. Always include a plain text alternative that's actually readable, not just a dump of the HTML content.
12. Broken links. Links that 404, redirect loops, or point to staging environments. Click every link before sending. Automate link checking in your pre-send process.
Infrastructure mistakes
13. Hardcoding SMTP credentials. Credentials in code end up in version control, logs, and error messages. Use environment variables or secrets management. Rotate credentials if they've ever been exposed.
14. No retry logic for transient failures. SMTP connections fail. Servers return temporary errors. Without retry logic, these transient failures become permanent delivery failures. Implement exponential backoff and retry for recoverable errors.
15. Synchronous email sending. Sending email in the request/response cycle makes your application slow and fragile. If the email server is slow or down, your application is slow or down. Use a queue for email sending—accept the request, queue the email, return immediately.
The meta-mistake
The biggest mistake is treating email as simple. "Just send an email" sounds trivial until you're debugging deliverability issues at 2 AM, explaining to legal why unsubscribe doesn't work, or telling customers their password resets went to strangers.
Email is a distributed system with unreliable components, inconsistent implementations, and high stakes. Treat it with the same rigor you'd apply to any critical system: testing, monitoring, error handling, and incident response.
Prevention strategies
Checklists. A pre-send checklist catches obvious mistakes before they reach recipients. Make it mandatory, not optional.
Testing environments. Never test with production data or production recipients. Use dedicated test environments with fake data and internal addresses.
Staged rollouts. For large campaigns, send to a small percentage first. Verify everything works before sending to the full list.
Monitoring. Track delivery rates, bounce rates, and complaint rates. Anomalies indicate problems—catch them early.
Code review. Email-related code changes deserve extra scrutiny. A bug in email code affects users directly and visibly.
Incident response. Know what to do when email goes wrong. Who can stop a campaign mid-send? How do you communicate with affected users? Plan before you need it.
Frequently asked questions
What's the most common email mistake you see?
Broken personalization and sending to wrong recipients are the most common high-impact mistakes. They're visible to users and often embarrassing. Authentication misconfiguration is the most common low-visibility mistake—it silently hurts deliverability without obvious symptoms.
How do I prevent sending test emails to production users?
Use separate environments with separate recipient lists. Implement safeguards in code that prevent production sends from non-production environments. Some teams use email interception in non-production environments to catch all outgoing email.
What should I do if I send an email to the wrong people?
First, stop any ongoing sends. Then assess the impact—what information was exposed? who was affected? Communicate transparently with affected users. Document the incident and implement preventive measures. For serious incidents, involve legal and security teams.
How do I know if my emails are actually being delivered?
Delivery rate (accepted by receiving servers) is a start but doesn't guarantee inbox placement. Monitor open rates for sudden drops. Use seed list testing to check actual inbox placement. Set up Google Postmaster Tools for Gmail-specific insights.