DEV Community: Mira John

Catch DNS and Certificate Failures Before Your Client Hears the Complaints

Mira John — Mon, 05 Oct 2026 08:00:00 +0000

The client's website is managed by a separate web agency. It is excluded from your contract. You do not have the hosting login, the WordPress password or the certificate-renewal job.

Then one of the client's customers opens the site and sees Your connection is not private.

They send the screenshot to your client. Your client calls you.

The web server may be running normally. Exchange may be healthy. The failure can sit entirely in public DNS, the certificate served at the edge, or an expired domain registration.

None of that helps once a customer has shown your client the warning. The client is embarrassed, the fix becomes urgent and the relationship is suddenly under review.

You may not own the system, but you can still monitor what the public sees. Responsibility and visibility are separate.

Staying out does not mean staying blind

Do not accept operational responsibility for a website you do not host or maintain. Taking ownership of another supplier's WordPress security, plugin updates or deployment process creates risk you cannot control.

Do monitor the small set of public signals that affect the client's business:

does the public DNS still return the expected records?
are the authoritative nameservers consistent?
is the website serving the expected certificate?
is that certificate approaching expiry?
is the domain registration approaching expiry?

These checks require no access to the website, DNS provider or registrar. They change nothing. They tell you what the client's customers can see from outside.

When something changes, tell the client and direct the incident to the supplier that owns the repair. You provide the warning without inheriting somebody else's platform.

Clients do not think in supplier boundaries

An MSP sees a website supplier, a hosting supplier, a registrar and perhaps a separate marketing agency.

The client sees one company website and one company email address.

Their customers see even less. They see an unsafe warning, a dead page or a bounced sales email. They do not care whether the certificate belongs to the web agency or the MX record belongs to the IT provider.

That is why the order of discovery matters so much:

The client's customer sees the failure.
The customer tells the client.
The client becomes embarrassed and alarmed.
The client calls whichever supplier they trust to explain it.
Planned work stops and the incident becomes urgent.

Reverse that order and the same technical fault becomes much easier:

A quiet outside-in monitor notices a change.
You check whether the result is real.
You identify the responsible supplier.
You contact the client with an explanation and a next step.
The client's customers may never see the failure.

The email version is worse

A certificate warning is visible immediately. Broken email can stay hidden.

A potential customer sends a message to the client's sales address. It comes back as unreachable. The sender knows first. Your client hears next. You hear last.

By then nobody can say how many enquiries failed or how long the problem existed.

The website may still be online with a green uptime check while the MX route is missing, SPF is broken or a nameserver migration has dropped records. Watching the homepage alone does not cover the public infrastructure behind email.

Visibility is not another security service

Do not turn this into another sprawling security product.

You do not need AI analysis of vaguely similar domains, a speculative risk score or another dashboard full of unrelated modules. Those features create more alerts and more arguments about ownership.

The useful service is smaller:

watch the public state the client depends on;
remain quiet while it is unchanged;
report the old and new values when it changes;
let the responsible human decide what the change means.

You get independent visibility without taking ownership of the repair.

A cheap warning for an expensive conversation

DNS Notify provides that outside-in layer for DNS changes, served certificates and domain expiry. It does not require DNS-provider credentials and does not modify the systems it watches.

It costs £5 per month for five domains, or £50 per year. On the annual plan that is about 83p per domain per month.

For an MSP or agency, the choice is direct: pay less than £1 per domain each month for an early warning, or let the client's customer report the failure and turn a routine fix into a client-retention problem.

You do not have to own the website to be the first professional who notices.

Catch an Expired Certificate Before Your Client Hears “Your Website Is Unsafe”

Mira John — Wed, 30 Sep 2026 08:00:00 +0000

A customer opens your client's website and Chrome shows the warning everyone recognises: Your connection is not private.

They take a screenshot and send it to your client. Your client sends it to you. A certificate renewal that should have been routine is now public, embarrassing and urgent.

Once that screenshot reaches the client, a routine renewal failure becomes an urgent incident. Check the certificate customers actually receive from outside the network. You do not need access to the website or its renewal system, and you do not need to own the repair.

Since 15 March 2026 no public certificate authority will issue you a TLS certificate valid for more than 200 days. In March 2027 the cap drops to 100 days, and in March 2029 to 47. The last of the old 398-day certificates run out in April 2027, and after that everybody is on the short schedule whether they planned for it or not.

