The complete guide to email authentication

Email authentication is a set of three DNS based standards, SPF, DKIM, and DMARC, that let a receiving server confirm a message genuinely came from your domain and was not forged in transit. Together they decide whether your mail is trusted enough to reach the inbox instead of the spam folder or a hard rejection.

Email was built in an era of trust, with no way to verify who actually sent a message. To this day, anyone can put your domain in the visible From line of an email they send. Authentication closes that gap. SPF publishes the list of servers allowed to send for your domain, DKIM adds a tamper proof signature to every message, and DMARC ties both checks to the address your recipients actually see and tells receivers what to do when something does not line up.

Why email authentication is now mandatory

Since February 2024, the largest mailbox providers require authentication from bulk senders. Any domain sending more than 5,000 messages a day to Gmail or Yahoo, and to consumer Outlook addresses since 2025, must publish SPF, DKIM, and a DMARC record or watch its mail get filtered or rejected.

The Google and Yahoo bulk sender guidelines, published in 2024, set the baseline that the rest of the industry now follows. Bulk senders must authenticate with SPF and DKIM, publish a DMARC policy of at least p=none, pass DMARC alignment, support one click unsubscribe through the List-Unsubscribe header, and keep spam complaints low. Google asks senders to stay under 0.1% complaints and treats 0.3% as a hard ceiling that triggers filtering. Microsoft extended the same expectations to high volume senders into consumer Outlook in 2025.

The threshold catches more senders than people expect, and the bar keeps moving toward enforcement. Even if you send far fewer than 5,000 messages a day, missing authentication caps how high your reputation can climb and leaves your domain open to being spoofed in phishing attacks against your own customers. There is no real downside to authenticating, and a large one to skipping it.

How SPF, DKIM, and DMARC work together

When a server receives your message it runs three checks in sequence. SPF asks whether the sending IP is authorized, DKIM verifies the cryptographic signature, and DMARC asks whether an authenticated domain matches the visible From address. The message passes when SPF or DKIM aligns and passes; if both fail, your DMARC policy decides what happens.

The reason DMARC matters is that SPF and DKIM each leave a gap on their own. SPF checks the hidden Return-Path address used during delivery, not the From address your recipient reads, so a spoofer can pass SPF with their own domain while displaying yours. DKIM proves a message was signed and unchanged, but on its own it carries no instruction for what a receiver should do when the signature is missing or broken. DMARC fixes both by requiring that whatever passed, SPF or DKIM, lines up with the visible From domain, and by publishing a clear policy. That single requirement, called alignment, is what turns two useful checks into real protection against someone forging your address.

SPF: which servers may send as your domain

SPF, the Sender Policy Framework defined in RFC 7208, is a single DNS TXT record that lists every server allowed to send mail for your domain. When a message arrives, the receiver compares the sending IP against that list and the check passes only if it matches.

SPF record syntax

An SPF record lives as a TXT record at your domain root. It always begins with v=spf1 and ends with an all mechanism that sets the default for anything not explicitly listed.

v=spf1 include:_spf.google.com include:_spf.yourprovider.com ip4:203.0.113.50 -all

Reading that record left to right:

• v=spf1 is the version tag. It is required and must come first.
• include:_spf.google.com authorizes every server listed in another provider's SPF record, used here for a hosted mail platform.
• include:_spf.yourprovider.com adds a second sending service, such as a marketing or transactional platform.
• ip4:203.0.113.50 authorizes one specific IPv4 address, such as your own server.
• -all hard fails everything else, meaning no other server is allowed to send as your domain.

SPF mechanisms

The qualifier on all

The character before all decides what happens to mail from a server that is not on your list:

• -all is a hard fail. Unauthorized mail should be rejected. This is the recommended setting once your record is complete.
• ~all is a soft fail. Unauthorized mail is accepted but marked as suspect. Use it while you are still finding all your senders.
• ?all is neutral. It makes no assertion at all and offers no protection.
• +all passes everything. Never use it; it authorizes the entire internet to send as your domain.

DKIM: cryptographic proof the message is genuine

DKIM, DomainKeys Identified Mail from RFC 6376, adds a digital signature to every message you send. Your server signs each email with a private key, the matching public key is published in DNS, and the receiver uses it to confirm the message really came from your domain and was not altered along the way.

