What is email authentication?

Email authentication is a set of protocols that verify whether an email actually came from the domain it claims to come from. Without it, anyone can send an email that appears to originate from your organization's domain, and receiving mail servers have no reliable mechanism to tell the difference between a legitimate message and a spoofed one.

Understanding email authentication

The three protocols that form the foundation of email authentication are Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). Each addresses a different part of the authentication problem, and together they give receiving mail servers both the information and the instructions needed to act on unauthenticated traffic.

SPF, developed in the early 2000s, allows a domain owner to publish a list of IP addresses authorized to send email on that domain's behalf. When a message arrives, the receiving server checks whether the sending IP appears on that list. DKIM, which followed shortly after, adds a cryptographic signature to outgoing messages. The receiving server retrieves the corresponding public key from the sender's DNS record and uses it to verify that the message was not altered in transit. DMARC ties SPF and DKIM together and introduces a policy layer: domain owners can instruct receiving servers to monitor, quarantine, or outright reject messages that fail authentication checks. According to SC World's 2026 email authentication analysis, organizations tend to fall into three groups regarding these protocols: those who do not understand them, those who understand them but have not prioritised implementation, and those who believe they have implemented them correctly when they have not.

The impact of misconfigured email authentication

The consequences of weak or absent email authentication are measurable and direct. According to Cloudflare's 2026 threat report, 46% of all emails fail DMARC validation, reflecting just how much unauthenticated traffic continues to flow through global email infrastructure. When DMARC is absent or set only to monitor, spoofed messages reach inboxes unchecked, giving attackers a frictionless path to impersonation, phishing, and social engineering.

Healthcare organizations carry particular exposure. According to Paubox's 2026 Healthcare Email Security Report, 74% of organizations that suffered email-related breaches in 2025 either lacked DMARC entirely (41%) or operated in monitor-only mode (33%). Over half of breached organizations used permissive SPF configurations, 46% used soft-fail policies, and 9% had no SPF record at all. None of the breached organizations enforced MTA-STS, leaving email delivery dependent on opportunistic encryption that can be bypassed in a downgrade attack. According to Paubox's 2025 Healthcare Email Security Report, 30.6% of breached organizations in 2024 lacked DMARC records entirely, and 34.4% had DMARC in monitor-only mode.

The regulatory environment is also shifting. In the United States, the Cybersecurity and Infrastructure Security Agency (CISA) issued Binding Operational Directive 18-01 in 2017, requiring federal agencies to implement full DMARC enforcement. In the European Union, the Digital Operational Resilience Act (DORA) creates liability for organizations whose cyberattacks could have been avoided through reasonable measures, with email authentication increasingly viewed as one of those measures.

How email authentication works

When an organization sends an email, the receiving mail server runs a sequence of checks before deciding how to handle it. SPF confirms whether the sending server's IP address is listed in the domain's authorized sender record. DKIM verifies the cryptographic signature attached to the message, confirming the email originated from the attested domain and was not modified in transit. DMARC then checks whether at least one of those two protocols passed and whether the authenticated domain aligns with the visible From address in the message header.

That alignment requirement is where many organizations encounter unexpected failures. SPF and DKIM can each pass independently, while DMARC still fails, because DMARC requires the authenticated domain to match the domain in the From header that recipients actually see. A message routed through a third-party sending service, a marketing platform, a CRM, or a billing system may use a different envelope sender domain, causing DMARC alignment to fail even when SPF and DKIM are individually configured.

DMARC operates across three policy modes. At p=none, no action is taken on failing messages; they are delivered normally, and the policy serves only as a monitoring tool. At p=quarantine, failing messages are sent to spam or junk folders. At p=reject, the receiving server refuses to deliver them entirely. The gap between p=none and p=reject is where most organizations stall. Many organizations settle on quarantine mode as a compromise, but users often retrieve messages from junk folders, particularly when messages appear to come from trusted contacts, which means quarantine is not a true safeguard against spoofing and phishing.

Why email authentication gaps persist

The technical complexity of moving to full DMARC enforcement creates a genuine implementation barrier. Before setting a reject policy, an organization must identify every legitimate source of email sent from its domain marketing platforms, ticketing systems, payroll services, CRMs, and any third-party application that sends on the organization's behalf. Each of those senders needs to be authorized in SPF and signing with DKIM before enforcement can proceed without disrupting legitimate mail flow.

Healthcare organizations face a version of this challenge that is compounded by vendor complexity. According to Paubox's 2026 Healthcare Email Security Report, 28% of email-related breaches in 2025 involved a business associate, meaning the misconfigured authentication often sits with a vendor rather than the covered entity itself. A billing service, a referral network, or a patient engagement platform operating under a healthcare organization's domain with weak authentication extends that organization's attack surface in ways that may not be visible without active monitoring.

