DEV Community

Cover image for Catch DNS and Certificate Failures Before Your Client Hears the Complaints
Mira John
Mira John

Posted on

Catch DNS and Certificate Failures Before Your Client Hears the Complaints

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 client-customer escalation chain that preventative monitoring should reverse

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:

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

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

  1. A quiet outside-in monitor notices a change.
  2. You check whether the result is real.
  3. You identify the responsible supplier.
  4. You contact the client with an explanation and a next step.
  5. 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.

A customer email bounces before the client or MSP knows there is a problem

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.

Top comments (0)