| Gate | Evidence collected | What it cannot prove |
|---|---|---|
| Record-only | Expected TXT, MX, and address answers | A receiving server accepted a message |
| Outcome-first | Record answers plus a controlled delivery receipt | Every recipient's future delivery |
Short answer: For an edtech onboarding gate, choose outcome-first checks when the domain will send enrollment mail. Keep the record-only check as a fast diagnostic, not as proof that students can receive messages. A TXT lookup can confirm a claimed domain; it cannot tell you whether an enrollment message reached a mailbox. Separate ownership proof, DNS health, and mail evidence in both the UI and the stored result.
Should DNS configuration monitoring check records or mail outcomes?
The ownership gate should have a narrow pass condition: a fresh, unpredictable token is published at a specified name under the domain, and an authoritative DNS lookup returns the expected value. This shows control over that DNS name at the time of the check. It does not authenticate mail, establish control of every subdomain, or prove delivery. Give the token an expiry in your own application and require a new challenge when the ownership claim changes; the expiry is an application policy, not a DNS guarantee.
For an enrollment workflow, use a second state for mail readiness. A domain can pass its ownership challenge while a sender's SPF authorization is wrong, DKIM signatures fail verification, or DMARC alignment fails. DMARC evaluates identifier alignment with an authenticated SPF or DKIM result; the mere presence of a DMARC TXT record is not a passing result. And SMTP acceptance only says the receiving server accepted responsibility for the message at that stage, not that the learner read it or that a mailbox placed it in the inbox. Those distinctions belong in the status names. A single green "DNS good" badge hides too much. Imagine the onboarding screen showing ownership verified after a token lookup, while the controlled receipt remains pending: those are two accurate signals, and the pending result tells support which evidence is still missing without implying that DNS has failed. Conversely, when a test message gets a permanent SMTP rejection, preserve that rejection rather than relabeling the ownership challenge as failed. The distinction keeps the next action legible.
Two checks, two claims.
I would budget two independent checks here: one ownership challenge and one controlled delivery attempt to a mailbox the onboarding team can inspect. That is a trade-off, not a benchmark. The second check adds test-mail handling and recipient privacy work, but it gives operators evidence tied to the actual workflow instead of another record diff. Never send a synthetic enrollment message to a real student just to test setup.
Evidence beats a configuration snapshot
Start by recording what was asked, where it was asked, when it was observed, and what happened. For DNS, retain the queried name, record type, expected value or digest, observed answers, resolver vantage point, and timestamp. A recursive resolver may still serve cached answers during a change. DNS TTL controls how long a resolver may cache an answer; an immediate retry against the same cache is not an independent observation. Query the authoritative nameservers when validating a fresh ownership token, then check through the resolver path your production workload uses for ongoing health.
Mail needs a different trail. Log the test's correlation ID, submission result, SMTP response at the handoff you control, and a receipt from the controlled destination if one exists. Treat missing receipts as unknown until the test window ends. SMTP replies distinguish temporary failures from permanent ones; a temporary failure should schedule a bounded retry, while a permanent failure merits investigation. Do not collapse "accepted for relay" into "delivered to inbox." Even a final SMTP acceptance is weaker than an observed mailbox receipt.
The difference matters during a cutover. An operator might see the new MX answer from one resolver while a cached answer persists elsewhere. Or a sender might publish an SPF record yet use a different envelope domain than the one the enrollment team expected. Test the actual sender identity and message path, with consent and a controlled recipient. Don't infer that an MX lookup validates outbound sending: MX records specify where mail for a domain is received.
That's the trap.
A small TypeScript result contract
The check runner can remain boring. Keep DNS observations and mail observations separate, then derive the gate result from explicit evidence. This sketch accepts observations from adapters; it does not pretend that a DNS library can inspect an inbox.
type Observation = {
checkedAt: string;
source: string;
passed: boolean;
};
type OnboardingEvidence = {
ownership: Observation | null;
mailReceipt: Observation | null;
};
type Gate = "pending" | "ready" | "needs-attention";
function evaluate(evidence: OnboardingEvidence, requiresMail: boolean): Gate {
if (!evidence.ownership || (requiresMail && !evidence.mailReceipt)) {
return "pending";
}
if (!evidence.ownership.passed ||
(requiresMail && evidence.mailReceipt?.passed === false)) {
return "needs-attention";
}
return "ready";
}
The contract is deliberately small: two observations and one policy switch. In a real runner, also persist the challenge identifier, expected DNS name, test message identifier, deadline, and redacted diagnostic details. Deduplicate retries by challenge and test-message ID so a delayed receipt does not attach to a later attempt. Avoid logging token values after verification, message bodies, or student addresses. The code's checkedAt is evidence metadata, not an excuse to treat an old passing observation as current; enforce freshness at the storage boundary before calling evaluate.
That boundary is a useful DX test. If adding a second DNS vantage point requires a new configuration tree or changing the gate semantics, the interfaces are too coupled. Measure time-to-first-result in your own staging setup, including the wait for DNS propagation and the controlled mailbox, rather than quoting a universal number. Record latency distributions and failed-step counts separately. A fast TXT lookup is cheap operationally; an unnecessary mail test on every health poll creates traffic, mailbox cleanup work, and misleading noise. Run the receipt test at onboarding and on meaningful sender changes; use lightweight DNS and authentication-result monitoring between those events.
When is the smaller gate enough?
Record-only wins when the edtech domain is used solely to establish ownership of a custom hostname, with no enrollment mail sent through it. It also wins as an early preflight while the controlled mailbox is not ready. Call that result "ownership verified," never "mail ready." For incoming mail, inspect MX resolution and a controlled inbound delivery separately. For outbound mail, inspect authentication results and a controlled message sent through the intended path. Those are different tests with different failure owners.
Deploy the runner with bounded timeouts and retries, and preserve the last observation alongside the newest one so a temporary DNS timeout does not masquerade as a configuration change. Alert on persistent failure or expired evidence, not on a single transient lookup. Keep a manual review path for institutions whose mail controls block synthetic messages; a review is a different outcome, not an invented pass.
The cost question is mostly about operational load: how many mailbox probes, how much retention, and who investigates an inconclusive result. Start with the smallest set of observations that supports the claim you display. For enrollment mail, that claim requires delivery evidence beyond DNS. For ownership alone, it doesn't.
Top comments (0)