The complete guide to email authentication

24 June 2026 · DMARC Engine · 13 min read

Email was designed in an era of mutual trust, and that original sin still shapes the inbox today: by default, anyone can put your domain in the "From" address of a message and most receivers will deliver it. Email authentication is the layered set of standards that closes that gap, proving a message genuinely came from your organisation, that it was not tampered with in transit, and that receivers should reject anything that fails. This guide is the canonical overview: what SPF, DKIM, DMARC, MTA-STS and BIMI each do, the crucial concept of alignment that ties them together, and the exact order to deploy them so you move from zero to fully protected without breaking legitimate mail.

If you read nothing else, read this: SPF and DKIM are the two underlying checks, DMARC is the policy layer that makes them meaningful through alignment, MTA-STS secures the transport, and BIMI is the visible reward you earn only after the rest are enforced. They are not alternatives. They are a stack, and the order matters.

Why email needs authentication at all

The protocol that carries email, SMTP, has no built-in notion of identity. A sending server simply announces who the mail is from and the receiving server takes it largely on faith. That is why spoofing, phishing and business email compromise remain among the most effective attack techniques in existence: an attacker does not need to break into your systems to send mail that looks exactly like it came from your CEO, your finance team or your billing department.

There is also a deliverability dimension that has become unavoidable. Since February 2024, Google and Yahoo have required bulk senders (those sending roughly 5,000 or more messages a day to their users) to authenticate with SPF and DKIM, publish a DMARC policy, and keep spam complaints low. Microsoft has since signalled the same direction. Authentication is no longer a security nicety; it is the price of admission to the inbox.

To understand the stack, it helps to separate two questions a receiver asks. First: "Is this server allowed to send for this domain, and was the message altered?" That is SPF and DKIM. Second: "Does the domain the human sees actually vouch for this, and what should I do if it doesn't?" That is DMARC. Everything hinges on connecting those two questions, which is what alignment does.

SPF: who is allowed to send

The Sender Policy Framework (RFC 7208) lets a domain owner publish, in DNS, the list of servers permitted to send mail using that domain. It is a single TXT record at the domain root that a receiver looks up and evaluates against the connecting server's IP address.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.20 -all

Reading it left to right: v=spf1 declares the version; each include pulls in the SPF record of a third-party sender (Google Workspace, SendGrid, your CRM); ip4 authorises a specific address; and the final mechanism is the all-important qualifier.

That trailing qualifier is where most SPF mistakes live:

• -all (hardfail) means "anything not listed above is unauthorised: reject it." This is the goal.
• ~all (softfail) means "treat unlisted senders as suspicious but accept." Useful while testing, but not a finished state.
• +all means "anyone may send as me." Never use this; it is the equivalent of leaving the door open.

SPF has two limitations you must respect. First, it authenticates the envelope sender (the MAIL FROM, also called the Return-Path), not the From: header the human reads, a gap DMARC later closes through alignment. Second, RFC 7208 imposes a hard limit of 10 DNS lookups when evaluating a record. Every include, a, mx, ptr and exists mechanism costs lookups, and nested includes count too. Exceed ten and the result is a permerror, which DMARC treats as an SPF failure, silently breaking your mail. This is the single most common SPF fault we see, and it is why SPF flattening (resolving those includes down to a compact set of IP ranges) exists. Our SPF checker counts your lookups and flags a permerror before it bites; the SPF generator helps you build a clean record from scratch.

DKIM: proof the message was not tampered with

Where SPF authorises servers, DomainKeys Identified Mail (RFC 6376) authenticates the message itself. The sending server signs selected headers and the body with a private key, and attaches a DKIM-Signature header. The matching public key lives in DNS, so any receiver can verify the signature.

The DNS side uses a selector so that one domain can run multiple keys (different vendors, or old and new keys during rotation). The public key is published at selector._domainkey.yourdomain.com:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The signature header on a message points back to it:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
  c=relaxed/relaxed; h=from:to:subject:date; bh=...; b=...

A few things matter here. The d= tag is the signing domain. Remember it, because alignment will compare it to the visible From: domain. The h= tag lists which headers were signed; c= is the canonicalisation (the relaxed/relaxed setting tolerates the minor whitespace and header changes that mailing lists and gateways introduce, which is why it is the sensible default). Use 2048-bit RSA keys; 1024-bit is now considered weak.

