The email failures that never tell you
The dangerous email problems are not bounces. They are the ones where your provider accepts the message, reports success, and nobody receives anything.
Suppression lists
Providers keep a list of addresses they will not send to, usually built automatically after a hard bounce or complaint. Once an address is on it, sends to that address are accepted by the API and silently discarded.
The nasty case is your own addresses. If an internal alerting address bounces once during an outage, it can be suppressed permanently. Every alert after that reports success and goes nowhere. We lost two months of sale notifications exactly this way.
When mail is not arriving, check suppressions first. Before DNS, before spam folders, before anything. It is the fastest check and a common cause.
Domains that fall out of verification
Sending domains are verified by DNS records. Those records can be changed by someone tidying up, lost in a registrar migration, or invalidated when a provider rotates requirements.
A domain can sit in a failed state while mail still appears to flow, or while it silently degrades. Nothing announces it. Check verification status on a schedule rather than assuming that setting it up once was enough.
Receiving is separate from sending
A domain verified for sending is not necessarily configured to receive, and vice versa. A support address that was set up but never had its inbound records added will accept nothing, with no error anywhere in your systems, because no message ever reaches you to be errored on.
The only way to catch that is to test the path end to end, or to monitor the configuration itself.
Monitor it, cheaply
A daily job that checks three things and only speaks up when something changes:
- Every sending domain still verified
- None of your own addresses suppressed
- Recent bounces above a threshold
Re-raise weekly if unfixed, so a problem you ignored once does not disappear. Ours found four real problems on its first run, including an inbound address that had been dead since the day it was created.
The principle
Anything that fails by doing nothing needs a monitor, because the absence of a symptom is the symptom. Loud failures find you. Quiet ones require you to go looking on a schedule.
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.