What is email authentication, and how does it work?

Email was designed without any way to check who sent a message. Anyone can type any address into the From line, and the receiving server has no built-in way to know it's false. Email authentication fixes that for domains that take part: it lets receivers verify the sending domain, reject impostors and build trust in your real mail. This guide explains what it is, how the pieces fit together, and how to set it up.

What is email authentication?

Email authentication is a group of standards that let a receiving mail server verify that a message really comes from the domain it claims to be from. Microsoft defines it as "a group of standards to identify and prevent the delivery of email messages from forged senders (also known as spoofing)" (Microsoft Learn).

The domain owner publishes records in DNS (the internet's public directory). Receiving servers look those records up for each message and record a pass or fail. The main standards are:

• SPF (Sender Policy Framework): a list of servers allowed to send for a domain.
• DKIM (DomainKeys Identified Mail): a digital signature added to each message.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): a policy that ties SPF and DKIM to the From address people see.

Authentication answers "is this really from that domain?" It doesn't answer "is this safe?" A scammer can authenticate their own domain perfectly.

Why does email need authentication?

The protocol that moves email, SMTP, doesn't check senders. Microsoft puts it plainly: SMTP email "makes no effort to validate that the message sender is who they claim to be."

Part of the problem is that every message has two sender addresses:

An attacker can use their own domain in the envelope and your domain in the From line. Here's a simplified example, adapted from Microsoft's documentation (example only):

MAIL FROM: <bounce@attacker.example>
From: "Your Bank Security" <security@yourbank.example>
Subject: Action required: verify your account

SPF alone could pass for attacker.example. Only DMARC asks whether the domain that passed matches yourbank.example. That's why the three standards are used together. Spoofed senders are a common tool in business email compromise and phishing; see what is email spoofing.

What are the main email authentication methods?