SPF alone also has a structural limitation worth understanding. SPF checks the envelope sender domain, not the visible From address. An attacker can spoof the From address while using an entirely different envelope sender that passes SPF, which is precisely why DMARC's alignment requirement exists. According to Cloudflare's explanation of email authentication protocols, SPF and DKIM function as separate verification layers, but without DMARC tying them together and specifying a policy, neither prevents a spoofed From address from reaching a recipient's inbox.

Recognizing email authentication failures

Authentication failures surface in DMARC aggregate reports, which mail servers generate and send to the address specified in a domain's DMARC record. A domain operating at p=none receives these reports without any messages being blocked, allowing administrators to see what is being sent on their behalf and whether those sources are passing or failing authentication before moving to enforcement.

Warning signs that authentication is misconfigured include a pattern of phishing reports from recipients who received emails appearing to come from your domain, bounce notifications referencing authentication failures, or DMARC reports showing unfamiliar sending sources. In healthcare specifically, Paubox's Top 3 Healthcare Email Attacks in 2025 report identifies impersonation as appearing repeatedly inside the most damaging email breaches of 2025, often functioning as the trigger that turns unauthorized access into patient data exposure. Weak DMARC posture is the configuration gap that makes domain impersonation possible.

Best practices for email authentication in healthcare

Moving from p=none to p=reject is the defining action. Organizations should begin with a monitoring period at p=none, review DMARC aggregate reports to map all legitimate sending sources, configure SPF and DKIM for each of those sources, then progress to p=quarantine and eventually p=reject as confidence in the configuration grows. SPF records should use hard-fail configurations rather than soft-fail, so that messages from unauthorized servers are rejected outright rather than delivered with a warning flag.

Healthcare organizations with complex vendor ecosystems benefit from working through authentication setup systematically across business associates, not just their primary domain. According to Paubox's 2026 Healthcare Email Security Report, none of the breached organizations analyzed in 2025 enforced MTA-STS, a protocol that requires encrypted connections between mail servers and prevents downgrade attacks. Addressing authentication and transport security together closes the two most commonly exploited gaps in healthcare email infrastructure.

Paubox seamlessly encrypts emails and adds DMARC, DKIM, and SPF configuration support as part of its setup process, helping healthcare organizations establish authenticated, encrypted outbound email without requiring IT teams to manage DNS records independently. According to Paubox's 2025 Healthcare Email Security Report, 37.2% of breached Microsoft 365 organizations had DMARC in monitor-only mode despite paying for E5 security licenses, demonstrating that platform investment alone does not close authentication gaps.

FAQs

What is the difference between SPF, DKIM, and DMARC?

SPF verifies that a sending server is authorized to send email for a domain. DKIM adds a cryptographic signature to messages that confirms the email originated from the stated domain and was not altered in transit. DMARC ties the two together, requires alignment between the authenticated domain and the visible From address, and tells receiving servers what to do with messages that fail, nothing, quarantine, or reject. All three are needed because SPF and DKIM alone cannot prevent a spoofed From address from reaching a recipient's inbox.

What does DMARC monitor-only mode actually mean?

Monitor-only mode, also called p=none, means a domain has published a DMARC record and is receiving reports on authentication results, but has not instructed receiving servers to take any action against failing messages. Spoofed emails continue to reach inboxes as normal. Monitor-only is a starting point for understanding authentication posture, not a protective state.

Does having Microsoft 365 or Google Workspace mean email authentication is handled automatically?

No. Both platforms require administrators to configure SPF, DKIM, and DMARC records manually. According to Paubox's 2026 Healthcare Email Security Report, 53% of breached healthcare organizations in 2025 used Microsoft 365 as their primary platform, and 37.2% of breached Microsoft 365 users in 2024 had DMARC in monitor-only mode despite holding E5 security licenses.

How does email authentication reduce phishing risk in healthcare?

Phishing and impersonation attacks rely on spoofed sender identities to appear legitimate. DMARC enforcement at p=reject prevents emails that fail authentication from reaching recipients, removing one of the primary mechanisms attackers use to trick staff into disclosing credentials or patient data. According to Paubox's Top 3 Healthcare Email Attacks in 2025, impersonation was present in the most damaging email breaches of 2025 and frequently served as the trigger for mailbox takeover and patient data exposure.

Learn more: Paubox Email Suite | Paubox's 2026 Healthcare Email Security Report