The CA/Browser Forum voted this through in April 2025 (ballot SC-081v3), with Apple, Google, Microsoft and Mozilla all in favour. The reasoning is sound. Revocation has never worked well in browsers, so the practical way to limit the damage from a stolen or mis-issued certificate is to make it expire sooner.

The part I care about is what it does to failure. At eight renewals a year nobody renews by hand, so nobody forgets. What happens instead is that the automation stops working and nothing tells you.

Five ways automated renewal fails quietly

The job stopped running. The server was rebuilt and the cron entry or systemd timer wasn't carried over. The container image was rebuilt without the ACME client. Nothing logs an error, because nothing runs.

The certificate renewed and the server never reloaded. The ACME client wrote new files and exited. nginx, HAProxy or Postfix are still serving the old certificate from memory and will keep doing so until somebody restarts them. The renewal log says success. There is a longer write-up of this one, with the other places an old certificate hides, in renewed the certificate, old one still served.

It renewed on the wrong machine. You renewed on the origin. Visitors talk to a load balancer, a CDN, or the second box in the pool, and each of those has its own copy.

The challenge started failing. A firewall rule now blocks port 80. The DNS API token used for DNS-01 was rotated. Someone added a CAA record that doesn't include your CA. A CAA mistake used to bite once a year. At 47 days it bites eight times a year.

The validation expired. The same ballot shortens how long a CA may reuse a domain validation, down to 10 days by 2029. Setups that leaned on a long-lived validation will have to prove control again at nearly every renewal.

What these have in common is that the certificate on disk, the renewal log, or both look fine. The only place the problem is visible is from outside, in the certificate visitors are actually handed.

The one check that catches all five

Connect the way a browser does and read what comes back:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -issuer -serial -enddate

Keep the -servername. Without SNI, a server that hosts several sites hands you its default certificate, which may not be the one you think you're checking.

Run that on a schedule, from a machine that is not the one doing the renewing, for every hostname that answers on 443. example.com and www.example.com can serve different certificates. So can api., mail. and whatever sits behind your CDN. If a disk fills up on the box that renews, you don't want the warning to live on the same disk.

If you want to spot-check a hostname without a terminal, this SSL certificate checker makes the same connection and shows the expiry, days left, issuer, serial and fingerprint.

How early to warn

The classic advice is a 30-day warning. On a 47-day certificate that renews at around day 30, a 30-day warning is true for most of the certificate's life. It fires constantly, so people filter it, and then it is worthless on the one day it matters.

Work backwards from the renewal point instead. If your client renews with a third of the lifetime left, a healthy 47-day certificate never drops below about 15 days remaining. A first warning at 14 days then means "renewal should have happened by now and didn't". After that you want reminders that get harder to ignore, and a final one that means a person has to act today. I settled on 14, 7, 3 and 1.

Two more rules kept the noise down for me, the same way they did for DNS records in the seven false alarms post. A new serial with a later expiry is a renewal, so it goes on a timeline and nobody gets an email. A new serial with an earlier expiry does get an email, because that usually means someone installed the wrong file.

Where this fits

Certificate expiry is one of four things I watch per domain in DNS Notify, next to DNS records, nameservers and the registration. Its SSL certificate expiry monitoring is deliberately narrow. It reads the leaf certificate served on port 443 and tracks the dates, issuer, key and fingerprint. It does not grade your TLS configuration or validate the chain, because other tools already do that well.

Certificates also fail for DNS reasons. A CAA record that blocks your CA and a broken _acme-challenge CNAME are both DNS changes, which is part of why the two live in one product. I covered the email equivalent of this, records that break without anyone noticing, in the four records that break mail while your site stays up.

If you do one thing this quarter, list every hostname you serve over HTTPS and check that each one is renewed by a machine, reloaded by a hook, and read from outside by something that will tell you when the first two stop working.

Catch Broken Email DNS Before Your Client Hears “Your Messages Are Bouncing”

Mira John — Fri, 25 Sep 2026 08:00:00 +0000

A potential customer emails your client's sales address. Seconds later the message comes back: address not found, mailbox unavailable, or domain could not be reached.

That customer sees the failure first. They tell your client. Your client calls you. By then nobody knows how many enquiries were lost, and a small DNS problem has become an embarrassing business problem.

