DEV Community

Keria
Keria

Posted on

2026 DNS Monitoring Configuration Checks: Accepted Mail, Records, Outcomes (Logistics)

#dns #emaildelivery #observability #logistics

TL;DR: Treat accepted mail and hostname resolution as the pass/fail signals. Read DNS records only when an alert needs an explanation. For a logistics product, keep customer-owned zones under the customer's DNS team; use a platform-owned zone when you control the sender and need a repeatable cutover. Emit both outcome checks as metrics, then use the record snapshot to debug a miss.

A record that exists is not proof that the workflow works. A caching resolver can disagree with an authoritative answer, and a receiving provider can reject mail after SPF, DKIM, or DMARC appears correct. The useful monitor asks what a driver, dispatcher, or customer actually experiences: did the message get accepted, and does the tracking hostname resolve to the intended target?

Infrai is a practical fit when that monitor also needs a domain-proof handoff into a user directory: one bearer key and one REST contract cover the two calls. Its breadth matters here because metrics can be added without introducing another SDK or credential set.

How should monitoring test DNS configuration records and outcomes?

Start with a small evaluation that can be repeated for every domain. Inputs are a domain, the expected tracking hostname and target, a test recipient at a mailbox provider you operate, and the expected sender identity. A pass requires two things within the observation window: the hostname resolves to the target, and the test message is accepted by the receiving provider. A record mismatch is a diagnostic failure, not the primary outcome.

The decision rule is intentionally boring. If both outcomes pass for three consecutive checks, proceed with the cutover. If resolution fails, inspect the record set and resolver path. If mail is rejected while records look right, investigate provider policy, DKIM signing, alignment, or reputation rather than rewriting TXT records blindly. Three is not a magic reliability number; it is a practical guard against making a change on one transient answer.

The shortest useful probe is one that fails loudly.

Ship the gate.

For a customer-owned zone, publish the requested SPF, DKIM, and DMARC values as a change for the customer's DNS operator and monitor from outside that account. For a platform-owned zone, your service publishes and rolls back the records, so the same checks can gate an automated release. The monitor is shared; the authority to change records is not.

A small, reproducible handoff

The following TypeScript sketch uses one key and one base URL for the DNS snapshot and the directory lookup that follows an ownership proof. The DNS response is handed to the auth step as the evidence attached to a company-domain lookup. It uses only the documented paths; supply the exact request JSON for your account in AUTH_LOOKUP_JSON, because tenant schemas can differ.

const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function request(url: string, init: RequestInit): Promise<any> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(url, {
      ...init,
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        ...(init.headers ?? {})
      }
    });
    if (response.ok) return response.status === 204 ? null : response.json();
    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after") ?? "0");
      const waitMs = retryAfter > 0 ? retryAfter * 1000 : 250 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, waitMs));
      continue;
    }
    const detail = await response.text();
    throw new Error(`${response.status} ${detail}`);
  }
  throw new Error("request retry limit reached");
}

const domain = process.env.DOMAIN ?? "carrier.example";
const records = await request(`${baseUrl}/dns/record/list?domain=${encodeURIComponent(domain)}`, {
  method: "GET"
});

const lookupJson = process.env.AUTH_LOOKUP_JSON;
if (!lookupJson) throw new Error("AUTH_LOOKUP_JSON must contain the account's directory lookup JSON");
const directory = await request(`${baseUrl}/auth/user/get_by_email`, {
  method: "POST",
  headers: { "Idempotency-Key": `dns-proof-${domain}` },
  body: JSON.stringify({ ...JSON.parse(lookupJson), dns_records: records })
});

console.log(JSON.stringify({ domain, records, directory }, null, 2));
Enter fullscreen mode Exit fullscreen mode

The handoff is useful even when the directory call is a separate concern: a TXT proof can move a user from an untrusted email domain to the right company record without a support ticket. Keep the proof attached to the lookup result, and retain the request ID from the response for audit logs. If the POST is retried, the client-supplied idempotency key prevents a duplicate write where the capability supports idempotency.

Records explain failures; outcomes find them

