What to monitor on a transactional email sender, and what to actually alert on

Most infrastructure fails loudly. A database goes down and every request errors. A certificate expires and every browser complains. Email is the exception: a sender can be badly broken for a month while every send call returns success, because the send call only measures the handoff to a relay, and everything that matters happens after it.

The monitoring has to be designed for that. It has to look for silence and for slow drift, not for errors, because the errors mostly do not exist.

The four things to alert on

An alert is a page. It should fire when something has happened that a person needs to act on today. Four signals meet that bar for a transactional sender.

1. Complaint rate above 0.1%. Complaints are recipients marking your mail as spam, reported back through feedback loops and visible in the complained events from your relay. The receivers publish 0.3% as the level at which they start filtering a sender and 0.1% as the target. For transactional mail, where every message was requested, the rate should sit near zero, and crossing 0.1% means a specific thing is going wrong: a notification people did not want, a template that looks like phishing, or a stream that is not transactional at all. Measure it as complaints divided by messages delivered, per sending domain, over a rolling day.

2. Hard bounce rate above 2%. Every address in a transactional system came from a person typing it, so hard bounces should be rare. A jump means an import, a form that stopped validating, or a retry loop hitting suppressed addresses. Any of those is doing reputation damage by the hour. Measure as failed events over sends, per day.

3. Volume of zero where it should not be. The most damaging email outage is the one where nothing is sent at all: a queue worker died, a credential was rotated, a deploy broke the mailer, and the send call now fails before it reaches the relay, or never runs. Nobody notices because nothing errors at the relay, since the relay never heard from you. Alert on zero sends over a window that would normally have some, scaled to your traffic. For a busy application, fifteen minutes. For a quiet one, a few hours.

4. An authentication or reverse DNS record that stops verifying. SPF, DKIM, DMARC and forward-confirmed reverse DNS are checked by every receiver on every message and by you, typically, once at setup. They rot: a DNS clean-up, a provider migration, an IP reassignment. Re-resolve the records daily and alert on any change from the known-good state. This is the cheapest check in the list and the one most often absent.

The five things to watch

These belong on a dashboard someone looks at weekly. They drift rather than break, and the right response is investigation rather than a page.

5. Delivery latency, p95, by receiving domain. Request to delivered, as a distribution. A rising p95 at one receiver is greylisting or a scoring hold, which is a reputation signal at that receiver. A rising p95 everywhere is your own queue. The magic link post covers why this is the metric rather than the average.

6. Deferrals by receiving domain. Temporary 4xx responses, especially 4.7.x codes about rate or reputation. A receiver deferring your mail is a receiver that is about to start filtering it, and the deferrals arrive days before the placement changes. Group by domain; a problem at one large receiver looks like a small blip in the total.

7. Suppression list growth. The suppression list should grow slowly and steadily. A step change means a bounce storm, and a bounce storm has a cause worth finding. It is also worth knowing how many addresses are on it, because a support ticket saying “I never get your emails” is answered by looking there first.

8. DMARC aggregate report failures. Run the reports through a parser and look, weekly, for two things: a source you do not recognise sending as your domain, and a known source whose alignment pass rate has fallen. The DMARC reports post covers reading them.

9. Blocklist status. Check the sending IPs and the sending domain against the major DNS blocklists daily. A listing is rare for a well-run transactional sender and immediately damaging when it happens. Most providers check their own IPs; check your domain yourself, since a listing there follows you.

Two things not to bother with

Open rate. Open tracking measures whether a tracking pixel loaded, which since 2021 has been decided mostly by mail clients prefetching images rather than by people. For transactional mail it is noise. Delivery, latency and complaint rate tell you what you need.

Per-message success. Alerting on individual failed sends produces an alert every time someone typos an address. Aggregate to rates, and let suppression handle the individual case.

Where the data comes from

Almost all of the above derives from the event stream a relay emits: accepted, delivered, failed, complained, with timestamps and the receiving domain. Feed the webhook into whatever you already use for metrics and the rates fall out. The exceptions are the DNS checks, which are two dig commands per record on a schedule, and the DMARC reports, which arrive by mail and need a parser.

Nothing here needs a dedicated tool. It needs someone to decide the thresholds and wire the four alerts. The reason most senders do not have them is not difficulty; it is that nothing ever told them the sender was broken.

Where Pharos fits

Pharos emits the full event stream as signed webhooks and keeps it in a queryable log, so the rates above are a small amount of arithmetic on data you already receive. The sending domain’s four records are re-verified daily and reverse DNS is re-scanned across the sending set daily, which covers the fourth alert without you scheduling it. The suppression list is per account, visible and exportable, and a complaint rate above 0.1% is the line the acceptable use policy holds every account to.