Exchange can be healthy. The mail server can be running. Every internal dashboard can be green. If the public MX, SPF, DKIM or DMARC records are missing or wrong, customers still see the failure.

A homepage uptime check will never catch it. Web and email share a domain name and almost nothing else. The website depends on an A, AAAA or CNAME record. Email depends on four different DNS records that an ordinary website check never reads.

Staying out of a client's mail platform does not mean staying blind. An MSP, agency or developer can watch these four public records from the outside and warn the client before the client's customers become the monitoring system.

Here are the four, how each one usually gets broken, and how to check it from a terminal.

MX: where your mail is delivered

dig example.com MX +short
10 mail1.example.net.
20 mail2.example.net.

MX records tell every other mail server where to deliver mail for your domain. They break during migrations. Someone moves the domain to a new DNS provider and the zone import drops a record, or keeps an MX for a mailbox provider you left two years ago. They also break when a domain changes hands inside a company and the new owner rebuilds the zone from memory.

A wrong MX does not bounce mail straight away. If the listed host is gone, senders keep retrying for days before they give up. If it still accepts mail for your domain, the mail is delivered, into a mailbox nobody reads.

MX record monitoring is the easiest kind to justify, because the record almost never changes and when it does the meaning is obvious. If you want to see what a domain publishes right now, this MX lookup asks the domain's own nameservers instead of a cache.

SPF: who may send as you

dig example.com TXT +short | grep spf1
"v=spf1 include:_spf.google.com include:sendgrid.net -all"

SPF is a TXT record at the apex of the domain, which is its weakness. The apex collects TXT records from every service that ever asked you to verify ownership. A year later somebody cleans up the junk, and the SPF line looks like junk too.

The other common break is a second SPF record. A new tool's setup guide says to add v=spf1 include:newtool.com ~all, and someone adds it as a new record instead of merging it into the existing one. Two SPF records is a permanent error, and receivers treat it as no SPF at all.

Either way your mail still sends. It just starts failing authentication at the other end, and you hear about it from a customer weeks later.

DKIM: the key that signs your mail

dig selector1._domainkey.example.com TXT +short
dig selector1._domainkey.example.com CNAME +short

DKIM public keys live under selector names that mean nothing to a person reading the zone. s1._domainkey, k2._domainkey, mte1._domainkey. They look like leftovers, and they get deleted as leftovers. Your provider keeps signing with the private key, receivers can no longer find the public one, and every signature fails.

You need the selector name to query it, and most people don't remember theirs. Send yourself an email and look for s= in the DKIM-Signature header, or run a DNS record scanner that tries the common selector names against your domain.

DMARC: what receivers do when the checks fail

dig _dmarc.example.com TXT +short
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails both. The usual accident here is a debugging session. Deliverability is bad, someone sets p=none to rule DMARC out, the real cause turns out to be something else, and the policy never goes back to reject. Nothing breaks. You have just quietly stopped telling the world to refuse forged mail from your domain, and no test you own will ever notice.

The other one to watch is the rua address. If it changes to an address you don't recognise, your aggregate reports, which list every IP sending as you, are going to someone else.

What to do about it

All four are plain DNS records, so the dig commands above are most of a monitor already. Run them on a schedule, compare with the values you expect, and send yourself the old and new value when they differ. I went through the ways that comparison produces false alarms in an earlier post. For email records the two that matter are to query the authoritative nameservers, and to join split TXT strings before comparing. SPF and DKIM values are long enough to be split into several strings, and servers don't always split them the same way twice.

This is also what I built DNS Notify to do. Its email DNS monitoring watches the MX set, the SPF and DMARC records and whichever DKIM selectors you pick, and the alert is the record name with the accepted value and the current value next to each other. It doesn't validate SPF syntax or read DMARC reports. There are good tools for both and it isn't trying to be them. It tells you a record changed, within minutes, while you can still remember who was in the DNS panel that day.

Whichever way you do it, write down the four values today. The hardest part of fixing a broken SPF record is working out what it used to say.

Detect Website and Email Failures Before Someone Tells Your Client

Mira John — Mon, 21 Sep 2026 06:30:00 +0000

Imagine the message arriving in the middle of an ordinary working day:

One of our customers just sent us this screenshot. Why does our website say it is unsafe?

