Most engineering teams we work with monitor everything. Error rates, queue depth, p99 latency, certificate expiry, disk space on a box nobody has logged into since 2022. There is a dashboard, there is an alert, and there is a rota of people who get woken up.
Then there is email, which usually has none of that.
The reason is understandable. When your application hands a message to your sending platform, the API returns a 250ok and the job is done. Nothing failed. Your logs are clean. The send is recorded as successful and everybody moves on, because from the application's point of view the email has left the building and its fate is now somebody else's problem.
Except it isn't. That 250ok means the platform accepted the message for processing. It tells you nothing about whether Gmail put it in the inbox, dropped it in spam, or accepted it and quietly discarded it somewhere in between. There is no callback for "delivered, but nobody will ever see it".
So this is the piece that tends to be missing: not the sending infrastructure, which is usually fine, but any ongoing view of whether the mail is arriving. Here is what that view should actually contain.
Start with what your platform is not telling you
Every sending platform reports a delivery rate, and almost every one of them looks excellent. Ninety-eight, ninety-nine per cent. It is a comforting number and it is measuring the wrong thing.
Delivered means the receiving mail server accepted the connection and took the message. That is a conversation between two servers. What happens next, which is the filtering decision about whether the message goes to the inbox, the promotions tab, the junk folder, or straight into a black hole, happens after acceptance and is never reported back to the sender.
A message that lands in spam is counted as delivered. So is a message that gets accepted and silently dropped, which Microsoft in particular will do.
Your platform can tell you what it sent and what bounced. It cannot tell you where anything landed. Any monitoring worth having is built to fill that gap, and it does it by triangulating from several sources rather than trusting one number.
The five things worth watching
Reputation, at each provider separately
Sender reputation is not a single score that follows you around. Each provider forms its own view of you based on how its own users behave, which means you can have a perfectly healthy relationship with Gmail and be in real trouble at Microsoft at the same time. If you are only looking at one, you are seeing part of the picture.
For Gmail, Google Postmaster Tools gives you domain reputation and IP reputation on a four point scale of Bad, Low, Medium and High, plus a user reported spam rate and authentication pass rates. It is free, it takes about ten minutes to set up with a DNS TXT record, and it is the single most useful window any sender has into how they are seen.
For Microsoft, SNDS gives you IP level data: complaint rates, trap hits, and the filter result. It is less generous than Postmaster and considerably more awkward to access, because you need to prove control of the IP range, which you cannot do if you are on your platform's shared pool. In that case the data sits with your provider and you have to ask them for it.
Yahoo Sender Hub covers Yahoo and AOL, which is a smaller slice of most UK lists but not nothing, particularly for consumer businesses with older lists.
Then there are the outside opinions: Cisco Talos and Sender Score both publish a reputation view of your sending IPs based on data neither Google nor Microsoft will share with you. They are a useful cross check, not gospel.
Authentication, watched for drift rather than checked once
Authentication is the part everybody treats as a setup task. Configure SPF, DKIM and DMARC, confirm they pass, close the ticket.
The problem is that authentication decays quietly as the business changes around it. Marketing signs up for a new tool that sends from your domain. Somebody adds an include to the SPF record and pushes it past the ten DNS lookup limit, at which point the whole record returns a permanent error and every receiver treats it as though SPF was never configured. A DKIM key gets rotated at one provider and not at another. A subdomain gets spun up for a new product and inherits nothing.
None of that generates an alert. You find out weeks later when placement has already slipped.
This is what DMARC aggregate reports are genuinely good for, and it is a different job from the one most people set them up to do. Once you are collecting reports, you have a continuous feed of every source sending mail that claims to be from your domain, and new entries appearing in that feed is one of the earliest and cleanest signals available that something has changed. If you have not got to that point yet, the 90 day DMARC plan covers the route.
Bounces and complaints, split rather than aggregated
An aggregate bounce rate hides almost everything interesting. What you want is bounces broken down by provider and by sending stream, because that is where the shape of the problem shows up.
A hard bounce rate creeping up across all providers usually means list quality. A sudden spike at one provider only, with the rest flat, means something specific happened between you and that provider. Soft bounces and deferrals matter more than most people realise: Microsoft handing back 421 responses is not a delivery failure yet, it is throttling, and throttling is what happens immediately before blocking.
Bounce codes are where the real detail lives, and how much of it you can get varies a lot by platform. Some expose the full SMTP response. Others give you a tidy category like "invalid recipient" and throw the underlying code away, which limits what you can diagnose. Worth establishing early which camp yours falls into.
Complaint rate needs the same treatment. It is a list quality signal rather than a content one, and what it is actually telling you depends heavily on which provider is reporting it.
Blocklist status
The straightforward one. Your domain and your sending IPs should be checked against the significant blocklists on a schedule rather than when somebody notices a problem, because a listing on Spamhaus or a similar operator does its damage over days, and the recovery is faster the earlier you catch it. Our blocklist guide covers which lists actually matter and which ones you can safely ignore.
Actual placement
Everything above is a proxy. Seed testing is the closest you get to measuring the thing itself: send to a set of seed accounts across the providers your list is made of, then record where each message landed.
I will be honest about its limitations, because plenty of tools sell this as the whole answer and it isn't. Seed accounts do not behave like real subscribers. They never open, never reply, never move anything out of spam, and providers increasingly personalise filtering per user, which means a seed result tells you about the seeds rather than about your actual audience. Treat it as one data point sitting alongside reputation and complaint data, not as the score.
Where it earns its place is in showing change. If placement at Microsoft was fine in March and is failing in July, that is worth knowing, and it is much easier to act on than a vague sense that things feel worse.
The Postmaster problem nobody warns you about
Worth flagging separately, because it catches a lot of people out and there is no error message when it happens.
Google Postmaster Tools reports reputation against the domain in the d= tag of your DKIM signature, not the domain in your From address. Those are often the same thing. They are not always the same thing.
If your platform signs messages using its own domain rather than yours, which some do by default and some do when DKIM was never fully configured, then your reputation data is being filed under your provider's domain. You will add your domain to Postmaster, verify it correctly, and see nothing at all. No error, no warning, just empty charts and the reasonable conclusion that your volume must be too low to report.
So if Postmaster is showing you nothing, check the d= value in the headers of a message you have actually received before assuming anything else.
A note on Microsoft, because this is a UK problem
Most deliverability writing is American, and American consumer email skews heavily to Gmail. UK business email does not. Microsoft 365 is everywhere in UK corporate environments, which means for a B2B sender here, Outlook and Hotmail placement is frequently more commercially significant than Gmail, and it is the harder of the two to get visibility into.
Microsoft gives you less data, changes its filtering with less warning, and is much quicker to throttle a sender it does not recognise. If your customers are UK businesses and your monitoring only covers Gmail, you are watching the wrong provider carefully and the right one not at all.
The numbers that actually mean something
A few thresholds worth committing to memory.
1 - Gmail's user reported spam rate should sit below 0.10 per cent, and the number to genuinely worry about is 0.30 per cent, which is where Google's published sender requirements say you are in trouble. The gap between those two is your working margin, and it is narrower than most people assume.
2 - Domain reputation dropping from High to Medium is the signal you want to catch, because it is the one that arrives before anything visible happens to your open rates. By the time reputation reads Low, placement has already moved and you are recovering rather than preventing.
3- Deferral rates rising at a single provider is an early warning of throttling. A hard bounce rate above two per cent on a marketing send is a list quality problem, and if it is above five per cent you have a data source problem rather than a hygiene one.
The part that gets skipped: what happens when a number moves
This is where most monitoring falls over, and it has nothing to do with the tooling.
Plenty of companies have dashboards. Far fewer have decided, in advance, what anyone is supposed to do when a number on one of them changes. A signal with no defined response is not monitoring, it is decoration, and after a few months of nothing appearing to go wrong, people stop opening it.
The fix is unglamorous. For each signal you watch, write down three things: what change counts as significant, who looks at it, and what they check first.
Domain reputation drops High to Medium, for example. Significant. The first check is whether volume changed in the preceding seven days, then whether complaint rate moved, then whether any new sending source appeared in your DMARC reports, in that order, because that sequence goes from most likely cause to least. Nobody should be working that out from scratch at the point the alert fires.
The same applies to a blocklist appearance, a new SPF failure, or a deferral spike at one provider. Half an hour spent writing those down is worth more than any amount of additional data collection, and it is the difference between monitoring that changes outcomes and monitoring that documents them.
What a tool cannot do for you
Plenty of platforms will sell you the data layer, and some of them are good. What none of them will do is tell you what a change means in the context of your programme.
A tool can tell you domain reputation moved to Medium. It cannot tell you that it happened because a re-engagement send went to a segment nobody had mailed in fourteen months, that the dormant portion of your list is now dragging placement down for everybody else, or that the fix is a suppression rule rather than anything to do with your DNS. It cannot tell you that your transactional and marketing streams share a domain and that this is why a promotional send is affecting password resets.
Interpretation is the work. Data collection is the easy part, and it is the part that has been commoditised.
Where to start
If none of this exists at your company right now, do it in this order. Get Postmaster Tools connected, because it is free, it takes ten minutes, and it backfills nothing, so the sooner it starts collecting the sooner you have a baseline. Get DMARC reporting switched on, even at p=none, purely for the visibility. Then find out whether you can get SNDS access for your sending IPs, or whether you need to ask your provider for it.
That gets you most of the way to seeing what is happening. Deciding what to do about it is the harder half, and it is the reason Ongoing Monitoring exists as a service rather than a dashboard login.
If you want a read on where your setup stands today before committing to any of it, run the free health check. You send one email, you get an immediate report on your authentication and reputation signals, and there is no sign up. If the results raise questions, that is exactly what the free check-up call is for.
