Email authentication is the set of DNS records that lets a receiving server verify a message genuinely came from the domain in the From address. Three records do the work — SPF, DKIM, and DMARC — and all three have been mandatory for bulk senders at Gmail, Yahoo, and Microsoft since 2024.
The reason any of it exists: the From: header in an email is just text. Anyone can type anything into it, the same way anyone can write any return address on an envelope. Authentication bolts verification onto a protocol that was designed without it.
This guide explains what each record proves, how they fit together, and the detail behind most "everything says pass but it still fails" cases: alignment.
The short answer
| Record | What it proves | What it looks like |
|---|---|---|
| SPF | This server is allowed to send for this domain | A TXT record listing permitted senders |
| DKIM | This message came from this domain and wasn't altered | A cryptographic signature validated against a public key in DNS |
| DMARC | What to do when SPF or DKIM fail — and who is sending as you | A TXT record with a policy: none, quarantine, or reject |
| BIMI | Optional. Displays your logo in the inbox | A TXT record pointing at an SVG, gated behind DMARC enforcement |
All three of the first three are required, not as best practice but as the price of admission. They also need to be aligned, which is a separate condition from passing and the part most setups get wrong.
SPF: the list of servers allowed to send as you
SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers may send email on behalf of a domain. When a message arrives, the receiving server looks up the record and checks whether the sending IP appears on the list.
A basic record:
v=spf1 include:_spf.google.com include:spf.mailerlite.com ~all
Read left to right: SPF version 1, authorise everything Google's servers authorise, authorise everything MailerLite's servers authorise, soft-fail anything else.
The final qualifier decides what happens to unlisted senders:
-all— hard fail. Anything not listed should be rejected.~all— soft fail. Anything not listed is suspicious but may still be delivered.?all— neutral. Effectively no policy, and worth avoiding.
Most senders belong on ~all while still discovering which services send on their behalf, moving to -all once the list is confidently complete.
The two SPF failures that catch almost everyone
A domain may publish exactly one SPF record. Not one per service — one, total. A second record causes a permanent error under the specification, and receiving servers may disregard both. This happens constantly after a website migration or when a new tool is added without checking what already exists. Every sending service belongs in the same record, as another include:.
SPF is limited to 10 DNS lookups. Every include: triggers a lookup, and each of those can trigger more inside the provider's own record. Exceeding ten returns a permanent error, which reads as a fail. Three or four services is usually fine; a CRM, a helpdesk, a billing system, and a newsletter tool together can quietly cross the line with nothing visible changing.
SPF flattening — replacing include: statements with the IP ranges they resolve to — fixes a lookup overrun and introduces a new fragility: when a provider changes infrastructure, the flattened record goes stale silently. It is a fix for senders who genuinely need it, not a default.
DKIM: the signature that proves nothing was tampered with
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message, verified by the receiving server against a public key published in DNS. A valid signature proves two things: the message came from a system holding the private key, and the signed headers and body were not modified in transit.
The public key lives at a subdomain built from a selector:
selector._domainkey.yourdomain.com
The selector is an arbitrary string chosen by whoever configured the signing. Google uses google, some platforms use s1 and s2, others use k1 or default. That arbitrariness has a practical consequence: no external tool can reliably enumerate a domain's DKIM records. A checking tool reporting "no DKIM found" usually means it guessed a handful of common selectors and none matched.
Two settings carry most of the weight:
Use a 2048-bit key where the DNS host allows it. 1024-bit remains widely accepted and is the weaker option, and some providers now treat it less favourably.
Sign under your own domain, not your platform's. This is the single most consequential DKIM setting, and it is what alignment depends on.
DMARC: the policy that ties them together
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when SPF and DKIM don't check out, and sends you reports on everyone sending mail that claims to be from your domain.
A starter record, published at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
The tags that matter:
| Tag | Meaning |
|---|---|
p |
The policy: none (monitor only), quarantine (send to spam), or reject (refuse delivery) |
rua |
Where to send aggregate reports — the useful ones |
ruf |
Where to send forensic reports — rarely used, and many providers don't send them |
pct |
Percentage of failing mail the policy applies to, for staged rollout |
sp |
A separate policy for subdomains |
adkim / aspf |
Alignment mode — r for relaxed (the default), s for strict |
Start at p=none. It changes nothing about delivery and turns on reporting. Publishing p=reject before every legitimate sending service is known is how senders block their own invoices, password resets, and CRM notifications.
p=none satisfies the minimum bulk-sender requirement at Gmail, Yahoo, and Microsoft. It also protects nobody from spoofing — it reports the spoofing without stopping it. Enforcement is where the security benefit lives.
The staged rollout — how long to sit at each policy, what to look for in reports before tightening, and how to back out safely — is in how to set up DMARC from p=none to p=reject. Making sense of the XML those reports arrive as is in how to read DMARC reports without a paid tool.
DMARC alignment: why records pass while DMARC fails
DMARC requires one of SPF or DKIM to align, not merely to pass. Alignment means the domain in the visible From: address matches the domain that was actually authenticated — and those are different domains more often than senders expect.
Consider a message where:
- The visible
From:sayshello@yourbrand.com - SPF validates against the envelope sender, which the platform set to
bounces@mail.esp-provider.com - DKIM signs with a key published at
s1._domainkey.esp-provider.com
SPF passes. DKIM passes. Every checker shows green. DMARC fails, because neither authenticated domain matches the one the recipient sees.
This mechanism sits behind the most common complaint in email deliverability: "I set up SPF, DKIM, and DMARC and nothing changed." The records exist. They pass. They do not align.
Relaxed versus strict alignment
| Mode | Requirement | Example |
|---|---|---|
Relaxed (r, default) |
Organisational domains must match | mail.yourbrand.com aligns with yourbrand.com |
Strict (s) |
Domains must match exactly | mail.yourbrand.com does not align with yourbrand.com |
Leave both adkim and aspf on relaxed without a specific reason to do otherwise. Strict alignment breaks subdomain sending and gains very little.
How to fix misalignment
The fix always lives in the same conceptual place — domain authentication settings, not campaign settings. The action is instructing the sending platform to sign as you rather than as itself.
In MailerLite that is Account settings → Domains → Add domain, which returns three records to publish: DKIM as a CNAME, SPF as a TXT, and a verification TXT, followed by Authenticate and Check DNS Records.
Every platform has an equivalent, labelled "domain authentication", "sender authentication", or "custom sending domain". Until it shows as verified, mail goes out under the platform's identity and DMARC alignment cannot pass regardless of how correct the records look.
Two error codes point straight at alignment:
- Gmail returning
421-4.7.32— no DMARC alignment - Microsoft returning
550 5.7.515 Access denied— a hard authentication rejection
Either one means checking alignment before checking anything else.
What Gmail, Yahoo, and Microsoft require
Authentication stopped being optional in 2024, and enforcement has tightened since.
| Requirement | Applies to |
|---|---|
| SPF and DKIM on every sending domain | Bulk senders at Gmail, Yahoo, Microsoft |
DMARC published at p=none or stronger |
Bulk senders at all three |
An aligned From domain via SPF or DKIM |
Bulk senders at all three |
| One-click unsubscribe, honoured within two days | Bulk senders at all three |
| Spam complaint rate below 0.1%, never reaching 0.3% | Google and Yahoo, published explicitly |
| TLS for transmission | All three |
| Forward-confirmed reverse DNS on sending IPs | All three |
The threshold is 5,000 messages a day to a given provider, and enforcement escalated in stages: Google and Yahoo began with temporary 421 deferrals in February 2024, Microsoft's Outlook.com enforcement began on 5 May 2025, and Google ramped to permanent 550 rejections from November 2025.
Full provider-by-provider detail, including what happens at each stage of non-compliance, is in bulk sender requirements 2026: the checklist.
BIMI: your logo in the inbox
BIMI (Brand Indicators for Message Identification) displays your logo next to your messages in supporting inboxes, and requires DMARC at enforcement to work at all.
A policy of p=quarantine or p=reject, applied to all mail, is a hard prerequisite. p=none does not qualify. BIMI therefore belongs at the end of an authentication project rather than the beginning — it is a reward for finishing, not a shortcut.
A logo in the SVG Tiny Portable/Secure profile is also required, and for most display, a certificate.
Two certificate types
| VMC | CMC | |
|---|---|---|
| Requires a registered trademark | Yes | No |
| Alternative requirement | — | Logo publicly used on a domain you own for at least 12 months |
| Gmail | Logo and verified checkmark | Logo only, no checkmark |
| Yahoo / AOL | Accepted, subject to reputation | Accepted, subject to reputation |
| Apple Mail | Documented support (macOS 13+, iOS 16+) | Not confirmed |
| Microsoft Outlook | Not displayed | Not displayed |
The Common Mark Certificate is the meaningful recent development. Before it existed, BIMI was effectively closed to anyone without a registered trademark — which is most small businesses and every solo operator. A CMC opens the door at the cost of Gmail's blue verified checkmark.
For most small senders, BIMI is not yet worth the cost. Outlook does not display it, Apple's CMC support is unconfirmed, and the certificate is a recurring annual expense. The strongest argument for pursuing it is that it forces a domain to DMARC enforcement, and enforcement is worth having on its own merits.
Full setup, the SVG specification, and an honest cost breakdown are in BIMI: how to get your logo in the inbox.
How to check what you have in five minutes
No paid tool is required to establish where a domain stands.
The Gmail method — the fastest reliable check:
- Send an email from your normal sending platform to a Gmail address
- Open it in Gmail on desktop
- Use the three-dot menu → Show original
- Read the summary at the top
SPF, DKIM, and DMARC each appear marked PASS or FAIL. All three should say PASS. DMARC failing while SPF and DKIM pass is an alignment problem.
Show original also reveals the actual domains used, which is how alignment gets confirmed rather than assumed.
Then check DNS directly:
yourdomain.comTXT— should return exactly one record startingv=spf1_dmarc.yourdomain.comTXT— should return one record startingv=DMARC1- DKIM requires the selector, which the sending platform will supply
Then register for the free provider dashboards. Google Postmaster Tools and Yahoo's Sender Hub both show authentication results as the provider sees them, which is more authoritative than any third-party checker. Postmaster Tools gives a plain Pass / Needs Work compliance verdict against Gmail's published requirements — covered in how to read Google Postmaster Tools.
Which record is broken? A symptom lookup
| Symptom | Most likely cause |
|---|---|
| SPF fails | Sending service missing from the SPF record, or two SPF records exist |
| SPF returns permerror | More than 10 DNS lookups, or a syntax error |
| DKIM fails | Signing not enabled, wrong selector published, or a key rotated without updating DNS |
| SPF and DKIM pass, DMARC fails | Alignment. The platform is signing as itself, not as you |
| Everything passes, mail still filtered | Not an authentication problem — see why authenticated emails still land in spam |
Gmail 421-4.7.32 |
No DMARC alignment |
Gmail 421-4.7.30 |
DKIM does not pass for a bulk sender |
Gmail 550-5.7.26 |
Unauthenticated mail, permanently rejected |
Microsoft 550 5.7.515 |
Hard authentication rejection |
| Worked yesterday, fails today | A DNS change, a site migration, or a rotated DKIM key |
That final row deserves standing attention. Most sudden authentication failures trace back to a DNS or hosting change that nobody connected to email. Re-verify authentication after every DNS change, every host migration, and every website rebuild — the diagnostic order for a sudden failure is in why your emails suddenly went to spam.
What email authentication does not buy you
Authentication proves identity. It says nothing about desirability.
Passing SPF, DKIM, and DMARC tells Gmail who you are. It does not tell Gmail that anyone wants your mail. Inbox placement is decided mostly by sender reputation and engagement — how recipients have historically behaved toward your messages. A perfectly authenticated email to a list of people who never open anything is still filtered.
Authentication gets a message evaluated. It does not decide the evaluation.
Authenticated mail that still lands in spam is a different problem with a different fix, diagnosed in email deliverability: why authenticated emails still land in spam.
The order to set up email authentication in
Starting from nothing:
- Inventory every service that sends as your domain. Newsletter platform, CRM, helpdesk, billing, form notifications, the website itself. A missed service becomes blocked mail later.
- Publish one SPF record covering all of them, ending
~all. - Enable DKIM in the sending platform, signing under your own domain, and confirm it shows as authenticated there.
- Publish DMARC at
p=nonewith a reporting address. - Send a test to Gmail and read Show original. All three should pass, and the domains should align.
- Read reports for two to four weeks and add any legitimate sender that turns up.
- Move to
p=quarantine, then eventuallyp=reject. - Only then consider BIMI.
Steps 1 to 5 take about twenty minutes for most setups. Steps 6 and 7 take weeks, and rushing them is how senders block their own invoices.
What's in the book, not here. The copy-paste record library for each major platform, the provider-by-provider quick reference, the full 100-point audit scorecard, and the 14-day implementation plan are in The Email Deliverability Playbook. This article is the complete explanation. The book is the complete implementation.
Frequently asked questions
Do I need all three of SPF, DKIM, and DMARC?
Yes. Since 2024, Gmail, Yahoo, and Microsoft require all three from bulk senders, and failures result in rejection rather than filtering. SPF and DKIM alone are not sufficient, because DMARC is what tells receivers how to handle failures and what gives you visibility into who is spoofing your domain.
Can I have more than one SPF record?
No. A domain may publish exactly one SPF record. A second causes a permanent error and can invalidate both. Every sending service goes into the same record as an additional include: statement. Two SPF records left over from a migration is among the most common causes of sudden authentication failure.
What is DMARC alignment?
Alignment means the domain in your visible From: address matches the domain that SPF or DKIM actually authenticated. SPF and DKIM can both pass while DMARC fails, because neither authenticated the visible domain. It is the most common cause of "everything says pass but it doesn't work."
Does DKIM expire?
The DNS record does not expire on a timer, and keys should be rotated periodically, with some platforms rotating automatically. DKIM failing suddenly after months of working usually means a rotated key whose public half was never updated in DNS.
What is a DKIM selector?
A DKIM selector is an arbitrary string identifying which key to use, forming the DNS location selector._domainkey.yourdomain.com. Because each platform chooses its own selectors freely, no external tool can reliably enumerate them — which is why "no DKIM found" from a checker often means it guessed wrong.
How long does email authentication take to work?
DNS propagation is usually minutes and occasionally up to 24 hours. Once records resolve, authentication works immediately on the next message sent. Reputation is a separate matter and takes far longer.
Do I need BIMI?
No. BIMI is optional, requires DMARC at p=quarantine or p=reject, needs a specially formatted SVG, and generally needs a paid certificate. Microsoft Outlook does not display it at all. The strongest argument for pursuing it is that it forces a domain to DMARC enforcement.
What to do next
Send yourself a test email and read Show original in Gmail. That single step establishes where you stand in about a minute, and it is more trustworthy than any external checker because it shows exactly what Gmail saw.
DMARC failing while SPF and DKIM pass means an alignment problem — fix it in the platform's domain authentication settings before changing anything in DNS.
Free: The 60-Minute Email Authentication Fix — a checklist that walks through verifying all four of these on your own domain in under an hour.
Go deeper: The Email Deliverability Playbook — the copy-paste record library, the provider-by-provider reference, a 100-point audit scorecard, and the 14-day implementation plan.
Related guides
- Why authenticated emails still land in spam — what authentication doesn't cover
- How to set up DMARC safely — the staged rollout to enforcement
- How to read DMARC reports — making sense of the XML
- Bulk sender requirements 2026 — what Gmail, Yahoo, and Microsoft demand
- BIMI setup — logo in the inbox, honestly assessed
- Why your emails suddenly went to spam — when a record broke overnight
- WordPress emails not sending — authentication for your site's own mail
Free: The 60-Minute Email Authentication Fix
A no-fluff checklist to set up SPF, DKIM & DMARC correctly and pass Gmail & Yahoo's sender requirements.
Muhammad Basim has worked in digital marketing since 2013, focused on email deliverability and AI-assisted content production. He is the author of the Email Deliverability Playbook and the Email Copywriting Playbook, and has run 100+ email campaigns for ecommerce brands, coaches, and B2B senders. He writes about email, SEO, WordPress, and AI — with a bias toward what can be tested over what sounds good.
Related Articles
How to Read Google Postmaster Tools
Google Postmaster Tools is a free dashboard reporting how Gmail treats mail from your domain, and since 2025 it no longer reports a reputation grade — it reports compliance, spam rate, and a plain-language verdict on whether Gmail's users want your email. No third-party checker carries the same authority, because no third party is making […]
Email Verification Tools: Which Are Worth Paying For
Email verification checks whether an address can receive mail, and it cannot tell you whether anyone behind it wants yours. That distinction decides whether the spend is worth it, because a verified address that never opens damages your reputation exactly as much as it did before you paid to confirm it exists. Verification solves one […]
Email Spam Traps: How to Find and Remove Them
A spam trap is an email address that exists only to catch senders with poor list practice, and no tool can tell you whether one is on your list. Traps accept mail silently. They do not bounce, they do not complain, and they do not appear in any report until the damage is already done. […]