For years, email authentication was the thing you knew you should do and quietly put off. That window has closed. Since February 2024 the largest mailbox providers have moved SPF, DKIM and DMARC from "best practice" to "send this and we will deliver it, skip it and we will not". The penalty is rarely a loud bounce. It is a slow leak of mail into spam folders that you only notice when a customer tells you they never got the invoice.
What changed in February 2024
On 1 February 2024 Google and Yahoo began enforcing a shared set of sender requirements. The headline target was bulk senders, defined as anyone sending roughly 5,000 or more messages a day to Gmail, but the practical effect reached much further. The two providers between them handle a large share of the world's consumer inboxes, so a rule they both apply becomes the de facto standard for everyone.
Microsoft followed. In 2025 it announced that high-volume senders, again around 5,000 or more messages a day, to consumer Outlook.com, Hotmail and Live accounts must pass SPF, DKIM and DMARC. Microsoft began applying these checks by routing non-compliant mail to the Junk folder first, with outright rejection set to follow. The direction of travel is the same across all three: authenticate, or lose the inbox.
The bulk-sender requirements in plain English
Strip away the jargon and the rules are short. To stay on the right side of Gmail, Yahoo and Outlook, mail leaving your domain needs to do the following.
- Pass SPF and DKIM. Both should be present and valid for the sending source. SPF authorises the sending IP; DKIM signs the message cryptographically.
- Publish a DMARC record with alignment. A policy of
p=noneis the minimum, but the SPF or DKIM domain must align with the visible From domain for DMARC to actually pass. - Offer one-click unsubscribe on marketing mail, using the RFC 8058 header so a recipient can opt out in a single click without typing or logging in.
- Keep your spam-complaint rate low. Gmail's Postmaster Tools should show you under 0.3%, and ideally well under it. Spikes above that threshold are a fast route to the spam folder.
- Have valid forward and reverse DNS on the sending host, so the IP resolves to a name and the name resolves back to the IP.
None of these are exotic. The catch is that they all have to be true at once, for every system that sends mail in your name, and most organisations have more of those than they think.
The requirements side by side
The providers phrase things differently and apply timing differently, but the substance overlaps heavily. This is the practical summary.
| Requirement | Google (Gmail) | Yahoo | Microsoft (Outlook / Hotmail) |
|---|---|---|---|
| SPF and DKIM | Both required for bulk senders | Both required for bulk senders | Both required for high-volume senders |
| DMARC record | Required, p=none minimum, with alignment | Required, p=none minimum, with alignment | Required, with alignment |
| One-click unsubscribe (RFC 8058) | Required on marketing mail | Required on marketing mail | Expected on marketing mail |
| Spam-complaint rate | Below 0.3% in Postmaster Tools | Kept low | Kept low |
| Forward and reverse DNS | Valid PTR required | Valid PTR required | Valid PTR required |
| Effective date | 1 February 2024 | 1 February 2024 | Rolling out from 2025, Junk first then rejection |
The full, current breakdown lives on our sender requirements page, which tracks the rules as the providers update them.
Why this hits ordinary businesses, not just marketers
It is tempting to read "bulk sender" and assume the rules are someone else's problem, a thing for newsletter teams and email agencies. That reading misses where the risk actually sits, because the providers do not only check marketing campaigns. They check everything arriving from your domain.
Think about what an ordinary business sends without ever calling it a campaign:
- Invoices from
accounts@yourcompany.com - Quotes and statements to clients
- Password reset and login verification emails
- Booking and order confirmations
- Receipts, dispatch notices and appointment reminders
This is transactional mail, and it is often the most important email a company sends. A customer who never receives a password reset cannot log in. A client who never sees the invoice does not pay it on time. None of this mail benefits from being lenient about authentication, and all of it is judged by the same rules. Even below the bulk threshold, an unauthenticated stream of transactional mail builds a poor sender reputation that drags everything else down with it.
The quiet failure mode
The most dangerous part of all this is how little noise it makes. When a server rejects mail outright, you get a bounce message, an error code, something to act on. The modern deliverability failure does not work like that. The receiving server accepts the message, says thank you, and files it in the spam folder. From your side, the send looks successful. There is no error in your logs.
So you find out the slow way. A customer calls to ask where their statement is. A new user complains that the verification email never arrived, having waited twenty minutes before giving up. A finance team chases a payment that was held up because the invoice sat unseen in junk. By the time these signals reach you, the mail has been failing for weeks and your sender reputation has already taken the hit.
Loud failures get fixed because they demand attention. Quiet failures cost you customers because nobody knows they are happening.
This is why monitoring matters more than it used to. You cannot rely on bounces to tell you something is wrong, because the failure mode that costs you the most never produces one.
How broken SPF or unaligned DKIM tanks deliverability silently
Two technical faults cause most of the quiet damage, and both are easy to miss because the mail keeps flowing while they are present.
SPF that exceeds 10 DNS lookups
RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include:, a, mx and redirect mechanism can consume one or more, and they nest. Add a few common services, your CRM, your help desk, your invoicing tool, your marketing platform, your security gateway, and you sail past ten without noticing. An SPF record with 11 lookups does not warn you. It returns permerror, and a permerror means SPF fails. The record looks fine to the eye; the evaluation quietly collapses.
The fix is flattening: resolving those nested include: mechanisms down to the underlying IP ranges so the record stays under the limit and stays valid as providers change their IPs. Our SPF flattening service keeps the record both compliant and current, which is the part manual flattening tends to get wrong over time.
DKIM that signs but does not align
DKIM can pass and still leave DMARC failing. The signature in the DKIM-Signature header carries a d= domain naming who signed the message. For DMARC to credit that signature, the d= domain has to align with the From domain. A common trap: a third-party platform signs your mail with its own domain, say d=sendgrid.net, while your From address reads @yourcompany.com. DKIM is valid. Alignment is not. DMARC sees no aligned identifier and fails the message.
The selector matters here too. Keys are published at <selector>._domainkey.<domain>, for example s1._domainkey.yourcompany.com, and using a selector under your own domain with a properly delegated key is what makes alignment possible. Our guide on getting alignment right walks through configuring each sending source so SPF or DKIM lines up with the visible From domain.
DMARC enforcement, inbox placement and reputation
Most domains that publish DMARC never move past p=none. They watch but never block. That is understandable, because moving to p=quarantine or p=reject feels risky if you are not sure every legitimate source is authenticated. But staying at p=none indefinitely leaves two things on the table.
First, enforcement is what actually stops spoofing. A record at p=none tells receivers to do nothing when mail fails, so a forger sending fake invoices from your domain is unaffected. Only p=quarantine or p=reject instructs the receiver to act.
Second, mailbox providers read your policy as a signal of how seriously you manage your domain. A domain that authenticates cleanly and enforces a real policy is a domain with a clear, trustworthy sending identity, and that feeds into the reputation that decides inbox placement for all of your mail. Enforcement and deliverability are not separate projects. The work that gets you to p=reject safely is the same work that keeps your legitimate mail landing in the inbox.
The route to enforcement is gradual: start at p=none with reporting on, read the aggregate reports to find every legitimate source, fix authentication and alignment for each one, then raise the policy in steps. Done carefully, you reach p=reject without ever blocking a real message.
Practical steps to protect deliverability
Here is the order of work that fixes the problem and keeps it fixed.
- Authenticate every source. Inventory everything that sends mail as your domain, your mail server, CRM, invoicing tool, help desk, marketing platform, and make sure each passes SPF or DKIM, ideally both. The ones you forget are the ones that fail.
- Fix alignment, not just signing. Confirm that the SPF or DKIM domain aligns with your From domain on each source. Passing without aligning does nothing for DMARC.
- Keep SPF under 10 lookups. Audit your record, count the lookups, and flatten if you are near or over the limit so you never hit
permerror. - Turn on reporting and read it. Publish
rua=aggregate reporting and review it. The reports show you exactly which sources pass and fail, which is how you find the broken ones before a customer does. - Watch Postmaster Tools. Track your Gmail spam-complaint rate and keep it under 0.3%. A rising complaint rate is an early warning, well before deliverability drops noticeably.
- Move to enforcement. Once your sources are clean, raise the policy through
p=quarantinetop=rejectso spoofers are blocked and your reputation reflects a properly managed domain.
The quickest way to see where you stand is to look at the records you already publish. A free scan checks your SPF, DKIM and DMARC, flags an over-limit SPF record or a missing alignment, and shows you what a receiving server sees when your mail arrives. If you would rather have the whole path to enforcement handled, our team does the authentication, alignment and policy work for a one-time fee; details are on the pricing section. You can also create an account to start monitoring straight away.
The bottom line
Email authentication stopped being optional the day the major providers started enforcing it, and the cost of ignoring it is not a dramatic outage but a quiet erosion: invoices in spam, password resets that never arrive, a sender reputation worn down message by message. The good news is that the same handful of fixes, authenticate every source, align with your From domain, keep SPF valid, monitor the reports and watch your complaint rate, both restores deliverability and earns you a clean path to full enforcement. Find out what is broken before your customers do.