What DMARC evaluates and what alignment means
Email has several identities. The address a person sees in From is not necessarily the envelope identity evaluated by SPF or the domain associated with a DKIM signature. DMARC checks whether a successful authentication result relates to the visible From domain under the applicable alignment rules.
A passing aligned SPF result or a passing aligned DKIM result can satisfy DMARC. A message does not universally have to pass both mechanisms. Equally, an SPF or DKIM pass on an unrelated identity is not by itself a DMARC pass. Read the authentication identity, result and alignment together rather than relying on the word pass in isolation.
| SPF route | DKIM route | DMARC interpretation |
|---|---|---|
| Passes and aligns | Fails or is unavailable | Can pass through the aligned SPF result |
| Fails or does not align | Passes and aligns | Can pass through the aligned DKIM result |
| Passes without alignment | Passes without alignment | These passes do not satisfy DMARC alignment |
| Fails | Fails | No passing aligned route is established |
How domain policy relates to receiver handling
A domain owner can request monitoring, quarantine or rejection handling through its DMARC policy. The receiver evaluates the message and applies its own handling, which can also involve other checks or local policy. A published record is a policy signal, not a record of the final decision for every message.
Monitoring is useful for gathering evidence before a stronger policy, but it does not validate a business sender automatically. Enforcement should follow an inventory of legitimate sources and agreed acceptance checks, including systems that send only periodically. A deadline or copied DNS example is not evidence that those systems are ready.
What aggregate reports add, and what they leave out
Aggregate reporting can summarize observed authentication outcomes for sources and reporting periods. The data helps an authorized team relate sending infrastructure to business systems or an investigation. Counts, source addresses and reported handling need context; unfamiliar infrastructure is not automatically a malicious or approved sender.
A report is not a complete mailbox audit or an inbox-placement record. Reporting coverage and timing can vary, and a successful authentication result does not establish that a person opened the message or that the request was honest. Keep the report window, receiver context and business sender mapping beside the conclusion.
The current standard and implementation differences
RFC 9989, published in May 2026, supersedes RFC 7489 for the DMARC protocol; RFC 9990 describes aggregate reporting. Old tutorials and provider interfaces can retain legacy terminology. Do not treat the older pct tag as a current guaranteed staging mechanism merely because an old example contains it.
Use the relevant provider's current implementation guidance alongside the standard. The safe sequence still begins with actual senders, message evidence and authority to change policy. This entry explains the mechanism; it is not a production record to paste into DNS or an instruction to enable rejection for an unmapped domain.
What DMARC does not solve
A lookalike domain or a forged display name can impersonate a business without using the protected domain in the same way. A compromised legitimate mailbox or authorized application can send authenticated mail. The technical result therefore does not settle whether an invoice, password request or bank-detail change is legitimate.
Separate domain authentication from account security, recipient filtering, content, reputation and business verification. If a suspicious message may involve a compromised account or a payment already made, use the appropriate incident or financial response. Publishing a stronger domain policy does not replace that work.
How a business can use the definition
Ask which domain the test message displays, which identities were authenticated and which result supplied alignment. Use evidence from the trusted receiving system; an arbitrary authentication header inside a message is not automatically trustworthy. Keep examples redacted and do not share complete private mail threads or credentials in an enquiry.
CyberFixCrew is an Israeli cybersecurity company serving worldwide businesses, with a focus on websites, mail and digital infrastructure. Our related setup service scopes the sender inventory, implementation and verification separately from this definition. Country-specific legal requirements and provider feature availability need their own assessment.