DEV Community

SterlingVance2196
SterlingVance2196

Posted on

SPF DKIM and DMARC as One System: Alignment Beyond Three Records

#emailsecurity #dns #dmarc #backend

When a customer-support domain changes its mail path, the hard problem is not writing three DNS records. It is surviving a period in which recursive resolvers, relays, and mailbox receivers hold different versions of those records. I model SPF, DKIM, and DMARC as one state machine whose safe transition is limited by propagation delay.

Short answer: publish the new DKIM key and SPF authorization before sending with them, run DMARC in observation mode, and keep the old sender and selector alive until reports cover the expected cache interval. Faster enforcement gives less evidence and makes rollback harder to audit.

How do SPF, DKIM, and DMARC form one decision?

SPF authenticates the SMTP envelope sender (the MAIL FROM) against permitted hosts. DKIM authenticates a signature and its d= domain. DMARC evaluates the visible From domain and accepts a message when at least one of those mechanisms both passes and aligns with that visible domain. Alignment can be relaxed, allowing a subdomain relationship, or strict, requiring an exact match.

Signal Identifier Alignment failure in support mail
SPF Envelope-from domain A ticket relay rewrites MAIL FROM
DKIM d= signing domain A new selector is enabled before its key is visible
DMARC Visible From domain Enforcement starts before unknown senders are identified

The distinction matters operationally. DMARC does not require both SPF and DKIM to pass; requiring both is a reliability objective for the service, not a protocol rule. A support platform that signs with d=mailer.example.net while displaying From: support.example.com may produce a valid DKIM signature that still fails DMARC alignment under strict mode.

Which constraint should drive the cutover?

DNS has no global commit. A recursive resolver may retain an old answer until its TTL expires, and negative answers can be cached as well. Therefore a nameserver lookup that looks correct from one network is evidence of one observation point, not proof that every receiver has converged. A 300-second TTL is a hint, not a five-minute guarantee; resolver behavior and earlier cached values still matter.

For a support domain, I use this order: publish the DKIM public key, deploy the signer, authorize every current SPF sender, then publish DMARC with p=none and an aggregate-report address. Keep the previous selector and relay available while a normal support cycle passes. Only after aligned results are visible should enforcement move to quarantine and later reject, with a recorded rollback value.

This is a deliberate trade-off. Overlap consumes operational attention and leaves more authorized paths temporarily active, but it preserves an explainable audit trail. A rapid cutover reduces that overlap while increasing the chance that a cached receiver sees an old key or an old SPF include. No DNS API can remove that physics; a provider can automate edits, but it cannot force arbitrary recursive caches to refresh.

That is the constraint.

Measure it.

What evidence proves alignment rather than mere validity?

Aggregate DMARC reports contain counts, dispositions, and authentication results, yet they arrive asynchronously and do not prove that every message was delivered. SPF pass with alignment failure usually indicates an envelope-domain mismatch. DKIM pass with alignment failure usually indicates that the signing domain is a sibling or unrelated domain. Inspecting received headers at several mailbox providers remains necessary for a controlled probe.

I treat report ingestion as an audit pipeline. Delivery is commonly at-least-once, so the consumer should be idempotent even though the desired accounting result is exactly once. Store the original XML separately, restrict access because sender and source data can be sensitive, and retain an immutable observation record.

type Observation struct {
    ReportID string
    Source   string
    From     string
    SPFPass  bool
    SPFAlign bool
    DKIMPass bool
    DKIMAlign bool
}

type AuditStore interface {
    PutIfAbsent(key string, value Observation) error
}

func Record(store AuditStore, o Observation) error {
    key := o.ReportID + ":" + o.Source + ":" + o.From
    return store.PutIfAbsent(key, o)
}
Enter fullscreen mode Exit fullscreen mode

This key does not replace schema validation: report identifiers, source addresses, and domain names still need bounded lengths and canonicalization. That small discipline prevents duplicate counts from becoming a misleading enforcement signal.

A DNS provider such as Cloudflare can automate record changes, but signing and report interpretation remain separate responsibilities. Google Postmaster Tools exposes reputation and authentication signals for qualifying Gmail traffic, not a complete deployment controller. Microsoft Defender for Office 365 reports authentication outcomes inside a tenant, so its visibility is bounded by that tenant's mail flow. These tools can complement a standards-based collector; none is a universal delivery oracle.

The useful comparison is therefore about boundaries, not rankings. A managed DNS API is convenient when the team already has authoritative-zone controls, but it cannot guarantee cache convergence. A mailbox telemetry console is useful for a dominant receiver, but it cannot represent smaller providers or internal relays. A self-hosted parser offers portable retention and export, at the cost of operating storage, XML parsing, access control, and alerting. Choose the boundary that matches the evidence your compliance process must retain.

The choice is architectural, not promotional.

A compact rollout and rollback method

Inventory every support sender, including regional failover relays and automated ticket notifications. Give each signer a distinct selector. Publish keys before activation, query independent recursive resolvers, and record the observed TTL and policy at each transition. Use DMARC p=none until unknown aligned sources have been investigated; an exit criterion such as two complete business days is a policy choice, not a protocol requirement.

Then enforce gradually. Move to quarantine for a monitored slice where receivers support percentage controls, review dispositions, and only later choose reject. Rollback means restoring the prior policy and sender path while both selectors remain published. Deleting the newest record is not rollback when some receivers still cache it.

Authentication is successful when a receiver can verify SPF or DKIM and align it with the visible From throughout the interval in which caches may disagree. Design for that interval, measure it with reports and controlled probes, and preserve the evidence. Speed is available, but it is purchased with a shorter observation window and a less defensible decision.

Sources

Top comments (0)