Treat SPF, DKIM, and DMARC as one acceptance pipeline: authenticate a permitted sender, preserve a signed identity, then compare at least one authenticated identity with the domain visible in From. For a property-management platform sending rent reminders and maintenance updates on a customer's domain, the release gate should be alignment evidence from real message paths, not three green DNS lookups.
TL;DR: SPF authenticates the sending path through the envelope sender domain; DKIM authenticates signed content and a signing domain; DMARC evaluates whether either authenticated domain aligns with the visible From domain, then applies the published policy and produces feedback. A record can exist and still contribute nothing to DMARC if its domain does not align.
How do SPF and DKIM become one DMARC system?
The common mental model is a checklist: publish SPF, add a DKIM key, publish DMARC. The receiver does not evaluate that checklist. It evaluates a message. DMARC takes the result of SPF and DKIM authentication and asks a separate identity question about the RFC5322.From domain, the address residents actually see.
Records are inputs.
For SPF, DMARC compares the authenticated RFC5321.MailFrom domain with the visible From domain. If the envelope sender is absent, the HELO identity can be relevant to SPF processing. For DKIM, DMARC compares the domain in the signature's d= tag with the visible From domain. One passing, aligned path is enough for DMARC to pass; both do not need to align on every message.
That distinction matters during forwarding. SPF checks the client IP against the domain used by the SPF evaluation, so a forwarder can change the path and cause SPF to fail. A valid DKIM signature can survive forwarding when the signed fields and body remain valid. Mailing-list modifications or footer insertion can break that signature. Neither mechanism is a universal backup.
The operational trap is crisp: spf=pass for a platform-owned bounce domain and dkim=pass for a platform-owned signing domain can coexist with dmarc=fail for notices.example-property.com. Authentication passed; alignment did not.
Consider a scheduled rent-reminder job that hands mail to an outbound relay. The relay uses bounce.relay.example as RFC5321.MailFrom, signs with d=relay.example, and leaves From: billing@notices.example-property.com untouched. SPF can pass because the relay is authorized for its own bounce domain. DKIM can pass because the signature verifies against the relay's key. Yet neither authenticated domain aligns with the property company's visible From domain, so DMARC has no passing aligned path. Adding another SPF include to the property domain does not repair that particular message if the evaluated MailFrom remains the relay's domain. Publishing another DKIM selector under the property domain does not help unless the message is actually signed with that domain. The correction belongs in the live sending configuration: arrange an aligned envelope domain, an aligned signing domain, or both, then send a new message and inspect the result. This example also explains why screenshots of DNS records are weak release evidence. They show potential configuration, while the received message shows which identity the system used.
Model the message as two independent paths
For each message stream, record the visible From domain and the two possible alignment paths. Do this separately for rent reminders, maintenance updates, application receipts, and human replies because they may travel through different systems.
| Stream | Visible From | SPF identity to inspect | DKIM identity to inspect | Evidence required |
|---|---|---|---|---|
| Rent reminder | notices.example-property.com |
Envelope sender domain | DKIM d= domain |
At least one passing aligned path |
| Maintenance update | alerts.example-property.com |
Envelope sender domain | DKIM d= domain |
At least one passing aligned path |
| Leasing receipt | leasing.example-property.com |
Envelope sender domain | DKIM d= domain |
At least one passing aligned path |
Alignment can be strict or relaxed. Under relaxed alignment, the authenticated domain and visible From domain may share the same Organizational Domain. Under strict alignment, they must be identical. SPF and DKIM have separate alignment modes, selected by DMARC's aspf and adkim tags; their defaults are relaxed. This is why a policy review must include the effective modes rather than only the p= value.
Keep the dependency graph explicit: SPF depends on the actual outbound IP path and its evaluated domain, DKIM depends on key publication plus signature survival, and DMARC depends on the resulting authentication and alignment. DNS publication starts the system. Receiver evaluation completes it.
Messages decide.
Make the cutover safe
Start with inventory, not policy enforcement. Enumerate every legitimate sender that can place the customer domain in the visible From field, including scheduled billing jobs, maintenance queues, support tools, and any building-level relay. Unknown senders are a migration risk because a stronger DMARC policy can expose their lack of alignment.
Publish keys and authorize paths according to the standards, then configure each sender to use an aligned envelope sender or DKIM signing domain. Prefer distinct selectors and message-stream labels where the sending architecture permits them; separation makes rotation and diagnosis less ambiguous. Do not count DNS presence as proof. Send representative messages through each production path and inspect the receiver's authentication results.
The following Go model is intentionally small. It captures the release decision without pretending to perform DNS lookup, SPF evaluation, DKIM verification, or Organizational Domain discovery. Those inputs must come from a standards-aware verifier.
package main
import "fmt"
type Result struct {
SPFPass, SPFAligned bool
DKIMPass, DKIMAligned bool
}
func (r Result) DMARCPass() bool {
return (r.SPFPass && r.SPFAligned) ||
(r.DKIMPass && r.DKIMAligned)
}
func main() {
r := Result{
SPFPass: true, SPFAligned: false,
DKIMPass: true, DKIMAligned: true,
}
fmt.Println(r.DMARCPass())
}
A boolean is not sufficient evidence for an on-call handoff. Store the stream name, visible From domain, envelope domain, DKIM d= domain and selector, observed receiver result, and test timestamp. Exclude message bodies and recipient data from the evidence unless they are required; authentication diagnosis does not justify retaining tenant content.
Move policy in controlled stages. DMARC defines none, quarantine, and reject policies, plus reporting mechanisms. A monitoring policy is useful while the sender inventory is incomplete, but it is not the desired steady state when the domain owner intends receivers to act on failures. Aggregate reports describe observed authentication disposition; they are feedback, not a guarantee that every mailbox provider will deliver a message.
This method has a real limitation: DMARC evidence covers domain authentication and reported disposition, not inbox placement or human readership. A p=none phase trades enforcement for observation, while quarantine or reject asks receivers to act on failures and raises the cost of an incomplete sender inventory. Relaxed alignment accommodates legitimate subdomain layouts but accepts a broader identity relationship than strict alignment. Strict alignment narrows that relationship and demands tighter coordination across every sender. Choose those trade-offs from the domain owner's threat model and observed mail paths, not from a generic maturity ladder.
Verify the system, not the zone
The pre-deployment check should cover every sending path and at least one realistic receiving path. Confirm the visible From domain, identify which alignment path passed, and verify that the result remains acceptable after the transformations the message normally encounters. A direct test alone does not exercise a forwarding path.
Then watch ratios by customer domain and stream: DMARC pass, aligned SPF pass, aligned DKIM pass, and messages with neither aligned path. Keep the denominator. Ten failures mean something different in a stream of twenty messages than in a stream of a million. Aggregate reports are delayed operational evidence, so pair them with controlled message tests during a change window.
Page on loss of both aligned paths, not on an isolated SPF or DKIM failure. Either mechanism may be the expected surviving path for a particular route. Alerting on every single-mechanism failure produces noise and hides the condition DMARC actually evaluates.
Keep the denominator.
There is another useful signal: a sudden appearance of an unknown source using the customer domain. It might be abuse, or it might be an unrecorded leasing workflow. Treat it as an ownership question before changing authorization. The runbook should name who can classify the source and how quickly policy changes can be approved.
Roll back without losing the evidence
Rollback has two layers. If a newly configured sender breaks alignment, stop or reroute that stream to the last known-good authenticated path. If the domain policy itself is rejecting legitimate mail, reduce enforcement in a controlled DNS change while preserving the reports and samples that explain the failure. Account for DNS caching when setting expectations; a policy edit is not an instantaneous global switch.
Do not delete selectors, sender records, or telemetry during the rollback. That erases the comparison needed for the postmortem and can disrupt messages still in flight. Record the effective DNS values, the affected streams, the first and last observed failures, and which aligned path disappeared.
The durable acceptance rule is short: every property-notice stream must demonstrate at least one aligned authentication path at representative receivers, and the team must be able to identify the owner of the other path when it fails. This frames deliverability as evidence with a rollback plan, rather than confidence inferred from three records.
Top comments (0)