How Email Authentication Works: SPF, DKIM, DMARC

Email authentication is the set of DNS-based standards that let receiving mail servers verify that a message actually came from the domain it claims to be from. Without authentication, anyone can forge the From address on an email, which is exactly how phishing, business email compromise (BEC), and brand impersonation attacks succeed.

Two years ago, in February 2024, Gmail and Yahoo jointly announced bulk sender requirements that mandated SPF, DKIM, and DMARC for any domain sending more than 5,000 messages a day. The grace period ended, enforcement tightened through 2025, and by 2026 the expectations have cascaded down to every sender regardless of volume. Mailbox providers now silently junk or reject unaligned mail even from small domains.

Beyond the public inbox providers, corporate security programs have made authentication mandatory through their own channels. Microsoft 365 tightened its anti-spoofing in 2025, enterprise secure email gateways check alignment before trust scoring, and cyber insurance questionnaires now explicitly ask whether DMARC is enforced at quarantine or reject. A domain without SPF, DKIM, and DMARC is no longer just a deliverability risk — it is an audit finding.

This guide walks through each of the five protocols that make up modern email authentication, how they fit together, how to deploy them in the correct order, and how to read the telemetry that comes back. If you want the broader context of how these controls plug into deliverability metrics, pair it with our email deliverability benchmarks for 2026 and the email marketing statistics that drive program design.

SPF is the oldest of the three core standards. It is a DNS TXT record published on the sending domain that lists the IP addresses and hostnames authorized to send mail on that domain's behalf. Receivers check the envelope sender (the return-path, not the visible From) against the SPF record of that domain and return a pass, fail, softfail, neutral, or none result.

Anatomy of an SPF record

An SPF record is a single TXT record at the apex of the sending domain beginning with the version tag v=spf1. It combines mechanisms (which authorize senders) and qualifiers (which decide how to handle mismatches).

; DNS TXT record at example.com
example.com.    IN    TXT    "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all"

Mechanisms you will actually use

• ip4 / ip6: a single address or CIDR range (e.g. ip4:198.51.100.24 or ip4:203.0.113.0/24). Use this only for IPs you directly control.
• include: delegates to another domain's SPF record (e.g. include:_spf.google.com). Most third-party senders publish their own include domain.
• a / mx: authorize the A records or MX hosts of a domain. Rarely needed for modern senders and a frequent cause of excess lookups.
• redirect=: replaces the record entirely with another domain's record. Useful for centralized management across many brand domains.

Qualifiers: +all, -all, ~all, ?all

Every SPF record ends with an all mechanism that tells receivers what to do with messages from IPs not covered earlier in the record. The prefix changes the verdict.

The 10 DNS lookup limit

SPF caps the total number of DNS lookups a receiver will perform when evaluating a record at 10. Every include:, a, mx, redirect=, and exists: mechanism counts, and nested includes count their own lookups too. Exceeding the limit produces a permerror, which most DMARC-aligned receivers interpret as a failure.

If you add a new ESP and your record suddenly permerrors, the fix is usually SPF flattening — resolving the includes into their underlying IP ranges and publishing those directly. Automated flattening services refresh the record on a schedule to track upstream changes.

DKIM solves SPF's biggest weakness — it survives forwarding. The sending server signs the message body and selected headers with a private key, and the receiver fetches the matching public key from DNS to verify the signature. If the message has not been tampered with in transit, the signature validates and DKIM passes.

Selectors and the DKIM DNS record

DKIM public keys are published as TXT records at <selector>._domainkey.<domain>. The selector is an arbitrary label that lets you publish multiple keys for different sending services or rotate a key without downtime. Common selectors are s1, s2, google, k1, and dkim2026-style date rotations.

; DKIM public key at s1._domainkey.example.com
s1._domainkey.example.com.  IN  TXT  ( "v=DKIM1; k=rsa; t=s; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzv1..."
  "...QIDAQAB" )

