Zero Trust email needs DMARC, PKI and TLS together

At a glance

What this is: This is an analysis of how DMARC, PKI, and TLS combine to extend Zero Trust from web traffic into email identity verification.

Why it matters: It matters because identity teams cannot treat email as a separate trust domain, and gaps in sender verification still drive phishing, impersonation, and domain abuse across NHI, autonomous, and human-facing communications.

By the numbers:

• 69% of organisations now have more machine identities than human ones.
• 57% of organisations lack a complete inventory of their machine identities.

👉 Read DigiCert's analysis of Zero Trust email, DMARC, PKI and TLS

Context

Zero Trust for email means the sender must be verified before the message is trusted, just as a website certificate must be validated before a browser accepts a connection. DigiCert’s core point is that email still relies too heavily on implicit trust in the visible From field, which makes it a weak link in broader identity security programmes.

That gap matters to IAM and security architects because phishing and impersonation often succeed before any user control, email gateway, or awareness training can intervene. DMARC, SPF, DKIM, PKI, and TLS are not separate concerns here, they are the channel-specific controls that make identity verification real across both machine-driven and human-facing communications.

Key questions

Q: How should organisations implement DMARC without breaking legitimate mail flow?

A: Start by inventorying every system that sends email for the organisation, then publish SPF and DKIM for each legitimate source. Run DMARC in monitoring mode only long enough to identify gaps, and then move gradually to quarantine and reject. The goal is to prove coverage before enforcement, not to avoid enforcement forever.

Q: Why do email impersonation attacks still work in Zero Trust programmes?

A: They still work because many programmes verify users and devices but leave the email channel dependent on implicit trust. If the receiving domain does not enforce DMARC, attackers can exploit the visible sender name and address even when web access and endpoint controls are strong. Zero Trust fails when one channel is exempt.

Q: What do security teams get wrong about SPF and DKIM?

A: They often treat SPF and DKIM as complete controls when they are really evidence inputs. Without DMARC policy, authenticated messages can still be delivered even when they fail alignment or come from an unexpected source. Teams should measure whether authentication evidence is actually being enforced at the receiving edge.

Q: Who is accountable for email authentication across domains and SaaS senders?

A: Accountability should sit with both security and the teams that own the domains or applications sending mail. A shared service can send messages, but it still needs an owner who maintains records, reviews failures, and removes old trust paths. Without clear ownership, email authentication degrades into a technical orphan.

Technical breakdown

Why email identity verification differs from web TLS

Web traffic and email solve different trust problems. PKI and TLS give browsers a cryptographic way to verify server identity and encrypt the connection before data moves. Email was not designed with the same default verification model, so the visible From address can claim almost anything unless the receiving domain enforces authentication checks. That mismatch is why email remains attractive for impersonation and phishing. The core issue is not delivery, it is identity assurance at message receipt.

Practical implication: treat email authentication as a first-class identity control, not as a content filter problem.

How SPF, DKIM, and DMARC work as a layered control

SPF authorises sending servers, DKIM signs messages so tampering can be detected, and DMARC ties both to the domain shown to the user. DMARC is the policy layer. It decides whether a message that fails authentication should be delivered, quarantined, or rejected. That makes it the enforcement mechanism, while SPF and DKIM provide the evidence. In practice, the stack only works when all legitimate senders are covered and policy moves beyond monitoring to enforcement.

Practical implication: map every sender first, then raise DMARC from visibility to quarantine and reject.

Why Zero Trust email is a governance model, not just a mail setting

Zero Trust email is really about consistent verification across channels. The same organisation that requires certificate validation for web access should not accept unverified sender identity in email. That is a governance problem because it crosses security, messaging, domain administration, and third-party service ownership. It also exposes operational blind spots, such as legacy domains, parked domains, and SaaS platforms that send on behalf of the business without being explicitly governed.

Practical implication: assign ownership for every sending domain and include email authentication in identity governance reviews.

Threat narrative

Attacker objective: The attacker aims to gain trust at the inbox boundary so they can deliver phishing, impersonation, or business email compromise at scale.

1. Entry occurs when an attacker sends email that claims to come from a trusted domain or business contact.
2. Credential-harvested or abused access is not required here because the attack succeeds by exploiting the receiver’s implicit trust in the sender identity.
3. Impact follows when the recipient opens a malicious link, shares data, or authorises a fraudulent action based on the forged message.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Implicit trust in the From field is a broken identity assumption, not a mail hygiene issue. Email security still fails when organisations treat sender identity as self-declared rather than verified. That assumption aged badly once phishing became industrialised and third-party delivery platforms multiplied. The implication is that email must be governed as an identity channel, not just a messaging channel.

