Email authentication is the set of DNS records and protocols that let a receiving mail server confirm a message actually came from the domain it claims to come from. It exists because SMTP, the protocol that moves email, was designed with no built-in concept of identity, so anyone can put your domain in the From: address. SPF, DKIM, and DMARC are the three standards that close that gap, and supporting signals such as reverse DNS, ARC, BIMI, and MTA-STS reinforce them.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Why email authentication exists
When SMTP was standardized in the early 1980s, every server on the network was assumed to be trustworthy. There was no requirement to prove who you were before handing off a message. That assumption is why spoofing is trivial: a sender can write any address into the From: header, and a bare SMTP server will accept and relay it.
Two different addresses matter here, and confusing them causes most authentication mistakes. The envelope sender (also called the 5321.MailFrom or Return-Path) is the address used during the SMTP conversation and for bounce handling. The header From (the 5322.From) is the address a human sees in their mail client. Attackers spoof the visible header From, which is exactly the field that plain SMTP never checks. Email authentication adds cryptographic and DNS-based proof so a receiver can tie a message back to a real, controlled domain and reject the rest. For a deeper look at the attack this defends against, see what is email spoofing.
The three core standards
SPF, DKIM, and DMARC each solve one piece of the problem. None is sufficient alone. Together they let a receiver both verify identity and decide what to do when verification fails.
SPF: which servers may send for your domain
Sender Policy Framework (RFC 7208) is a DNS TXT record that lists the IP addresses and hosts authorized to send mail using your domain in the envelope. A receiver looks up the record, checks the connecting IP against it, and returns a result such as pass, fail, or softfail.
SPF has one limit that trips up most senders: the standard caps evaluation at 10 DNS-querying mechanisms (include, a, mx, ptr, exists, and the redirect modifier). Exceed it and the receiver returns PermError, a permanent failure that means your record could not be evaluated at all. Nested include statements from multiple vendors are the usual cause. The same standard also caps void lookups (mechanisms that return NXDOMAIN or no record) at two, which produces the same PermError. If you hit either wall, read fix SPF too many DNS lookups.
SPF also breaks on forwarding, because the forwarding server sends from its own IP, which your record does not list. That is why SPF cannot stand alone.
DKIM: a signature that survives the trip
DomainKeys Identified Mail (RFC 6376) attaches a cryptographic signature to each message. Your mail server signs selected headers and the body with a private key, and receivers fetch the matching public key from DNS to verify it. The public key lives at selector._domainkey.yourdomain.com, where the selector is a label you choose (for example s1 or google) so you can publish more than one key and rotate them. Use a 2048-bit key where your provider supports it; 1024-bit keys are weaker and being phased out, and a 2048-bit key usually needs a multi-string TXT record to fit.
Because the signature travels inside the message and does not depend on the connecting IP, DKIM usually survives forwarding when SPF does not. The domain that matters for alignment is the d= value in the signature, not the selector and not the Return-Path. See how to set up DKIM.
DMARC: policy and reporting on top
Domain-based Message Authentication, Reporting and Conformance is the layer that ties SPF and DKIM to the visible header From and tells receivers what to do on failure. It was defined in RFC 7489 in 2015 and updated in 2026 by RFC 9989 (with reporting split into RFC 9990 and RFC 9991), which promoted it to a Proposed Standard. Records that start with v=DMARC1 remain valid; the refresh introduced no breaking changes. A DMARC record is a TXT record at _dmarc.yourdomain.com with a policy tag:
p=nonemonitors only and takes no action.p=quarantinesends failing mail to spam or holds it.p=rejectrefuses failing mail outright.
DMARC also requests reports, so you get visibility into who is sending as your domain before you enforce. Start at p=none, read the data, then tighten. The full progression is covered in DMARC policy: none, quarantine, or reject.
How the three fit together: alignment
DMARC passes when at least one of SPF or DKIM both authenticates and aligns. Alignment means the domain that authenticated matches the domain in the header From that the recipient sees.
| Check | Authenticates | Aligns against |
|---|---|---|
| SPF | Return-Path (envelope) domain | Header From domain |
| DKIM | d= signing domain | Header From domain |
This is the key insight: SPF can pass while DMARC still fails, because SPF validates the envelope, and if that envelope domain differs from the visible From domain, they do not align. The same is true for DKIM if the d= domain differs. DMARC only needs one aligned pass, which is why enabling both SPF and DKIM gives you a durable result across forwarding and relays. Alignment can be relaxed (the two domains share an organizational domain, so mail.example.com matches example.com) or strict (an exact match). The tradeoffs are in relaxed vs strict alignment.
Supporting signals
The core three answer one question: is this really you. A second tier of signals affects reputation, trust, and transport security.
| Signal | What it does | Where it lives |
|---|---|---|
| PTR / reverse DNS | Maps your sending IP back to a hostname; receivers expect forward-confirmed reverse DNS (FCrDNS) | Reverse DNS zone for the IP |
| ARC | Preserves original authentication results across forwarders and mailing lists | ARC-* headers added in transit |
| BIMI | Displays your logo next to authenticated mail; requires DMARC enforcement | default._bimi.yourdomain.com TXT record |
| MTA-STS | Forces receivers to use TLS with a valid certificate to your MX | _mta-sts TXT record plus a policy file |
Reverse DNS matters because mailbox providers penalize or reject mail from IPs whose PTR record does not resolve back to the sending hostname, then forward-confirm by resolving that hostname back to the same IP. ARC (RFC 8617) exists because forwarding and mailing lists break SPF and can invalidate DKIM. An intermediary that supports ARC records the authentication results it saw, so the final receiver can trust the original verdict even after the message was modified.
BIMI and MTA-STS are optional but valuable. BIMI turns a strong DMARC posture into a visible brand logo in the inbox, and mailbox providers require enforcement (p=quarantine or p=reject) before they will show it. MTA-STS protects the connection itself against downgrade and interception attacks by telling senders to require TLS to your mail servers.
How receivers actually use this
At delivery time, a receiving server evaluates SPF, DKIM, DMARC, connection IP reputation, and PTR, then writes the outcome into the Authentication-Results header. You can open that header on any message you receive to see the verdict, including which checks passed and which domains aligned.
Authentication is now a hard gate, not a nice-to-have. Gmail, Yahoo, and Microsoft require bulk senders (roughly 5,000 or more messages per day to their users) to authenticate with SPF and DKIM, publish at least a p=none DMARC record, align their domains, keep spam complaint rates below 0.3% and ideally under 0.1%, offer one-click list unsubscribe per RFC 8058, and maintain valid forward-confirmed reverse DNS. Google moved from temporary deferrals to permanent rejections during 2025, so failing these rules now means mail is bounced with a 550 error rather than merely delayed. The full checklist lives in bulk email sender requirements.
How to check a domain
You can inspect any domain yourself:
- Query the SPF
TXTrecord at the root of the domain and confirm it stays under 10 DNS lookups. - Query DKIM at
selector._domainkey.domain.comfor each selector your senders use. - Query the DMARC
TXTrecord at_dmarc.domain.comand note the policy. - Check reverse DNS for each sending IP and confirm it is forward-confirmed.
- Send a test message and read the
Authentication-Resultsheader to see the live verdict.
A scanner does all of this at once and flags misalignment, lookup-limit problems, and missing records.
Frequently asked questions
Do I need SPF, DKIM, and DMARC, or is one enough?
You need all three. SPF and DKIM each provide an authentication signal, but only one has to align for DMARC to pass, so publishing both gives you resilience across forwarding. DMARC is the layer that protects the visible From address and tells receivers what to do when authentication fails.
Can email authentication stop all spoofing?
DMARC at p=reject stops attackers from spoofing your exact domain, because unaligned mail gets refused. It does not stop lookalike domains, display-name spoofing, or compromised accounts, so treat it as one strong layer rather than a complete anti-phishing solution.
Why does my email pass SPF but still fail DMARC?
SPF authenticates the envelope (Return-Path) domain, while DMARC checks alignment against the visible header From. If your sending platform uses its own domain in the Return-Path, SPF can pass without aligning, and DMARC will fail unless aligned DKIM covers the message.
What is the difference between the envelope sender and the From header?
The envelope sender (Return-Path) is used for routing and bounces during the SMTP transaction. The header From is the address the recipient sees. Attackers forge the header From, which is why DMARC alignment focuses on it.
If you are not sure where your domain stands, run a free scan with the checker above. It reports your SPF, DKIM, DMARC, and reverse DNS status in seconds and points you to the exact fix for anything that is missing or misaligned.