Authentication

Email Authentication

Definition

Email authentication is the collective term for the standards that let a receiving server confirm a message truly came from the domain it names. The stack is three layers: SPF authorises your sending servers, DKIM cryptographically signs each message, and DMARC binds both to the visible From: address and tells receivers how to handle forgeries. Together they are now a baseline requirement for reaching the inbox.

  • The umbrella term for the SPF, DKIM, and DMARC stack
  • Each layer is published as DNS records under your own domain
  • Set up SPF and DKIM first, then layer DMARC on top to enforce alignment
  • A mandatory baseline for bulk senders to Gmail and Yahoo since February 2024
At a glance
Made up of SPF + DKIM + DMARC
Published as DNS records
Setup order SPF and DKIM, then DMARC
Extends to ARC, BIMI
Required by Gmail & Yahoo bulk senders (Feb 2024)
Goal Prove the message is really from your domain

What email authentication covers

Email authentication is not a single switch; it is the umbrella name for the standards that, between them, prove a message’s origin. The three that matter are SPF, DKIM, and DMARC, all published as DNS records and all working on the same principle: a receiver can verify a claim about your domain against something only the real domain owner could have set.

The point of authenticating is trust. Mailbox providers use the results to decide whether to deliver, filter, or reject your mail, and they use the consistent identity it establishes to track your reputation over time. Unauthenticated mail is increasingly treated as suspect by default.

The order to set it up

The layers depend on each other, so the sequence matters:

  • 1. Publish SPF. One DNS TXT record listing every service that sends for you, ending in ~all or -all. Watch the 10-lookup limit.
  • 2. Enable DKIM. Turn on signing at each sending platform and publish the public key under a selector in your DNS, signing with your own domain so it can align.
  • 3. Add DMARC at p=none. Publish a record with a reporting address, read the aggregate reports until every legitimate source aligns, then tighten to quarantine and reject.

Trying to enforce DMARC before SPF and DKIM are solid is the classic mistake; it blocks your own mail. Verify each layer in turn with the SPF, DKIM, and DMARC checkers before moving on, and follow the full email authentication guide for the details.

Reading the results

Every receiver records what it found in an Authentication-Results header on the delivered message. It is the fastest way to confirm your setup is working end to end:

An Authentication-Results header showing all three checks passing and aligned 
Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Building the authentication stack in order

Publish an SPF record listing every sending service
Enable DKIM signing and publish the public key under a selector
Add DMARC at p=none with a reporting address
Read aggregate reports until every legitimate source aligns
All sources pass: tighten Gaps found: fix first
Move DMARC to quarantine then reject

The three layers at a glance

SPF DKIM DMARC
Job Authorise servers Sign messages Enforce alignment + report
Set up First First Last
Breaks on forwarding? Often Rarely Depends on the above
Stops From: spoofing? No No Yes, at reject

By the numbers

3
DNS-based layers in the core stack: SPF, DKIM, and DMARC.
5,000+/day
The volume to Gmail or Yahoo at which full authentication became mandatory in February 2024.
p=none
The minimum DMARC policy the bulk-sender mandate requires, and the right place to start.

Common mistakes

Enforcing DMARC before the basics align
Publishing p=quarantine or p=reject while a legitimate sending service still fails alignment quarantines your own invoices and password resets. Start at p=none and read reports first.
Forgetting a sending service
CRMs, help desks, invoicing tools, and marketing platforms all send as your domain. Miss one in SPF or DKIM and its mail fails authentication. Inventory every source before you enforce.
Signing DKIM with the provider’s domain
If DKIM signs with your ESP’s domain instead of yours, it passes DKIM but fails DMARC alignment. Configure each platform to sign as your own domain.

Frequently asked questions

What is email authentication in simple terms?
It is how a receiving mail server checks that a message really came from the domain it claims, instead of an impostor. It works through three DNS-based standards, SPF, DKIM, and DMARC, that together prove the sender, confirm the message was not altered, and tell the receiver what to do if the checks fail.
What order should I set up SPF, DKIM, and DMARC?
Publish SPF and enable DKIM first, since DMARC relies on their results. Then add DMARC at p=none with a reporting address, read the aggregate reports until every legitimate sender aligns, and only then tighten the policy to quarantine and reject. Enforcing DMARC before the other two are solid blocks your own mail.
Does email authentication guarantee inbox placement?
No. Authentication is necessary but not sufficient: it gets you past the door, but content, engagement, complaint rate, list hygiene, and IP and domain reputation all still decide whether you land in the inbox or the spam folder. Think of it as the foundation that the rest of deliverability is built on.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary