Email was designed in an era when nobody needed to prove who sent a message, which is why spoofing and phishing are so easy. Email authentication fixes that: a set of DNS-based standards that let receiving servers verify your mail genuinely comes from you. Since Gmail and Yahoo made authentication mandatory for bulk senders, getting it right is the price of reaching the inbox at all.
This guide explains each standard in practical terms — SPF, DKIM and DMARC, alignment, reporting and enforcement, plus ARC, BIMI, MTA-STS, TLS-RPT and reverse DNS — and how to read email headers to diagnose failures. For the wider picture, see email deliverability explained.
SPF
SPF Records Explained: Syntax and How They Work
SPF (Sender Policy Framework) is a DNS TXT record listing the servers allowed to send email for your domain. A receiving server checks the sending IP against the SPF record of the domain in the message's envelope sender (Return-Path).
Example:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -allv=spf1— versioninclude:— authorise another domain's SPF list (your email providers)ip4:/ip6:— authorise specific addresses-all— reject everything else (~allis a softer "soft fail")
Publish only one SPF record per domain; multiple records cause failures.
The SPF 10 DNS Lookup Limit and How to Avoid Exceeding It
SPF evaluation may trigger at most 10 DNS lookups (mechanisms like include, a, mx, exists and redirect each count, including those nested inside includes). Exceed it and SPF returns a permanent error — often failing authentication for all your mail. Avoid it by removing services you no longer use, preferring providers' DKIM alignment for DMARC, using sending subdomains with their own SPF records, and only "flattening" (replacing includes with IP addresses) with automated tooling, since provider IPs change.
DKIM
DKIM Signing Explained: Keys, Selectors and Headers
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The sending server signs selected headers and the body with a private key; the receiving server fetches the public key from DNS and verifies the signature, proving the message was authorised by the signing domain and not altered in transit.
- The selector (
s=in the signature) tells receivers where to find the key:selector._domainkey.example.com. - The d= tag names the signing domain, which matters for DMARC alignment.
- Use 2048-bit keys where supported, and rotate keys periodically.
Common DKIM Signing Mistakes That Break Alignment
- Your email platform signs with its own domain rather than yours (no custom DKIM set up) — DKIM passes, but it does not align with your From domain.
- The DNS record is published incorrectly (wrong selector, broken line breaks, truncated key).
- Mailing lists or security gateways modify signed content, breaking the signature.
- An old selector is removed while mail is still signed with it.
Set up custom DKIM for every service that sends mail as your domain.
DMARC
DMARC Explained: Policy, Alignment and Reporting
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM to the domain people actually see — the From address — and tells receivers what to do when authentication fails. A DMARC record looks like:
v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1p=— policy:none(monitor),quarantine(send to spam) orrejectrua=— where to send aggregate reportssp=— policy for subdomainspct=— percentage of mail the policy applies to (being replaced in the updated standard)
A message passes DMARC if either SPF or DKIM passes and aligns with the From domain.
Understanding DMARC Alignment: SPF vs DKIM Alignment Modes
Alignment means the domain authenticated by SPF (Return-Path) or DKIM (d= tag) matches the From domain:
- Relaxed alignment (default) — the organisational domain must match:
mail.example.comaligns withexample.com. - Strict alignment — the domains must match exactly.
DKIM alignment is usually more robust than SPF, because SPF breaks when mail is forwarded while DKIM signatures usually survive.
Managing DMARC Alignment Across Multiple Sending Sources
Most organisations send from many systems: a marketing platform, a CRM, a helpdesk, billing software, the website. Inventory every source (DMARC aggregate reports reveal them), then configure custom DKIM — and where possible a custom Return-Path for SPF alignment — for each. Sources that cannot align should send from a dedicated subdomain or be replaced.
Handling Multiple ESPs Under One Domain Without Breaking Authentication
When several email service providers send as the same domain, each needs its own DKIM selector, and SPF includes must stay under the 10-lookup limit. Using subdomains per platform (news.example.com, billing.example.com) keeps records manageable and reputations separate, while DKIM alignment carries DMARC compliance.
Moving From p=none to p=quarantine to p=reject Safely
- Publish
p=nonewith reporting and collect aggregate reports for several weeks. - Identify every legitimate sending source and fix its authentication and alignment.
- Move to
p=quarantine, optionally applying it to a percentage of mail first, and monitor. - When legitimate mail consistently passes, move to
p=reject. - Keep monitoring — new tools added later are the most common cause of failures.
Enforcement protects your domain from spoofing and is required for BIMI.
Reading and Interpreting DMARC Aggregate (RUA) Reports
Aggregate reports are daily XML files from receivers summarising messages that claimed to be from your domain: source IPs, volumes, and SPF, DKIM and DMARC results. They are hard to read raw, so most people use a DMARC reporting service to visualise them. Look for legitimate sources failing alignment (fix them) and unknown sources sending as you (likely spoofing — what enforcement will block).
Reading DMARC Forensic (RUF) Reports
Forensic (failure) reports contain details of individual messages that failed DMARC, sometimes including headers or content. Few major providers send them today, largely for privacy reasons, so treat them as occasional supplementary data rather than a reliable source.
Understanding DMARCbis and What's Changed in the Updated Standard
DMARCbis is the IETF's revision of the DMARC specification. Notable changes include replacing the pct tag with a simpler testing flag (t=), adding an np tag for policies on non-existent subdomains, and replacing reliance on the Public Suffix List with a DNS "tree walk" to determine organisational domains. Existing DMARC records continue to work; review your records against the updated specification as receivers adopt it.
Beyond the Core Three
Understanding ARC (Authenticated Received Chain) for Forwarded Mail
Forwarding and mailing lists often break SPF (different sending server) and sometimes DKIM (modified content). ARC lets intermediate servers record the authentication results they saw before forwarding, signed so the final receiver can trust them. It helps legitimate forwarded mail pass, but receivers decide how much to trust each ARC signer.
BIMI and Verified Mark Certificates Explained
BIMI (Brand Indicators for Message Identification) displays your logo next to your messages in supporting inboxes. Requirements:
- DMARC at enforcement (
p=quarantineorp=reject) - Your logo in SVG Tiny PS format, referenced in a BIMI DNS record
- For Gmail and some others, a Verified Mark Certificate (VMC) — which requires a registered trademark — or a Common Mark Certificate (CMC) for logos with demonstrated use
BIMI rewards strong authentication with brand visibility and can increase recognition and trust.
MTA-STS: Enforcing Transport Security for Inbound Mail
MTA-STS lets your domain tell sending servers that they must use TLS with a valid certificate when delivering mail to you, preventing downgrade attacks that strip encryption. It uses a DNS record plus a policy file served over HTTPS. Start in testing mode, monitor with TLS-RPT, then move to enforce.
TLS-RPT: Monitoring TLS Delivery Failures
TLS-RPT (TLS Reporting) is a DNS record asking sending servers to report problems establishing secure connections to your mail servers — certificate errors, MTA-STS policy failures. It is essential when deploying MTA-STS, so you can spot issues before enforcement blocks legitimate mail.
Understanding PTR Records and Reverse DNS
A PTR record maps an IP address back to a hostname (reverse DNS). Receiving servers check that sending IPs have valid reverse DNS; missing or generic PTR records (like 123-45-67-89.isp.example) look like compromised home computers and hurt deliverability. Gmail's sender guidelines require valid reverse DNS. If you use an email service provider, they manage this for their IPs.
Forward-Confirmed Reverse DNS (FCrDNS) Explained
FCrDNS means the IP's PTR hostname resolves forward to the same IP — a two-way match (IP → hostname → IP). Many receivers check it as a basic legitimacy test. Ensure your sending IPs' PTR hostnames have matching A (or AAAA) records.
Diagnosing Problems
Reading Full Email Headers to Diagnose Authentication Failures
Open the full headers ("Show original" in Gmail) and find the Authentication-Results header:
Authentication-Results: mx.google.com;
dkim=pass header.d=example.com;
spf=pass smtp.mailfrom=bounce.example.com;
dmarc=pass (p=REJECT) header.from=example.comCheck that SPF and DKIM pass, which domains they authenticated (smtp.mailfrom, header.d), and whether those align with header.from. Read the Received headers bottom to top to see the path the message took. A DKIM pass for your provider's domain rather than yours, or an SPF pass on a domain that does not align, explains most "authenticated but failing DMARC" mysteries.
The Bottom Line
Authenticate every source that sends as your domain with SPF and custom DKIM, publish DMARC with reporting, use the reports to fix alignment, and move steadily to enforcement. Then add the extras that strengthen trust — MTA-STS and TLS-RPT for transport security, valid reverse DNS, and BIMI for brand visibility.
Next step: Learn how to monitor results and respond to problems in our deliverability monitoring and troubleshooting guide.