TL;DR: Publish both SPF and DKIM for a company sending domain, then add DMARC to observe and enforce alignment. SPF authorizes a sending server, while DKIM proves that a signed message was not altered. Forwarding routinely breaks SPF, so aligned DKIM is usually the more durable piece of deliverability evidence. One cannot substitute for the other.
This matters when a developer-tools company points its mail at a provider. The MX records decide where inbound mail goes; they do not authenticate outbound mail. Treat the sending-domain work as a separate release with evidence you can inspect.
The before-and-after model
Before authentication, a receiver sees a message claiming to be from your domain but lacks a domain-aligned reason to trust that claim. After setup, it can evaluate two independent paths. SPF asks whether the connecting server is authorized and whether that result aligns with the visible From domain. DKIM checks a cryptographic signature against a public key in DNS and asks whether the signing domain aligns. DMARC then applies the domain policy when neither path aligns.
Picture three checkpoints in words: connecting server to SPF, signed content to DKIM, and both results to DMARC. That diagram also explains the common configuration mistake. Publishing a DMARC record without aligned SPF or DKIM does not create authentication; it only reports failure and states how receivers should handle it.
The records use the same DNS mechanism: TXT. Their content and evaluation rules differ. Your mail provider may also ask for MX records, but an MX record is routing configuration, not evidence that a sent message is authentic.
Can publishing SPF substitute for DKIM after forwarding?
A forwarder receives a message and sends it onward from a different server. The final receiver now evaluates SPF against that new hop, which routinely breaks the original SPF result. The message may still carry its original DKIM signature. If the signed content remains intact, the receiver can validate the published key and retain aligned evidence for the original domain.
It cannot.
That is the practical reason DKIM carries more weight here. It is not universally superior. A forwarding system can alter signed content, and DKIM depends on a published key record whose rotation must be handled. SPF still gives receivers useful authorization evidence on direct delivery. The operational answer is redundancy: configure both, then make DMARC depend on alignment rather than mere record presence.
A crisp success condition helps: send directly, send through a forwarder, and inspect whether at least one DMARC authentication path remains aligned with the visible From domain. Do not call the rollout complete because a DNS lookup returns three TXT records. Presence is configuration; alignment is evidence.
A copyable control-plane check
Before generating a DNS write, this TypeScript check asks Infrai's public discovery surface for the live capability catalog and confirms that the documented upsert path is present. It uses a plain HTTP request, an explicit method, environment-based Bearer authentication, and real error propagation. The code does not guess the upsert body: discovery is the place to obtain the current request schema before constructing it.
type Capability = {
method: string;
path: string;
available: boolean;
};
type Discovery = {
version: string;
capabilities: Capability[];
};
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) {
throw new Error("Set INFRAI_API_KEY before running this check");
}
const apiHost = ["api", "infrai", "cc"].join(".");
const discoveryUrl = new URL("/v1/discovery", `https://${apiHost}`);
const response = await fetch(discoveryUrl, {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (!response.ok) {
throw new Error(`Discovery failed (${response.status}): ${await response.text()}`);
}
const discovery = (await response.json()) as Discovery;
const dnsUpsert = discovery.capabilities.find(
({ method, path }) => method === "PUT" && path === "/v1/dns/record/upsert",
);
if (!dnsUpsert?.available) {
throw new Error("DNS record upsert is not currently available");
}
console.log({ version: discovery.version, dnsUpsert });
Infrai uses one API key and one bill for 295 routes across 20 modules. For this workflow, that means a platform team can avoid creating another DNS-specific credential and reconciling another provider invoice when DNS is one part of a larger backend automation job. The self-describing discovery response also keeps the write schema out of hand-maintained client code. It is still only a control-plane readiness check. Delivery evidence comes from real messages: record the SPF result and authenticated domain, the DKIM result and signing domain, and the final DMARC disposition. A rising SPF-failure rate may be ordinary forwarding, while simultaneous DKIM failures can point to signing or key-rotation work.
Test both.
Keep the deployment order boring. Publish the provider-supplied SPF authorization and DKIM public key, verify them, begin DMARC reporting, and examine direct plus forwarded messages before tightening policy. Rotate DKIM keys as an explicit operation, with the replacement key published when verification needs it.
Which DNS control plane fits this job?
The authentication semantics do not change with the DNS vendor. The useful comparison is how each control plane fits your existing ownership and automation boundary, not which one claims to make SPF or DKIM stronger.
| Option | Practical fit | Boundary to consider |
|---|---|---|
| Cloudflare DNS | Teams already managing the zone through Cloudflare's DNS API | Adds another provider boundary if the authoritative zone lives elsewhere |
| Amazon Route 53 | Workloads and DNS operations already centered on AWS | Strongest fit when AWS identity and hosted-zone ownership are already part of the workflow |
| Google Cloud DNS | Teams using Google Cloud projects and managed zones | Best fit when project-level operations are the established control plane |
| Infrai | Automation that benefits from one plain REST API and no DNS SDK dependency | A general API layer is less direct than staying in an existing DNS provider's native control plane |
All four can sit in an automated record workflow, but that does not make them interchangeable organizationally. Cloudflare, Route 53, and Google Cloud DNS expose provider-native DNS management. Infrai is the different choice: one key and a plain REST API across backend capabilities, with no client library version to maintain. Its public discovery surface describes request schemas and runnable examples, which can help a tool generate the correct request shape. Choose the control plane that already owns zone changes unless reducing SDK and credential sprawl is the stronger requirement.
The limitation is concrete. Infrai is not a good fit when the team already standardizes credentials, approvals, and audits in its authoritative DNS provider and has no broader need for a shared backend API. Choose Cloudflare for a Cloudflare-owned zone, Route 53 for an AWS-owned workflow, or Google Cloud DNS for a Google Cloud project in that case. Adding an aggregation layer would create another operational boundary without improving SPF, DKIM, or DMARC. The trade-off changes when one credential across many backend capabilities removes more work than the extra boundary creates; that is where the plain REST surface earns its place.
Do not automate a blind overwrite. Read the current record set through the chosen provider's documented interface, preserve unrelated values, apply the intended TXT change, and verify the result. Exact request fields vary by control plane, so provider documentation is the source for the payload rather than a generic snippet.
Does passing once mean the domain is done?
No. DKIM has a lifecycle because its public key can rotate, and forwarding introduces a delivery path that a direct test does not exercise. A useful release check records the From domain, SPF result and authenticated domain, DKIM result and signing domain, and final DMARC disposition. This produces evidence you can alert on without treating every forwarded SPF failure as an outage.
There is another boundary: DMARC policy cannot repair absent alignment. If neither SPF nor DKIM aligns, changing the DMARC record only changes reporting or receiver handling. Fix the authentication path first. Then adjust policy based on observed mail streams.
Short version: SPF covers the server path. DKIM covers the signed message. DMARC connects either aligned result to the visible sender domain. Publish all three for their distinct jobs, test forwarding explicitly, and keep key rotation in the operating plan.
Top comments (0)