The Bounce Investigation: Diagnosing a Failing Sender Reputation Report

Marketing Academy · Field Work●Email & Lifecycle

All projects·From: Deliverability: SPF, DKIM, DMARC

CoreAudit· 45 minutes

Zendesk

Objective: Given a supplied sender-reputation and authentication-status report (SPF/DKIM/DMARC pass rates, complaint rate, bounce rate, Google Postmaster domain reputation), diagnose which specific factor is tanking inbox placement and sequence the fix in the correct order.

You're the lifecycle marketing analyst at Zendesk. Marketing ops just forwarded a Google Postmaster Tools export and a DMARC aggregate report summary after three straight weeks of declining open rates on the product newsletter, and asked you to find the cause before the next send.

Read the authentication and reputation report line by line, separate a hard blocker (would cause outright rejection) from a soft signal (would cause filtering), and decide which to fix first.

Before you start

What you'll need

Free path (everything below is enough to finish)

Google Sheets

FreeImport and filter the DMARC aggregate report and Postmaster export

No account cost, handles pivoting and filtering a few thousand rows without issue

Paid upgrades (optional, faster/deeper)

Mailchimp(optional)

FreemiumESP-side domain authentication setup and ongoing complaint-rate monitoring

Automates DKIM key rotation and surfaces complaint rate per campaign without a manual export

The process

2 steps

Step 01 of 02

SPF envelope-sender authorization

SPF checks whether the sending IP is on the domain's approved list; a spoofer or a forgotten ESP integration missing from that list fails SPF outright.

The report shows SPF passing at 61% and DKIM passing at 98%. Every failing row traces back to one sending IP block. What does that gap most likely mean?

Google Sheets— Import the DMARC aggregate report summary CSV and filter rows where spf_result = fail.

Procedure

Import the DMARC report summary and filter to spf_result = fail
Group the failing rows by source_ip to find the common IP block
Cross-reference that IP block against the current SPF TXT record's include: list

Sample output

spf_result breakdown (10,400 rows)
  pass: 6,344 (61.0%)
  fail: 4,056 (39.0%), all from source IP block 198.51.100.0/24

Current SPF record: v=spf1 include:mailchimp.com include:sendgrid.net ~all
198.51.100.0/24 does not appear in either included range.

Healthy

SPF pass rate above 95%, with the rare failures scattered across unrelated one-off IPs rather than concentrated in one block.

Unhealthy

39% of mail failing SPF, all traced to a single IP block, meaning one entire sending source was never added to the SPF record.

What this means

A concentrated SPF failure on one IP block is almost never spoofing, it's an onboarding gap: a transactional tool or a new ESP send domain that was never added to the include list.

So what do I do about it?

Symptom	Action	Effort
SPF fails cluster on one IP block, not scattered	Identify the sending service behind that IP block and add its include: statement to the SPF record	30 min

YouYou can do this yourself, no engineering access required.

Step 02 of 02

Spam complaint rate as a hard reputation threshold

Complaint rate above roughly 0.1% is treated as a hard reputation threshold by mailbox providers, crossing it triggers filtering that persists even after the underlying cause is fixed.

The complaint rate this month is 0.34%, more than 3x the 0.1% threshold. Is fixing SPF enough to recover inbox placement on its own?

Google Sheets— The same report's weekly complaint-rate tab.

Procedure

Chart complaint rate by week for the last 8 weeks
Identify the week the rate crossed 0.1% and cross-reference it against send calendar changes
Flag the finding as a second, independent blocker from the SPF gap

Sample output

Week 1: 0.06%   Week 2: 0.07%   Week 3: 0.09%
Week 4: 0.21%   Week 5: 0.29%   Week 6: 0.34%  <- current

Send calendar: Week 4 added a re-engagement blast to the full unfiltered list, including 90+ day inactive addresses.

Healthy

Complaint rate holding steady under 0.1%, tracked weekly, with any spike investigated within days.

Unhealthy

Complaint rate has tripled over 3 weeks and coincides with a send to an unfiltered inactive list.

What this means

SPF and complaint rate are two separate failures that happened at the same time. Fixing SPF alone will not undo reputation damage already caused by the complaint spike.

So what do I do about it?

Symptom	Action	Effort
Complaint rate above 0.1% and rising	Suppress the 90+ day inactive segment immediately and route it through a re-engagement flow before any further bulk sends	30 min

YouYou can do this yourself, no engineering access required.

Final deliverable

A one-page diagnosis memo naming both root causes (the SPF onboarding gap and the complaint-rate spike), in the order they should be fixed, with the specific action for each.

See a reference example

Sample output

Chewy, deliverability diagnosis memo (excerpt)

ROOT CAUSE 1 (fix first): Complaint rate at 0.34%, tripled since Week 4's unfiltered re-engagement blast. Action: suppress 90+ day inactive segment now.

ROOT CAUSE 2: SPF failing on 39% of mail, all from one unregistered IP block. Action: add the missing include: statement.

Do not re-launch bulk sends until both are resolved; fixing only one leaves the other actively suppressing inbox placement.

Success criteria

You're done when you can:

Correctly separates the SPF gap from the complaint-rate spike as two independent causes
Sequences the complaint-rate fix first since it is the harder, slower-to-recover reputation signal
Names a specific, concrete action for each cause rather than a general recommendation