InboxRatio
Check your domain

Email authentication: how mail proves who sent it, and why receivers now insist

Email's founding protocol never asked senders to prove who they were. SMTP — designed in the early 1980s for a small, cooperative network — accepts whatever sender address a connecting machine declares, the way a paper envelope accepts whatever return address you write on it. Every phishing message, every spoofed invoice, every "CEO" wire-transfer request exploits that single omission.

Email authentication is the repair job: a stack of standards, built over two decades and bolted on through DNS, that lets a receiving server verify a message's claimed origin. This guide is the map of that stack — what each layer contributes, how receivers use the results, and what's now mandatory versus optional. For the record-level detail of the three core protocols, see the dedicated deep dive.

One scope note: this is about sender-domain authentication. If your phone is showing an "authentication failed" error on a personal mail account, that's a login problem between your app and your provider — a different topic entirely, not covered here.

Why DNS became the identity layer

Any authentication scheme needs something only the legitimate party controls. For email, the industry settled on DNS: whoever controls example.com's DNS zone can publish records there, and no one else can. So every authentication standard works the same basic way — the domain owner publishes claims in DNS, and receivers check arriving mail against those claims.

That design has a useful consequence: you can audit any domain's authentication posture from the outside, in seconds, because it's all public DNS. Our email authentication checker does exactly that — SPF, DKIM, DMARC, MX and reverse DNS in a single pass. Running it on your own domain before reading further gives the rest of this guide a scoreboard.

The core stack: three layers, one system

SPF publishes the list of servers allowed to send mail for a domain. The receiver checks the connecting IP against the list. Path-based, simple, and blind to anything that happens after the first hop — forwarding breaks it.

DKIM puts a cryptographic signature on the message itself, verifiable against a public key in the signer's DNS. It proves authorization and that the signed content arrived unmodified, and it survives forwarding — the case SPF loses.

DMARC is the coordination layer, and the only one that examines the From: address recipients actually see. It requires an SPF or DKIM pass whose domain aligns with that visible From domain, lets you publish a policy for failures (none, quarantine, reject), and makes receivers report back to you about mail sent in your name.

The division of labor is the point. SPF and DKIM generate proofs about technical identities recipients never look at; DMARC connects those proofs to the human-visible identity and adds consequences. Any layer alone is incomplete: SPF and DKIM without DMARC verify the wrong address, and DMARC without either has nothing to align.

The supporting cast

Three more pieces round out the stack, each answering a narrower question.

Reverse DNS (PTR records). A sending IP should resolve back to a hostname, and that hostname should resolve to the IP. It predates the formal authentication stack, but receivers still check it, and Google's sender guidelines list valid forward and reverse DNS among their requirements. On managed ESP infrastructure this is the platform's job; on your own servers it's yours.

ARC (Authenticated Received Chain). Forwarders and mailing lists legitimately break SPF and sometimes DKIM. ARC lets an intermediary record the authentication results it saw on arrival and pass them along, cryptographically sealed, so the final receiver can weigh the original verdict. It's infrastructure-side — mostly implemented by providers and forwarding services, not something a typical sender deploys — but it explains why forwarded mail fails less often than the raw mechanics predict. More in the protocols overview .

BIMI. The reward tier: with DMARC at enforcement and (at Gmail and some others) a verified logo certificate, your brand mark displays next to your messages. BIMI authenticates nothing by itself — it's an incentive receivers built to push domains toward DMARC enforcement, and it works.

What receivers actually require now

