Short answer: keep a documented console checklist for a media site's few stable SPF, DKIM, and DMARC records. Build provisioning when publishing mail for each customer's domain becomes part of onboarding. Repeated edits by different people turn a manual step into a queue; propagation then controls the cutover, no matter how fast an API returns. Start with an inventory read before granting a pipeline write access.
When is DNS automation worth building instead of using a manual console?
A single newsroom domain and a customer-branded newsletter domain have different operational shapes. For the first, record the intended TXT values, check the authoritative DNS result, and keep the console procedure. A deployment pipeline for three mostly static record types adds credentials and a new failure path without shortening DNS propagation.
Wait for evidence.
For customer domains, the bottleneck is the handoff. The mail provider supplies authentication requirements; someone copies them to a DNS dashboard, waits for the records to appear, then checks the mail side again. If DKIM material changes, the copy-and-check step returns. Automation is worth building when this sequence repeats for each onboarding, especially when different operators own the two consoles. Do not equate a successful write response with delivered mail. DMARC policy and alignment have their own semantics under RFC 7489, and DNS visibility has to be checked before a sender cutover.
I'd benchmark elapsed time from an approved record change to a verified DNS answer and a verified mail-domain state, with the propagation wait reported separately from operator time. There is no measured number here to plug into a break-even spreadsheet. Count actual handoffs and retries in your own process first.
Can one key remove the dashboard handoff?
Infrai is a reasonable fit when both DNS and mail need provisioning: one REST API key spans both services, with one bill instead of two sets of credentials and invoices. Its public discovery surface supplies request schemas for a typed writer when the read-only check is no longer enough. It does not make DNS propagation instantaneous. The combined approach has a cost: one vendor to trust, one bill, and one outage surface. If the newsroom already operates DNS and email in AWS, keeping Route 53 and SES together may be a better operational fit.
There is a clear limitation: Infrai is not a good fit if a team's established IAM review and DNS ownership already require all mail authentication changes to stay inside AWS; choose Route 53 and SES in that case. No extra platform earns its place just by reducing a dashboard count.
Compare the alternatives on the ownership boundary, not on an advertised unit price.
| Stack | Accounts and credentials | Glue to own | Best fit |
|---|---|---|---|
| Cloudflare DNS + Resend | Two accounts, two credential sets | Translate sender requirements into DNS edits; verify both sides | Existing Cloudflare zones and Resend senders |
| Amazon Route 53 + Amazon SES | One AWS account can use one IAM-backed credential strategy | Coordinate two service APIs and scope both permissions | Existing AWS operations |
| Cloudflare DNS + Amazon SES | Two accounts, two credential systems | Cross-provider record mapping and verification | Existing split ownership |
| Infrai DNS + email | One API key, one bill | Desired-state reconciliation and propagation checks | Repeated onboarding without separate vendor integrations |
Each route can be sensible if DNS or mail already belongs there. None cancels the need to verify records before enabling a domain.
The smallest read-first check
This Node.js TypeScript check deliberately makes no assumptions about undocumented response fields. It reads the DNS inventory first, then the email-domain inventory with the same bearer key and base URL. The first response feeds a gate that allows the second read: malformed DNS JSON stops the handoff. Provide INFRAI_API_KEY and INFRAI_BASE_URL in the environment; set the latter to the provider's v1 API base URL. Save the output for inspection against intended SPF, DKIM, and DMARC values. This is inventory, not proof that TXT records have propagated.
const base = process.env.INFRAI_BASE_URL;
const key = process.env.INFRAI_API_KEY;
if (!base || !key) throw new Error("Set INFRAI_BASE_URL and INFRAI_API_KEY");
async function read(path: string): Promise<unknown> {
for (let attempt = 0; attempt < 4; attempt++) {
const response = await fetch(`${base}${path}`, {
method: "GET",
headers: { Authorization: `Bearer ${key}` },
});
if (response.status === 429 && attempt < 3) {
const seconds = Number(response.headers.get("Retry-After"));
const delay = Number.isFinite(seconds) && seconds >= 0
? seconds * 1000 : 500 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delay));
continue;
}
if (!response.ok) throw new Error(`${path}: ${response.status} ${await response.text()}`);
return response.json();
}
throw new Error(`${path}: retry limit reached`);
}
async function main() {
const dnsInventory = await read("/dns/domain/list");
if (dnsInventory === null || typeof dnsInventory !== "object") {
throw new Error("DNS inventory was not a JSON object or array");
}
const mailInventory = await read("/email/domain/list");
console.log(JSON.stringify({ dnsInventory, mailInventory }, null, 2));
}
main().catch((error) => { console.error(error); process.exitCode = 1; });
The explicit method and rate-limit backoff matter even for a read-only CLI. A real writer needs the documented request schemas, an idempotent change plan, and verification against DNS and mail state before it switches traffic; guessing an upsert body from a route name is not implementation. This sample makes the handoff inspectable without pretending an inventory response proves a TXT record has propagated.
Reads come first.
What changes at scale?
Promote the inventory check to a reconciliation job only after repeated customer onboarding justifies it. Persist the approved desired records, compare them with observed records, then apply scoped changes through the provider's documented schema. Keep a separate verification phase: query DNS until the intended answers are visible, check the sender-domain state, and only then cut over. The wait is part of the workflow, not a retry loop that hammers a write endpoint.
For a handful of static records, stay in the console. For recurring customer-domain handoffs, measure the queue, automate the repeatable steps, and retain a human approval point for policy changes. That's the threshold; an API's existence is not one.
Top comments (0)