Email was designed in an age when everyone on the network was trusted, and the From address could say anything. That is why forged email is easy and why phishing exists. Email authentication is the set of standards that adds proof to a message, so that receivers can check who sent it and whether it was changed on the way. This guide gives a clear overview of the main methods: SPF, DKIM, DMARC, ARC and BIMI, plus encryption in transit with TLS, how they fit together, what each one checks, and the order in which to set them up for your own domain.
Why email authentication matters
Without authentication, anyone can send a message that claims to be from your bank, your company or you. Authentication gives receivers evidence to act on. For senders it means three practical things. Your genuine mail is more likely to reach the inbox. Criminals find it harder to impersonate your domain. And you gain reports that show who is sending mail in your name.
It is also a requirement in practice. Large mailbox providers expect authenticated mail, especially from senders who send in volume, and they publish their requirements, which change over time. Check each provider's current sender guidelines rather than relying on a summary.
The two identities in an email
To understand the standards, you need to know that a message has two sender addresses.
- The envelope sender (MAIL FROM, or Return-Path) is used between servers, and it is where bounces go.
- The header From is the address that people see in their mail app.
They can differ, and the standards check different identities. SPF checks the envelope sender. DKIM checks the domain that signed the message. DMARC ties both back to the header From, which is the one people trust. Our article on the Gmail via label shows what happens when these identities do not match.
SPF: who may send
Sender Policy Framework is a DNS TXT record on your domain that lists the servers and services allowed to send mail using it. When a message arrives, the receiver looks at the envelope sender's domain, fetches its SPF record and checks whether the connecting IP address is on the list.
- Strength: simple, and checked early in the delivery.
- Weakness: it breaks when mail is forwarded, because the forwarder's IP is not on your list. It also limits the number of DNS lookups a record may use.
Read the SPF record guide for syntax, and SPF too many lookups if your record has grown long.
DKIM: the signature
DomainKeys Identified Mail adds a cryptographic signature to the message headers. Your sending system holds a private key and signs each message. You publish the matching public key in DNS. The receiver fetches the key and verifies the signature. If someone changes the signed parts of the message in transit, verification fails.
- Strength: survives forwarding when the message is unchanged, and identifies the signing domain.
- Weakness: some forwarders and mailing lists change the message, which breaks the signature.
The DKIM setup guide walks through the records.
DMARC: policy and reporting
Domain-based Message Authentication, Reporting and Conformance builds on SPF and DKIM. It does two things. First, it requires alignment: a message passes DMARC only if SPF or DKIM passes and the domain that passed matches the domain in the header From. Second, it lets the domain owner publish a policy for failures and ask for reports.
| Policy | Meaning | When to use it |
|---|---|---|
| p=none | Monitor only, take no action on failures | At the start, to read reports |
| p=quarantine | Ask receivers to treat failures as suspicious, such as sending them to spam | After you have fixed legitimate sources |
| p=reject | Ask receivers to refuse failures | When you are confident that all genuine mail aligns |
Start with monitoring, read the reports, fix each legitimate sender and only then tighten the policy. Moving to reject too early can block your own mail. See how to set up DMARC.
ARC: keeping trust through forwarding
Authenticated Received Chain is for intermediaries such as forwarders and mailing lists. When a message passes through, the intermediary records the authentication results it saw and signs that record. A later receiver, seeing that SPF or DKIM now fails because of forwarding, can look at the ARC chain and decide whether to trust the original results. It does not force any receiver to do so. Our guide to email forwarding shows where this matters.
BIMI: your logo in the inbox
Brand Indicators for Message Identification lets a sender publish a logo that supporting mailbox providers can show next to authenticated messages. It depends on strong DMARC enforcement and, at some providers, on extra verification of the logo. It is a visual reward for good authentication, not a substitute for it. See BIMI setup.
TLS: protecting the message in transit
The standards above prove who sent a message. TLS protects the connection between servers, so that nobody can read or change the message while it travels. It does not prove identity by itself, and a message can pass through several hops, so it is not end-to-end encryption. Read email SSL, TLS and STARTTLS.
How the pieces fit together
- The sender signs the message with DKIM and sends it from a server listed in SPF.
- The receiving server checks SPF against the envelope sender and DKIM against the signing domain.
- It then evaluates DMARC: did one of them pass, and does the passing domain match the header From?
- It applies the domain's DMARC policy if not, and records the result in an Authentication-Results header.
- If the message passed through a forwarder, the receiver may consult ARC.
- If everything passes and the domain qualifies, a supporting provider may show the BIMI logo.
You can see the verdicts yourself in a message's headers. Our guide to reading email headers shows where.
How to set up email authentication, in order
- List every system that sends mail as your domain: your mail provider, your newsletter tool, your CRM, your website and your sending service.
- Publish one SPF record that includes them all.
- Turn on DKIM for each sending system, using your own domain.
- Publish DMARC at p=none with an address for reports.
- Read the reports for a few weeks, and fix sources that fail or do not align.
- Move to quarantine, then reject, when you are sure.
- Consider BIMI after enforcement is in place.
The full walk-through is in authenticating your sending domain, and the free SPF, DKIM and DMARC checker tests your records at each step. The DNS side is covered in DNS records for email.
What authentication does not do
Authentication proves that a message came from the domain it claims, and not that the message is good. A criminal can register a lookalike domain, authenticate it perfectly and still send phishing. It also does not replace a good list, consent, and sensible content. Treat it as the foundation that makes the rest of your deliverability work count. For a wider view see our deliverability overview.
Test your domain's authentication in a minute See what your SPF, DKIM and DMARC records publish and what to fix.
References and further reading
Frequently asked questions
What is email authentication?
It is a set of standards, mainly SPF, DKIM and DMARC, that lets a receiving server check who sent a message and whether it was changed in transit.
What is the difference between SPF, DKIM and DMARC?
SPF lists the servers allowed to send for a domain. DKIM signs the message. DMARC requires that one of them passes and matches the visible From domain, and sets a policy and reporting.
In what order should I set up authentication?
List all your senders, publish one SPF record, turn on DKIM for each sender, publish DMARC at monitoring, read the reports, fix gaps and then tighten the policy.
Does authentication guarantee inbox delivery?
No. It is the baseline that lets providers trust the sender. Reputation, list quality and content still decide placement.
What are ARC and BIMI?
ARC lets forwarders pass on the authentication results they saw. BIMI lets authenticated senders show a brand logo in supporting inboxes.