Sample records for a domain that sends through Google Workspace (example only; use your provider's exact values):

example.com.                      TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey.example.com.    TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.com.               TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Each standard has its own guide: what is SPF, what is DKIM, what is DMARC and ARC explained. For a side-by-side of what each one proves and doesn't, see SPF vs DKIM vs DMARC.

Two related standards are often mentioned alongside them. BIMI shows your logo in some inboxes, but only for domains with an enforcing DMARC policy (BIMI explained). MTA-STS protects the connection between servers, not the sender's identity (MTA-STS and TLS-RPT).

How does email authentication work, step by step?

1. The domain owner publishes records. SPF lists the sending services, DKIM publishes a public key for each one, and DMARC publishes a policy.
2. The sending service signs the message. It adds a DKIM-Signature header using its private key, with d= naming the signing domain.
3. The receiver checks SPF. It looks up the SPF record for the envelope domain and compares the connecting IP address.
4. The receiver checks DKIM. It fetches the public key named in the signature and verifies the signature against the message.
5. The receiver checks DMARC. It looks up the DMARC record for the From domain and asks whether SPF or DKIM passed for an aligned domain. "Aligned" means the same domain, or under relaxed alignment, the same organizational domain (alignment explained).
6. The receiver applies the policy. With p=none it only reports. With p=quarantine failing mail usually goes to spam, and with p=reject it's refused. The receiver still makes the final decision.
7. The receiver records the result in an Authentication-Results header and, if you asked for reports, includes the message in a daily DMARC aggregate report.

What does a passing result look like?

Receivers record their verdict in the Authentication-Results header defined by RFC 8601. A fully authenticated message looks like this (example only):

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com header.s=google;
  dmarc=pass (p=QUARANTINE) header.from=example.com

Read it field by field: SPF passed for example.com as the envelope domain, DKIM passed with example.com as the signing domain using selector google, and DMARC passed because both match the From domain. Microsoft 365 adds a compauth (composite authentication) value that also weighs reputation and history.

The usual problem is dkim=pass with dmarc=fail, which means a service signed with its own domain instead of yours. Our guide on how to check if an email passed SPF, DKIM and DMARC shows where to find the header in each email app, or paste headers into the Email Header Analyzer.

Is email authentication required?

For mail to the largest mailbox providers, effectively yes, at the time of writing (November 2026).

Google warns that messages without authentication "might be marked as spam or rejected with a 5.7.26 error" (Gmail Help). Yahoo's rules are on its Sender Hub, and Microsoft's are on its Outlook.com postmaster policies page. Our bulk sender requirements guide covers thresholds, deadlines and Microsoft's rejection code in detail.

Even if you send far less, authentication decides whether your invoices and replies reach the inbox, and DMARC is the only thing that stops others from sending as your exact domain.

What doesn't email authentication do?

Authentication is necessary, but it's one layer. It doesn't:

• Stop look-alike domains. examp1e.com can pass SPF, DKIM and DMARC for itself. See lookalike domain phishing.
• Stop display-name tricks. A From line reading "Your CEO" with a free-mail address passes for the free-mail provider. See display name spoofing.
• Stop compromised accounts. Mail sent from a real, hijacked mailbox authenticates perfectly.
• Prove a message is safe or wanted. Spammers authenticate too.
• Survive every forward. Forwarding often breaks SPF, and mailing lists that change content can break DKIM; see email forwarding and DMARC.

That's why inbound filtering still checks content, links, attachments and reputation after authentication.

Do subdomains and SPF endings matter?

Two details trip up many first setups: subdomains and the last word of the SPF record.

Do subdomains need their own records?

For SPF, yes. Microsoft says "Each domain and any subdomains require their own individual SPF records. Subdomains don't inherit the SPF record of the parent domain" (Microsoft Learn). If your newsletter tool sends as news.example.com, that subdomain needs an SPF record of its own.

DKIM works per signature: each sending service signs with a selector and a domain you set up for it. DMARC is different. A subdomain without its own DMARC record falls back to the record of its organizational domain, and the sp tag there sets the policy "for all subdomains" that exist (RFC 9989). The newer np tag covers subdomains that don't exist at all, which is where attackers often invent addresses. Our guide to the DMARC subdomain policy has examples.

Should SPF end in ~all or -all?

The ending tells receivers what to do with servers you didn't list. Microsoft describes -all as a "hard fail" to reject the message and ~all as a "soft fail" to accept and mark it. Its advice for a domain that isn't sure of every sender is to start with ~all, find the remaining sources, and only then consider -all. Once DMARC is enforcing, the DMARC policy decides what happens to failing mail, so the ending matters less than it seems. See SPF softfail vs hardfail for the details.

Microsoft also notes that these standards are "interdependent building blocks" and that "Anything less than all of the email authentication methods results in substandard protection." In practice, that means publishing all three, not picking one.

How many domains have it set up?

Adoption is far from complete. In our scan of the Tranco top 1,000 domains in October 2026, 76.4% published SPF, 26.5% had no DMARC record at all, and 38.3% didn't enforce DMARC (no record, p=none or invalid). Twenty-two domains had SPF records that broke the 10-lookup limit. If very large sites miss these, smaller ones are worth checking.

How do you set up email authentication for your domain?

1. List every service that sends as your domain: your mailbox provider, marketing platform, CRM, helpdesk, billing and website forms. Our guide to authenticating third-party senders helps.
2. Publish one SPF record that includes those services and stays under 10 DNS lookups. Build it with the SPF Generator.
3. Turn on DKIM for each service using your own domain, not the service's default. See DKIM records by provider.
4. Publish DMARC at p=none with a rua= reporting address, using the DMARC Generator.
5. Read the reports for a few weeks and fix every legitimate source that fails (how to read DMARC reports).
6. Move to p=quarantine, then p=reject. Our DMARC none-to-reject plan gives a timeline.
7. Lock down domains that don't send with v=spf1 -all and p=reject (protect parked domains).

Next steps

• Check your domain now with the free Email Health Check, which grades MX, SPF, DKIM, DMARC and transport security in one scan.
• Send yourself a test message and confirm spf=pass, dkim=pass and dmarc=pass in the headers.
• If you have no DMARC record, publish one at p=none with reporting today.
• iBlockSpam's DMARC monitoring collects your aggregate reports, shows which senders pass or fail, and recommends when to move to quarantine and reject. It's included in every plan; see pricing.

Browse our other SPF, DKIM and DMARC guides.