What Is Email Authentication?

Email authentication is a set of DNS-based checks that let a receiving mail server verify that a message really came from the domain it claims to come from. Three protocols do this work together: SPF, DKIM, and DMARC. Together they stop attackers from sending mail that appears to come from your organization.

Without these checks, anyone can put your domain in the From line of an email. That is the mechanism behind most domain spoofing, brand impersonation, and a large share of business email compromise. Authentication also decides whether your legitimate mail reaches the inbox at all, because Google, Yahoo, and Microsoft now require it from high-volume senders.

This page explains what each protocol does, how they work together, how to implement them in the right order, and what to do about application and transactional email.

Email authentication is a collection of DNS-based checks that confirm that the sender of an email is who they claim to be, protecting both the sender’s brand and the email recipients from email spoofing, phishing, and other malicious activities.

The process validates the domain ownership of any message transfer agent (MTA) that handled the message. It gives receiving providers a reliable way to separate legitimate mail from forgeries.

Three protocols work together: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC). Each answers a different question, and none is sufficient alone.

Authenticated emails are more likely to reach the intended recipient’s inbox, improving deliverability and protecting the sender’s domain reputation. Authentication also reduces brand impersonation, which lowers the chance of successful phishing against your customers and partners.

A receiving server runs three checks in sequence, all against records the sending domain publishes in DNS. Here is the sequence:

1. Sender configuration: The domain owner sets up authentication records (SPF, DKIM, and DMARC) in their Domain Name System (DNS).
2. Email sending: When an email is sent, it includes information about the sender and authentication details in its headers.
3. Receiver verification: The receiving mail server checks the email against the authentication records published in the sender’s DNS.
4. SPF check: The server verifies that the sending IP address is approved to send emails for the domain.
5. DKIM verification: The server uses the public key in the DNS to validate the DKIM signature and verify the email’s integrity.
6. Alignment check: The server confirms that the domain that passed SPF or DKIM matches the domain in the visible From address. A message can pass SPF and still fail DMARC if the domains do not align.
7. DMARC evaluation: If neither SPF nor DKIM passes in alignment, the server consults the DMARC policy to determine how to handle the email.
8. Decision: Based on the authentication results, the receiving server decides whether to deliver, quarantine, or reject the email.

This process happens within seconds, providing a robust defense against email security threats while ensuring legitimate emails reach their intended recipients.

SPF, DKIM, and DMARC are the core three, but three further standards sit alongside them.

• BIMI (Brand Indicators for Message Identification) displays your verified logo beside authenticated messages in supporting inboxes. It requires DMARC at p=quarantine or p=reject first, so it is a reward for enforcement rather than a route to it.
• MTA-STS (SMTP MTA Strict Transport Security) tells sending servers to require encrypted connections to your domain, closing off downgrade attacks. It secures the transport, not the sender identity.
• ARC (Authenticated Received Chain) preserves authentication results across forwarding and mailing lists, where SPF would otherwise break. It helps intermediaries pass along a verdict the original sender earned.

Google, Yahoo, and Microsoft all require authentication from organizations sending high volumes of mail to their consumer mailboxes. Messages that fail are rejected at the SMTP level — bounced, not filed as spam — which makes this an availability problem as much as a security one.

The common floor across all three is: a passing SPF record, a passing DKIM signature, and a published DMARC record of at least p=none that aligns with the From domain. The threshold is generally 5,000 messages a day to a given provider’s consumer addresses. One setup satisfies all three; there is no per-provider configuration.

Two points are worth being clear about. First, p=none satisfies the requirement but provides no protection — it monitors only. Meeting the minimum is not the same as stopping spoofing. Second, the requirements apply to transactional mail as well as marketing mail, which is where most organizations find gaps.

What changed with DMARCbis

DMARC was promoted to an IETF Standards Track specification in 2026, replacing the original experimental standard. Existing DMARC records remain valid and the bulk-sender requirements are unchanged, so no immediate action is required — but the new specification adds tags worth knowing about when you next review your records.

Transactional and application-generated email — password resets, receipts, appointment reminders, alerts from SaaS platforms and AI agents — is usually the hardest traffic to authenticate, because it is the traffic organizations are least likely to have inventoried.

This mail is sent on your behalf by systems you may not control, often from infrastructure with its own authentication. Each one that sends using your domain without aligning to it will fail DMARC, which is what blocks the move to enforcement.

The sequence that works: inventory every application and third party sending as your domain; authenticate each one, or route it through dedicated sending infrastructure that handles DKIM signing and DMARC alignment centrally; then separate application traffic from user mail so a problem with one does not damage the reputation of the other.

Authentication affects four things an organization can measure.

• Protection against spoofing and phishing: Enforcement stops attackers sending mail that appears to come from your domain, which closes off the most convincing form of brand impersonation against your customers and partners.
• Deliverability: Authenticated mail is far more likely to reach the inbox, and unauthenticated bulk mail is now rejected outright by the major consumer providers.
• Visibility into who sends as your domain: DMARC aggregate reports show every source sending under your domain, including third parties and shadow systems nobody documented.
• Compliance and due diligence: Authentication is referenced in sector guidance and government directives, and demonstrates due diligence over the communications channel.

Most organizations stall on the same step: they cannot see every system sending as their domain, so they never move DMARC to enforcement. Proofpoint addresses that directly.

• Proofpoint Email Fraud Defense discovers the legitimate senders using your domains, guides SPF, DKIM, and DMARC toward enforcement, and monitors lookalike domains that imitate your brand.
• Proofpoint Secure Email Relay authenticates and governs email generated by applications, SaaS platforms, and AI agents, separating that traffic from user mail while handling DKIM signing and DMARC alignment centrally.