# Monitoring Mail Servers & DKIM: Reachability No Browser Check Sees

> Why a reachable website ≠ working mail, and how SMTP/IMAP monitors and auth-record checks (DKIM, SPF) catch delivery problems early.

Source: https://uptimeify.io/blog/mail-server-dkim-monitoring

The client's website is green, monitoring reports 100% uptime, and yet the client calls: "We haven't been getting any emails since this morning." How can that be, if everything's "online"? The answer lies in a common blind spot: **a reachable website doesn't mean the mail works.** Website and mail server are separate services, and an ordinary browser check simply sees nothing of the mail side. This article explains why that's so, how SMTP and IMAP monitors close this blind spot, and why authentication records like DKIM belong in your monitoring too.

- **Website reachable ≠ mail works.** They're separate services; an HTTP check says nothing about the mail server.
- **SMTP monitors check outbound sending**, IMAP/POP monitors check mailbox access, the reachability no browser check sees.
- **Auth records (DKIM, SPF) are DNS entries** whose silent change tips delivery over, monitorable against a target value.
- **This angle is reachability & configuration**, not spam/blacklist. That's a separate, complementary topic.
- **For agencies:** mail outages are often more business-critical for clients than a brief website outage.

## Why a website check doesn't see the mail

The fallacy starts with an understandable simplification: "The domain is online, so everything's running." But behind a domain hide several independent services that need have nothing technically to do with one another. The web server that serves `yourclient.com` in the browser is a different service from the SMTP server that sends this domain's emails, and different again from the IMAP server through which mailboxes are retrieved. Often they run on different systems, sometimes even at different providers.

A website monitor asks exactly one thing: does the web server respond with a valid page? That's a valuable question, but it's a question about the *web* service, and only it. The mail server can, in that same moment, be crashed, overloaded, or misconfigured without the website check so much as twitching. It simply doesn't look there. For the entire mail side of a domain, pure web monitoring is blind.

And this blind spot is dangerous because it's invisible. A website outage announces itself: visitors complain, monitoring fires. Dead mail sending often stays silent for days, because no one actively "tests" whether emails are going out right now. You notice it only when an expected mail fails to arrive or a client wonders why they got no reply. By then the damage is long done.

Website and mail server are separate services. An HTTP check only answers "is the website up?" It says nothing about the mail server. Monitor only the website and you have an invisible blind spot for all of mail.

## Checking reachability: SMTP and IMAP monitors

The fix is to check the mail server just as directly as the web server, only with the right protocol. Instead of loading a web page, a protocol monitor connects to the mail server itself and checks whether it responds as expected. Two monitor types cover the two directions of mail.

**The SMTP monitor** checks the outbound path. SMTP (Simple Mail Transfer Protocol) is the protocol over which mail is sent. An SMTP monitor opens a connection to the server's SMTP port at short intervals, typically port 587 for authenticated sending, and checks whether the server accepts the connection and responds correctly. If it doesn't, outbound mail is impaired and you're alerted. That exact check would have caught the dead sending in the opening example immediately, instead of the client noticing hours later.

**The IMAP/POP monitor** checks the inbound path, more precisely, access to the mailboxes. IMAP and POP are the protocols mail programs use to retrieve mailboxes. An IMAP/POP monitor connects to the relevant service and checks its reachability. If it fails, the client's users can no longer retrieve their mail, a state just as business-critical as dead sending.

The decisive point: these monitors see exactly what a browser check doesn't. They speak the mail server's language and check reachability at the layer where mail actually happens. At Uptimeify, here too every outage is confirmed from multiple EU locations before an alert fires, so a brief network hiccup at one node produces no false alarm.

An SMTP monitor checks outbound sending (connection to the mail server, say port 587), an IMAP/POP monitor checks mailbox access for inbound mail. Both speak the mail server's language, and see the reachability a browser check doesn't know.

## The second layer: authentication records like DKIM

A reachable mail server is necessary but not sufficient. Even when the SMTP server runs flawlessly and sends mail, something else can fail silently: the authentication that ensures the sent mail is actually accepted by the recipient. This authentication doesn't live on the mail server but in DNS, in the form of several TXT-based records.

**DKIM** (DomainKeys Identified Mail) is the most important of them. It's a DNS record that publishes a cryptographic key used to sign outbound mail. The receiving server uses this record to verify that a mail really comes unaltered from the stated domain. **SPF** (Sender Policy Framework) is a related TXT record that defines which servers may send in the domain's name at all. **DMARC** builds on both and tells receiving servers how to handle mail that fails SPF or DKIM.

