The month Gmail sent my password resets to spam at $39K MRR: a founder diary (2026)

That was the fourth ticket in two days, and it was the sentence that finally made me stop looking at my own code. I was at $39,000 MRR in 2026, running a small B2B SaaS on my own, and I had spent most of a morning adding logging to a password reset flow that turned out to be working perfectly. The email was being generated. It was being accepted. It was being delivered. It was being delivered into the spam folder, which from a customer's point of view is the same thing as not being delivered at all, except that it is my fault in a way they cannot see and I could not measure.

Quick answer (2026): This is a composite founder diary about the month my transactional email quietly stopped reaching inboxes. The cause was not a bug and not a blocklist. It was one product launch email, sent to my whole list in a single afternoon, which pushed me over 5,000 messages in a day and therefore over the line where Gmail and Outlook both apply their strict bulk sender rules. The complaints from that one send attached to my sending domain, and my sending domain was also the domain that sent password resets, receipts and failed-payment notices. The part that made it hard to catch is structural: Google Postmaster Tools shows a solo operator almost nothing on a normal day, because normal-day volume is too low to report on, so the only days you can see your own reputation are the days you have already damaged it. The fix took five weeks and cost me roughly $800 of MRR on the way through.

What I thought a bulk sender was

I thought a bulk sender was somebody else.

My mental model was about identity rather than arithmetic. Bulk senders were newsletter companies and marketing departments. I was a developer with a product, sending what I would have called operational mail: password resets, receipts, trial expiry warnings, an occasional product update. On a normal Tuesday my application sent somewhere around 800 emails. That is not a bulk sender, I thought. That is barely a mailing list.

The rules do not work that way, and I had never actually read them. Google's sender guidelines apply their strict tier to anyone who sends "more than 5,000 messages per day to Gmail accounts", a threshold that took effect on February 1, 2024. Microsoft published a matching rule for consumer Outlook in 2025: domains sending more than 5,000 emails per day to outlook.com, hotmail.com and live.com must pass SPF, pass DKIM, and publish DMARC at a minimum of p=none aligned with one of them, with enforcement beginning May 5, 2025. Yahoo's requirements landed in the same window, in February 2024.

Read that threshold again, slowly, because I did not. It is not five thousand emails per month. It is not an average. It is per day. It is a line you cross or do not cross on each individual calendar day, and nothing about it cares whether you crossed it once or three hundred times.

The afternoon that made me a bulk sender

I shipped a feature I was proud of and I emailed my list about it. The list was 6,240 people. I sent it in one afternoon, because that is what the send button does.

That single afternoon put me over 5,000 messages in a day for the first time in the history of the business. For that day, by both Google's and Microsoft's definitions, I was a high-volume sender with all the obligations that implies. I had SPF. I had DKIM, because my email provider had set it up for me years earlier and I had never thought about it since. I had no DMARC record at all, and I did not have a working one-click unsubscribe, because I had written the unsubscribe link myself as an ordinary link to a page with a confirmation button on it.

That last detail turns out to matter more than it looks. The one-click standard is RFC 8058, and it is specific: it defines a List-Unsubscribe-Post header alongside the older List-Unsubscribe, it requires the mail client to be able to complete the unsubscribe with a single HTTPS POST, and it states that the process "has to work without manual intervention, and in particular without requiring that software attempt to interpret the contents of a confirmation page". My confirmation page was exactly the thing the standard exists to eliminate. So when Gmail rendered its own unsubscribe control on my message and a recipient pressed it, nothing happened that Gmail could verify.

When the easy exit does not work, people use the other one. They press the spam button. It is not malice and it is not a referendum on your product. It is the fastest available control.

The arithmetic I should have run first

Google's guidelines ask senders to keep spam rates reported in Postmaster Tools "below 0.10%" and to "avoid ever reaching a spam rate of 0.30% or higher". Yahoo publishes the same 0.3% ceiling. Those look like generous numbers when you read them as percentages, and they are brutal when you convert them into people.

Of 6,240 recipients, 0.30% is nineteen. Nineteen people pressing "report spam" on a product announcement they genuinely subscribed to is not a disaster of a send. It is a completely ordinary send. On a list that had not been cleaned in two years, that included addresses collected from a lead magnet in 2024, and that offered no working one-click unsubscribe, nineteen was never the ceiling. I ended up with twenty-two, which is 0.35%.

Twenty-two people. That was the whole event. There was no attack, no blocklist, no compromised account, and nothing that would ever show up in an error log, because none of those messages failed. They were accepted and then filed.

Why I could not see any of it

Here is the part I want to press on, because every guide I read afterwards skipped it, and it is the thing that turned a bad afternoon into a five-week problem.

Google Postmaster Tools is where your spam rate lives. It is also, for an operator at my volume, mostly empty. Google's own help page says plainly that "Data might be missing if the total number of messages for a given day is too low. This is to protect users' privacy." At 800 messages a day, spread across many recipient domains, I had never seen a meaningful reputation number in my life. I had opened Postmaster Tools once, found blank charts, concluded it was broken or not for me, and closed it.

So the shape of the trap is this. The rules switch on above roughly 5,000 messages a day. The instrument that tells you how you are doing against those rules also switches on somewhere around meaningful daily volume. A steady bulk sender lives permanently above both lines and can therefore see what it is doing. A solo operator lives permanently below both lines, except on the handful of days a year when a launch pushes them above, which are precisely the days that generate the damage. You get data on the day you break it, and then your volume drops back to 800 a day and the charts go quiet again while you sit inside the consequences.

I want to be careful about what I am claiming. Google does not publish an exact numeric floor for Postmaster Tools reporting, and I am not going to invent one. What I can tell you is what a person at 800 messages a day actually sees, which is nothing, and what that absence does to their mental model, which is to convince them that reputation is not a thing that applies to them.

The bill did not arrive where I expected

I assumed the cost of a bad marketing send was a bad marketing send. Fewer opens. Some unsubscribes. Move on.

The complaints do not attach to the campaign. They attach to the domain, and my domain sent everything. Password resets, receipts, trial expiry notices, seat invitations and failed-payment notices all left from the same place as the launch announcement, so all of them inherited the same degraded reputation.

Password reset tickets went from about four a month to thirty-one over nine days, which is how I found out at all. Seat invitations to new team members stopped arriving, which meant that expansion inside existing accounts silently stalled, which is not a number that appears anywhere on a dashboard.

The one that actually cost money was dunning. When a card fails, the recovery is entirely an email conversation, and I had already been through the exercise of measuring what failed payments were costing me, so I had a baseline. My failed-payment recovery rate that month fell from roughly 62% to roughly 41%. Customers who had every intention of paying me were being told about a problem in a folder they do not read. MRR went from $39,000 to about $38,200, and none of that $800 was a decision anybody made.

That is the honest through-line of this month: an email deliverability problem presented itself to me as a support problem, then as a churn problem, and never once as an email problem until I went looking.

Three things the guides told me that were not quite right

I read a lot of deliverability advice in that fortnight. Most of it was fine. Three specific things were subtly wrong in ways that cost me time, and they are wrong in the same direction, which is that blog posts round off what the primary sources actually say.

"Split transactional mail onto a subdomain." This is the universal advice and it is sensible, but it is not what Google's guidelines say. What that page actually recommends is to "use a different IP address for each message type. For example, use one IP address for sending account notifications and a different IP address for sending promotional messages." IP separation and domain separation are different mechanisms, they are priced differently by email providers, and on a shared-IP plan the subdomain split alone does not give you the thing the guideline is asking for. Do both if you can. Know which one you have actually bought.

"Gmail requires you to honour unsubscribes within two days." I saw this repeated everywhere, attributed to Gmail. Google's sender guidelines page does not state a timeframe. Yahoo's page does: bulk senders must "honor unsubscribes within 2 days". The two-day rule is real and worth following, and it is Yahoo's published rule. If you are going to cite a deadline to a nervous cofounder, cite the source that actually publishes it.

"Outlook junks non-compliant mail." Microsoft's own announcement contradicts itself on this point, and I do not think that is my misreading. One paragraph says the decision was made "to reject messages that don't pass the required authentication requirements", with the SMTP response 550; 5.7.515 Access denied, taking effect May 5th. The next paragraph says that after May 5th, 2025, Outlook "will begin routing messages from high volume non-compliant domains to the Junk folder", with rejection coming at a future date to be announced. Both sentences are on the page. I planned for rejection, because a bounce you can see is a better problem than a delivery you cannot.

What I actually did

Nothing clever. In order:

I published a DMARC record at p=none with reporting turned on, and I left it at p=none for six weeks while I read the reports, because moving straight to p=reject when you do not yet know every system that sends mail on your behalf is how you break your own invoicing.

I implemented one-click unsubscribe properly, to the RFC 8058 shape, with the List-Unsubscribe-Post header and an endpoint that acts on a bare POST with no confirmation page and no session.

I split marketing mail onto a separate subdomain and a separate IP, and I moved nothing else, so that transactional mail stayed on the domain with the longer history.

I deleted 1,900 addresses that had not opened anything in eighteen months. This felt like setting money on fire and it was the single most useful thing I did. It also, I noticed later, made my churn numbers look worse for a month, in the same way that properly cohorting my customers once made my real churn rate look worse without a single customer having changed their behaviour. Measuring honestly usually costs you a nice number first.

And I stopped sending 6,000 emails in an afternoon. Google's guidance on this is explicit and I had never read it: "Avoid introducing sudden volume spikes if you do not have a history of sending large volumes. For example, immediately doubling previously sent volumes suddenly could result in rate limiting or reputation drops." Now a launch goes out over four days in batches, most engaged segment first.

One honest note about the fix, because I have not seen it written down and it caught me out. Moving marketing to a fresh subdomain made things slightly worse before they got better. A new subdomain has no sending history, and history is the asset. I do not have a vendor document that quantifies that valley and I am not going to pretend I do. I can tell you that I made the cutover expecting immediate relief, got two weeks of worse, and nearly reverted it, which would have been the wrong call. Make that change when you are not already in a crisis, if you have the choice. I did not have the choice.

Recovery took about five weeks. Reset tickets returned to normal first, then dunning recovery, which was the last to come back.

What I would tell myself

Read the threshold as arithmetic and not as identity. You are not a bulk sender because of what kind of company you are. You are a bulk sender on any day you send more than 5,000 messages, and if you have a list and a launch button, that day is already in your calendar.

Then go and look at the volume of the largest single send you have planned this quarter, multiply it by 0.003, and ask yourself whether that many people pressing a button is a plausible Tuesday. If it is, the ceiling is not protecting you, and the only lever you actually control is making the easy exit work so that nobody has to reach for the hard one.

The uncomfortable part is not the rules. The rules are published, they are free to read, and they took me an hour. The uncomfortable part is that I ran a business on email for two years without once checking whether email was working, because the failure mode of email is silence, and silence looks exactly like everything being fine.

I am still not certain I would have caught it without those four support tickets, and that is the detail from this month that I have not managed to stop thinking about.