Sender Reputation Monitoring — What to Watch in AcelleMail

Three numbers tell you everything: bounce rate, complaint rate, and inbox placement. AcelleMail surfaces all three in the campaign report and sending-server panels. This guide walks where each one lives + when to act on it.

The three numbers that matter

Sender reputation is the score receiving servers give you. It's not published anywhere — you reverse-engineer it from three measurable signals:

Signal Healthy Warning Critical
Bounce rate <2% 2-5% >5% (Gmail throttles)
Complaint rate <0.1% 0.1-0.3% >0.3% (most ISPs blocklist)
Inbox placement >85% 70-85% <70% (re-engagement campaign overdue)

AcelleMail surfaces all three in the campaign report. The fourth signal — engagement rate (open + click) — is the leading indicator: a 30% open campaign predicts good reputation next month; a 5% open campaign predicts blocks next month.

Reading the campaign report

Where the bounce signals live

Open the campaign → Bounce log tab. Every failed delivery is row-listed with the recipient, bounce type (Hard/Soft chip), and the raw reason from the receiving server:

Campaign bounce log — hard + soft bounces with DSN reason

For machine-codes (5.x.x / 4.x.x DSN classifications) the per-row reason text is the receiving server's verbatim response. See Decoding bounce messages for the full code reference.

The complaint signal — feedback log

Same campaign → Feedback log tab. Every "Mark as Spam" click recipients made gets recorded here:

Campaign feedback log

Complaints are the most expensive signal. A 0.3% complaint rate gets you blocklisted at Gmail / Outlook within 24 hours. Read the log row-by-row when complaints spike — patterns reveal:

  • All from one list segment? Bad source — pause sending to that segment, audit signup flow
  • All on first send to a freshly imported list? Permission unclear at signup — full audit needed
  • Spread evenly across the list? Content issue (subject line over-promised, body misleading)

Sending-server health signal

Open the sending server detail and check: SPF/DKIM/DMARC chips green, recent throughput, error-rate trend:

Sending server detail with SPF/DKIM/DMARC chips

If any chip flips red mid-campaign, that's your authentication setup breaking — receiving servers will start rejecting + downgrading reputation immediately.

The diagnostic test for reputation triage

When you suspect a problem, fire a one-off test to your own personal Gmail / Outlook / Yahoo accounts:

Sending server test send

Open each on its receiving side. Three outcomes:

  • All inbox → reputation OK; the original issue is content or list-quality, not transmission
  • Gmail spam / Outlook inbox → Gmail-specific reputation hit; check Google Postmaster Tools
  • All spam → systemic auth break; check DKIM/SPF/DMARC alignment

Acting on each signal

If you see... First action
Bounce rate jumps from 1% → 6% on one campaign List hygiene — bad import; run email verification, prune syntactic + role-account addresses
Complaint rate > 0.3% PAUSE the campaign. Audit consent. Send re-engagement BEFORE next send to this list.
Engagement drops 30% → 12% over 3 sends Send frequency too high. Cut cadence in half for 2 weeks; engagement recovers, reputation follows.
Inbox placement on test send: Gmail spam, Outlook inbox Gmail reputation hit specifically. Check Google Postmaster Tools (separate setup).
SPF / DKIM chip red mid-campaign DNS change broke alignment. Re-verify domain immediately.
Daily-quota exceeded errors Vendor cap hit. Either lower send rate or add a second sending server.

When to add a second sending server

Once you cross any of these thresholds, run on two servers minimum:

  • Sending more than 50k/day
  • Mixing marketing + transactional traffic
  • Operating in regulated industry (finance, healthcare) where outage costs > $1k/hr
  • Single vendor cost > $300/mo (free Postmark tier + paid SES is often cheaper)

See Configuring multiple sending servers for the setup walkthrough.

Advanced: postmaster-tool integrations + per-recipient reputation tracking

The campaign-level signals tell you the aggregate. The next layer is per-recipient-domain reputation, which AcelleMail doesn't surface natively but which postmaster tools expose.

Google Postmaster Tools (gmail.com / googlemail.com):

  1. Add your authenticated domain at https://postmaster.google.com
  2. Verify via TXT record (Google walks you through it)
  3. Within 24 hours you get dashboards for: Spam rate (real Gmail user complaints), IP reputation (High/Medium/Low/Bad), Domain reputation, Authentication results (SPF/DKIM/DMARC pass rates), Encryption (TLS adoption), Delivery errors

Daily check: spam rate. If it crosses 0.3% Google starts throttling silently. Fix immediately by pausing sends + auditing list.

See Gmail postmaster tools walkthrough for full setup.

Microsoft SNDS (outlook.com / hotmail.com / live.com):

  1. Sign up at https://sendersupport.olc.protection.outlook.com/snds/
  2. Add your sending IPs (one entry per IP)
  3. Get per-IP reputation (Red/Yellow/Green) + filter results + complaint rate

See Microsoft SNDS walkthrough for full setup.

