Email can carry several domain identities at once. The address displayed in the From header can differ from the envelope sender used by SMTP, while a DKIM signature can name yet another domain in its d= tag. SPF and DKIM authenticate identities from those separate protocol layers; neither mechanism alone requires its authenticated domain to match the domain presented to a recipient in From.
Domain-based Message Authentication, Reporting, and Conformance (DMARC), specified in RFC 7489, connects those layers. A receiver evaluates SPF and DKIM, tests domain alignment against the RFC5322.From domain, and obtains a policy published by that domain. A message passes DMARC when at least one qualifying SPF or DKIM path both authenticates successfully and aligns.
SPF contributes an aligned path through the envelope identity
SPF validates whether the connecting SMTP client is authorized for an SPF identity. For ordinary mail transactions, the relevant identity is commonly the RFC5321.MailFrom domain. DMARC then compares that authenticated domain with the domain in RFC5322.From.
Suppose a message contains:
MAIL FROM:<bounce@mail.example.com>
From: Billing <billing@example.com>If SPF passes for mail.example.com, relaxed DMARC alignment can treat that result as aligned with example.com because both belong to the same organizational domain. Under strict alignment, the domains must match exactly, so this SPF path would not align.
A successful SPF result for an unrelated envelope domain does not produce a DMARC pass for example.com. SPF authentication and DMARC alignment are separate decisions.
DKIM contributes an aligned path through the signing domain
DKIM attaches a cryptographic signature to selected message headers and the message body. Its d= tag identifies the signing domain. DMARC compares that domain with RFC5322.From after DKIM verification succeeds.
A simplified signature can contain:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...For a message whose visible From domain is example.com, a valid signature with d=example.com is aligned under both strict and relaxed modes. A valid signature from mailer.example.net can still establish DKIM authenticity for that signer, but it does not align with example.com and therefore cannot by itself make DMARC pass for that From domain.
Multiple DKIM signatures can be present. DMARC needs only one valid DKIM signature with suitable alignment to provide a passing DKIM path.
Relaxed and strict alignment set different domain boundaries
A DMARC record can select alignment modes with aspf for SPF and adkim for DKIM. The default for each is relaxed alignment. Strict mode is selected with s.
A policy record can therefore include:
v=DMARC1; p=reject; adkim=s; aspf=sStrict alignment requires an exact DNS-domain match between the authenticated identifier and RFC5322.From. Relaxed alignment compares organizational domains according to the DMARC specification’s domain model.
This distinction affects legitimate mail architectures. A service that signs as a subdomain can satisfy relaxed alignment while failing strict alignment for a parent-domain From address. Tightening alignment is therefore a routing and identity decision, not merely a syntax change in the TXT record.
Policy is consulted after the authentication and alignment result
A domain publishes DMARC policy beneath _dmarc. A compact record can be:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"The p tag states the requested receiver policy for messages that fail the DMARC mechanism. RFC 7489 defines none, quarantine, and reject. none requests no specific delivery treatment based on DMARC failure, quarantine asks receivers to treat failing mail as suspicious, and reject asks for rejection during SMTP handling.
These values are published policy requests within the DMARC processing model. They do not convert SPF or DKIM into universal sender authorization, and they do not guarantee identical handling by every receiver. Local receiver policy remains relevant.
The sp tag can specify policy for subdomains when present. Without it, the applicable DMARC rules determine how the parent policy is inherited. Domain operators therefore need to account for subdomains that legitimately send mail before applying a restrictive policy.
Aggregate reports expose authentication and alignment outcomes
The optional rua tag identifies destinations for aggregate feedback. Supporting receivers can send XML reports that summarize observed source IPs, message counts, policy disposition, and SPF or DKIM evaluation data for the reporting period.
Aggregate reports do not carry the original message body as a normal part of their aggregate record format. They are operational telemetry for observing authentication behavior across mail streams. A domain can use that telemetry to identify legitimate systems that still send with unaligned identities before moving from monitoring toward a stricter policy.
Report delivery has its own authorization rules when the destination lies outside the policy domain. Publishing an arbitrary external rua address does not automatically authorize that domain to receive reports.
Forwarding exposes the difference between SPF and DKIM paths
Mail forwarding can change the SMTP client that connects to the final receiver. The original envelope identity may then fail SPF because the forwarding system’s IP address is not authorized by the original domain. A DKIM signature can survive forwarding if the signed content remains valid and the signing domain aligns with RFC5322.From.
That asymmetry is central to DMARC’s two-path design. A DMARC pass does not require both SPF and DKIM to pass and align. One aligned, authenticated path is sufficient. Conversely, SPF and DKIM can each report successful authentication for domains unrelated to RFC5322.From while DMARC still fails because neither result aligns.
DMARC therefore adds an identity relationship rather than a third independent proof of message origin. Its decision is built from existing SPF and DKIM results, the visible From domain, alignment rules, and the sender domain’s published policy. Keeping those components separate makes configuration errors easier to isolate: authentication can succeed while alignment fails, and policy enforcement begins only after that distinction has been evaluated.