The screenshot is the browser warning everybody recognises: Your connection is not private.

The customer saw it first. They told your client. Your client is now forwarding it to you.

By then the failure is public and you are reacting on the client's schedule.

The same thing happens with email:

A customer says their message to our sales address bounced back as unreachable. How long has this been happening?

The sender sees the failure first: “address not found”, “mailbox unavailable” or “domain could not be reached.”

The web server can be up. Exchange can be healthy. Every internal dashboard can be green. A missing MX record, wrong nameserver, expired certificate or lapsed domain can still make those working systems unreachable from outside.

Your client did not discover the problem from an internal alert. Their customer received the failure and had to find another way to make contact.

Now the failure is public. Your client is embarrassed in front of their own customer, does not know how much business may have been missed, and immediately wonders what they are paying you to look after.

You no longer control the schedule

Five minutes earlier, you had a plan for the day.

Now you have to stop everything.

The certificate warning, broken DNS record or missing MX route may be straightforward to fix. That does not make the situation small. Once the client knows, the work becomes urgent regardless of what else you were doing.

You need to investigate immediately, send updates, coordinate with whichever supplier owns the affected system, and explain why nobody noticed first.

For an employee, the same escalation may reach a boss before it reaches the technical team. For an agency or MSP, it can put the entire client relationship under review.

The technical incident may last an hour. The doubt it creates can last much longer.

The failure may sit outside your contract

This problem is not limited to infrastructure you directly manage.

An MSP may not host the client's website. A web agency may not manage the client's mail service. A developer may have no access to the registrar. That does not make early visibility useless.

If the MSP sees that the public website or served certificate has failed, it can warn the client and direct the incident to the web team. If the web agency sees that an MX record changed or disappeared, it can tell the client to contact IT before customers start reporting bounced messages.

You do not need to own the repair to provide the early warning.

That is valuable because clients rarely think in supplier boundaries while something is broken. They see one business, one website and one email address. Whoever notices early looks proactive. Whoever learns from the client's customer looks absent.

Quiet monitoring beats another noisy dashboard

A day earlier is a different kind of incident

Some warnings arrive days or weeks early: certificate expiry, domain expiry, and planned DNS changes that do not look right.

Other changes need attention as soon as they are visible: an MX record disappearing, nameservers disagreeing, or a critical DNS value changing unexpectedly.

Either way, an internal alert changes the nature of the work.

Instead of dropping everything after an embarrassed phone call, you can investigate, identify the responsible supplier, prepare the fix, and contact the client with an answer already in hand.

Sometimes the client never needs to see the failure at all.

That is the difference between reactive support and preventative monitoring.

A deliberately small tool for a costly problem

DNS Notify monitors DNS changes, SSL certificates and domain expiry from outside the provider account. It does not need DNS-provider credentials, does not change DNS, and does not use AI to manufacture extra findings. It is designed to stay quiet until the monitored state changes.

It costs £5 per month for five domains, or £50 per year. On the annual plan that is about 83p per domain per month.

The choice is not really between monitoring and doing nothing.

It is between:

losing a client after their customers discover the problem;
abandoning planned work and fixing it in a panic; or
paying less than £1 per domain per month to hear about important changes as soon as possible.

Which would you choose?

You can also use the free DNS, MX, certificate and domain-expiry tools without creating an account.

DNS change monitoring: the seven false alarms I had to kill

Mira John — Sat, 19 Sep 2026 14:28:30 +0000

A client's customer should never be the first person to tell you that the website is unsafe, email is bouncing, or a DNS change broke something public. By then the failure is already embarrassing, your client is asking what they are paying you for, and a routine fix has become an interruption.

The catch is that a noisy monitor is almost as bad as no monitor. If it sends false alarms every time answer order changes or a resolver cache catches up, people stop reading it. The useful monitor stays quiet until a meaningful public state changes.

The first version of any DNS checker is about ten lines. Look up a record, compare it with the value stored last time, send an email if they differ. Point that at a real domain for a day or two and it will email you about records nobody has touched. The checker behind DNS Notify started there too.

DNS change monitoring is easy to describe and annoying to get right, because DNS answers vary in ways that mean nothing. Below are the false alarms I had to design out, and what I did about each. If you want to monitor DNS changes with your own script, this should save you a week.

