Email Authentication 101: A Reading Guide

Who This Is For

You administer email for a domain. SPF, DKIM, and DMARC are not new concepts to you, but you may have set them up once years ago and never thought about them again — or you've inherited a domain whose authentication state you don't fully understand. You want a structured way to learn the surface area without reading thirty unrelated articles in random order.

This page is a reading guide. Each section is a short orientation followed by links into the deeper guides. Read it top-to-bottom on your first pass. Come back to individual sections when you're working on a specific problem.

If you need a definition rather than a guide, jump to the Email Authentication Glossary.

Start Here: Why Email Authentication Exists

SMTP, the protocol that delivers email, was published in 1982. It has no built-in mechanism to verify sender identity. Any server on the internet can claim to be sending mail from any domain, and the receiving server has to take that claim at face value unless something else tells it otherwise. SPF, DKIM, and DMARC are that "something else." They are three layers that, together, let a receiving server decide whether an inbound message actually came from the domain it claims.

Start with the Complete Guide to Email Authentication. It walks through the full stack end-to-end in one read. Treat the rest of this page as the deeper-dive sequel.

Then read Bulk Sender Requirements for the current rules at Google, Yahoo, and Microsoft. Authentication moved from "recommended" to effectively required in 2024, and the enforcement bar keeps moving.

SPF: Authorizing Senders

SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and hosts allowed to send mail on behalf of your domain. A receiving server looks up your SPF record, checks whether the sending IP is on the list, and produces a pass/fail/softfail result. SPF is specified in RFC 7208 — or read our annotated walkthrough at SPF Standard (RFC 7208) Explained.

Three things trip people up on SPF, in order of how often we see them:

• The 10-lookup limit. Every include:, a, mx, exists:, and redirect= counts against a hard 10-lookup budget. Most modern setups (Google Workspace + Microsoft 365 + a marketing tool + a transactional tool) exceed it. When you exceed it, your SPF result becomes permerror and SPF stops being evaluated at all. See How to Build an SPF Record for the mechanics and What Is SPF Flattening? for the fix.
• SPF checks the envelope, not the visible From:. SPF authenticates the Return-Path (RFC5321 MailFrom), which the user never sees. This is why SPF alone can't stop spoofing — DMARC is what ties SPF back to the From: header.
• SPF breaks on forwarding. If a server forwards your email to a different address, the forwarding server's IP is not in your SPF record. SPF fails at the final destination. See Email Forwarding and Authentication.

When you're ready to inspect a real domain, the mxio SPF Checker shows the current record, the resolved lookup count, and which includes are eating your budget.

DKIM: Signing Messages

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. The sending server signs specific headers and the body with a private key; the public key lives in DNS at <selector>._domainkey.<domain>. The receiving server fetches the public key, verifies the signature, and confirms that the signed content wasn't modified in transit. DKIM is specified in RFC 6376 — or read DKIM Standard (RFC 6376) Explained.

The DKIM section of the Complete Guide to Email Authentication covers selectors, key rotation, and the canonicalization options. The two things worth internalizing on your first read:

• Selectors let you have many DKIM keys at once. Each service that signs mail as your domain (Google, Microsoft, SendGrid, Mailchimp, MailRoute) signs with its own selector. There is no conflict between them — each selector is a separate DNS record.
• DKIM survives forwarding, SPF does not. The signature travels with the message. This is one of the main reasons DMARC was designed to pass if either SPF or DKIM aligns with the From: header.

If you're chasing down a specific DKIM problem, DKIM Record Not Found and DKIM Body Hash Not Verified are the two most-hit error pages.

DMARC: Enforcing Policy and Getting Reports

DMARC (RFC 7489, annotated at DMARC Standard Explained) does two things SPF and DKIM cannot do on their own:

1. It ties SPF and DKIM back to the From: header that users actually see. This is called alignment.
2. It tells receivers what to do when authentication fails (p=none, p=quarantine, or p=reject) and asks them to send you reports about what they're seeing.

The reports are the part most admins underuse. DMARC aggregate reports are the only way to see which IPs are sending mail claiming to be your domain — including IPs you didn't know about. Start with Understanding DMARC Reports and then DMARC Aggregate Report Explained for the XML field reference.

For deployment, follow the DMARC Deployment Guide. The short version: start at p=none with reporting on, watch the aggregate reports for two to four weeks, fix the senders that fail alignment, then move to p=quarantine with pct=10 and ratchet upward. The full path is in The DMARC Enforcement Journey.

If you're on Google Workspace or Microsoft 365, DMARC for Google Workspace and Microsoft 365 and Setting Up DMARC on Office 365 cover the provider-specific gotchas.

The mxio DMARC Checker verifies your record and reports its policy state.

Adjacent Protocols: BIMI, MTA-STS, TLS-RPT, ARC

Once SPF, DKIM, and DMARC are in place, four adjacent protocols are worth knowing about.

• MTA-STS (RFC 8461, annotated at MTA-STS Standard Explained, guide at MTA-STS Explained) tells sending servers to require TLS for connections to your inbound mail. It closes a downgrade attack that opportunistic TLS leaves open.
• TLS-RPT publishes a reporting address for TLS-delivery failures, so you find out when senders can't establish TLS to your domain. It pairs with MTA-STS.
• BIMI (Brand Indicators for Message Identification) lets you publish a logo that compatible clients display next to authenticated mail. BIMI requires DMARC at p=quarantine or p=reject and, for most placements, a Verified Mark Certificate (VMC). It's brand-trust signal, not a security control. See the glossary entry for the short version.
• ARC (Authenticated Received Chain) preserves the original authentication results across forwarding hops, so a mailing list or forwarder can vouch that the message passed authentication at an earlier point. See the glossary entry.

Operate and Maintain

Email authentication is not a project you finish; it's a system you operate. The pieces drift. SPF includes change without warning. DKIM keys get rotated. A new SaaS tool gets approved and starts sending mail through a selector you didn't know about. A subdomain gets handed to a marketing agency.

Three habits handle most of the drift:

• Monitor the records. Domain Health Check Explained covers what mxio watches and how often.
• Read the DMARC reports. Don't just publish DMARC and ignore it — the aggregate reports are how new senders surface. mxio's DMARC dashboard groups senders by source and surfaces the ones you haven't seen before.
• Read headers when something looks wrong. Email Header Analysis walks through the Authentication-Results header and what each result means.

For multi-tenant operators (MSPs and IT services firms), Email Authentication for MSPs covers managing authentication across many client domains.

When You Need a Definition, Not a Guide

The Email Authentication Glossary defines the working vocabulary — SPF mechanisms, DMARC tags, alignment modes, report types, and the protocols above — with a link from each term back to the guide that covers it in depth.