SPF, DKIM and DMARC: The Complete Email Authentication Guide

Every day, attackers send billions of emails pretending to be brands they are not. Spoofed invoices, fake password resets, forged CEO requests — all of them work because, by default, anyone can put any address in the From field of an email. SPF, DKIM and DMARC exist to close that loophole. Together they let mailbox providers verify that a message really came from the domain it claims, and they have quietly become the price of admission to the inbox: since February 2024, Gmail and Yahoo require authentication from every sender and full SPF, DKIM and DMARC from bulk senders. This guide walks through how each protocol works, the exact DNS records you need, the mistakes that silently break them, and a rollout plan you can follow this week.

Why Email Authentication Matters

The core problem is that SMTP, the protocol that moves email around the internet, was designed in an era of trust. It performs no identity check on the visible From address. That single design gap fuels phishing and business email compromise (BEC) at industrial scale: the FBI's Internet Crime Complaint Center attributed roughly 2.9 billion dollars in reported losses to BEC in 2023 alone. When criminals spoof your domain, your customers get defrauded and your deliverability suffers — mailbox providers cannot tell your real campaigns from the forgeries.

Authentication fixes this with three complementary DNS-based protocols:

• SPF declares which servers are allowed to send mail for your domain
• DKIM cryptographically signs each message so tampering and forgery are detectable
• DMARC ties both to the visible From address and tells receivers what to do when checks fail

The Gmail and Yahoo Mandate

In February 2024, Google and Yahoo turned long-standing best practice into hard requirements. All senders must authenticate with at least SPF or DKIM. Senders that exceed roughly 5,000 messages per day to a provider must have both SPF and DKIM, plus a DMARC policy (minimum p=none), a From domain aligned with authentication, one-click unsubscribe honored within two days, and a spam complaint rate below 0.3%. Non-compliant mail is first throttled with temporary errors, then rejected outright. Microsoft announced equivalent requirements for Outlook.com high-volume senders in 2025, so the direction of the industry is unambiguous.

Adoption is climbing but far from universal: EasyDMARC's analysis of the world's top 1.8 million domains found that 47.7% had a DMARC record in 2025 — and industry studies consistently show that a large share of published records still sit at the monitoring-only p=none policy, offering no actual spoofing protection. Getting this right is still a competitive advantage.

SPF: Sender Policy Framework

How SPF Works

SPF is a DNS TXT record that lists every server authorized to send mail on behalf of your domain. When a receiving server accepts a connection, it looks at the Return-Path domain (also called the envelope from or MAIL FROM address — not the From header your recipients see), fetches that domain's SPF record, and checks whether the connecting IP is on the list. If it is, SPF passes; if not, SPF fails or soft-fails depending on your policy.

Record Syntax Walkthrough

A typical SPF record for a company using Google Workspace, a marketing platform and one dedicated sending IP looks like this:

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 ~all"

Reading it left to right:

• v=spf1 — the version tag; every SPF record starts with it
• include:_spf.google.com — authorizes Google Workspace's sending servers by referencing Google's own SPF record
• include:servers.mcsv.net — authorizes a marketing platform (Mailchimp, in this example)
• ip4:203.0.113.10 — authorizes one specific IPv4 address, for example your own SMTP server
• ~all — the catch-all: any server not listed should soft-fail. The qualifier matters: -all is a hard fail (recommended once your record is complete), ~all is a soft fail, and +all authorizes the entire internet — never use it

The 10-DNS-Lookup Limit

RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include, a, mx, ptr and exists mechanism counts — and includes count recursively, so one marketing platform's include can consume three or four lookups on its own. Exceed the limit and receivers return permerror, which many providers treat as an SPF failure. Plain ip4 and ip6 mechanisms cost nothing, so prefer them where practical, remove services you no longer use, and consider SPF flattening if you legitimately need many providers.

Common SPF Mistakes

• Publishing multiple SPF records. A domain must have exactly one record starting with v=spf1. Two records produce a permanent error, which fails validation. Merge all mechanisms into a single record.
• Using +all. It tells the world that any server may send as you — effectively disabling SPF and flagging your domain as misconfigured.
• Forgetting a sending service. Your helpdesk, billing system and CRM all send mail. If they are not in the record, their messages soft-fail.
• Letting the record rot. Decommissioned services leave dangling includes that waste lookups and may create security exposure.
• Assuming SPF covers the visible From. It checks the Return-Path only. Alignment with the From header is DMARC's job, which is why SPF alone stops very little spoofing.

DKIM: DomainKeys Identified Mail

How DKIM Signing Works

DKIM adds a cryptographic signature to every outgoing message. Your sending server holds a private key and signs a hash of the message body plus selected headers (From, Subject, Date and others). The matching public key is published in your DNS, and the receiving server uses it to verify the signature. A valid signature proves two things: the message was authorized by the domain that signed it, and the signed content was not modified in transit. Unlike SPF, a DKIM signature survives forwarding, which makes it the more resilient of the two mechanisms.

Selectors and the DNS Record

The public key lives at a DNS name built from a selector: selector._domainkey.yourdomain.com. Selectors let multiple keys coexist — one per sending service, or old and new keys during rotation. A published key record looks like this:

s1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Zx8...IDAQAB"

And each signed message carries a header that references it:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=s1;
  h=from:subject:date:to:mime-version; bh=Kx9c1...; b=HqTf3...

The d= tag names the signing domain and the s= tag names the selector — together they tell the receiver exactly where to fetch the public key.