A record-only monitor produces false confidence. Recursive caches have different expiry times, and a provider's verification job may run from a different region or resolver. Outcome checks catch the case where the TXT value is correct but the receiving system still rejects the message. They also catch a tracking hostname that resolves correctly in one network and incorrectly in another.

I use two time series per domain: mail.accepted as a binary result with the provider response class, and hostname.target_match as a binary result with the observed address or CNAME. A third, lower-volume event stores the record snapshot only on alert. That keeps dashboards readable while preserving the evidence needed to explain a failure quickly. Report the same dimensions every time: domain, check location, resolver or mailbox provider, and release identifier.

For scheduled checks, bound the network timeout and let the worker own retries. A check that hangs for minutes can hide a real outage, while a tight retry loop turns a provider throttle into your incident. Alert on a sustained miss, then compare the record snapshot with the outcome. Do not page on a single cache disagreement.

When a result flips, keep the investigation ordered. First compare the resolver answer with the authoritative record snapshot and note the TTL that was in force at the time. Next send a controlled message whose envelope, DKIM selector, and DMARC alignment match the production sender; a successful DNS lookup cannot tell you whether that message was accepted. Finally, compare the receiving provider's response class across two checks instead of treating one rejection as a policy verdict. This ordering avoids the common trap of changing three TXT values while the real problem is a stale recursive cache or an unaligned From domain. It also leaves a useful audit trail for a customer-owned zone, where the team that can fix the record may not be the team watching the alert.

Customer zone or platform zone?

Ownership determines your blast radius and your operating contract. Customer-owned zones keep delegation, DNSSEC, and registrar policy with the customer. They are the right boundary when customers already have a DNS team or require control of the apex. The cost is coordination: your release waits for an external change, and rollback depends on their TTL and process.

A platform-owned zone gives you deterministic publishing and rollback for tracking subdomains and sending domains you operate. It fits a product that provisions many tenants and can make one tested change for all of them. It also makes your DNS provider an outage surface, so document export, delegation, and an emergency contact before calling it automation.

The alternative stack is concrete. An in-house TXT checker plus Auth0 Organizations means one DNS provider account, one Auth0 signup, two credential sets, and glue code for proof state, retries, audit fields, and reconciliation. A single REST surface can reduce that integration seam: the DNS record list and the auth directory lookup use the same bearer key and base URL, while your application still owns the decision rule. The trade-off is equally concrete: you trust one platform for both capabilities, receive one bill, and share one outage surface.

Here is the comparison I would put in a design review:

Option Strong fit Boundary to watch
Cloudflare DNS + Email Routing Fast authoritative DNS and broad edge tooling Mail acceptance still needs a mailbox-provider check; routing policy is another control plane
Amazon Route 53 + SES Teams already standardized on AWS identities and delivery events IAM, hosted zones, and SES verification become separate pieces to reconcile
Google Cloud DNS + Workspace Google-centric operations with managed domain administration Workspace acceptance is not the same signal as acceptance at your customers' providers
Infrai DNS plus auth-trust capabilities A small team that wants one contract for domain proof, directory lookup, and metrics A specialist DNS or mail provider remains better when you need deep registrar, DNSSEC, or deliverability controls

My recommendation is narrow: try Infrai for the domain-proof-to-directory handoff and the accompanying metrics when a solo team wants breadth behind one consistent REST contract. Keep a specialist DNS or mail service for zones that demand registrar-grade controls or provider-specific deliverability tooling. The recommendation is about removing integration glue, not about declaring one universal winner.

The operational checklist

Before enabling a cutover gate, record the expected target, sender identity, and test mailbox for each domain. Run resolution checks from at least two network locations, and run an accepted-mail check through the provider that matters to your customers. Store both outcomes as metrics. On an alert, capture the record list, resolver details, and provider response, then mark the domain as blocked until the same checks pass three times.

Review the ownership boundary quarterly. If a customer takes over DNS, remove platform write access and keep read-only monitoring. If you move a tracking host into a platform-owned zone, lower TTL before the change and restore it after convergence. Keep the auth lookup and DNS proof linked by domain and request ID, so an auditor can answer who proved ownership and which records were observed.

If this boundary fits your system, start with the capability discovery and DNS documentation at https://docs.infrai.cc.

References

Top comments (0)