Two DKIM disciplines repay the effort:

• Key rotation. Keys should be rotated periodically. Because selectors let you publish a new key alongside the old one, you can rotate with zero downtime: publish the new key, switch signing to the new selector, then retire the old one once no in-flight mail relies on it.
• Verify before you trust the dashboard. Vendors love to claim DKIM is "enabled" when the DNS record is missing or truncated. Confirm the published key resolves with a DKIM checker, and generate fresh keys with the DKIM generator.

DKIM survives forwarding far better than SPF, because the signature travels with the message rather than depending on the connecting IP. That resilience is why DKIM alignment is often the workhorse that keeps DMARC passing.

DMARC: the policy layer that makes it all mean something

Here is the problem SPF and DKIM leave open. SPF checks the Return-Path. DKIM checks the signing domain in d=. Neither is required to match the From: address the recipient actually sees. An attacker can pass SPF for their own throwaway domain while spoofing your brand in the visible From:. DMARC (RFC 7489) fixes this with two ideas: alignment and policy.

Alignment is the whole point

DMARC says a message passes only if at least one of SPF or DKIM both passes and aligns with the From: header domain.

• SPF alignment: the From: domain matches the Return-Path domain that SPF authenticated.
• DKIM alignment: the From: domain matches the d= domain that signed the message.

Alignment can be strict (an exact match) or relaxed (the organisational domain matches, so mail.example.com aligns with example.com). Relaxed is the default and is almost always what you want. DMARC passes if either SPF or DKIM achieves an aligned pass. You do not need both. This is the conceptual centre of the entire stack: SPF and DKIM are necessary, but alignment is what turns them into a real identity guarantee.

Policy tells receivers what to do

A DMARC record is a TXT record published at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1; adkim=r; aspf=r

The key tags:

• p= is the policy applied to mail that fails DMARC: none (monitor only, take no action), quarantine (send to spam), or reject (refuse outright). p=reject is the destination.
• rua= is where aggregate reports are sent: daily XML summaries from receivers showing every source sending as your domain, and whether it passed. These reports are how you discover your own legitimate senders before you start blocking.
• sp= sets a separate policy for subdomains; pct= rolls a policy out to a percentage of mail; adkim/aspf set strict or relaxed alignment; fo=1 requests failure reports for any mechanism failure.

The reason DMARC is deployed in stages is precisely that rua data. You start at p=none not because it protects you (it does not, it is monitor-only) but because it shows you the full inventory of who sends mail as your domain. Almost every organisation discovers forgotten senders: a marketing platform, an invoicing tool, a helpdesk, a regional office. You authenticate those, watch the pass rate climb, and only then tighten the policy. Skipping the monitoring stage and jumping straight to p=reject is the fastest way to block your own payroll system. See the enforcement journey for the full staged approach, and parse your own policy with the DMARC checker.

MTA-STS: securing the transport

SPF, DKIM and DMARC authenticate the content and sender of a message, but they say nothing about whether the connection delivering it was encrypted. By default, SMTP encryption (STARTTLS) is opportunistic. If an attacker on the network strips the TLS offer, the message can be delivered in plaintext or redirected, and neither side notices. This is a downgrade attack.

MTA-STS (RFC 8461) closes that hole. You publish a DNS TXT record and host a policy file over HTTPS that tells sending servers: "for my domain, TLS is mandatory; if you cannot establish a valid TLS connection to my listed MX hosts, do not deliver." The policy is served at a well-known URL:

https://mta-sts.example.com/.well-known/mta-sts.txt

with contents such as:

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

The companion standard, TLS-RPT, asks reporting receivers to send you summaries of any TLS negotiation failures, so you find problems before they cause silent delivery loss. Start MTA-STS in mode: testing (which reports failures without enforcing), confirm clean reports, then move to mode: enforce. Validate the published policy with the MTA-STS checker and watch failure reports through the TLS-RPT checker. Our hosted MTA-STS handles the HTTPS endpoint and certificate so you do not have to stand up a web server purely to serve one text file.

BIMI: the visible reward

Brand Indicators for Message Identification is the only part of the stack your recipients actually see: your logo displayed next to your messages in supporting mailboxes. It is also the part you cannot fake your way into, because the BIMI specification has a hard prerequisite: your domain must already be at an enforced DMARC policy (p=quarantine with a high percentage, or p=reject). BIMI is deliberately positioned as the carrot at the end of the journey: you only get the brand visibility once you have proven your domain is locked down.

