Gmail, SPF, DKIM, DMARC, and 3 Weeks of Hell: 99% Reputation Isn't Enough

Gmail sent me to spam. Not once — systematically. And it did it after I configured SPF, DKIM, DMARC, warmed the domain for weeks, and hit 99% reputation in Google Postmaster Tools. This week a thread blew up on HN about deliverability — 300+ points — and it confirmed something I already suspected: the problem isn't me. The problem is structural. And it probably doesn't have a technical solution.

But I'm going to walk you through everything I did anyway, because if you're going to run your own newsletter in 2025, you need to know where the walls are before you smash your head into them.

Gmail, email reputation, and deliverability: the minefield nobody tells you about

I sent the first batch on a Tuesday at 10am. Three hundred subscribers, all opt-in, all from this blog. I opened Gmail Postmaster Tools two hours later and saw something I didn't want to see: a spam rate of 0.8%. Sounds low. It isn't. Google's threshold for starting to filter is 0.1%. I was eight times over.

The first thing I did was what any systems architect would do: find the failure point. And here's where it gets ugly — with email there's no stack trace. No accessible logs. No decent error message. You get Postmaster Tools, which gives you four metrics at 24-hour resolution, and that's it.

I went back to basics:

# Verify DNS records — always the first step
dig TXT yourdomain.com | grep -E 'spf|dkim|dmarc'

# SPF lookup — maximum 10 lookups allowed per RFC 7208
nslookup -type=TXT yourdomain.com

# DKIM — you need to know the selector your ESP uses
dig TXT selector._domainkey.yourdomain.com

# DMARC
dig TXT _dmarc.yourdomain.com

Everything looked fine. SPF was clean, DKIM signed, DMARC at p=quarantine. Technically immaculate. And still, spam.

Week 1: the setup I thought was enough

I reviewed the full configuration. Here's what my original SPF looked like:

# SPF BEFORE — too many nested includes
v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ~all

# The problem: each include adds lookups
# Google + SendGrid + Mailchimp = potentially 8+ lookups
# If you exceed 10, the record fails silently

I simplified it:

# SPF AFTER — only what I actually use
v=spf1 include:_spf.resend.com ip4:xxx.xxx.xxx.xxx ~all

# Resend uses fewer nested includes
# Added the sending server's IP directly
# ~all instead of -all to avoid being too strict at the start

DKIM was already configured with a 2048-bit key — the minimum acceptable standard today. If you're on 1024, change it now, not later.

I moved DMARC from p=none (monitoring only) to p=quarantine with rua for reports:

# DMARC with aggregate reporting
_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:[e-mail]; pct=100; adkim=s; aspf=s"

# adkim=s and aspf=s = strict mode
# Means the From domain must match exactly
# More secure but more demanding

Week 2: domain warmup and the theater of volume

I added list-unsubscribe headers. Both the mailto version and the HTTP one-click version (RFC 8058). Google explicitly requires this for high-volume senders as of 2024:

# Headers Gmail expects to see in every email
List-Unsubscribe: <https://yourdomain.com/unsubscribe?token=xxx>, <mailto:[e-mail]?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

# Without this, Gmail can penalize you directly
# It doesn't matter that you're technically not "high volume"
# The algorithm doesn't know if you're sending 300 or 300,000

I did the domain warmup by hand because I controlled the full stack. Started with 50 emails on day 1, 100 on day 3, 200 on day 7, 300 on day 14. Followed every guide out there. Reached 99% domain reputation in Postmaster Tools.

And on the third batch, 15% still went to spam in Gmail accounts.

Week 3: the uncomfortable revelation

I started reading the DMARC reports coming in. Raw XML, very friendly:

<!-- Fragment from a real DMARC report -->
<record>
  <row>
    <source_ip>xxx.xxx.xxx.xxx</source_ip>
    <count>47</count>
    <policy_evaluated>
      <!-- Everything passes ✓ -->
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <!-- SPF and DKIM pass. DMARC passes.
       And they still go to spam. Why?
       Because Google has another layer on top of all of this
       that isn't documented in any RFC -->
</record>

There's the raw problem: DMARC pass does not imply inbox placement. Technical standards are a necessary condition for staying out of spam, but not sufficient for landing in the inbox. Google has its own reputation system that operates as a black box on top of the entire authentication stack.