The treacherous thing about these records is that their disruption is completely invisible, until delivery suffers. If the DKIM record changes accidentally, isn't carried over during a server migration, or a DNS change overwrites the SPF record, then the mail server keeps running flawlessly, but the sent mail is suddenly classified as unauthenticated by recipients and lands in spam or gets rejected. The client sees no error on their side; they only notice that their mail "no longer arrives."

This is exactly where monitoring the auth records comes in. Because DKIM, SPF, and DMARC live in DNS as TXT records, they can be checked against an expected value, the way you'd monitor an A record. A DNS monitor that watches these TXT records fires as soon as the real value deviates from the stored target. At Uptimeify this can be modeled with a DNS monitor that checks, say, the SPF or DKIM TXT record against the expected content and alerts on a deviation (or when the record no longer resolves at all). That makes a silent configuration change visible before it tips deliverability over.

DKIM, SPF, and DMARC are DNS TXT records that secure the authenticity of outbound mail. Their silent change sends mail to spam even though the server runs. Monitor them against a target value and you catch the deviation before delivery suffers.

## Where this angle stops: reachability vs. reputation

Honesty calls for a clear boundary, because "mail works" has more than one layer. This article covers two of them: the **reachability** of the mail server (is SMTP up, is IMAP up?) and the **configuration** of authentication (are DKIM, SPF, DMARC correct?). Both are technical prerequisites you can check against a target state: is the server there, is the record correct, yes or no.

Distinct from that is the third layer: **reputation and deliverability** in the narrower sense, the question of whether your correctly sent, correctly authenticated mail nonetheless ends up in spam, say because the sending IP is on a blacklist. That's not a reachability problem but a reputation problem, with its own causes and its own tools (such as blacklist monitoring). It complements the layer described here but doesn't replace it, and vice versa.

The clean separation helps with diagnosis. When mail problems arise, you work through the layers in order: is the mail server reachable at all (SMTP/IMAP)? Are the auth records correct (DKIM/SPF/DMARC)? And only then: is there a reputation problem (blacklist)? This article covers the first two layers, the basic prerequisites, without which the third isn't even relevant yet.

"Mail works" has three layers: reachability (SMTP/IMAP), auth configuration (DKIM/SPF/DMARC), and reputation (blacklist). This angle covers the first two, the technical prerequisites; the reputation question is a separate, complementary topic.

## Why this matters especially for agencies

For many clients a mail outage is more business-critical than a brief website outage, and that's exactly why the blind spot on the mail side is so dangerous. A website unreachable for ten minutes costs a few visitors. A mail server that accepts or sends no mail for half a day can mean lost orders, inquiries, invoices, or appointment confirmations, unnoticed, because a mail that didn't arrive produces no error message. The client often learns of the damage only once a deal has already fallen through.

For an agency responsible for its clients' digital infrastructure, that's a double risk. First, the outage is especially painful for the client, which magnifies the loss of trust. Second, it's especially embarrassing when the answer to "why didn't you notice this?" is "our monitoring only watches the website." A client rightly expects "you look after our systems" to include the systems their business communicates through.

Conversely, monitoring mail reachability and auth records is a quiet but strong differentiator. It covers exactly the area many simple web-monitoring tools leave out, and that a client rarely asks for explicitly but sorely misses when it's absent. Monitor the mail side too and you offer a completeness that turns "we monitor your website" into a credible "we monitor your digital infrastructure."

For the mail side not to stay a blind spot, you need monitors that check the mail server directly. See how SMTP, IMAP, and auth-record monitoring set up alongside website monitoring.

## Closing the blind spot

The heart of this topic is an overdue widening of view. Most monitoring setups end at the website, the most visible, but only one, part of a client's digital presence. The email infrastructure, over which the actual business traffic often runs, stays out of view because a web check can't technically reach it. This blind spot isn't an exotic edge case but one of the most common causes of the frustrated client call that no green uptime dashboard can contradict.

Closing it is straightforward with the right tools. An SMTP monitor for sending, an IMAP/POP monitor for receiving, and monitoring of the auth records for deliverability together cover the layers a browser check systematically overlooks. Each of these checks runs on the same calm principle as the rest of monitoring: confirmed from multiple EU locations, alerting over your usual channels, EU-hosted.

In the end it's about the same completeness that good monitoring is about overall: leaving no invisible gaps where an outage can grow without anyone seeing it. Mail is the largest of these gaps in pure web monitoring, and at the same time one of the most important, because the client's business runs over it. Monitor it too, and you turn a green dashboard that shows only half the truth into one that stands up to the whole of it.

Close the biggest blind spot in monitoring. See how Uptimeify monitors SMTP and IMAP reachability and the auth records of your client domains, EU-hosted, confirmed from multiple EU locations.