Email authentication overview

21 June 2026 · 13 min read

Email authentication is the set of standards that lets a receiving mail server, such as Gmail, Yahoo or Microsoft 365, decide whether a message that claims to come from your domain genuinely did. The original email protocol shipped with no way to prove the sender, so anyone can write your domain in the visible "From" line and post a message that looks exactly like it came from you. Five standards close that gap: SPF, DKIM, DMARC, MTA-STS and BIMI. They are not competing options where you pick one. They are layers, each answering a different question, and they only deliver real protection when they work together correctly. This page is the map of the whole stack. It explains what each layer proves, how they fit, the order to deploy them in, and where DMARC Engine takes the manual work off your plate. Each section links to the detailed doc for that layer, so you can read this top to bottom and then drill into whichever piece you need.

If you would rather start from absolute first principles with no DNS knowledge assumed, read Email authentication for beginners first, then come back here for the full picture.

Why any of this exists

Every email carries two different "from" addresses, and almost every misunderstanding about authentication starts with confusing them.

The envelope sender, also called Return-Path or MAIL FROM, is the hidden address that mail servers use to route the message and to send bounce notifications back. Your recipients rarely see it.
The header From is the friendly From: Acme Ltd <billing@acme.com> line your email client displays. This is the address a human reads and trusts.

A scammer can set both to anything they like. They can send a message where the header From reads billing@yourcompany.com while having no connection to your company at all. This is spoofing, and it is the mechanism behind most phishing, invoice fraud and business email compromise. The receiving server has no innate way to tell a spoof from the real thing. Authentication exists to give it one. For the full attack picture, see why your domain can be spoofed.

All five standards are published as records in your domain's DNS, the public directory of the internet. Anyone can read them, which is the point: any receiving server worldwide can look up the rules you have set and check incoming mail against them. You publish these records through whoever manages your DNS, which is your registrar, your hosting provider, or a platform that manages them for you. If you want the exact syntax for every record type in one place, the DNS record reference lists them all.

The five layers at a glance

Before the detail, here is the one-line job of each layer and the question it answers for the receiver.

SPF (Sender Policy Framework): is the server that delivered this message on the list of servers I authorised to send for my domain? It checks the envelope sender against a published list of sources.
DKIM (DomainKeys Identified Mail): was this message signed by the domain it claims to come from, and has it been altered since? It uses a cryptographic signature checked against a public key in DNS.
DMARC (Domain-based Message Authentication, Reporting and Conformance): tie SPF and DKIM back to the visible From address, tell receivers what to do when neither aligns, and send me reports. This is the layer that actually stops spoofing of the address your users read.
MTA-STS (SMTP MTA Strict Transport Security): require that mail to my domain is delivered over encrypted, certificate-validated TLS, closing a downgrade gap that SPF, DKIM and DMARC do not touch.
BIMI (Brand Indicators for Message Identification): once DMARC is enforced, display my verified brand logo next to my messages in supporting inboxes.

The crucial relationship is that SPF and DKIM are checks, and DMARC is the policy that gives those checks meaning for the address people actually see. MTA-STS protects the transport channel rather than the message, and BIMI is the visible reward you can only claim after the first three are working at enforcement. Read on for how each one works and why the order matters.

SPF: which servers may send for you

SPF answers a narrow question: is the server that delivered this email allowed to send on behalf of my domain? You publish a single TXT record listing your legitimate sending sources, which are usually your providers: Google Workspace, Microsoft 365, your newsletter tool, your invoicing system, your help desk. A simple record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Reading left to right: v=spf1 declares an SPF record; each include: pulls in the servers belonging to a named provider; and -all means anything not listed is not authorised. The receiving server looks at the actual sending server and checks whether it falls inside the sources you permit.

SPF has two limits that explain why it is never enough on its own.

It validates the envelope sender, not the visible From. A spoofer can pass SPF on a domain they control while still showing your domain in the From line a human reads. SPF alone does nothing about that visible address.
It breaks on forwarding. When a message is forwarded, the forwarding server becomes the new sender and is almost never in your SPF record, so the forwarded copy fails SPF even though the original was legitimate. This is expected behaviour, and it is one reason you cannot rely on SPF by itself. See why forwarding breaks authentication.

There is also a hard rule that trips many domains: an SPF record may trigger at most ten DNS lookups during evaluation. Every provider include: counts, and large providers consume several each. Exceed ten and the record returns PermError, at which point receivers may treat your mail as if SPF were not set up at all. Domains break this way quietly as they add tools over time. The standard fix is SPF flattening, which resolves the includes into a compact set of IP ranges that stays under the limit, then keeps it current as providers change their infrastructure. We cover the mechanism in how SPF flattening works, and you can count your own lookups with the SPF checker. For how DMARC Engine maintains a flattened record automatically, see hosted SPF and the SPF product page.

