SPF, DKIM & DMARC: How Email Authentication Works

Email was built on trust, so the From line can be faked with no technical barrier. A handful of DNS records exist to close that gap: MX records say where mail is delivered, SPF, DKIM and DMARC say who may send and how to treat impostors, and newer records such as MTA-STS and BIMI protect the connection and display your logo. This guide shows what each one does, how they fit together and which of the detailed guides to read next.

The authentication protocols do not judge whether a message is wanted or safe. They answer a narrower question: is this sender authorised to act for this domain, and can that claim be verified? Standards and sender rules were checked against the RFCs, the BIMI Group and the providers’ own pages on 8 October 2026.

At a Glance: Which Guide Should You Read?

The Three Protocols Compared

SPF: who is allowed to send

You publish the servers allowed to send for your domain, and receivers compare the connecting IP address with that list. It is good at stopping low-effort spoofing but it was not meant to work alone. Read the SPF guide.

DKIM: proving the message was not altered

A signature travels with the message, so it usually survives forwarding where SPF does not. It proves integrity, not identity, because a message can carry a valid signature from an unrelated domain while showing a bank’s name in From. Read the DKIM guide.

DMARC: tying identity to policy

DMARC introduces alignment: the visible From domain must match the domain verified by SPF, DKIM or both. If it does not, the policy decides: none (monitor), quarantine (spam folder) or reject (refuse at the server). It turns the From line from a cosmetic label into a verified identifier. Read the DMARC guide.

The Rest of Your Email DNS

Authentication records sit alongside the records that make mail work at all. These are the ones worth knowing.

MX and reverse DNS

MX controls inbound mail and nothing else, so it is separate from authentication. Your mailbox provider gives you the values. A domain that sends no mail and receives none can publish a “null MX” (RFC 7505) to say so, which saves senders retrying. Reverse DNS matters when you run your own mail server, since many receivers distrust sending IPs without a sensible PTR record. If you use a hosted provider, they manage it.

MTA-STS and TLS reporting

Ordinary SMTP encryption (STARTTLS) can be stripped by an attacker on the path. MTA-STS (RFC 8461) lets you publish a policy that senders cache: a TXT record at _mta-sts signals it, and the policy itself is fetched over HTTPS from https://mta-sts.yourdomain/.well-known/mta-sts.txt. It lists your allowed MX hosts, a mode of testing, enforce or none, and a cache lifetime. In enforce mode, senders must not deliver to a server that fails certificate or STARTTLS checks.

TLS-RPT (RFC 8460) is the companion: a TXT record at _smtp._tls such as v=TLSRPTv1; rua=mailto:reports@yourdomain asks senders to send daily JSON reports on failed TLS sessions. Start with MTA-STS in testing mode and read the reports before enforcing.

MTA-STS protects mail arriving at your domain. It says nothing about whether the sender is genuine, so it complements SPF, DKIM and DMARC rather than replacing them.

BIMI

BIMI displays your brand logo beside your messages in supporting mailbox providers. According to the BIMI Group, you need SPF, DKIM and DMARC all passing and aligned, DMARC at quarantine or reject with no partial percentage, a logo in SVG Tiny PS format and a TXT record at default._bimi. A Verified Mark Certificate or Common Mark Certificate is optional in the specification but strongly recommended, because providers have limited support for self-asserted logos. Each mailbox provider sets its own rules for when a logo appears. It is a branding feature for organisations, not a security control.

What Gmail, Yahoo and Outlook.com Expect

The Outlook.com rule is the one I could confirm only through a secondary source, so check Microsoft’s own announcement before relying on the exact threshold.

Why Authentication Does Not Guarantee Inbox Delivery

A common misconception is that correct SPF, DKIM and DMARC setup guarantees inbox placement. It does not. Authentication proves a sender is technically authorised to speak. It does not prove the recipient wants to listen.

Spam filters also weigh behaviour:

• Sender reputation built up over time.
• Sudden volume spikes or irregular sending patterns.
• Engagement, such as opens, spam complaints and clicks.

A fully authenticated domain can still land in spam if its sending habits look abusive.

What Authentication Protects Against, and What It Does Not

It solves impersonation and exact-domain spoofing by unauthorised third parties. It ignores intent. Mail can pass all three checks and still carry scams, malicious links or unwanted marketing. Attackers increasingly register their own domains and give them complete, valid authentication records rather than spoofing yours, which is why a pass is a floor and not a verdict.

Practical Checklist for Domain Owners

1. Audit your senders. List every service that sends as your domain: mailbox provider, newsletter tool, CRM, web host, helpdesk, invoicing.
2. Publish one SPF record covering them, and keep it under 10 DNS lookups.
3. Turn on DKIM in every service, signing with your own domain.
4. Publish DMARC at p=none with a reporting address, and read the reports.
5. Fix legitimate failures, then move to quarantine and reject.
6. Lock down domains that never send mail with v=spf1 -all and a p=reject DMARC record.
7. Add MTA-STS and TLS-RPT if you want to protect inbound delivery.

Frequently Asked Questions

Do I need all three of SPF, DKIM and DMARC?

For a domain that sends real mail, yes. SPF and DKIM provide the checks and DMARC makes receivers act on them and ties the result to the From address. Gmail and Yahoo expect all three from bulk senders.

Which should I set up first?

SPF and DKIM, then DMARC at p=none. DMARC reports then show what you missed.

Will correct records stop my email going to spam?

Not on their own. They remove one reason for rejection, but reputation, content and engagement still matter.

Can someone still spoof my domain if I have SPF?

Yes. SPF checks the envelope sender, not the From header. DMARC enforcement is what blocks spoofed From addresses.

Is MTA-STS the same as DMARC?

No. MTA-STS secures the connection when mail is delivered to you. DMARC controls how receivers treat mail claiming to be from you.

Do I need BIMI?

No. It is optional branding for organisations that already have DMARC enforcement in place.

Do free Gmail or Outlook users need to do anything?

No. The provider publishes these records for its own domains. The work applies when you use your own domain.

The Bottom Line

Authentication answers “who is this from?” but not “should I trust it?”. SPF says which servers may send, DKIM says the message was not changed, and DMARC decides what happens when the answers do not line up with the From address. Get those three right, add the transport and branding records if they suit you, and read the detailed guides when something fails.

Sources: RFC 8461 (MTA-STS); RFC 8460 (TLS-RPT); BIMI Group implementation guide; plus the sources listed in the SPF, DKIM and DMARC guides. No affiliate links in this article.