A matching DKIM-Signature header on an outgoing message looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=s1; t=1744819200;
  h=From:To:Subject:Date:Message-ID:MIME-Version;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=Q9Nwm9rZ6y9fj2Kq...==

What actually gets signed

• The d= tag specifies the signing domain and is what DMARC aligns against.
• The h= tag lists which headers are included in the signature. From, Subject, Date, and Message-ID should always be signed.
• The bh= tag is the hash of the message body, which is how tampering is detected.
• The b= tag is the actual signature over the canonicalized headers and body hash.

Key size and rotation

2048-bit RSA keys are the modern baseline. 1024-bit keys still work but have been discouraged for years and some newer receivers flag them. Ed25519 is supported by the spec and a subset of mailbox providers, but for broad interoperability in 2026 the safe default is still RSA-2048 with a secondary Ed25519 key for senders who support both.

Rotate DKIM keys at least every six months. The standard pattern is dual publication: put the new key at a new selector, move signing traffic over once the DNS has propagated, and leave the old selector in place for a week before retiring it. Many ESPs automate this rotation on your behalf.

DMARC is the glue that ties SPF and DKIM back to the visible From address. A message passes DMARC if at least one of SPF or DKIM passes and the authenticated domain aligns with the From domain. DMARC is published as a TXT record at _dmarc.<domain>.

; DMARC record at _dmarc.example.com
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1"

Alignment modes

Alignment comes in two flavors controlled by the adkim and aspf tags:

• Relaxed (r, default): the organizational domain must match. Signing d=mail.example.com aligns with a From of news@example.com.
• Strict (s): the full domain must match exactly. d=mail.example.com does not align with news@example.com.

Policy levels: p=none, quarantine, reject

pct rollout and subdomain policy

The pct= tag lets you apply the policy to only a sample of failing mail during rollout (e.g. pct=25 quarantines 25% while monitoring the other 75%). The sp= tag sets a different policy for subdomains — always explicitly set sp=reject on apex domains so unused subdomains cannot be abused for spoofing.

Aggregate (rua) vs forensic (ruf) reports

The rua= tag lists email addresses that should receive daily XML aggregate reports summarizing authentication results for your domain. These are the reports that matter — they reveal every service sending as you. The ruf= tag requests per-message forensic failure reports, but most major providers no longer send these due to privacy concerns. Set both, but plan your program around the rua stream.

Aggregate XML is effectively impossible to read by eye. Route it through a DMARC analytics platform (Dmarcian, Valimail, Postmark, EasyDMARC, and others all work) so you can see, per source, what percentage of mail is authenticating and which IPs are claiming to be you.

Brand Indicators for Message Identification (BIMI) is the layer on top of DMARC that lets mailbox providers display your verified logo next to authenticated messages. It is the visible reward for doing DMARC correctly — and the carrot that usually convinces marketing stakeholders to fund the full authentication project.

Prerequisites

• DMARC enforced at quarantine or reject with pct=100.
• A trademarked logo rendered as SVG Tiny 1.2 Portable/Secure (SVG-PS), square aspect ratio, solid background.
• A Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) from an authorized CA (DigiCert or Entrust).
• SVG and PEM certificate hosted over HTTPS on a domain you control.

; BIMI record at default._bimi.example.com
default._bimi.example.com.  IN  TXT  "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"

Where the logo actually renders

Gmail was the first major provider to display BIMI logos in 2021 and remains the highest-volume renderer. Apple Mail added support in iOS 16 and macOS Ventura, rendering logos in the message header. Yahoo, AOL, and Fastmail also honor BIMI. Outlook and Microsoft 365 have been piloting BIMI for several years but as of early 2026 have still not shipped broad rendering — expect BIMI to cover roughly two-thirds of consumer inboxes and a smaller share of corporate.

Budget for the VMC as an annual expense ($1,000–$1,500 at list price) and remember that the trademarked logo must be registered in at least one supported jurisdiction before the CA will issue the certificate.

