Short answer: Publish and align both SPF and DKIM; forwarding can break SPF while preserving DKIM, so one record is never a substitute for the other.
Moving an edtech sending domain off a registrar API forces a choice between fast cutover and predictable DNS propagation. Stage both records, verify alignment under DMARC, then switch traffic after the old path has drained. A quick DNS edit can still leave regional resolvers serving yesterday's answer.
What does each record actually prove?
SPF authorizes hosts listed in a domain's TXT policy to send mail for that domain. The receiver evaluates the envelope-from identity. SPF can pass while the visible From domain is unrelated; DMARC calls that an alignment failure. Ten lookups is the limit. A long include chain can fail even when every individual provider is legitimate.
DKIM signs selected headers and the message body with a private key. The receiver fetches the public key from a selector such as s2026._domainkey.school.example. The signature survives ordinary forwarding better than an SMTP client IP does. That helps. List software can still modify signed content and invalidate it. Rotating selectors gives an overlap window: publish the new key, sign with both during migration, then retire the old key after its TTL has elapsed.
DMARC evaluates alignment between the authenticated SPF or DKIM domain and the visible From domain. RFC 7489 defines relaxed and strict alignment. A passing SPF result therefore does not substitute for DKIM, and DKIM from an unrelated service domain may still fail policy alignment.
Can publishing one SPF or DKIM record substitute for the other during forwarding?
Forwarding commonly changes the connecting IP and envelope sender. The forwarder cannot pass the original sender's SPF check unless it rewrites the envelope, and rewriting can break bounce handling. DKIM has a different failure mode: it can remain valid through a forward only if signed content survives untouched. DMARC accepts either aligned SPF or aligned DKIM.
For a tutoring platform, the original transaction might use From: notices.school.example, envelope-from bounce.school.example, and DKIM d=school.example. After forwarding to a parent mailbox, the receiving system may see a new SMTP client and the same DKIM signature. The useful diagnostic is the Authentication-Results header at the final hop, correlated with DMARC aggregate reports.
This Python sketch accepts normalized results from a receiving probe; it does not pretend to be a DNS resolver or DMARC parser.
def aligned_pass(*, spf_pass, spf_domain, dkim_pass, dkim_domain,
from_domain, strict=False):
def matches(auth_domain):
if strict:
return auth_domain.lower() == from_domain.lower()
return (auth_domain.lower() == from_domain.lower() or
auth_domain.lower().endswith("." + from_domain.lower()))
return (spf_pass and matches(spf_domain)) or (dkim_pass and matches(dkim_domain))
The gate should record which branch passed. If both fail, hold the new sender in a canary queue and keep the registrar-managed path available while resolvers converge. An authoritative lookup showing the new TXT value is not proof that public resolvers have updated.
How should propagation affect the cutover decision?
Set record TTLs lower before migration, but do not assume every cache honors the requested value. I use three checkpoints: authoritative DNS, several recursive resolvers, and an end-to-end mailbox probe. Cut over only when the latter two agree for an observation interval chosen by the team.
There is a real trade-off. A short overlap reduces duplicated state but increases the chance that one region still uses the old selector or SPF include. A longer overlap costs attention but makes rollback boring: restore the previous route, keep both DKIM selectors published, and continue collecting DMARC reports.
Boring rollback wins for student password resets.
Inventory every envelope-from, visible From, DKIM selector, and forwarding path. Publish target SPF and DKIM records alongside existing records, respecting SPF's lookup budget. Send signed canaries through real forwarding paths. Compare Authentication-Results with DMARC aggregate data, watching alignment failures rather than raw pass counts. Switch traffic after the observation interval, retain old credentials and records through the planned cache window, then remove obsolete includes and selectors.
The decision is not “SPF or DKIM.” It is how much propagation uncertainty the learning workflow can tolerate, and which aligned signal will survive the next forward.
Top comments (0)