The Outage Nobody Alerts You About: Domain & Email Health Monitoring

In 2025, a typo'd renewal setting took a multi-million-user service offline for hours — not a hack, not a deploy, just a domain that lapsed. It happens to companies with entire infrastructure teams, regularly enough that "did the domain expire?" is a standard first question in outage triage.

Below your application sits a layer of infrastructure almost nobody monitors: domain registration, DNS, certificates, and email authentication. It changes rarely, fails rarely — and when it fails, it fails completely, with no error in your logs, no failing health check, and often no symptom you can see from your own machine. Your uptime monitor says fine; meanwhile half the internet can't resolve you, or every email you send lands in spam.

This is a tour of that layer: what actually breaks, why you never notice in time, and what continuous monitoring looks like.

Domain registration: the single point of failure you check annually

Your domain is a lease, and the failure modes are bureaucratic, which makes them worse — no stack trace, just an expiry date that passed while the renewal card was expired and the reminder emails went to a founder who left.

What's worth watching, all of it readable from public RDAP registration data:

• Expiry runway — not "is it valid" but "how many days remain." Inside 30 days without auto-renewal confirmed is an incident-in-waiting. After expiry comes a grace period, then redemption (expensive), then the open market (catastrophic — expired SaaS domains get snapped up for traffic and phishing).
• Transfer lock — the registrar-level flag (clientTransferProhibited) that stops a hijacker from moving your domain to another registrar. It should always be on; it occasionally gets toggled off during legitimate changes and never re-enabled.
• Registrar drift — the registrar of record changing when you didn't change it is the signature of a hijack in progress.

DNS: drift, DNSSEC, and who's allowed to issue your certificates

DNS changes are infrequent, manual, and high-blast-radius — the perfect profile for silent breakage:

• Nameserver drift. Your NS records moving to servers you don't recognize is either a migration someone forgot to mention or an active hijack; both deserve an alert within hours, not at the next annual audit.
• DNSSEC signs your DNS responses so resolvers can detect forgery (cache-poisoning answers that send your users to someone else's server). If you have it: a broken signature chain takes you offline for validating resolvers, so it needs watching. If you don't (most sites): that's a deliberate trade-off to at least make consciously.
• CAA records are a two-line file saying which certificate authorities may issue certificates for your domain. Without one, any CA on earth can be tricked or compelled into issuing for you; with one, mis-issuance attempts fail closed. It's the cheapest meaningful hardening in DNS.
• Hygiene basics — apex and www both resolving, IPv6 (AAAA) presence matching what you intend. The classic failure: www works, the bare domain doesn't, and a third of typed-in traffic bounces.

Certificates belong in this layer too: Certificate Transparency logs make every certificate ever issued for your domain public record, which means expiry runway — including for certs a teammate issued from a different ACME client — is externally monitorable. (We covered what makes certificates and TLS configuration healthy in the TLS grade explainer.)

Email authentication: where "sent" and "delivered" diverge

Email infrastructure fails differently: nothing bounces, nothing errors — your password resets, receipts, and onboarding emails just start landing in spam, and you find out from a support ticket weeks later. Since Google and Yahoo's 2024 bulk-sender requirements (and Microsoft following for Outlook in 2025), authentication isn't best practice anymore; it's the price of inbox admission.

Three records decide whether you're a legitimate sender:

• SPF lists which servers may send mail for your domain. The two ways it silently breaks: publishing multiple SPF records (the spec says that's an automatic failure, not a merge), and blowing the 10-DNS-lookup limit — every include: recurses, and a domain that's accreted Google Workspace + a marketing tool + a CRM + a support desk is usually at 8 or 9 lookups, one integration away from every check returning permerror. The limit has to be counted recursively; eyeballing the record tells you nothing.
• DKIM cryptographically signs your mail. Each sending service publishes a public key under a selector (google._domainkey, selector1._domainkey, …); the silent failure is a service rotating or retiring a selector while your DNS still serves the old key.
• DMARC ties them together: it tells receivers what to do when a message claiming to be you fails alignment (p=none — observe; p=quarantine — spam-folder it; p=reject — refuse it), and where to send aggregate reports about everything seen claiming to be you. p=none with no one reading reports — the most common deployment — is a camera with no film: spoofers impersonate your domain freely, and you've opted out of finding out.

Those XML aggregate reports (rua=) are the only visibility you get into spoofing and misconfiguration — which third-party sender just started failing alignment, which IP ranges are impersonating you, whether it's safe to move from none to quarantine to reject. Raw, they're unreadable zipped XML from every major receiver daily; parsed and trended, they're the dashboard for your sending reputation. That's why "a DMARC report inbox that parses these for you" is a feature and not a luxury.

The supporting cast, one line each: MX records that actually accept mail (or an explicit RFC 7505 null-MX on no-mail domains so the internet stops trying); MTA-STS and TLS-RPT to enforce and report on encrypted delivery between mail servers; BIMI to display your verified logo in inboxes — which requires p=reject DMARC plus a Verified Mark Certificate, making it as much a proof of finished authentication as a branding feature.

Why this layer needs monitoring, not an audit

Everything above shares three properties. It's externally observable — RDAP, DNS, CT logs, and DMARC reports are all public or sent to you; no agent to install. It changes rarely — which is why nobody looks. And it fails silently — the breakage announces itself days or weeks later, through symptoms (spam-foldered email, unreachable site, hijacked traffic) that don't point back at the cause.

That combination is exactly what scheduled checks are for. The cadence that works: re-check everything daily, alert only on deltas and thresholds — expiry runway crossing 30 days, an SPF record exceeding the lookup limit, NS set changing, transfer lock dropping, DMARC policy weakening, a new certificate appearing in CT logs that you didn't issue. Zero noise on the 360 days a year nothing changes; a same-day email on the day something does.

CheckVibe packages this as two checks that run with every scan and on your monitoring schedule:

• Domain Watchtower — RDAP expiry runway and lock status, registrar drift, nameserver set and diversity, DNSSEC validation, CAA presence, certificate expiry via CT logs, apex/www/IPv6 hygiene
• Email deliverability — SPF validity with true recursive lookup counting, DKIM selector discovery, DMARC policy strength and reporting setup, MX/null-MX posture, MTA-STS, TLS-RPT, and BIMI readiness — plus a managed DMARC report inbox that parses the XML into who's-sending-as-you

Both sit in the same dashboard as uptime, performance, and the security scanners — the whole "is my site actually okay" question in one place. Run a free scan and the first pass takes about a minute.

FAQ

How do I monitor my domain's expiration date?

Query RDAP (the structured successor to WHOIS) for the expiry timestamp and alert on runway — days remaining — rather than validity. A 30-day threshold catches expired payment cards and lapsed auto-renewal with time to fix; checking only "is it valid today" tells you about the outage after it starts.

What is the SPF 10-lookup limit?

SPF evaluation may perform at most 10 DNS lookups, counted recursively through every include:. Exceed it and receivers return permerror — your SPF effectively stops existing, on every email. Domains accumulate includes (workspace, marketing, CRM, support tools) until one new integration tips them over; the count has to be computed by following the chain, not by reading the record.

Should my DMARC policy be none, quarantine, or reject?

p=none is the observation phase: collect aggregate reports for a few weeks to find every legitimate sender. Move to quarantine once reports show your real mail aligning, then reject for full spoofing protection — it's also required for BIMI. Staying on none forever (the most common state) provides monitoring data but zero protection.

What are DMARC aggregate reports and do I need to read them?

Receivers like Gmail send daily XML summaries of every message claiming to come from your domain — passing or failing SPF/DKIM alignment, from which IPs. They're the only way to see spoofing attempts and to safely tighten policy without losing legitimate mail. Raw XML is impractical at any volume; use a parser or a managed report inbox that trends it.

What is a CAA record and should I add one?

A CAA record whitelists which certificate authorities may issue certificates for your domain — without one, any trusted CA can be tricked into issuing to an attacker. It's two DNS records (issue + a reporting address), costs nothing, breaks nothing if it matches the CA you actually use, and fails closed against mis-issuance. One of the best effort-to-value ratios in DNS hardening.