Last updated: July 2026

In short: “Email authentication” is really two layers. One proves who sent a message — that’s SPF, DKIM and DMARC. The other protects the message in transit — that’s TLS, MTA-STS, DANE and TLS-RPT. You want both. This page explains how the pieces fit and links you straight to the setup guide for your provider.

SMTP, the protocol that moves email around, was designed in an era of mutual trust. It has no built-in way to prove a sender is who they claim to be, and no built-in guarantee that a message travels encrypted. Everything we call “email authentication” today is a set of standards bolted on top to close those two gaps. Understanding which gap each standard closes is the whole game.

Layer one: who sent this? (identity)

Three records, published in your domain’s DNS, let a receiving server judge whether a message really came from you.

SPF — which servers may send for you

SPF (Sender Policy Framework, RFC 7208) is a TXT record listing the mail servers allowed to send with your domain as the sender. The value starts with v=spf1 and ends with a policy like ~all or -all. A receiver looks it up on every incoming message and checks whether the delivering server is on your list. Without SPF, anyone can put your domain in the “From” envelope. It’s the easiest starting point — see the SPF setup guides for your host.

DKIM — a cryptographic signature

DKIM (DomainKeys Identified Mail, RFC 6376) adds a digital signature to every message. Your mail server signs outgoing mail with a private key; the matching public key lives in your DNS as a v=DKIM1 record under a selector. The receiver verifies the signature, which proves two things: the message really came through your infrastructure, and it wasn’t altered on the way. Unlike SPF, DKIM survives forwarding — the signature travels with the message.

DMARC — the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is where SPF and DKIM become useful. A v=DMARC1 TXT record tells receivers what to do when a message fails both checks — p=none (monitor only), p=quarantine (spam folder), or p=reject (bounce it). It also asks receivers to send you aggregate reports, so you can see who is sending in your name before you tighten the screws. The recommended path is none → quarantine → reject, watching the reports at each step.

The three build on each other: SPF and DKIM are the checks, DMARC is the verdict. We go deeper on how they interlock in SPF vs DKIM vs DMARC: how they fit together.

Layer two: was it protected in transit? (transport)

Proving identity is only half the story. A message can be perfectly authenticated and still be read or tampered with on the wire if the connection between servers isn’t encrypted and verified.

TLS and STARTTLS — opportunistic encryption

Modern mail servers offer STARTTLS, upgrading an SMTP connection to an encrypted one. The catch: by default it’s opportunistic. If the handshake fails, or an attacker strips the STARTTLS offer, delivery silently falls back to plaintext. Encryption happens when it can, not when it must. The next two standards turn “can” into “must”.

MTA-STS — enforce TLS via an HTTPS policy

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) publishes a policy file over HTTPS that tells sending servers: for my domain, TLS is mandatory and the certificate must be valid. That closes the downgrade gap without needing DNSSEC, which is why it works on almost any host. It’s the practical choice for most people — read MTA-STS at shared hosts for who can and can’t deploy it.

DANE — enforce TLS via DNSSEC

DANE (DNS-Based Authentication of Named Entities, RFC 6698) reaches the same goal — mandatory, authenticated TLS — but anchors trust in DNSSEC and a TLSA record at your MX. It’s stronger, but only the operator of your receiving mail server can deploy it, so it’s out of reach for most shared-hosting customers. We spell out exactly who qualifies in DANE for email: who can use it.

TLS-RPT — find out when delivery fails

TLS-RPT (SMTP TLS Reporting, RFC 8460) is the feedback channel. A small TXT record containing TLSRPTv1 asks sending servers to email you daily reports on how TLS delivery to your domain went — successes and, more importantly, failures. Whether you run MTA-STS or DANE, TLS-RPT is how you learn something broke instead of finding out from an angry customer.

The payoff: BIMI

Once DMARC is at enforcement (p=quarantine or p=reject), you can add BIMI (Brand Indicators for Message Identification). It displays your logo next to authenticated mail in supporting inboxes. BIMI does nothing for security on its own — it’s the visible reward for having done the authentication work. See the BIMI setup guides once your DMARC is enforcing. The standard is stewarded by the BIMI Group.

How to actually roll this out

A sane order of operations:

  1. SPF — publish or verify your record. One record, one policy.
  2. DKIM — turn on signing at your provider, publish the public key.
  3. DMARC — start at p=none and read the reports for a few weeks.
  4. Tighten DMARC — move to quarantine, then reject, once the reports look clean.
  5. Transport — add MTA-STS (or DANE if you qualify) and TLS-RPT.
  6. BIMI — the finishing touch, once DMARC enforces.

Every step is provider-specific in the details. Pick your host in the setup guides by provider and follow along.

Verify the result

The free MXAudit scanner checks all of this in one pass: SPF syntax and lookup count, DKIM keys, your DMARC policy, plus MTA-STS, DANE, TLS-RPT and BIMI. It’s the fastest way to see which of the two layers you’ve actually covered — and where the gaps are.

Further reading