DEV Community: Denys Button

The Fake Complaint Spike: When "Spam Complaints" Aren't Real Complaints

Denys Button — Mon, 28 Sep 2026 10:11:14 +0000

Some providers log a complaint when a recipient just deletes unread. Here's how to tell a real spam complaint spike from a false one.

The Fake Complaint Spike: Not Every "Complaint" Is a Complaint

You check your feedback loop data or Google Postmaster Tools and see it: complaint rate jumped from 0.03% to 0.4% overnight. Panic sets in. You pause the campaign, start rewriting copy, maybe pull the list and re-verify it. Then two days later it settles back down on its own, and you're not sure what actually happened or what you fixed.

Here's the piece almost nobody tells you, and it's the thing that separates a real deliverability problem from a false alarm: not every event a provider logs as a "complaint" is a recipient hitting "Report Spam."

What's actually happening

Some mailbox providers' feedback loop (FBL) mechanisms are looser than the name implies. Depending on the provider and the exact UI flow, an action as passive as deleting a message without opening it, or deleting it quickly after a glance, can get bucketed into the same complaint signal that a genuine "this is spam" click generates. The provider isn't lying to you — this is a real feedback signal reflecting real recipient disengagement — but it's not the same thing as "this recipient was offended enough to actively flag me," and treating it that way leads to the wrong fix.

This distinction matters because the two causes point to completely different problems:

A real complaint spike (recipients actively marking as spam) usually means your content, targeting, or send cadence crossed a line — wrong list segment, too aggressive a pitch, mismatched expectations from opt-in.
A false spike driven by delete-without-open behavior usually means something upstream changed engagement — a list segment that's gone cold, a subject line that stopped resonating, a send time that landed at a bad hour, or simply normal list fatigue on a long-running sequence.

Gutting a campaign's copy in response to a false spike fixes nothing, because copy was never the cause. Worse, it burns a debugging cycle while the actual cause — say, a cold list segment that needed to be trimmed — keeps degrading your sender reputation untouched.

How to tell the difference before you react

1. Check the timing against your send, not just the daily aggregate. A real complaint spike usually clusters tightly after send time — people react fast when something actively bothers them. A delete-driven signal tends to spread out more evenly over the following 24–48 hours, matching normal inbox-checking behavior rather than an immediate reaction.

2. Cross-reference against open rate for that specific send. If the "complaint" spike coincides with a lower-than-usual open rate on the same send, that's a strong signal you're looking at disengagement (deletes), not active complaints. A genuine complaint spike can happen even on a well-opened email — people open it, read it, then complain.

3. Compare magnitude against list segment, not domain-wide. Pull the complaint data by list segment or campaign, not just the domain aggregate. If the spike is concentrated in one old, rarely-engaged segment, that points to fatigue/deletes. If it's spread evenly across fresh and old segments alike, it's more likely a genuine content or targeting issue.

4. Check Google Postmaster Tools' spam rate trend over a rolling window, not a single day. A single-day blip that reverts within 2–3 days without any changes made is far more consistent with a noisy false signal than a real reputation hit. A real complaint-driven reputation problem tends to persist and compound if uncorrected.

5. Look at unsubscribe rate alongside complaint rate. A real jump in "this bothers me" sentiment usually shows up in both complaints and unsubscribes together. If unsubscribes stayed flat but the complaint metric alone spiked, lean toward the false-signal explanation.

What to actually do about each case

If it's a real complaint spike:

Pause the specific segment or campaign, not necessarily everything.
Review content against the specific segment's original opt-in context — did this list agree to this kind of email?
Check send frequency — are you over-mailing this segment relative to what they signed up for?

If it's a false spike from disengagement:

Suppress or re-engage the specific cold segment rather than touching copy.
Consider a sunset policy — stop mailing contacts who haven't opened in N sends.
Review subject line and send-time performance for that segment specifically, since the underlying issue is attention, not offense.

The bigger point