DKIM uses public key cryptography. The signature covers a defined set of headers, typically From, Subject, and Date, along with the body of the message. If any signed part is changed after sending, the signature no longer verifies and DKIM fails. That is what makes it tamper evident rather than just an identity claim.

The DKIM signature

The signature travels with the message as a header. A simplified example looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1; h=from:to:subject:date;
  bh=<body-hash>; b=<signature>

The fields that matter most:

• d= is the signing domain. It must align with your From domain for DMARC to count the DKIM result.
• s= is the selector, which tells the receiver where in DNS to find the public key.
• a= is the algorithm, normally rsa-sha256.
• h= lists the headers the signature protects.
• b= is the signature itself, and bh= is the hash of the body.

The DKIM DNS record and selectors

A selector lets one domain publish several keys at once, which is what makes key rotation and multiple sending services possible. The public key is published as a TXT record at selector._domainkey.yourdomain.com:

; published in DNS for selector "selector1"
selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

Here v=DKIM1 is the version, k=rsa is the key type, and p= holds the base64 encoded public key. An empty p= value means the key has been revoked.

Modern guidance, set out in RFC 8301, is to use a 2048-bit RSA key as the default and to treat 1024 bits as the bare minimum. A 2048-bit key is too long to fit in a single 255 character DNS string, so it is split across multiple quoted strings inside the same record; most DNS hosts handle that automatically. Rotate your keys periodically by publishing a new selector and switching your signing to it, so a leaked key has a limited useful life.

DMARC: alignment, policy, and reporting

DMARC, defined in RFC 7489, ties SPF and DKIM to the address your recipients see and tells receivers what to do when a message fails. It adds three things the other two lack: alignment with the visible From domain, an enforcement policy, and reports that show you exactly who is sending mail as your domain.

A DMARC record is a TXT record published at _dmarc.yourdomain.com. A monitoring record looks like this:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100"

DMARC tags

The policy ladder

The p= tag is the heart of DMARC. You climb it gradually, from monitoring to full enforcement, so you never block legitimate mail by accident:

• p=none takes no action and simply collects reports. It is where every rollout starts, and it provides no spoofing protection on its own.
• p=quarantine sends failing mail to the spam or junk folder. It is the safe intermediate step once your reports look clean.
• p=reject blocks failing mail outright during delivery. This is full protection and the goal of any serious rollout.

Alignment, relaxed and strict

Alignment is the rule that makes DMARC work. A message passes DMARC only when the domain that passed SPF or DKIM lines up with the domain in the visible From header.

• Relaxed alignment, the default, matches on the organizational domain, so mail.example.com aligns with example.com.
• Strict alignment requires an exact match, so mail.example.com would not align with example.com.

Reports are the other half of DMARC. Aggregate reports, requested with rua, are daily XML summaries that show every source sending under your domain and whether each one passed. They are the single most useful tool for finding forgotten senders before you tighten your policy. Failure reports, requested with ruf, contain per message detail and are rarely sent today because of privacy concerns, so most senders rely on aggregate reports alone.

SPF vs DKIM vs DMARC at a glance

SPF checks the sending IP, DKIM signs the message, and DMARC ties both to the visible From address and sets the policy. They protect different things and you need all three, because each one covers a gap the others leave open.

How to set up SPF, DKIM, and DMARC in the right order

Set them up in sequence: inventory your senders, publish one SPF record, enable DKIM on each service, then add a DMARC record in monitoring mode and tighten it only after the reports come back clean. Rushing straight to enforcement is the fastest way to block your own mail.

Common mistakes that break authentication

Most authentication failures trace back to a handful of avoidable errors: more than one SPF record, too many DNS lookups, and a DMARC policy that never leaves monitoring mode. Each one silently undermines the protection you think you have.

• Two SPF records. A domain must have exactly one v=spf1 TXT record. A second one is not additive; it makes SPF return a permerror and fail outright.
• Too many DNS lookups. Stacking include statements past the limit of 10 breaks SPF. Flatten or consolidate sources to stay under it.
• Forgotten senders. Every service that mails as your domain must be authorized in SPF and signing with DKIM, or its mail will fail once you enforce DMARC.
• Using +all or the ptr mechanism. +all authorizes the whole internet, and ptr is slow, unreliable, and discouraged by the specification.
• Living on p=none. Monitoring is a starting point, not a destination. A policy that never reaches quarantine or reject leaves your domain just as spoofable as having no DMARC at all.