The mistakes I made (and that you'll probably make too)

Mistake 1: Assuming 99% reputation in Postmaster Tools = inbox

Postmaster Tools measures domain reputation based on what Google has already received. It doesn't predict future deliverability. A domain can have 99% reputation and still trigger content filters, engagement filters, or the algorithm just decides your user segment doesn't open emails and starts filtering. It's maddening.

Mistake 2: Ignoring IP reputation

Postmaster Tools has two separate metrics: domain reputation and IP reputation. I had 99% on domain and MEDIUM on IP. That matters. If you're using an ESP like Resend, Postmark, or SendGrid, you're sharing IPs with other senders. If someone in that pool sends spam, your IP reputation drops even if you haven't sent anything wrong.

Partial solution: dedicated IPs. Additional cost. And still not a guarantee.

Mistake 3: Moving to DMARC p=quarantine too fast

I went from p=none to p=quarantine in a week. The right move was to stay at p=none monitoring for at least 30 days, verify that all legitimate flows were passing, and only then escalate. I missed catching that my transactional platform was using a from-address that didn't match the primary domain — those emails started bouncing silently.

Mistake 4: Not separating transactional domain from marketing domain

Everything was going out from the same domain. A "reset your password" email and a newsletter were sharing reputation. Today I use separate subdomains:

# Domain separation — good practice
mail.yourdomain.com     → transactional emails (high priority)
news.yourdomain.com     → newsletter (independent reputation)

# If the newsletter damages reputation, it doesn't drag transactional down
# Gmail's filters also treat them differently

I apply this same separation mentally when working on architectures with multiple services — the principle of separating concerns isn't just for code. I saw it clearly after debugging those PRs with hardcoded credentials where the problem was exactly that: everything mixed into the same context.

Mistake 5: Trusting that "following the standards" is enough

This is the most philosophical mistake and the most expensive one. SPF, DKIM, and DMARC are open standards defined by RFCs. I implemented them correctly. But Google has its own filtering layers that aren't documented, aren't auditable, and have no effective appeals mechanism. It's the same tension I talked about in the post on contributing to the Linux kernel with AI — there are systems where the technical standard and the actual power are completely decoupled.

The structural problem the HN thread exposed

The thread that blew up this week had one comment that's been stuck in my head: "Gmail isn't an email service. It's an email filter that also receives email."

Hyperbolic, but it captures something real. Google processes 40-60% of the world's email depending on which source you look at. That gives them unilateral decision-making power over what arrives and what doesn't. And that power isn't regulated by any technical standard, any RFC, any internet authority.

RFC 7208 (SPF), 6376 (DKIM), and 7489 (DMARC) are community agreements. Google respects them at the technical level — they won't accept emails that fail DMARC. But they use them as a floor, not a ceiling. Above the floor they built their own building and they don't let you see the blueprints.

This reminds me of something I wrote about broken AI agent benchmarks: when the evaluation system is opaque and controlled by a single actor, the results stop measuring what you think they're measuring. Email is the same. The "99% reputation" measures something — just not exactly what you need it to measure.

FAQ: Gmail, deliverability, and the hell of self-hosted email

Does having SPF, DKIM, and DMARC correctly configured guarantee I won't go to spam in Gmail?

No. They're a necessary condition for not going to spam, but not sufficient for landing in the inbox. Google has additional filtering layers based on engagement (opens, clicks, spam reports by users), IP reputation of the sending server, domain history, and content factors that aren't publicly documented. You can have all three protocols perfect and still end up in spam if your engagement is low or your IP has a negative history.

How long does it take to warm up a new domain for email?

Industry consensus is 4 to 8 weeks of gradual warmup. Start with small volumes (50-100 emails), double roughly every 3-5 days, and keep engagement metrics high in that initial period. The catch is that during those first weeks you'll have low deliverability anyway, and if you send to users who don't open, you damage the reputation you're trying to build. It's a bootstrapping problem with no elegant solution.

Is it worth having dedicated IPs for small newsletters?

Generally no, until you're at 50,000-100,000 emails per month. Below that, a dedicated IP with no history is worse than a shared IP with good reputation used by large ESPs. The reasoning: Google trusts IPs that send high volumes of clean email. A new IP with no history generates distrust. With low volume, you don't have enough signal to build that trust quickly.

What is Google Postmaster Tools and how do I use it to diagnose problems?

It's a free Google tool (postmaster.google.com) that gives you metrics on how Gmail sees your sending domain. It shows domain reputation, IP reputation, user-reported spam rate, authentication errors, and delivery rate. To use it you need to verify ownership of your domain. The big limitation is that data has 24-48 hours of latency and you only see averages, not individual emails. Useful for trends, useless for real-time debugging.

Does it make sense to have your own newsletter in 2025 or is it better to use Substack/Beehiiv?

Depends what you're prioritizing. Substack and Beehiiv have domain and IP reputation built over years with millions of senders. Your email goes out from their domains with their history — that gives you much better deliverability from day one. The cost is you don't control the infrastructure, you're subject to their terms, and if they have a reputation problem, it drags you down too. For small newsletters (under 5,000 subscribers), I'd recommend starting on Beehiiv or Substack today and migrating to your own domain when you have enough critical mass to sustain the warmup. I learned this the expensive way.

Is one-click unsubscribe actually required for Gmail?

Since February 2024, Google requires it for senders sending more than 5,000 emails per day to Gmail accounts. For lower volumes it's technically optional but highly recommended. The List-Unsubscribe-Post: List-Unsubscribe=One-Click header (RFC 8058) tells Gmail it can process the unsubscribe automatically without opening the email. Without it, users who want to unsubscribe will mark as spam instead of hunting for the unsubscribe link — and that destroys your reputation much faster than any technical issue.

So what would I do differently?

What three weeks of debugging taught me is that email deliverability has two completely distinct layers: the technical layer (SPF/DKIM/DMARC) that you can control, and the reputation/engagement layer that's partially in Google's hands and changes the rules without telling you.

On the technical layer, everything is current: separate subdomains for transactional and marketing, DMARC at p=reject after 60 days of monitoring, one-click unsubscribe implemented, full list headers in place. That I can control, and I do control it.

On the reputation layer, I learned to play defense: segment the list and send first to the most engaged, clean bounces and zero-open addresses every 90 days, and accept that a percentage of Gmail users will live in spam no matter what I do. That's not an implementation failure — it's a feature of the monopoly.

The uncomfortable question I started with — does it make sense to have your own newsletter in 2025? — here's my answer: it makes sense if you understand you're building your own infrastructure with all the maintenance costs that implies. It's not plug-and-play. It's the same decision as hosting your own database versus using a managed SaaS. You can do it, but know why you're doing it.

Same lesson I took from the dancer with ALS who controlled a performance with brainwaves: total control over the infrastructure has a real cost, and sometimes the right abstraction is letting someone else handle the hard layer.

I'm sticking with my own domain. But now I know exactly what I'm dealing with.

Do you run your own newsletter? How are you handling Gmail deliverability? Let me know in the comments — I'm genuinely curious if anyone found something I haven't tried yet.