The era of authentication as a best practice ended when the two largest consumer mailbox operators wrote it into policy. Google's bulk sender guidelines — mirrored closely by Yahoo's sender requirements — draw two lines:

  • Everyone sending to Gmail: authenticate with at least SPF or DKIM, maintain valid forward and reverse DNS, and stay under the spam-complaint threshold (0.3% per Google's Postmaster Tools documentation, with lower as the working target).
  • Bulk senders — on the order of 5,000 or more messages a day to Gmail addresses: SPF and DKIM, a published DMARC policy (even p=none), From-domain alignment, and one-click unsubscribe on marketing mail.

Microsoft has published equivalent requirements for high-volume senders to its consumer domains. The direction across all major receivers is identical and one-way: authentication requirements expand, and enforcement tightens over time.

Unauthenticated mail isn't merely disadvantaged anymore — at the required-and-missing end, it's increasingly rejected outright.

What authentication buys you (and what it doesn't)

It buys identity. Authenticated mail accrues reputation to your domain — a track record filters can trust and you can build on. It protects that same reputation by preventing spoofers from spending it: with DMARC enforced, their forgeries stop arriving as "you." See domain reputation for how that record compounds.

It buys eligibility. Compliance with the sender requirements above, DMARC's free reporting stream about everything sent as your domain, and — at the top of the ladder — BIMI logo display.

It does not buy placement. Authentication is an entry check, not a ranking factor you can max out. A fully authenticated sender with poor engagement and a stale list still lands in spam; filters simply move on to judging your mail on its merits, which is the privilege authentication grants. Passing everything and still hitting the spam folder means the problem is elsewhere — the diagnostic order lives in our spam-placement guide.

Auditing a real message

DNS says what should happen; headers say what did. Every major receiver stamps arriving mail with an Authentication-Results header:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce.example.com designates 203.0.113.25 as permitted sender);
       dkim=pass header.d=example.com header.s=s1;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Read: SPF passed for the envelope domain, DKIM verified with example.com's key, and DMARC passed against the visible From. Send yourself a message from your platform and paste its raw source into the email header analyzer for the decoded version of exactly this check — it's the fastest way to see your authentication the way Gmail sees it.

Related guides

About this guide

Written by InboxRatio Editorial. Standards behavior follows the governing RFCs; receiver requirements are attributed to Google, Yahoo and Microsoft's published sender documentation. Deliverability effects described here reflect our own controlled placement testing — we treat vendor claims as claims, per our published source rules.

Methodology

InboxRatio benchmarks email platforms by sending identical campaigns to a controlled seed list and recording placement per mailbox provider — with the full authentication stack configured on our own test domains first, since receivers filter unauthenticated mail differently and the comparison must isolate the platform. Protocol details: how we test.

Last updated

21 August 2026. Receiver requirements re-checked quarterly against provider documentation.

Frequently asked questions

What is email authentication in plain terms? Publicly checkable proof of who sent a message: DNS records that let receiving servers verify a message's claimed domain (SPF, DKIM) and confirm the address recipients see matches what was verified (DMARC).

Is email authentication required now? For bulk senders to Gmail and Yahoo, yes — SPF, DKIM and a DMARC policy are published requirements. For everyone else, at least SPF or DKIM is required by Google's general sender guidelines, and unauthenticated mail is filtered increasingly hard regardless of volume.

What's the difference between SPF, DKIM and DMARC? SPF authorizes sending servers by IP; DKIM signs the message cryptographically; DMARC requires one of those proofs to match the visible From address and sets the penalty for failure. They're layers of one system, not alternatives.

How do I check if my email authentication is set up correctly? Two checks: run your domain through the email authentication checker for the DNS side, then send a real message and inspect its Authentication-Results header for the live verdict. Do both — DNS can be right while your platform signs with the wrong domain.

Will setting up authentication stop my emails going to spam? It removes authentication failure as a filtering reason and is mandatory groundwork, but placement also rides on reputation, list quality and engagement. Authenticated spam is still spam to a filter.

Does authentication stop phishing emails that impersonate my brand? DMARC at quarantine or reject stops exact-domain spoofing at honoring receivers. It does not stop lookalike domains (examp1e.com) — those are a different attack needing different defenses, like monitoring and takedowns.

Authentication is now the price of admission — three DNS records and correct signing buy you identity, reporting and compliance with the receivers' published rules. Audit where your domain stands in one pass with the email authentication checker.