Domain monitoring

Domain monitoring watches the external surfaces your clients depend on — their website, their mail records, their SSL certificates — and alerts you before things visibly break.

Unlike most RMM features, domain monitoring doesn't need an agent. The checks run from OpsMerge's infrastructure, not from any endpoint.

What it monitors

For each domain you add, OpsMerge runs:

Check	What it does	Default frequency
SSL certificate	Expiry date, chain validity, signature algorithm	Daily
HTTP health	GET request, follow redirects, check final status code + content match	Every 5 min
DNS	A, AAAA, MX, NS records	Every 30 min
DNS propagation	Same records, queried via multiple resolvers globally	Daily
WHOIS	Domain expiry, registrar, owner	Daily
DMARC	Presence, policy, alignment	Daily
SPF	Record presence and syntax	Daily
MX reachability	TCP connect to each MX on port 25	Hourly

Adding a domain

Settings → RMM → Domain monitoring → + Add domain.

1. Enter the domain (e.g. acmecorp.co.uk).
2. Pick the client it belongs to.
3. Tick which checks you want enabled (default: all).
4. Set alert thresholds (e.g. SSL expiry → 30 days warning, 7 days critical).
5. Save.

The first round of checks runs within 60 seconds. Results appear on the domain's page in OpsMerge.

Auto-add from M365/CIPP

If a client is CIPP-connected, their primary and accepted domains can be added automatically. Client → M365 → Domains → Auto-monitor. Saves manually adding them.

SSL expiry — the most useful one

SSL certificate expiry is the single check that pays for the whole feature. Default alerting:

• 30 days out: Warning alert (creates a low-priority ticket).
• 7 days out: Critical alert (creates a high-priority ticket).
• Expired: Critical alert, plus the HTTP health check starts failing.

Tune the thresholds per-domain. For domains where you specifically manage the certificate, you might want longer warning (60 days) to leave time for renewal automation; for domains where the client controls the cert, shorter (14 days) so it doesn't sit in the queue.

HTTP health

The HTTP check does a GET to the configured URL (defaults to https://{domain}/) and:

• Follows redirects up to a limit.
• Checks the final status code is 200-399 (or matches your configured expectation).
• Optionally checks a string is present in the response body (e.g. the company name).
• Records response time.

Alerts on:

• Status code outside the expected range.
• Body-match failure (if configured).
• Connection refused / timeout.
• TLS handshake failure (separately from cert expiry).

Don't put authentication-required URLs in the body-match field — the check has no credentials. Use a public health endpoint or the home page.

DMARC

OpsMerge fetches the _dmarc.{domain} TXT record and parses the policy:

• No record: Information-only alert ("DMARC not configured").
• p=none: Information-only (monitoring mode is fine for some setups, but flagged).
• p=quarantine or p=reject: OK.

We also check the rua reporting address is set so DMARC reports go somewhere.

DNS propagation

Once a day we query the configured records via a handful of geographically-distributed resolvers (Cloudflare, Google, Quad9, OpenDNS, AWS). If the answers disagree, you get a propagation alert — usually meaning a DNS change is still rolling out (give it 24h), or worse, a registrar/nameserver issue.

WHOIS expiry

We check the domain registration expiry from WHOIS. Default alert thresholds match SSL: 30 days warning, 7 days critical.

WHOIS data is also rate-limited by registrars, so we cache aggressively. If you've just made a registration change and OpsMerge is still showing the old data, expect up to 24 hours for the next refresh.

Common patterns

"Alert me if the client's website goes down, but not for transient failures"

The HTTP health check needs 3 consecutive failures by default before alerting. Tune this per-domain — for a low-traffic site you might want 5 (more tolerant); for a critical site 1 (immediate).

"Track SSL on a non-HTTP service (e.g. SMTP TLS, IMAP)"

The SSL check defaults to port 443. For non-HTTP TLS, change the port in the domain's settings. The cert checks still work.

"I have 200 client domains; do I really have to add them one by one?"

Bulk import: Settings → RMM → Domain monitoring → Import. CSV with domain + client mappings. Or use the API.

For M365-connected clients, the auto-import gets you most of the way.

Common issues

Cert expiry alert keeps firing even after renewal. OpsMerge polls daily; a same-day renewal won't be reflected until the next poll. Force a check from the domain's page → Re-check now. If the alert still fires after a fresh check, the cert chain may be incomplete (intermediate cert missing) — check with openssl s_client -connect ....

WHOIS shows the wrong registrar. Some country-code TLDs (.co.uk, .nl, .de) have terse WHOIS that doesn't include all fields. Cross-check at your registrar's site.

DMARC alert says "no record" but I just added one. DNS TXT cache. Wait an hour, force a re-check. If it's still missing, the record was published to the wrong domain (a common mistake is publishing to _dmarc.subdomain.example.com rather than the apex).

HTTP check times out but the site is up. Some clients front their site with bot-protection (Cloudflare's "I'm under attack" mode, Akamai bot manager). The OpsMerge check's User-Agent may be challenged. Use the body-match feature with a string you know appears on the challenge page, or coordinate with the client to allow-list our checker.

False positives on DNS propagation. Some authoritative DNS providers (e.g. specific GoDaddy nameservers) are slower to propagate than others. If only one of the multi-resolver queries disagrees and it's always the same resolver, mute that specific resolver in the domain's settings.

Next

• Monitoring & alerts — domain alerts use the same alert-rule infrastructure
• Email gateway — closely related: domain reputation, DKIM/DMARC validation