1. Asking a resolver instead of the source

The obvious way to look up a record is through the system resolver, which is what dig example.com MX does by default. A recursive resolver answers from cache until the TTL runs out. Public resolvers are also big anycast clusters, so two queries a minute apart can land on machines with different cache contents. After a real change you can see old, new, old, new until the TTL has run out everywhere. To a naive checker each flip is a change.

The fix is to skip resolvers and ask the domain's own nameservers. With dig:

dig example.com NS +short
dig @ns1.example-dns.net example.com MX +noall +answer

And with dnspython, which is what the checker uses:

import dns.resolver

def authoritative_answer(domain, name, rtype):
    ns_hosts = [str(r.target) for r in dns.resolver.resolve(domain, "NS")]
    ns_ips = [a.to_text() for h in ns_hosts for a in dns.resolver.resolve(h, "A")]

    r = dns.resolver.Resolver(configure=False)
    r.nameservers = ns_ips
    r.timeout, r.lifetime = 5, 10

    ans = r.resolve(name, rtype, raise_on_no_answer=False)
    return sorted(rd.to_text() for rd in ans.rrset) if ans.rrset else []

If you only want to eyeball one record this way, I put the same logic behind a free authoritative DNS lookup so you don't need a terminal.

2. Answer order

Many nameservers rotate multi-value answers on purpose. Two A records come back as .10, .20 and then as .20, .10. A string comparison calls that a change. Sort the values before comparing. That is what the sorted() in the snippet above is for.

3. TTLs

Store the full answer line, TTL included, and you are in trouble twice. From a resolver the TTL counts down, so every check differs from the last. From an authoritative server the TTL is stable, but people lower it before a migration and raise it afterwards, and that is not something anyone wants an email about. I keep the TTL for display and leave it out of the comparison.

4. The SOA serial

The SOA record carries a serial number that goes up whenever anything in the zone is edited. Some providers bump it on their own schedule too. Include the SOA in naive DNS record monitoring and you get an alert for every edit to every record, including the ones you already alert on. I mask the serial before comparing. If the serial is the only difference, the new SOA is accepted quietly. Changes to the primary nameserver or the timers still come through, and those are the ones that tell you something.

5. Timeouts that look like deletions

A query that times out returns nothing. A record that was deleted also returns nothing. Treat them the same and every network blip becomes "your MX record was removed", which is a horrible email to get at 3am when it is not true.

These need to be separate code paths. NXDOMAIN and an empty answer are real answers from the server. A timeout or SERVFAIL is a failed check and says nothing about the record. I count failures per record and only alert after four failed runs in a row. When the record comes back, the recovery goes on the timeline without a second email.

6. Formatting noise

Mail.Example.NET. and mail.example.net are the same host. A long TXT record is sent as several quoted 255-byte strings, and where the splits fall is up to the server. Pick one canonical form and stick to it. The checker strips trailing dots, rebuilds MX and SRV answers field by field, and joins TXT strings into one value before comparing. SPF and DKIM records are where this bites, because they are the long ones.

7. Changes that undo themselves

Someone fat-fingers a record, notices, and fixes it two minutes later. The first alert is fair. A second alert saying it changed again, back to what you expected, is noise. I keep two values per record, the accepted one and the current one. When current goes back to accepted, the pending flag clears and a "reverted" event is logged with no email.

The same two-value model handles planned changes. After a migration you accept the new value and it becomes the baseline. Without that step the monitor nags forever about a change you made on purpose. I wrote the whole loop up as a guide, how to monitor DNS changes, with the dig commands for each step.

What I could not fix

Some records are supposed to differ depending on who asks. Latency-based routing, geo DNS and most CDNs return different A records from different places, and sometimes from the same place. No amount of normalising makes that a stable signal. I leave those records off the watch list and monitor the CNAME that points at the CDN instead. That one should never move without someone knowing.

What was left

After all of that, the checker got boring, which was the goal. DNS change alerts are only worth having if people still open them in month six. It emails when a value at the source differs from the value someone accepted, and shows both. It waits before reporting failures. It logs reverts and recoveries without emailing them.

This is how DNS change monitoring works in DNS Notify today. The full rules, including how certificates and registration data are compared, are on the methodology page. If you have run into a false alarm I have not listed, tell me in the comments. I would like to break the checker before a customer does.