DMARC is the policy layer that turns authentication evidence into enforceable trust decisions. SPF and DKIM can prove that a message is authorised or intact, but without DMARC they do not force a response. This is why partial deployments often create a false sense of control: visibility exists, but blocking does not. Practitioners should read this through NIST CSF and NIST SP 800-207, where verification and enforcement must align.

Zero Trust email exposes the same governance gap seen in NHI programmes: ownership without lifecycle control. Parked domains, legacy senders, and SaaS mail systems often outlive the teams that configured them. That creates unmanaged trust paths, much like orphaned service identities in other environments. The practitioner lesson is that sender governance needs inventory, ownership, and offboarding discipline, not just technical policy.

Brand impersonation is an identity risk because the victim experience happens before the security stack can intervene. Users do not evaluate SPF records when they decide whether to trust a message. That means the control point must sit at domain policy and receiving-enforcement level. For security leaders, this makes email authentication a board-relevant trust control, not an isolated email admin task.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• Manual processes still dominate: 61% rely on spreadsheets or manual tracking for machine identity management, according to the same report.
• For a broader view of identity trust controls, see Ultimate Guide to NHIs , Regulatory and Audit Perspectives.

What this signals

Email authentication is becoming part of the wider identity governance surface. As organisations add more machine identities, third-party senders, and automated communication channels, the boundary between email security and identity management keeps shrinking. Teams that already struggle to govern non-human identities should expect the same ownership and lifecycle problems to show up in email sender ecosystems.

DMARC enforcement should be treated as a trust-control maturity marker. The difference between reporting and rejection is the difference between seeing impersonation and stopping it. For practitioners, the real signal is whether email authentication is reviewed alongside the rest of the organisation’s identity and access posture, not left to messaging administrators alone.

A useful framing is sender lifecycle debt: legacy domains, dormant SaaS senders, and unmanaged subdomains keep transmitting trust long after their original business purpose has ended. That debt becomes visible only when organisations start tying domain ownership, offboarding, and policy enforcement together.

For practitioners

• Inventory every sending domain and service Build a complete list of domains, subdomains, and SaaS platforms that send mail on behalf of the organisation, including parked and legacy domains. Unknown senders are where trust gaps begin, so assign explicit ownership before changing policy.
• Move DMARC from visibility to enforcement Start with p=none only long enough to learn the sender landscape, then move to quarantine and reject once all legitimate sources are covered by SPF and DKIM. Enforcement is what stops impersonation, not reporting alone.
• Review email authentication in identity governance cycles Include SPF, DKIM, and DMARC status in periodic access and domain reviews alongside other trust controls. Use the same governance process you apply to credentials and workload identities so email senders do not become unmanaged trust paths.
• Align web and email verification policy Compare certificate validation, TLS posture, and domain authentication so the organisation applies one trust standard across channels. If web connections require verification, email should not be treated as an exception.

Key takeaways

• Email remains a Zero Trust exception in many organisations because sender identity is still accepted without enforcement.
• SPF and DKIM provide evidence, but DMARC is the control that turns evidence into a trust decision.
• Practitioners should treat email authentication as an identity governance problem with ownership, lifecycle, and enforcement requirements.

Key terms

• DMARC: Domain-based Message Authentication, Reporting, and Conformance is an email policy standard that tells receiving systems how to handle messages that fail authentication checks. It connects sender verification to enforcement, which makes it a governance control rather than just a reporting tool.
• SPF: Sender Policy Framework is a DNS-based control that lists which servers are allowed to send email for a domain. It helps receiving systems determine whether the sending source is authorised, but it does not by itself stop spoofed messages unless paired with policy enforcement.
• DKIM: DomainKeys Identified Mail adds a cryptographic signature to outgoing email so the receiver can verify that the message was sent by an authorised source and not altered in transit. It provides integrity evidence, but it needs policy logic to affect delivery decisions.
• Email Sender Governance: Email sender governance is the discipline of inventorying, owning, reviewing, and retiring the systems that send mail on behalf of an organisation. It becomes essential when business platforms, legacy domains, and SaaS services can all create trusted-looking messages.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Zero Trust email: How DMARC works with PKI and TLS. Read the original.