Key Length and Rotation

• Use 2048-bit RSA keys. 1024-bit keys are considered weak and some providers penalize them; 2048-bit is the current standard and what Google recommends.
• Rotate keys regularly. M3AAWG best practice is to rotate DKIM keys at least every six months. Publish the new key under a new selector, switch signing, then retire the old record after a few days.
• Sign with your own domain. Many platforms sign with their domain by default (which authenticates the mail but does not align with your From address). Complete the platform's custom-domain DKIM setup so d= matches your domain.

DMARC: Policy, Reports and Alignment

SPF and DKIM each verify something, but neither one checks the address your recipients actually see. DMARC closes the loop: a message passes DMARC only if SPF or DKIM passes and the domain that passed aligns with the visible From domain. DMARC also lets you publish a policy telling receivers what to do with failures, and gives you reporting so you can see who is sending as your domain — legitimately or not.

The DMARC Record and Policy Progression

DMARC is a TXT record at _dmarc.yourdomain.com. A sensible starting record:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"

The p= tag is the heart of the record, and it is designed to be tightened in stages:

• p=none — monitoring only. Failing mail is delivered normally, but you receive reports. Every deployment starts here.
• p=quarantine — failing mail goes to spam. Use pct= to ramp gradually, for example p=quarantine; pct=25 applies the policy to a quarter of failing messages.
• p=reject — failing mail is refused outright. This is the destination: full spoofing protection, and a prerequisite for BIMI.

An enforced record eventually looks like this:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"

rua and ruf Reports

The rua= tag requests aggregate reports: daily XML summaries from each receiving provider showing which IPs sent as your domain, what passed and what failed. They contain no message content and are the primary tool for discovering forgotten sending services. The ruf= tag requests failure (forensic) reports — per-message samples of failures. Few providers send them, and they can contain personal data, so most teams rely on rua alone, processed through a DMARC reporting tool rather than read raw.

Alignment: Relaxed vs Strict

Alignment is where most real-world DMARC failures happen. The aspf= and adkim= tags control how closely the authenticated domain must match the From domain. In relaxed mode (r, the default), a subdomain match passes — mail from news.yourdomain.com aligns with yourdomain.com. In strict mode (s), the domains must match exactly. Start relaxed; move to strict only once your reports show it will not break legitimate mail. Remember: SPF alignment compares the Return-Path domain, DKIM alignment compares the d= domain, and only one of the two needs to pass with alignment for DMARC to pass.

The Three Protocols at a Glance

Step-by-Step Rollout Plan

1. Audit every sending service (week 1). Inventory everything that sends as your domain: mail suite, marketing platform, CRM, helpdesk, billing, monitoring alerts. Miss one and you will break its mail later.
2. Publish or fix SPF (week 1). One record, all legitimate sources, under 10 lookups, ending in ~all (tighten to -all later).
3. Enable DKIM everywhere (weeks 1-2). Turn on custom-domain DKIM signing with 2048-bit keys in every platform from your audit, and verify each one with a test message.
4. Publish DMARC at p=none with rua reporting (week 2). No delivery impact — you are only collecting data.
5. Monitor for 4-6 weeks. Review aggregate reports weekly. Fix every legitimate source that fails alignment; what remains failing is spoofing.
6. Tighten gradually. Move to p=quarantine; pct=25, ramp to pct=100, hold for a couple of weeks, then move to p=reject. Keep monitoring — new tools and vendors will keep appearing.

Beyond DMARC: A Word on BIMI

Once you reach enforcement, BIMI (Brand Indicators for Message Identification) lets participating mailbox providers display your verified logo next to your messages. It requires DMARC at p=quarantine or p=reject with pct=100, an SVG logo, and — for Gmail's blue verified checkmark — a Verified Mark Certificate tied to a registered trademark (Google also accepts Common Mark Certificates for logo display). BIMI does not directly change filtering, but the visible trust mark measurably helps recognition and engagement, and it is a nice reward for finishing the DMARC journey.

Authentication + List Validation: The Complete Stack

Here is the part many guides skip: authentication proves who you are, not that your mail is wanted. Mailbox providers combine both signals. A perfectly authenticated sender who blasts a stale list still generates bounces and spam complaints, and Gmail's own 0.3% complaint threshold applies regardless of your DMARC policy. High bounce rates damage the very sender reputation that authentication is meant to protect.

That is why authentication and list hygiene are two halves of one deliverability strategy. AT Valid runs 20+ verification checks — syntax, MX, SMTP, disposable and catch-all detection among them — with 99.5% accuracy, so every message you sign with DKIM actually has a real inbox waiting for it. Validate at the point of capture through the API, or clean existing lists in bulk with native integrations for Salesforce, HubSpot, Mailchimp, RD Station, Pipedrive, Zapier and webhooks. Our complete email deliverability guide covers how the two disciplines reinforce each other.

Conclusion

SPF, DKIM and DMARC form a layered identity system: SPF authorizes servers, DKIM signs content, DMARC aligns both with the address your recipients see and enforces the result. Since the Gmail and Yahoo mandate, they are baseline requirements, not advanced options — and the path is well marked: audit your senders, publish SPF, enable 2048-bit DKIM, monitor at p=none, then tighten to p=reject.

Do it alongside continuous list validation and you cover both questions a mailbox provider asks: is this sender genuine, and is this mail wanted? Ready to complete your deliverability stack? Start with 200 free validation credits and see the difference authenticated, validated email makes.