Why your emails stopped reaching the inbox
A client of a membership website asks to reset their password, and the email never arrives. What comes back instead is a bounce, and Google's own sender FAQ lists its wording:
"550-5.7.26 This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM."
That is unusual and useful, because the failure names its own cause. You can arrive at it without having changed anything: what changed is what the receiving mailbox is willing to accept, and that change had a date.
The rules changed on a date, and the bottom rung applies to everyone
The widespread belief is that this is about bulk email. It is not, or rather it is only half about bulk email, and the half that catches small businesses is the other one.
Google's sender guidelines open with a date: "Starting February 1, 2024, all email senders who send email to Gmail accounts must meet the requirements in this section." All senders. One message a week counts.
What that section asks for is short:
- "Set up SPF or DKIM email authentication for your sending domains."
- "Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records."
- "Use a TLS connection for transmitting email."
- "Format messages according to the Internet Message Format standard, RFC 5322."
- "Don't impersonate Gmail From: headers."
And the consequence, in the same document: "Messages that aren't authenticated with these methods might be marked as spam or rejected with a 5.7.26 error."
Most of that list is handled by whoever runs your email, invisibly, and you will never think about it. The first item is the one that breaks, because it depends on records published in your domain's DNS, and DNS is the part of a small business's setup that nobody owns.
The 5,000 threshold is counted by domain, and it never lapses
The higher tier of requirements starts at volume: "Starting February 1, 2024, email senders who send more than 5,000 messages per day to Gmail accounts must meet the requirements in this section."
Five thousand a day sounds like somebody else's problem. Two details in Google's FAQ make it less comfortable.
The count is per domain, not per mailing. Google's example is worth reading carefully:
"When we calculate the 5,000-message limit, we count all messages sent from the same primary domain. For example, every day you send 2,500 messages from solarmora.com and 2,500 messages from promotions.solarmora.com to personal Gmail accounts. You're considered a bulk sender because all 5,000 messages were sent from the same primary domain: solarmora.com."
Google, email sender guidelines FAQ
So the total is everything leaving your domain towards personal Gmail addresses. The CRM, the invoices, the appointment reminders, the contact form, the newsletter, whatever the booking system sends, and anything a subdomain sends on your behalf. A business that has never run a campaign in its life can arrive at the threshold by accumulation.
The second detail: "Bulk sender status doesn't have an expiration date. Email senders that have been classified as bulk senders are permanently classified as such."
Cross it once, in one busy month, and the stricter requirements are yours from then on.
What the bulk tier adds
If you are over the line, the list grows. SPF and DKIM both, rather than either. Alignment, which Google states as "For direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain". A published DMARC policy. And one-click unsubscribe: "Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body."
One-click means a specific technical thing rather than a link that opens a preferences page. It is defined in a published standard, RFC 8058, which describes "a method for signaling a one-click function for the List-Unsubscribe email header field". The practical consequence for a small business is that the old approach does not qualify: "We'll continue to support mailto links but they don't meet our one-click unsubscribe requirement."
There is also a deadline attached to the button. Google recommends fulfilling unsubscribe requests within 48 hours; Yahoo's requirement is to "Honor unsubscribes within 2 days".
Even below the threshold, Google's own advice is to do all of it anyway: "To improve email delivery, we recommend that you always set up SPF, DKIM, and DMARC for your domains."
The bounce already contains the diagnosis
This is the most useful and least used fact in the whole subject. When a message is refused, you are told why. Google's FAQ: "Yes, when messages are rejected, we send a rejection code and a reason for the rejection."
The codes are worth recognising on sight, because each points at a different part of your setup:
| Code | What it means | Where the fix lives |
|---|---|---|
| 5.7.26 | the message was not authenticated with SPF or DKIM | DNS records for your sending domain |
| 5.7.25 | "This message was blocked because the sending IP address doesn't have a PTR record, or the forwarding DNS entry doesn't reference the sending IP address" | whoever operates the sending server |
| 4.7.28 | your own sending quota, exceeded: a temporary refusal rather than a permanent one | volume and sending pattern |
| 550 5.7.515 | Outlook's wording: the sending domain does not meet the required authentication level | same DNS records, different judge |
By the usual SMTP convention the 4-series codes are temporary and the 5-series permanent, which matters because a temporary refusal often looks like success in whatever tool you use. The message sits in a queue, gets retried, and eventually gives up somewhere nobody is watching.
The direction of travel is towards the permanent kind. Google's FAQ says: "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections."
The first thing to break is not the newsletter
If you are picturing a marketing campaign going to spam, you are picturing the wrong failure. Newsletters usually go out through a service that has already set all of this up. The things that break are the emails nobody thinks of as email.
Password resets and account notices. The example at the top of this article was a membership site. Nobody complains about a missing reset email; they just stop using the account.
Messages from your website's contact form. Google has a dedicated troubleshooting page for exactly this, which says "Often, the root cause of this issue is how the contact form provider authenticates email", and adds the requirement people miss: "When other services send email for your domain, you must update your SPF record to include these senders. If you don't, messages from these senders are more likely to be marked as spam."
Forwarding, which is where it gets genuinely nasty. Plenty of small businesses forward info@ to somebody's personal inbox. Google warns that "Email forwarding can affect message authentication, and forwarded messages often fail SPF authentication", and Microsoft says the same from the other side: "SPF breaks after messages encounter server-based email forwarding that redirects or relays messages." DKIM survives forwarding, because the signature travels with the message.
Which means a business that set up SPF and stopped there has a setup that works for direct mail and fails for anything forwarded. That produces the symptom that makes this so hard to diagnose: a mailbox that has forwarded to Gmail for years starts losing some messages and not others, the owner notices nothing from the inside, and finds out only when a sender mentions the bounce-backs they have been getting.
Intermittent, invisible from the inside, and discovered because somebody else mentioned it. That is the same shape as a green run that delivered nothing, and it is why the enquiries that stop arriving are never the ones you notice first.
Who decides a message is marketing
A common defence is that none of this applies because your emails are transactional. Invoices, receipts, appointment confirmations.
Google removes that defence in one sentence: "The distinction between promotional and transactional messages can vary depending on industry and applicable regulations. Message recipients, not Google, determine the nature of the messages they receive."
If enough people mark your invoice reminders as spam, your invoice reminders are spam as far as the receiving side is concerned. And the measurement is not generous. The requirement is to "Keep spam rates reported in Postmaster Tools below 0.3%." Google's own advice, further down the same page, is stricter: "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher." The FAQ adds that "Spam rate is calculated daily."
Three tenths of a percent to comply, one tenth to be comfortable, measured every day. On a list of a thousand, a single complaint puts you at the number Google recommends you stay under.
Postmaster Tools is where Google shows you these numbers, and it is worth registering for even though most small businesses will find it empty: "Data might be missing if the total number of messages for a given day is too low. This is to protect users' privacy." No threshold is published, so the honest answer is that you will find out by looking.
Every mailbox provider sets its own bar
Gmail is the most documented, not the only one. The others introduced their own requirements on their own dates, and they do not match.
| Gmail | Yahoo | Outlook.com | |
|---|---|---|---|
| Requirements began | 1 February 2024 | February 2024 | "Starting May 5th, 2025" |
| Volume threshold | 5,000 a day to personal accounts | "We will not specify a volume threshold" | "domains sending over 5,000 emails per day" |
| DMARC | required for bulk senders | "Publish a valid DMARC policy with at least p=none - DMARC must pass" | part of the stated requirements |
| Unsubscribe deadline | 48 hours recommended | "Honor unsubscribes within 2 days" | not published on the postmaster page |
| Spam rate | required below 0.3%, advised below 0.10% | "Keep your spam rate below 0.3%" | not published on the postmaster page |
Yahoo's refusal to name a threshold is deliberate and worth respecting: "A 'bulk' sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold." Anybody quoting a Yahoo number is quoting Google's and hoping.
Note also what the Outlook column is addressed to. Its requirements are published under a heading about high-volume senders and are scoped to "domains sending over 5,000 emails per day", where Google's bottom rung has no threshold at all. The consequence is stated plainly: "Non-compliant messages will be sent to the junk folder. Shortly we will reject the messages until the DNS records are corrected."
One more caution about that column. Microsoft's detailed announcement of these requirements would not load for me on the day I researched this, so everything above about Outlook comes from its postmaster page and from bounce texts posted by users. Treat it as thinner evidence than the Google rows.
And a note on Google Workspace, because it comes up: "The Email sender guidelines don't apply to messages sent to Google Workspace accounts. Sender requirements and Google enforcement apply only when sending email to personal Gmail accounts." The exemption is narrow. It covers business addresses hosted by Google, not business addresses generally: a customer on Microsoft 365 is behind Outlook's rules instead. And filtering and reputation apply everywhere regardless.
The traps in fixing it
Four ways this goes wrong for businesses that decide to sort it out properly.
Publishing DMARC straight at reject. The organisation behind the standard advises the opposite order: "Publish a DMARC record with the 'none' flag set for the policies, which requests data reports. Analyze the data and modify your mail streams as appropriate", and then "Modify your DMARC policy flags from 'none' to 'quarantine' to 'reject' as you gain experience." Going straight to reject without watching the reports first means the first thing you learn is which of your own systems you have switched off.
Assuming SPF is a one-time job. Every new service that sends on your behalf has to be added, and the record has a hard ceiling on the parts of it that trigger DNS lookups: the specification requires implementations to "limit the total number of those terms to 10 during SPF evaluation", returning a permanent error above that. A record grown by accretion over several years can quietly cross that line and start failing for everything.
Assuming subdomains inherit. Microsoft states it directly: "Each domain and any subdomains require their own individual SPF records. Subdomains don't inherit the SPF record of the parent domain." The booking subdomain is its own sender.
Running everything down one channel. Google's guidance is to keep categories apart: "Messages of the same category should have the same From: email address." The practical reason is reputation. Complaints about a promotion attach to the domain that also sends your invoices, and the invoice chasing that keeps your cash flow moving is a poor thing to gamble on a campaign's spam rate.
What to check in your own setup
Send yourself a message and read the headers. From your real system - the booking tool, the CRM, the website form - to a personal address on a large provider. The receiving mailbox will show whether SPF and DKIM passed. This takes five minutes and answers the main question.
Do it for every system separately. The invoicing tool, the booking system, the newsletter platform and the website form are four different senders using your name. They fail independently, and one of them passing tells you nothing about the others.
Read one real bounce, in full. Not the summary your tool shows. The actual text, with the code. It names which check failed and usually which domain failed it.
Find out who owns your DNS. Registrar, hosting company, email provider or an agency from years back. Every fix in this article lives there, and the most common delay is not the fix but working out who can make it.
List everything that forwards. info@ to a personal inbox, an old address to a new one, a shared mailbox that copies somewhere. Each of those is a place where SPF stops helping and DKIM has to carry the message.
Watch the messages you cannot afford to lose. Reset links, booking confirmations, quotes, invoices. If a reminder does not arrive, the customer does not arrive either, which is the same arithmetic as everything else about no-shows.
When this stops being a settings question
For one domain, one mail provider and a website form, this is a settings job. Publish the records, check the headers, read a bounce, done in an afternoon by somebody who knows where your DNS lives.
It stops being that when several systems send as you. Then the questions are which of them are authorised, what a new tool has to do before it is allowed to send, who watches the spam rate, what happens on the day a provider tightens its rules again, and how anyone would notice that the quiet channel went quiet. None of that is a DNS record. It is a decision about how your business communicates, written down once and maintained.
Working out which of those two situations you are in is what a process audit settles: $299, three business days, and a written map of every system that sends email in your name and what happens when one of them stops arriving.