Monitor Your Domain's DNS, SSL and Email Auth in CI

Three domain problems share an annoying property: they are invisible until they are urgent. A TLS certificate is valid right up to the minute it expires. An SPF record keeps working until someone adds a fourth include and trips the ten-lookup limit. A DMARC record sits at p=none for a year because nobody remembered to tighten it. In every case the first signal is a user complaint, which is the worst time to learn about it.

The fix is to check these on a schedule, in the one place that already runs on a schedule and can fail loudly: your CI pipeline. This post shows how to do that with @domainintel/cli, a small command-line tool that runs the same checks as DomainIntel and returns CI-friendly exit codes.

One command, no install

The CLI ships as a self-contained bundle, so there is nothing to install:

npx -y @domainintel/cli example.com

That prints a full report: WHOIS, DNS, SSL, security headers, reputation, and a security grade. Every query runs locally from wherever you invoke it. The lookups go straight to DNS, WHOIS and TLS endpoints, never to a DomainIntel server, so it is safe to run against internal hostnames too.

For automation you do not want the full report. You want a single check that exits non-zero when something is wrong. That is what the --exit-code flag does.

Gate a build on certificate expiry

The single most useful check. A certificate that expires over a weekend takes your site down until someone notices. Catch it days ahead instead:

npx -y @domainintel/cli ssl example.com --fail-under 21 --exit-code

--fail-under 21 makes the command exit 1 if the certificate has fewer than 21 days left. Drop it into a scheduled GitHub Actions workflow and the run goes red while you still have three weeks to renew:

name: domain-health
on:
  schedule:
    - cron: '0 6 * * *'   # daily at 06:00 UTC
  workflow_dispatch:

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Certificate not expiring within 21 days
        run: npx -y @domainintel/cli ssl ${{ vars.DOMAIN }} --fail-under 21 --exit-code

If your renewal is automated already, this is the smoke test that proves the automation actually ran. Background on what the expiry window should be is in the guide on SSL certificate expiration.

Catch broken email authentication

The dns check flags common misconfigurations, including a missing or broken SPF record and a missing DMARC record on a domain that sends mail. Add a second step:

      - name: DNS and email auth configured
        run: npx -y @domainintel/cli dns ${{ vars.DOMAIN }} --exit-code

With --exit-code, the step fails if the tool reports any warning. That turns "someone edited a TXT record and forgot a character" into a failed pipeline rather than a silent deliverability problem. If you want to see exactly what is being checked first, run it without --exit-code locally, or read how to check SPF, DKIM and DMARC.

Pipe the JSON wherever you need it

Every command takes --json, and stdout stays clean even for the noisier checks, so you can pipe straight to jq:

npx -y @domainintel/cli ssl example.com --json | jq '.ssl.daysRemaining'
npx -y @domainintel/cli dns example.com --json | jq '.dns.hasDmarc'

That is enough to build your own thresholds in a script, export metrics, or audit a fleet of domains in a loop:

cat domains.txt | xargs -I{} npx -y @domainintel/cli whois {} --json > whois.ndjson

Exit codes, briefly

The tool uses three exit codes so a pipeline can tell the difference between "all clear", "found a problem", and "could not run at all":

Code	Meaning
0	Ran successfully, no problems (or --exit-code not set)
1	Ran successfully but found problems (only with --exit-code)
2	Could not run: bad usage, invalid domain, or an analysis failure

That separation matters in CI. A network blip that returns 2 is a flaky run to retry, not a real cert expiry. Only 1 should fail the build for a genuine finding.

Where it fits

The CLI is one of three ways to reach the same engine. The web app is for a one-off look with a full dashboard. The MCP server is for AI agents. The CLI is for scripts and pipelines. Source and the full flag reference live on GitHub.

If domain health has ever surprised you in production, a five-line scheduled workflow is a cheap insurance policy.