BIMI is published as a TXT record at default._bimi.yourdomain.com pointing to a logo and, usually, a certificate:

v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem

The logo must be SVG Tiny PS (a specific, restricted SVG profile: square, no scripting, no external references). The a= tag points to a VMC (Verified Mark Certificate) or, for registered-but-not-trademarked logos, the newer CMC (Common Mark Certificate). Major mailbox providers, Gmail among them, require that certificate before they will render your logo. Convert and validate artwork with the BIMI SVG converter and logo validator, and confirm the published record with the BIMI checker. The full picture is on the BIMI product page.

How they interlock: the mental model

Put the layers together and the architecture is clean:

• SPF answers: is this server authorised? (envelope-level)
• DKIM answers: is this message intact and signed by a domain? (message-level)
• DMARC answers: does an SPF or DKIM pass align with the visible From:, and what should the receiver do if not? (policy + identity)
• MTA-STS answers: was the connection carrying the message encrypted and tamper-proof? (transport)
• BIMI answers: now that you are enforced, what logo should the inbox show? (brand)

The dependency chain runs strictly one way. DMARC is meaningless without at least one of SPF or DKIM aligning. BIMI is unobtainable without enforced DMARC. MTA-STS sits alongside, securing the pipe regardless. This is why "just turn on DMARC" advice is dangerous in isolation. DMARC without correct SPF and DKIM either does nothing (p=none) or blocks your own mail (p=reject).

The deployment roadmap: zero to fully protected

Deploy in this order. Each stage de-risks the next.

1. Inventory your senders. Before changing anything, list every system that sends mail as your domain: mail platform, CRM, marketing tool, invoicing, helpdesk, monitoring alerts, regional offices. You cannot authenticate what you have not found.
2. Publish SPF, ending in ~all. Authorise every known sender. Keep within the 10-lookup limit, flattening if needed. Use softfail initially so you can observe without blocking.
3. Enable DKIM on every sender and verify the keys resolve. Use 2048-bit keys and relaxed/relaxed canonicalisation. Confirm each vendor's selector actually publishes in your DNS.
4. Publish DMARC at p=none with rua reporting. Collect aggregate reports for two to four weeks. This is your discovery phase. The reports reveal senders you missed and whether they align.
5. Fix alignment gaps. For each legitimate source that fails, fix SPF (correct domain/IP) or DKIM (sign with your domain in d=). Drive your aligned pass rate toward 100%.
6. Tighten SPF to -all. Once SPF is complete and accurate, switch the qualifier to hardfail.
7. Move DMARC to p=quarantine, then p=reject. Step gradually, optionally using pct= to ramp. Keep watching reports at each step; back off if a legitimate source breaks.
8. Deploy MTA-STS in testing, then enforce. Add TLS-RPT, confirm clean reports, switch to mode: enforce.
9. Earn BIMI. With enforced DMARC in place, prepare your SVG Tiny PS logo, obtain a VMC or CMC, and publish the BIMI record.

The whole journey typically takes weeks, not days, and the slow part is intentional. Every escalation is validated against real report data before it goes live. Run a free snapshot of where you stand today with the domain analyzer or check a single policy with the DMARC checker.

Where DMARC Engine fits

The mechanics above are well-defined standards; the difficulty is operational: reading XML reports, chasing down shadow senders, flattening SPF without breaking it, rotating DKIM keys, hosting an MTA-STS endpoint, and timing each policy escalation safely. That is the work hosted DMARC is built to remove: managed records, human-readable analytics over your aggregate reports, drift detection when DNS changes, and a guided ramp to p=reject designed to reach enforcement with no email outage. The same applies across hosted SPF, DKIM, MTA-STS and BIMI.

Next steps

Email authentication is a stack, not a switch. SPF and DKIM establish the underlying checks; DMARC makes them meaningful through alignment and tells receivers what to enforce; MTA-STS secures the transport; and BIMI rewards a fully enforced domain with visible brand trust. Deploy them in order, let report data drive every escalation, and you will reach p=reject without losing a single legitimate message.

Start with a free assessment using the domain analyzer, then follow the enforcement journey to move from monitoring to full protection.