You ran the check. Everything was green. You closed the tab and got on with your week.
That green result was true — at 14:32 on a Tuesday. It said nothing about Thursday, when a contractor added a TXT record for a new marketing tool and pushed your SPF record past the lookup limit. It said nothing about Saturday, when a compromised mailbox got your sending address listed. It said nothing about the certificate that renewed correctly on the certificate authority's side but never reached the load balancer.
Almost every domain failure worth caring about happens after the last time somebody looked.
The gap nobody measures
There are two clocks running during any incident. The first starts when something breaks. The second starts when a human finds out. The distance between them is the only part of the incident you actually control, and it is where the damage accumulates.
Fixing a broken SPF record takes about four minutes. Discovering it four days later, after a week of invoices went to junk, costs you the four minutes plus a week of chasing, apologising and rebuilding trust with recipients whose mail filters have now learned something unhelpful about your domain.
Manual checking does not shrink that gap in any reliable way, because the checks happen when somebody remembers, and people remember most reliably right after an incident — when the system is already, briefly, fine.
Four failures that never announce themselves
A vendor edits your DNS
Agencies, hosting providers and SaaS onboarding wizards routinely hold DNS credentials. A new tool asks for "a quick DNS change" and someone replaces an MX record rather than adding a TXT one, or drops an existing verification record that another service still depends on. Nothing errors. Mail simply starts going somewhere else, or an integration stops working weeks later.
An SPF record grows past the limit
SPF permits ten DNS-querying mechanisms per evaluation. Each include: you add for a new sending platform brings its own nested includes with it. The record that worked yesterday with nine lookups returns a permanent error today with eleven — and most receivers treat that as "no SPF at all". There is no warning, because nothing in your DNS is invalid. It is only too long. The SPF lookup limit is worth understanding on its own.
A certificate renews but never deploys
Automated issuance made expiry rare and made deployment the new failure mode. The certificate authority issues a new certificate on schedule; the renewal hook fails, or the file lands on one node of three, or the service is never reloaded. Your monitoring of the renewal job says success. The certificate your visitors are actually served still expires on the original date.
An IP gets listed at the weekend
Blocklist listings do not wait for business hours, and the first symptom — mail being refused by some recipients — is invisible from your own inbox. By Monday you have two days of undelivered mail and no idea when it started.
Detection time is the only variable you control
You cannot prevent a vendor from making a mistake in your zone, or a mailbox from being phished. You can decide how long those events stay secret.
That gives a simple way to choose a cadence. For each thing you monitor, ask what a day of silence would cost:
| Signal | Cost of a day unnoticed | Reasonable cadence |
|---|---|---|
| Blocklist listing | High — mail refused, reputation decays | Hourly or better |
| Site or mail server down | High — immediate and visible | Minutes |
| DNS record change | High — can redirect mail or traffic | Hourly |
| SPF / DKIM / DMARC breakage | Medium to high — delivery degrades quietly | Hourly to daily |
| Certificate expiry | Low until the date, then total | Daily, with warnings well in advance |
| Domain registration expiry | Catastrophic, but with a long fuse | Daily, first warning weeks out |
The pattern is that anything which can change without your involvement needs checking on a cadence, and anything with a deadline needs a countdown rather than a check.
What breaks without it
Without continuous checks, three things reliably go wrong.
You find out from a customer. The most expensive way to learn that your mail is being refused is a phone call from the person who did not receive an invoice, because by then the problem has already lasted long enough for someone outside your company to notice a pattern.
You cannot tell what changed, or when. Without history, an incident becomes an argument. Was the MX record always like that? Did the certificate change last week or last month? A record of what your domain looked like at each check turns a guessing game into a diff.
Deadlines arrive without you. Domain and certificate expiries are the only failures on this list that are fully predictable, and they still cause outages — because the reminder went to a mailbox nobody reads any more. See the outage nobody plans for.
How to check it in 30 seconds
Start with a baseline. Run a Domain Health report on your main domain: it covers blocklists, mail servers and authentication, web and certificate, DNS delegation, and registration in one pass, and grades each finding as an error, a warning or a pass.
Read the errors first, then decide which of those checks you would want to be told about automatically. That list is your monitoring plan — you do not have to invent it.
Fix it
- Pick the domains that matter: the one your mail comes from, the one customers type, and any domain you own that redirects to them.
- Decide who receives alerts. A shared mailbox or a channel outlives any individual's inbox.
- Set the cadence by cost, using the table above, rather than by how interesting the check is.
- Record a baseline so that future changes can be compared against something.
- Write down who is allowed to edit DNS, and make sure alerts reach them too.
- Test the alert path once, deliberately, so you know it works before you need it.
Then keep it that way
StatusDNS re-checks each monitored domain on a schedule set by your plan. Each run covers blocklist status for the domain and its mail and web addresses, DNS records and delegation, SPF, DKIM and DMARC, the web response and certificate, mail server availability, and registration data, and stores the result so you have a history to compare against.
When something changes state — a new listing appears, a DNS record is added or removed, a check that was passing starts failing, or an expiry date comes within range — you get an alert by email, and on plans that include them by Slack or webhook. Alerts carry a severity, repeat events are deduplicated rather than resent, and quiet hours hold non-critical notifications until the morning. When the condition clears, the alert is resolved and you are told, so "did that ever get fixed?" has an answer.