DKIM: a tamper-evident signature on the message

Where SPF is about which server sent the mail, DKIM is about the message itself: was it signed by the domain it claims to come from, and has it changed since? DKIM uses a pair of cryptographic keys. Your provider holds a private key in secret and uses it to sign each outgoing message, attaching the signature to the hidden headers. You publish the matching public key in DNS, at a name like selector1._domainkey.yourcompany.com, so any receiver can fetch it and verify the signature.

The maths runs one way only: a signature made with your private key verifies solely against your matching public key, and it is computed from the message content. So a valid signature tells the receiver two things at once. The message really was signed by a holder of your domain's private key, and the signed parts, including the From header and body, have not been altered since signing. A published public key looks roughly like this:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

The selector (the selector1 part of the name) lets you run several keys at once, one per sending service, and rotate them without downtime. DKIM survives forwarding far better than SPF, because the signature travels with the message rather than depending on the connecting server, though some mailing lists modify messages in ways that break it, which is where ARC comes in. For the setup detail and how rotation works, see DKIM setup and hosted DKIM; to inspect a live selector, use the DKIM checker.

DMARC: the policy that ties it all together

SPF and DKIM each prove something useful, but neither, on its own, protects the address your recipients actually see. DMARC is the layer that does. It does three things.

First, alignment. DMARC requires that a passing SPF or DKIM result belongs to the same domain shown in the visible From address, not just any domain. This is the step that connects the underlying checks to the identity a human trusts, and it is what makes spoofing the visible From genuinely hard. A spoofer can pass SPF on their own throwaway domain, but it will not align with your From, so DMARC fails. Alignment is the single most important concept in the stack; DMARC alignment explained covers it in depth.

Second, policy. Your DMARC record tells receivers what to do with mail that fails alignment, via the p= tag:

p=none: take no action, just send me reports. This is monitoring only and provides no protection.
p=quarantine: send failing mail to spam or hold it.
p=reject: refuse failing mail outright. This is full protection and the goal.

A record looks like this:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

Third, reporting. The rua address receives daily aggregate reports from receivers worldwide: XML summaries of every source sending under your domain, and whether each passed SPF, DKIM and alignment. These reports are how you discover legitimate services you forgot about before you turn on enforcement, so you do not block your own payroll or marketing mail. Reading them by hand is painful, which is what the DMARC report analyzer and our reading DMARC reports guide are for.

The trap to avoid is leaving the policy at p=none forever, mistaking the presence of a DMARC record for protection. A record at p=none stops nobody from spoofing you; it only watches. We explain why this false sense of security is so common in the p=none false security trap. For the full anatomy of the record, see understanding your DMARC record and what is DMARC, and to read your current published record, use the DMARC checker.

The enforcement journey: none to reject without breakage

Moving from p=none to p=reject is where domains either succeed quietly or break their own mail. The whole point of DMARC Engine is to make that move safe. The path is:

Publish p=none and collect aggregate reports for a few weeks.
Use the reports to find every legitimate sender and bring each into SPF or DKIM alignment.
Step up to p=quarantine, optionally with pct sampling so only a fraction of mail is affected at first.
Confirm reports stay clean, then move to p=reject.

Rushing this is how legitimate mail gets lost; skipping the report-reading step is how forgotten services get blocked. We walk through the full sequence in the enforcement journey and reaching p=reject without breaking email. For the done-for-you version, see the DMARC product page and hosted DMARC.

MTA-STS: enforce encrypted delivery

The three layers above prove who sent a message and that it was not altered. None of them guarantees the message reached you over an encrypted connection. By default, SMTP encryption is opportunistic: servers try TLS, but if the handshake fails or a certificate is invalid, they quietly fall back to plain text. An attacker positioned on the network can exploit this by stripping the encryption offer, a downgrade attack, and read or tamper with mail in transit.

MTA-STS closes that gap. You publish a policy, served over HTTPS at a fixed location on your domain plus a small DNS TXT record, that tells sending servers: only deliver to my mail servers over TLS with a valid, matching certificate, and if you cannot, do not fall back to plain text. Sending servers that support MTA-STS cache this policy and enforce it. The companion TLS-RPT record asks those senders to report any delivery failures, so you learn about TLS problems rather than silently losing mail. You can confirm a policy with the MTA-STS checker and check reporting with the TLS-RPT checker.

