DMARC fails when neither SPF nor DKIM both passes and aligns with the visible From domain. That means a message can be authenticated at the transport layer and still be rejected or quarantined because the domain the recipient sees is not properly authorised. In practice, that creates deliverability problems and leaves room for spoofing.
Why This Matters for Security Teams
DMARC is the policy layer that turns SPF and DKIM from isolated checks into a practical anti-spoofing control. When alignment is missing, mail can appear legitimate to a receiver while still failing the authorisation test tied to the visible From domain. That creates two risks at once: business mail gets flagged or dropped, and attackers keep room to impersonate brands, suppliers, or executives. The NIST Cybersecurity Framework 2.0 treats identity and authentication as core protective measures, which is why email authentication failures should be handled as a control gap, not a nuisance.
Practitioners often get caught by assuming SPF or DKIM success alone is enough. It is not. DMARC only works when one of those mechanisms passes and aligns with the domain in the From header. That distinction matters because a message forwarded through intermediaries, relayed by a SaaS platform, or sent from a poorly configured service may authenticate technically but still fail policy evaluation. In practice, many security teams encounter DMARC failure only after users report delivery issues or a phishing campaign has already exploited a weak sender domain.
How It Works in Practice
DMARC evaluates two things: whether SPF and/or DKIM pass, and whether the authenticated domain aligns with the domain presented to the recipient. SPF alignment checks the envelope sender domain, while DKIM alignment checks the signing domain in the d= tag. A message can pass one or both tests and still fail DMARC if the domains do not match the visible From address. That is why alignment, not mere authentication, determines the final result.
Operationally, this means teams need to review every legitimate sending source, including marketing platforms, ticketing systems, payroll tools, and cloud mail relays. Each source must be configured so that either SPF or DKIM aligns with the organisational domain, or both do. Current guidance suggests using DKIM as the more resilient long-term control because SPF is vulnerable to forwarding and changes in sender infrastructure. For implementation and receiver behaviour, RFC 7489 remains the core reference for DMARC.
- Inventory all mail sources that send on behalf of the domain.
- Confirm the From domain, SPF domain, and DKIM signing domain are intentionally mapped.
- Use DMARC reports to identify sources that pass authentication but fail alignment.
- Move from monitoring to quarantine and then reject only after legitimate traffic is remediated.
- Re-test after changes to SaaS tools, DNS, forwarding rules, or subdomain policy.
For message authentication best practice, OWASP guidance on email spoofing defence is useful for translating policy into sender configuration and review steps. These controls tend to break down when organisations rely on multiple outsourced mail systems with inconsistent DNS ownership, because alignment drift is easy to miss across changing service providers.
Common Variations and Edge Cases
Tighter DMARC enforcement often increases operational overhead, requiring organisations to balance spoofing resistance against legitimate mail flow. That tradeoff is especially visible during rollout, when some messages must still be allowed while sender inventories are being cleaned up. Best practice is evolving, but there is no universal standard for how quickly every organisation should move to reject; the right pace depends on how stable the mail ecosystem is and how much third-party sending is involved.
Forwarding remains the most common edge case because SPF can fail when mail is relayed, even if the original sender was authorised. Mailing lists can also rewrite headers in ways that disrupt alignment, and some transactional platforms generate DKIM signatures from vendor-controlled subdomains that do not align cleanly with the brand domain. For teams handling regulated communications or high-volume customer mail, a staged policy with strong monitoring is usually safer than an abrupt reject posture. The CISA email authentication guidance is especially helpful when explaining these edge cases to administrators and business owners.
Where DMARC is most fragile is in complex hybrid environments with legacy systems, delegated DNS, or multiple business units sending from the same brand domain, because alignment decisions become inconsistent long before anyone notices the policy impact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | DMARC supports protecting message integrity and trusted communications. |
| OWASP Non-Human Identity Top 10 | Email sender domains act like identities that need governance and trust boundaries. | |
| NIST SP 800-63 | Alignment failures are an identity assurance problem for the sender domain. | |
| NIST Zero Trust (SP 800-207) | PEP | DMARC enforces policy after authentication, similar to policy decision and enforcement. |
| NIS2 | Email spoofing resilience supports incident prevention and operational security duties. |
Document email authentication controls as part of broader resilience and incident reduction measures.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
