DMARC implementation still fails without disciplined SPF and DKIM governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Valimail's blog post: Practical DMARC implementation becomes effective only when SPF, DKIM, reporting and phased enforcement are managed together.

Why it matters: For IAM and security teams, the governance lesson is that email trust depends on controlled sender identity, not just a DNS record, and weak implementation leaves impersonation risk in place.

Context

DMARC is an email authentication policy layer that tells receivers what to do when a message fails SPF or DKIM checks. The technical challenge is not the protocol itself, but the governance work of inventorying every legitimate sender, aligning those senders with the domain and keeping the record accurate as services change.

The article treats DMARC implementation as a staged control programme rather than a single configuration event. That framing is correct for enterprise environments, where marketing platforms, cloud notifications and third-party mailers all create identity and lifecycle dependencies that must be governed together.

Key questions

Q: How should security teams roll out SPF, DKIM, and DMARC without breaking legitimate email delivery?

A: Start by inventorying every system that sends mail on behalf of the domain, then publish SPF and DKIM for those senders before moving DMARC from monitor mode to enforcement. The practical goal is to preserve legitimate mail while closing spoofing paths. Teams should validate alignment, keep DNS records accurate, and watch for forwarding or platform changes that can cause authentication drift.

Q: Why can a legitimate email still fail DMARC even when SPF and DKIM both pass?

A: DMARC only counts SPF or DKIM when the authenticated domain aligns with the domain shown in the From header. A message can pass SPF through a third party return path, or pass DKIM with a different signing domain, and still fail DMARC because neither matches the recipient visible sender. Alignment, not just pass status, determines the result.

Q: What are common mistakes with DMARC Policy?

A: Common DMARC Policy mistakes are publishing policy before SPF and DKIM alignment is working, moving too quickly to reject, and forgetting to monitor reports for legitimate senders that fail authentication. Teams also leave subdomains uncovered or assume DMARC alone stops impersonation. Test changes gradually and review mail sources regularly.

Q: Should organisations treat third-party mail services as part of identity governance?

A: Yes. Any system that sends mail on behalf of your domain is exercising delegated identity, even if it is a marketing platform, CRM or cloud service. Those senders need ownership, lifecycle control and removal procedures just like other delegated access paths, or they become persistent trust assumptions.

Technical breakdown

How DMARC uses SPF and DKIM together

DMARC does not authenticate mail on its own. It evaluates whether SPF confirms the sending server and whether DKIM confirms message integrity with a cryptographic signature, then checks alignment between the authenticated domain and the visible From domain. That means DMARC is a policy decision point sitting on top of two separate trust signals. If either signal is misconfigured, legitimate mail can fail or spoofed mail can slip through until policy enforcement is tightened.

Practical implication: Map every sending source to the correct SPF and DKIM path before you change policy.

Why alignment and reporting matter more than a single pass or fail result

A message can pass SPF or DKIM and still fail DMARC if the authenticated domain does not align with the visible sender. That alignment check is what prevents attackers from using approved infrastructure or third-party services to send mail that appears to come from your brand. Reporting then turns the policy into a control loop by showing which sources are failing, which are legitimate and which look suspicious. Without that feedback, enforcement becomes guesswork. See the DMARC, SPF and DKIM Guide.

Practical implication: Use aggregate and forensic reports to separate misconfigured senders from likely impersonation activity.

Why phased enforcement is the safest way to reach reject

DMARC enforcement usually begins with p=none so teams can observe traffic before blocking anything. The point of the phased approach is to discover hidden senders, broken integrations and subdomain gaps before quarantine or reject starts affecting mail delivery. Organisations that skip this step often create self-inflicted outages and then weaken the policy to recover. A controlled rollout preserves business continuity while increasing protection over time. See the Email Identity and BEC Guide.

Practical implication: Move from monitoring to quarantine and reject only after you have validated every authorized sender.

NHI Mgmt Group analysis

DMARC is really a sender identity governance problem, not just an email authentication problem. The article shows that the hard part is not publishing a record, but maintaining control over every authorised mail source as marketing, cloud and SaaS systems change. That is an identity lifecycle issue in disguise, because the trust boundary is the set of systems allowed to speak for the domain.