This is exactly why step 3 of any real deliverability diagnosis — engagement and list quality — comes before step 4, content. A complaint-rate metric looks like a content signal on the surface, but it's frequently a list-hygiene signal wearing a content-signal costume. Reacting to the surface-level number without checking what's actually driving it is how teams end up rewriting perfectly good copy while the real cause, a stale segment nobody's pruned in six months, keeps quietly dragging down domain reputation.

Quick checklist before you react to a complaint spike

Does the spike cluster right after send (real) or spread over 24–48 hrs (deletes)?
Does it correlate with a lower open rate on that specific send?
Is it concentrated in one old/cold segment, or spread evenly?
Does it persist over a rolling window, or self-correct in a few days?
Did unsubscribes move with it, or stay flat?

Telling a real complaint problem from a false one is exactly the kind of nuance the technical diagnostic in the Cold Email Deliverability Kit (https://remixdenis.gumroad.com/l/kit) is built to catch before you burn a week second-guessing good copy. For the full breakdown of engagement signals and list-hygiene diagnostics, check out Deliverability Diagnostics: What Actually Gets Email to the Inbox (https://remixdenis.gumroad.com/l/mclaie).

How to Read a DMARC Report (RUA) — A Practical Walkthrough

Denys Button — Mon, 28 Sep 2026 10:08:54 +0000

What a DMARC aggregate report actually shows, how to start collecting one, and why you should not jump straight to p=reject. Step by step.

How to Read a DMARC Report Without Guessing

You set up a DMARC record, added a rua= tag, and now you're staring at either nothing (no reports arriving yet) or an inbox full of XML attachments that look like a server log dumped from orbit. Neither state tells you what to do next. Here's how to actually get useful data out of DMARC and read it correctly.

What a DMARC aggregate (RUA) report actually is

DMARC has two report types: aggregate (RUA) and forensic (RUF). RUA is what you want first — it's a daily XML digest, sent by every major receiving mailbox provider that supports DMARC (Google, Microsoft, Yahoo, etc.), summarizing every message they saw claiming to be from your domain: how many, from which sending IPs, and whether SPF and DKIM passed and aligned for each one.

It is not a list of individual emails or recipient addresses — it's aggregated by source IP and result, once a day per reporting provider. RUF (forensic) reports individual failing messages but almost no major provider sends them anymore due to privacy constraints, so don't build a workflow around expecting RUF data.

Step 1: Start collecting reports

Your _dmarc TXT record needs a rua= tag pointing to an address that can receive the reports:

_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

Two things matter here before you go further:

Start at p=none. This tells receivers "report to me, but don't do anything differently with delivery." It's monitor-only mode. You need data before you can safely change enforcement — more on this below.
Don't point rua= at a personal inbox. Raw XML is unreadable at any real volume. Use a free parser like dmarcian's DMARC XML parser (they offer a free tier for basic aggregate report parsing) or a similar tool that ingests the raw reports and renders them as a dashboard.

If you're new to this, sign up for a free DMARC report parsing tool, get their provided rua= address (many act as an intermediary and forward/parse automatically), and use that in your record instead of a raw mailbox.

Step 2: Give it time

Reports arrive roughly once every 24 hours per reporting provider, and you need enough volume and enough days to see a real pattern — a few days at minimum, ideally 1–2 weeks before drawing conclusions. A single day's report from a low-volume domain can be misleading.

Step 3: Read alignment, not just pass/fail

This is where most people misread the report. DMARC doesn't just ask "did SPF pass" and "did DKIM pass" — it asks whether the domain that passed matches the visible From domain, a concept called alignment.

SPF alignment (aspf) — does the domain in the Return-Path (envelope from) match the visible From domain? Under relaxed alignment (default), a subdomain match counts; under strict, it must match exactly.
DKIM alignment (adkim) — does the d= domain in the DKIM signature match the visible From domain? Same relaxed/strict distinction.
DMARC passes if either SPF or DKIM passes and is aligned. A message can have SPF technically pass while failing DMARC, if the SPF-passing domain doesn't align with the From header.

In the parsed report, look at each row's source IP alongside its dkim and spf result columns and their alignment flags. Group by source IP first — this is usually the fastest way to spot the real issue.

Step 4: Identify every source IP, then sort them

For every unique sending IP in the report, ask: do I recognize this?

Known senders failing alignment — your ESP, CRM, or transactional provider is sending on your behalf but SPF/DKIM isn't aligned to your domain. This is a configuration fix, not a threat.
Unknown senders passing SPF but not DKIM (or vice versa) — could be a legitimate forwarder, could be a spoofing attempt. Cross-reference against your actual vendor list.
Unknown senders failing everything — likely spoofing attempts being reported to you as evidence DMARC is doing its job, even at p=none.

Step 5: Why you must not jump straight to p=reject

Once you see failures, the instinct is to lock it down immediately — flip to p=reject and stop the bad traffic. Don't, until every legitimate source in your reports is passing and aligned.

p=reject tells every receiving provider to drop, outright, any message claiming your From domain that fails DMARC. If a legitimate but misconfigured sender — a support tool, a CRM, an internal system, an old marketing platform — is still in your sending mix and not yet aligned, p=reject will silently kill their mail with zero warning. You won't find out until someone asks why their emails never arrived.

The correct progression:

p=none — monitor only, collect reports, identify every legitimate sending source.
Fix SPF/DKIM alignment for each legitimate source (usually via custom DKIM selectors and adjusting SPF includes).
p=quarantine at a low percentage (pct=) — start enforcing softly, on a fraction of traffic, watch for unexpected impact.
Increase pct= and move to p=reject only once reports show 100% of legitimate traffic passing and aligned, consistently, over multiple weeks.

Skipping straight to step 4 is the single most common way DMARC rollouts break legitimate mail flows.

Quick checklist

rua= set, pointed at a parser, not a raw inbox.
Start at p=none.
Collect at least 1–2 weeks of reports before acting.
Group failures by source IP; identify every unrecognized sender.
Fix alignment for legitimate sources before tightening policy.
Move p=none → p=quarantine (with low pct=) → p=reject, only as reports confirm it's safe.

Reading DMARC reports correctly is one piece of a larger authentication check — SPF, DKIM, and DMARC all interact, and a mistake in one shows up as noise in the others. The Cold Email Deliverability Kit (https://remixdenis.gumroad.com/l/kit) walks through all three in a 20-minute diagnostic pass. For the full policy rollout strategy and alignment troubleshooting, see Deliverability Diagnostics: What Actually Gets Email to the Inbox (https://remixdenis.gumroad.com/l/mclaie).

SPF Too Many DNS Lookups: Fix the 10-Lookup Limit and permerror

Denys Button — Mon, 28 Sep 2026 10:04:02 +0000

SPF "Too Many DNS Lookups": Diagnosing and Fixing permerror

You added one more include: to your SPF record — a new ESP, a new outreach tool, a new SaaS vendor that needs to send on your behalf — and now mail that used to pass is failing SPF entirely. This is one of the most common silent failures in email infrastructure, and it doesn't throw an obvious error in most sending dashboards. It just quietly starts failing authentication.

The 10-lookup limit, explained

RFC 7208 caps SPF evaluation at 10 DNS lookups per check. Not 10 include: mechanisms — 10 total lookups, counting every mechanism that requires its own DNS query: include, a, mx, ptr, exists, and any redirect. ip4/ip6 and plain all don't count, since they don't require a lookup.

Here's the part that catches people off guard: each include: can itself contain more include: statements, each triggering its own lookup. A record with five includes can easily blow past 10 once you follow the chain, because vendors like your ESP or CRM often nest their own third-party includes inside their SPF record.

When the limit is exceeded, the result isn't "SPF fails" — it's permerror, a permanent evaluation error. Receiving servers treat permerror inconsistently, but many treat it as equivalent to a fail, which tanks deliverability across every stream sharing that domain, not just the one from the new vendor you added.

How to check your current lookup count

Pull the raw SPF record:

dig TXT yourdomain.com +short

For every include: in the record, resolve it and count its own lookups:

dig TXT _spf.vendor.com +short

Repeat recursively — an include can point to another include.
Or skip the manual recursion and run the domain through MXToolbox's SPF record check, which walks the full chain and reports the total lookup count plus a flag if you're at or over the limit.

If you're at 8–10, you're one vendor addition away from permerror. Fix it now, not after it breaks.

Common causes of an oversized SPF record

Stacking multiple ESPs (e.g., your transactional provider, your marketing platform, and a cold outreach tool) each with their own nested includes
Legacy vendors left in the record long after you stopped using them
CRM or helpdesk tools that ask you to add their SPF include for "better deliverability" but rarely get removed when you churn
Copy-pasted SPF records from old documentation that include unnecessary a or mx mechanisms alongside include: chains

How to fix it: flatten, consolidate, or delegate

1. Remove dead vendors first. Before doing anything structural, audit every include: against your actual active sending tools. This alone often solves it.

2. Flatten static includes into IP ranges. If a vendor's sending IPs are stable, replace include:vendor.com with the resolved ip4: ranges directly in your record. This removes the lookup entirely, but you now own the maintenance burden if the vendor changes IPs — track their changelog or re-flatten periodically.

3. Consolidate under one subdomain per sending stream. Some senders split cold outreach, transactional, and marketing mail across subdomains (e.g., mail.yourdomain.com for outreach), each with a leaner, purpose-specific SPF record instead of one bloated record trying to authorize everything.

4. Use a macro/flattening service if the includes are volatile. Tools like dmarcian's SPF Surveyor visualize the full lookup tree and can help you decide what to flatten versus what to leave as a live include for vendors that rotate IPs frequently.

What the fixed record should look like

A lean, well-scoped SPF record for a domain sending through one ESP and one cold outreach platform might look like:

v=spf1 ip4:203.0.113.0/24 include:_spf.esp-example.com -all

Note -all (hard fail) versus ~all (soft fail) — that's a separate decision from lookup count, but worth checking while you're in here. A record with ?all (neutral) provides essentially no protection and is worth tightening once your legitimate senders are fully accounted for.

Verification checklist

Run MXToolbox SPF check — confirm lookup count is under 10, ideally under 8 to leave headroom.
Confirm no permerror or temperror in the result.
Remove any include: for vendors no longer in active use.
Flatten stable, high-lookup includes to ip4:/ip6: where feasible.
Re-check after any new vendor is added — this is a recurring maintenance task, not a one-time fix.

Don't stop at SPF

A passing SPF record doesn't guarantee inbox placement on its own — it needs to align with DKIM under DMARC, and it's just one layer of a much larger diagnostic. Vendors change IP ranges without much warning, so this is worth re-checking on a schedule, not just when something breaks.

For a full DNS-lookup audit workflow alongside DKIM and DMARC checks, the Cold Email Deliverability Kit (https://remixdenis.gumroad.com/l/kit) includes the exact diagnostic steps and a bounce-code cheat sheet for when authentication failures start showing up as bounces. The course Deliverability Diagnostics: What Actually Gets Email to the Inbox (https://remixdenis.gumroad.com/l/mclaie) covers flattening strategy and multi-vendor SPF architecture in more depth.

Why Does My Email Go to Spam? A Diagnostic Order That Actually Works

Denys Button — Mon, 28 Sep 2026 09:56:16 +0000

A step-by-step order for diagnosing why email lands in spam: technical auth first, then reputation and engagement, then copy last. Stop guessing.

Why Does My Email Go to Spam? Diagnose It in the Right Order

Something worked last month. Now half your sends are landing in Promotions, spam, or nowhere at all, and everyone on the team has a theory. Someone wants to rewrite the subject line. Someone wants to swap the send time. Someone's convinced it's the word "free" in paragraph two.

Most of that is noise. After 16 years working email infrastructure and deliverability across 1,000+ sending domains — including ramping fresh domains to 20,000+ sends/day in 14 days without triggering blocks — the pattern is consistent: people diagnose in the wrong order. They start with copy because copy is the easiest thing to blame and the easiest thing to change. But copy is rarely the actual cause, and "fixing" it without checking the plumbing first just burns another send cycle and another chunk of reputation.

Here's the order that actually finds the cause, fastest.

Step 1: Technical authentication — check this before anything else

If SPF, DKIM, or DMARC is broken or missing, nothing else you do matters. Mailbox providers use these three records to decide whether your mail is even eligible to be evaluated as legitimate, let alone land in the inbox.

SPF — does the sending IP appear in the domain's v=spf1 record? Check for permerror from exceeding 10 DNS lookups, a common silent failure.
DKIM — is the message actually being signed, and does the selector's public key in DNS match what's in the d= and s= tags of the signature?
DMARC — is there a _dmarc TXT record, and are SPF and/or DKIM aligned with the visible From domain (not just passing in isolation)?

Run the domain through MXToolbox's SPF/DKIM/DMARC checkers and dig for the raw TXT records yourself:

dig TXT yourdomain.com
dig TXT _dmarc.yourdomain.com
dig TXT selector._domainkey.yourdomain.com

If any of these are broken, fix them before touching anything else downstream.

Step 2: Domain and IP reputation

Authentication passing doesn't mean the sender is trusted — it means the mail is verifiably from you. Reputation is a separate question.

Check the sending IP and domain against major blocklists (Spamhaus, Barracuda, SORBI) via MXToolbox's blacklist tool.
Pull up Google Postmaster Tools for the domain — check IP and domain reputation buckets, spam rate, and delivery errors over the last 30 days.
New domain or new IP? Reputation isn't built yet. Sudden volume on an unwarmed domain looks identical to a burst of spam from a compromised account, and filters treat it that way.

Step 3: List quality and engagement

Once auth and reputation are clean, look at who you're actually mailing.

Bounce rate above ~2% on a single send is a signal your list has decayed or was never verified.
Spam complaint rate above ~0.1% (Gmail's Postmaster threshold) will suppress inbox placement even with perfect SPF/DKIM/DMARC.
Low open/engagement rates over time train Gmail and Outlook's ML filters to deprioritize you specifically, independent of content.

Step 4: Content — check this last, not first

Only once the first three layers are clean does content start to matter. And even then, it's rarely a single trigger word — it's structural: an unusually high link-to-text ratio, image-only emails with no text, a mismatched display name and From address, or missing a plain-text part. Legitimate mail with a slightly awkward subject line still gets delivered when the domain is trusted and the list is clean.

Why this order, and not the reverse

Filters layer their decisions the same way this checklist does — auth first, reputation next, behavior third, content last as a tiebreaker. If you start by rewriting subject lines on a domain with a broken DMARC record, you're optimizing a variable that isn't the bottleneck. You'll "fix" something, see no change, and conclude the whole system is a black box. It isn't. It's just being diagnosed backwards.

One thing this checklist explicitly does not include: tricks to fool spam filters — hidden text, invisible characters, zero-width joiners, cloaked links. Those get flagged the moment a provider updates its model, and the damage to domain reputation outlasts the campaign that triggered it. There's no shortcut around clean infrastructure.

Quick self-check

Do SPF, DKIM, and DMARC all pass and align? (dig + MXToolbox)
Is the domain/IP on any blocklist? (MXToolbox blacklist check)
What's the domain's reputation in Google Postmaster Tools?
What's the bounce rate and complaint rate on recent sends?
Only after 1–4 are clean: review subject lines, HTML structure, and link ratios.

Running through this manually across SPF, DKIM, DMARC, blocklists, and warm-up takes real time to get right the first time. The Cold Email Deliverability Kit (https://remixdenis.gumroad.com/l/kit) is a 20-minute technical diagnostic checklist covering exactly these steps, plus a separate content-audit checklist and a compliant HTML/SMTP boilerplate — no evasion tricks, just the setup that gets mail delivered. If you want the deeper version with real diagnostic walkthroughs, the course Deliverability Diagnostics: What Actually Gets Email to the Inbox (https://remixdenis.gumroad.com/l/mclaie) goes further.