MTA-STS is independent of DMARC: it protects the channel rather than the message identity, so it can be deployed at any point. Because it requires both an HTTPS endpoint and DNS records kept in sync, it is fiddly to maintain by hand, which is exactly what hosting it removes. See MTA-STS setup and the MTA-STS product page.

BIMI: your verified logo in the inbox

BIMI is the visible payoff for doing the rest correctly. Once your domain is at DMARC enforcement (p=quarantine or p=reject), BIMI lets supporting inboxes, including Gmail, Yahoo and Apple Mail, display your brand logo next to your messages. You publish a DNS record pointing to a logo in a specific SVG profile, and for the strongest treatment, a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) that proves you own the logo.

BIMI is deliberately last in the stack because it only works once DMARC is enforced; a domain at p=none cannot qualify. That dependency makes BIMI a useful incentive: the work that earns you the logo is the same work that stops you being spoofed. It also gives recipients a quick visual signal that a message is genuinely from you, which helps your real mail stand out from impersonation attempts. To check a BIMI record, use the BIMI checker; for the end-to-end build including the certificate, see BIMI setup and the BIMI product page.

How the layers fit together

It helps to see the stack as a sequence of questions a receiver asks about one incoming message:

Did it arrive over enforced TLS? MTA-STS governs this, at the transport layer, before the message content is even examined.
Is the sending server authorised? SPF answers this against the envelope sender.
Is the message signed and intact? DKIM answers this with the cryptographic signature.
Does a passing check align with the visible From, and what should I do if not? DMARC answers this and applies your policy.
May I show the brand logo? BIMI answers this, but only if DMARC was enforced.

The dependencies run in one direction. DMARC depends on SPF and DKIM existing and aligning. BIMI depends on DMARC being enforced. MTA-STS stands apart, protecting the channel rather than the identity. This is why the deployment order is SPF and DKIM first, then DMARC monitoring, then DMARC enforcement, then BIMI, with MTA-STS slotted in whenever convenient. The companion piece five records that protect email lays the same picture out record by record, and the glossary defines every term used here.

Where DMARC Engine fits

Every layer above is something you can do by hand. The reason most domains never reach p=reject, or reach it and break their mail, is that the manual version is a sustained operational job, not a one-time edit. Records drift as providers change infrastructure, SPF lookups creep over ten as you add tools, DKIM keys need rotating, reports pile up unread, and the safe path to enforcement requires weeks of patient watching. DMARC Engine is the done-for-you version of that whole job, running on Cloudflare.

Hosted SPF maintains a flattened record that stays under the ten-lookup limit and updates automatically as your providers change, so you never hit PermError. See hosted SPF.
Hosted DKIM manages keys and selectors and handles rotation without you touching DNS. See hosted DKIM.
Hosted DMARC publishes and steps your policy along the safe path, ingesting and parsing the aggregate reports so you see legitimate senders in plain language rather than raw XML. See hosted DMARC and the enforcement journey.
Hosted MTA-STS serves the HTTPS policy and keeps the DNS records in sync, with TLS-RPT collection. See MTA-STS setup.
Hosted BIMI sets up the logo record and the certificate once you reach enforcement. See BIMI setup.
Monitoring and change alerts email you the moment a record changes, a new source appears, or alignment slips, so a silent break does not become a deliverability incident. See monitoring and change alerts.

Most of this runs by delegating a portion of your DNS to us, so we can keep the records correct without you editing them on every provider change. That delegation is a one-time setup; delegating your DNS explains exactly what changes and what stays under your control. The dashboard at app.dmarcengine.com shows your live status across all five layers in one place.

Where to start

If you do nothing else today, check what your domain currently publishes. Run it through the free DMARC checker, SPF checker and DKIM checker; these need no account and tell you in seconds where you stand. From there:

New to all of this: read getting started, then email authentication for beginners.
You have a DMARC record but it is stuck at p=none: read the enforcement journey and the p=none false security trap.
You are failing under the Gmail and Yahoo sender rules: see Gmail and Yahoo require DMARC and the requirements page.
Your SPF is throwing PermError: read how SPF flattening works and run the SPF checker.

The standards are not complicated once you see how the layers stack: SPF and DKIM are the proofs, DMARC is the policy that makes those proofs protect the address people read, MTA-STS guards the transport, and BIMI is the visible reward for getting the rest right. The hard part is keeping all of it correct as your sending estate changes month after month, and that is the part we take off your hands.