The order of operations matters. Jumping to DMARC reject on day one will shred your legitimate mail. The sequence below is the one we use on client engagements and maps to a 6–12 week rollout depending on sending complexity.

1. 1. Audit what is already in DNS

   Pull every TXT and MX record on your apex and sending subdomains. Note existing SPF, any old DKIM selectors, and any legacy DMARC. Consolidate duplicate SPF records into one — multiple v=spf1 records produce a permerror.

   dig +short TXT example.com
   dig +short TXT _dmarc.example.com
   dig +short TXT s1._domainkey.example.com

2. 2. Inventory every sending source

   Google Workspace, Microsoft 365, your ESP, your CRM, your billing system, your support tool, your applicant tracking, every transactional microservice. If you miss one, it will fail DMARC once you enforce. The companion marketing automation stats for 2026 is a useful prompt for the platforms marketing teams forget.

3. 3. Build a clean SPF record

   Start with ~all (softfail), keep lookups under 10, and remove any redundant a or mx mechanisms. If you cannot fit all senders, flatten to IPs or move a class of mail (e.g. bulk) to a dedicated subdomain.

4. 4. Create DKIM keys for every sender

   Every ESP supports DKIM and will either give you a record to publish or require CNAMEs pointing to their hosted selector. Use 2048-bit RSA. Assign a distinct selector per sender so you can rotate independently.

5. 5. Publish DMARC at p=none with rua

   This is pure observation. You collect aggregate XML for at least two full weeks — ideally a month — to discover every source and confirm alignment. Route reports to a DMARC analytics platform rather than a raw mailbox.

6. 6. Fix the gaps

   Work through the report with each team — get marketing's ESP aligned, get the recruiting tool DKIM-signed, fix the forwarding case that breaks SPF by enabling ARC or redirecting to the authenticated domain. Keep iterating until your aggregate passing rate exceeds 98%.

7. 7. Move to p=quarantine with pct rollout

   Start at pct=10, watch your support inbox for a week, step up to 25, 50, 100. Any unexpected impact surfaces gradually rather than all at once.

8. 8. Move to p=reject and enable BIMI

   Once quarantine has been steady for at least 30 days, flip to reject. At this point you meet the BIMI prerequisite and can issue your VMC and publish the BIMI record to light up logos in the inbox.

When Gmail and Yahoo announced their joint bulk sender requirements in October 2023, with enforcement in February 2024, the industry had a year of scrambling to adapt. Today, in 2026, the requirements are the baseline expectation. The specific rules for senders that exceed 5,000 messages per day to Gmail or Yahoo accounts:

• SPF and DKIM must both pass, and at least one of them must align with the From domain under DMARC semantics.
• A published DMARC record at minimum p=none. Most senders now run p=quarantine or p=reject because it materially improves inbox placement.
• One-click unsubscribe (RFC 8058) in both the List-Unsubscribe header and List-Unsubscribe-Post: List-Unsubscribe=One-Click. Honoring unsubscribe requests within 48 hours is mandatory.
• Spam complaint rate below 0.3% measured in Gmail Postmaster Tools. Rates above 0.1% already drag placement; sustained rates above 0.3% cause throttling and eventual blocks.
• TLS for transmission is required — every major sender has moved to opportunistic or strict MTA-STS.
• Valid forward/reverse DNS on sending IPs, no private IPs in Received headers, and consistent HELO/EHLO identity.

What has changed since 2024

The 5,000-message threshold was always arbitrary. In practice, Gmail now applies the same authentication rules to every sender regardless of volume — if your transactional domain sends 200 emails a day and fails DMARC, you still get spammed. Apple, Microsoft, and Fastmail have implemented similar checks. Treat the 2024 rules as universal, not bulk-only.

Gmail Postmaster Tools now publishes three levels of domain reputation (high, medium, low) and a daily complaint rate granular to tenths of a percent. Hook it into your monitoring so a complaint spike does not go unnoticed — most programs we audit only discover a reputation drop when a campaign has already softened for a week.