Signed mail still fails governance when the identity behind it is not aligned. SPF and DKIM can both be technically correct, yet DMARC can still fail if the visible domain does not match the authenticated one. That matters because attackers frequently exploit trusted infrastructure and third-party senders rather than breaking cryptography. Practitioners should treat alignment as the real control boundary.

Incremental enforcement is a risk management discipline, not a convenience setting. The staged move from monitoring to quarantine to reject reflects how mature identity controls are normally deployed in complex environments. It recognises that unknown senders, subdomains and delegated services create operational blast radius if policy is tightened blindly. The practical conclusion is that email identity hardening succeeds when rollout is governed like any other enterprise control change.

Email authentication also exposes the limits of vendor-managed simplicity. The article hints that DMARC becomes difficult as soon as multiple teams and services can send on behalf of the domain. That is the point where ownership, documentation and exception handling matter more than tool choice. For security teams, the real work is establishing who controls sender identity across the business.

Service-linked mail sources need the same inventory discipline as other non-human identities. Third-party senders, notification platforms and cloud applications all act as delegated identities for the domain, even if they are not usually discussed that way. Workforce Identity Security Guide is relevant here because the same governance problem appears whenever an entity can act on behalf of a brand without being tightly lifecycle-managed. The practitioner takeaway is to govern delegated mail sources as identities, not ad hoc integrations.

What this signals

DMARC enforcement becomes a governance test of delegated trust. The operational question is not whether SPF and DKIM can be published, but whether the organisation can keep every sender current as systems are added, removed or repurposed. When that inventory drifts, the email domain becomes a trust surface rather than a controlled identity boundary.

Phased policy rollout is the control pattern that most teams actually need. Monitoring first, then limited quarantine, then reject remains the safest sequence because it exposes hidden dependencies before they become outages. In practice, the organisations that struggle most are the ones that treat email authentication as a one-time DNS task instead of an ongoing identity governance programme.

For practitioners

• Document every authorized sender Build and maintain a complete inventory of mail servers, SaaS platforms, notification services and subdomains that send on behalf of the domain.
• Publish SPF with explicit sender scope List only approved IPs and sending domains, then use the strictest qualifier that will not break legitimate mail after testing.
• Deploy DKIM per sender and subdomain Generate separate signing keys for each service that sends mail so delegated systems can be rotated or removed without affecting the rest of the estate.
• Start DMARC in monitoring mode Use p=none first, review aggregate and forensic reports, and resolve legitimate sender failures before moving into quarantine or reject.
• Tighten enforcement gradually Increase policy percentage in small steps so you can validate mail flow, subdomain coverage and exception handling before full reject.

Key takeaways

• DMARC only reduces impersonation risk when every legitimate sender is inventoried, aligned and continuously governed.
• The practical failure mode is not just a missing record, but a drifting sender estate that makes policy enforcement unreliable.
• Teams should treat phased enforcement as a control programme, because monitoring data is what makes quarantine and reject safe.

Related NHI Mgmt Group resources: Email Identity and BEC Guide · DMARC, SPF and DKIM Guide · Email Security Guide · IAM and Identity Provider Buyer's Guide

Key terms

• DMARC: DMARC is an email authentication policy mechanism that uses DNS-published records to tell receiving mail systems how to handle messages that fail alignment checks. It helps reduce impersonation risk, but it only works when the published policy is accurate, current, and governed as part of the domain's security state.
• SPF: SPF is a DNS-based policy that lists which systems are permitted to send email on behalf of a domain. It helps mail receivers validate whether the sender matches the domain’s declared sources, reducing the chance of forged or impersonated messages.
• DKIM: DKIM is an email signing method that relies on a public key published in DNS to let receivers validate message integrity. In practice, the DNS record becomes part of the trust chain, so key management and DNS governance must stay aligned if organisations want reliable authentication.
• Identifier Alignment: Identifier alignment is the rule that ties the visible From domain to the authenticated domain used by SPF or DKIM. DMARC only passes when the authenticated identity matches the domain being claimed closely enough, which prevents a message from authenticating under one domain while impersonating another.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps security practitioners connect identity controls to the broader governance challenges that shape modern access and trust.