Yahoo / AOL — historically had postmaster tools, mostly retired. Best signal is bounce + complaint rates from AcelleMail.

Per-recipient-domain rejection mining — for advanced ops, aggregate the bounce log by recipient domain:

# From your DB host:
mysql -e "
  SELECT
    SUBSTRING_INDEX(email, '@', -1) AS domain,
    COUNT(*) AS bounces,
    SUM(CASE WHEN bounce_type = 'hard' THEN 1 ELSE 0 END) AS hard
  FROM bounce_logs
  WHERE created_at >= NOW() - INTERVAL 30 DAY
  GROUP BY domain
  ORDER BY bounces DESC
  LIMIT 25
" your_database

If one domain (e.g. yahoo.com) accounts for 60% of bounces while contributing only 8% of your list, you have a Yahoo-specific reputation hit. Pause sending to that domain, work the reputation recovery (lower volume, higher-engagement-segment-first, monitor SNDS / Y!Mail postmaster signals).

Programmatic alerting — wire AcelleMail's campaign.bounce_rate_spike webhook (configurable threshold) to Slack:

[POST to your webhook URL]
{
  "campaign_uid": "...",
  "bounce_rate": 0.062,
  "threshold": 0.04,
  "exceeded_at": "2026-05-20T14:30:00Z"
}

Your bridge service formats + pings the on-call channel. Catches problems 6-12 hours before customers notice missing emails.

Reputation recovery cycle — when you've taken a hit:

Day 0:  Pause all bulk sending. Send ONLY to engaged-last-7d segment (highest open rate).
Day 7:  If engagement-segment sends stayed clean, expand to engaged-last-30d.
Day 14: Expand to engaged-last-90d. Monitor SNDS / Postmaster daily.
Day 30: Resume normal segment if reputation back to green/healthy.

The slope of recovery depends on volume + complaint severity. Mild reputation dips recover in 1-2 weeks; severe (>1% complaint) takes 4-6 weeks or never (sometimes you need a fresh IP + domain).

Related articles

19 comentarios

8 comentarios

  1. femi.adeyemi
    For very low-volume senders (< 5k/month), does warmup even matter? Or just send and let the provider's shared pool absorb the trickle?
    1. admin
      Yes, that pattern is supported. The undocumented bit is the order — config:cache MUST come after the migration, not before. Updating the docs to make that explicit
    2. admin (editado)
      We dont recommend that approach in production. It works in dev but has subtle race conditions under concurrent load. Stick with the documented pattern...
  2. lequan.saigon
    If you're warming a new IP after a known issue, consider seeding with transactional mail first (password resets, order confirmations). Higher engagement rate per send than marketing — helps the reputation ramp
  3. hung.nguyen.it
    Bookmarked. Going to share with the team — we've been winging warmup and it shows in the numbers.
    1. admin
      Glad it landed. Drop suggestions in the comments and we'll incorporate them on the nxt refresh.
  4. aisha.khan.pak
    confirming the postmaster tools data lag — sometimes 48 hours, sometimes longer. don't make decisions on a single day's data.
    1. admin (editado)
      Useful context. The fact that it took 3 weeks end-to-end is realistic; we sometimes get pushed to say 1-week timelines and theyre not honest.
    2. admin (editado)
      Great real-world detail. Your point about stale running_pid > 30 min as an alert is something we should add to the diagnostic flow.
  5. tranminh.devop…
    We hit a Spamhaus listing once. Self-service delisting was actually fast (< 24h) but the reputation recovery took weeks. Not the listing itself that hurt — the user complaints that caused it.
    1. admin (editado)
      Useful field report. The 'kill -9 was the only fix' edge case is rare but real — we'll note it as a fallback... :)
  6. sobrien.kw
    This is the clearest IP warmup schedule I've found. The volume table at the top is what I'm referncing daily.
    1. admin (editado)
      Thanks. Pass it along if it helps your team.
  7. ravi.kumar.del…
    Does engagement-based segmentation help during warmup? E.g. only sending to the most-engaged 20% during week 1?
    1. admin
      Good question. The campaign:rerun audit writes to laravel.log only when the audit decides to force-resume — pure noop runs are silent. We'll add an info-level heartbeat in a future Acelle release to make it easier to monitor.
    2. admin (editado)
      Suppression list import via CSV captures all opt-outs including preference-center ones if you exorted with the right field set. The export filter defaults exclude some — check the 'include unsubscribed' checkbox on Mailchimp's export wizard
    3. admin (editado)
      right — for RDS specifically, you can change wait_timeout via the parameter group without a reboot if its set as 'dynamic'. Most defaults are
    4. admin (editado)
      For your specific case, I'd recommend testing with `--dry-run` first. The behavior under high load isn't 100% deterministic and we want you to see your own pattern before committing.
  8. rafa.silva.br
    We warmed up a dedicated IP last fall. The 2-week ramp this article describes is on the aggressive side — Gmail in particular punishes anything faster than ~3-4 weeks. We did 4 weeks and had a clean ramp

More in Sending & Deliverability