Feedback Loops (FBL) — Setup + Wire in AcelleMail

When a recipient clicks "Mark as Spam" on a Microsoft / Yahoo / AOL / Comcast mailbox, those ISPs send you the complaint via Feedback Loop. AcelleMail processes it automatically — unsubscribes the complainer, updates the complaint stats. This guide walks the setup.

What FBL does for you

When a recipient on a major ISP (Microsoft, Yahoo, AOL, Comcast) clicks "Mark as Spam," the ISP sends a feedback message to you describing the complaint. AcelleMail's Feedback Loop handler:

  1. Receives + parses these messages from a dedicated address (e.g. feedback@yourdomain.com)
  2. Identifies the complaining subscriber + the original campaign
  3. Auto-unsubscribes them (prevents future sends)
  4. Updates the campaign's complaint rate stat
  5. (Optional) Webhook out to your CRM / Slack

Without FBL setup, you don't see these signals. Complaints pile up silently until your IP reputation drops.

Setup overview

[ISP side]                          [AcelleMail side]
1. Sign up for each ISP's FBL program
   → ISP needs an address to send to
2. Set up a `feedback@yourdomain` mailbox
                                     3. Configure FBL handler in sending server
                                     4. Test + verify

Phase 1: Sign up at each ISP

Microsoft (JMRP)

URL: https://sendersupport.olc.protection.outlook.com/pm/junkmail.aspx

Provide:

  • Each sending IP / IP range
  • Your contact + verification address (e.g. feedback@yourdomain.com)
  • Microsoft email account (free)

Approval: 24-48 hours.

Yahoo

URL: https://senders.yahooinc.com/

Sign up for the Yahoo Feedback Loop service. Provides per-IP complaint forwarding to your verification address.

AOL / Verizon

URL: https://postmaster.aol.com/

Similar process. Free.

Comcast / Xfinity

URL: https://postmaster.comcast.net/

Form-based application.

Apple iCloud / Yahoo Postmaster

iCloud doesn't have a public FBL program currently. The signals come via:

  • Bounce log patterns (5.7.x codes for spam-policy blocks)
  • iCloud's "Mail Privacy Protection" data via aggregate analytics

For iCloud, FBL isn't a setup task — accept that aggregate-level signals are all you get.

Phase 2: Set up the receiving mailbox

Create a regular mailbox at feedback@yourdomain.com (any name; convention is feedback@). This is where ISP-generated FBL messages arrive.

The mailbox needs:

  • IMAP or POP3 access (so AcelleMail can read it)
  • Always-accessible (don't delete messages immediately — AcelleMail polls and acts)

Configure at your usual mail host (Google Workspace, Microsoft 365, Mailtrap, anywhere with IMAP).

Phase 3: Configure AcelleMail's FBL handler

Open the sending-server detail

In AcelleMail's sidebar, click Sending → Sending servers. The list shows every server connected to this account with its status chip, sending limit, and last activity:

Customer sending-server list

Click into the row you want to configure. The detail page surfaces Connection settings (host / credentials), Configuration (server name, default from, sending limit, bounce + FBL handler), and the Test connection / Send test email buttons in the toolbar:

Server detail — Connection + Configuration

In the server detail's Configuration section (visible in the full-page server detail above), find the Feedback loop handler dropdown. The handlers themselves are managed as a reusable list at Admin → Sending → Feedback loop handlers:

Admin Feedback loop handlers list

Each handler is a named IMAP mailbox config — reusable across multiple sending servers. Define once, attach where needed. Click + New feedback loop handler to add a fresh one, OR edit the Default FBL Handler to point at your feedback@yourdomain.com IMAP credentials.

Back in the sending-server's Configuration field, the FBL handler dropdown lets you pick:

  • None — FBL processing disabled (default)
  • IMAP — AcelleMail polls an IMAP mailbox, parses FBL messages, processes them
  • POP3 — Same via POP3 protocol

Pick IMAP (most modern). The expanded form asks for:

IMAP server:    imap.gmail.com (or your provider)
Port:           993 (TLS)
Username:       feedback@yourdomain.com
Password:       app-specific password
Poll interval:  5 minutes

Save. AcelleMail starts polling the mailbox.

Phase 4: Verify it's working

Send yourself a test campaign. On a Microsoft / Yahoo account you control, click "Mark as Spam."

Wait 24-48 hours (FBL has delay). Then check:

  1. The feedback message arrived in feedback@yourdomain.com
  2. AcelleMail polled it (check the server's FBL processing log)
  3. Your test address is now marked unsubscribed in the original list
  4. Campaign feedback log shows the complaint:

Campaign feedback log

If steps 1-2 work but 3-4 don't: check AcelleMail's FBL parser is recognizing the ISP's specific FBL format. Some ISPs use ARF (Abuse Reporting Format); others have custom headers.

Common FBL signals + actions

Signal Action
Steady 0.05-0.1% complaint rate Healthy baseline; no action
Spike to 0.3% on one campaign Pause; audit content + list; investigate consent
Spike concentrated to one segment That segment's consent is unclear — audit signup flow
0 complaints (suspicious for any volume) FBL handler not working — check IMAP polling logs
Complaints from subscribers who never opted in Bot signups or imported list — audit acquisition
Yahoo complaints high, Microsoft normal Yahoo-specific list source issue; investigate Yahoo signups specifically

Common UI signals + fixes

Symptom Likely cause UI fix
FBL configured but unsubscribed count from FBL = 0 after a week Either FBL handler broken OR you're not sending to FBL-eligible ISPs Check IMAP credentials + recent campaign log
feedback@yourdomain mailbox grows but AcelleMail doesn't process IMAP polling broken or FBL message format unrecognized Re-check IMAP creds; check AcelleMail's FBL parser config
ISP sends bounce messages that look like FBL but get marked as bounces Bounce handler conflicting with FBL handler Use different mailboxes for each (bounce@ and feedback@)
Complaint rate looks too good (0% on high-volume sends) FBL probably not wired up or wired to wrong mailbox Check end-to-end with test send-and-complain
Complaints showing in AcelleMail but subscribers not auto-unsubscribed FBL handler set to log-only, not auto-action Server config → FBL → set "Auto-unsubscribe complainers"
Advanced: ARF parsing, multi-ISP routing, and complaint-rate-driven server disable

The Abuse Reporting Format (ARF) is RFC 5965 — the standard FBL message format. Microsoft, Yahoo, AOL use it. Others have custom formats.

ARF format key fields:

Message-ID: <...>
Feedback-Type: abuse
User-Agent: ARF/1.0
Reported-Domain: ...
Original-Mail-From: ...
Original-Rcpt-To: ...
Source-IP: ...
Reported-URI: ...

AcelleMail's parser identifies the Reported-Rcpt-To to find the subscriber, looks up the campaign via Original-Mail-From headers, and processes the complaint.

For non-ARF formats (some legacy AOL formats), AcelleMail has format-specific parsers. If a particular ISP's format isn't recognized, check the AcelleMail FBL parser config.

Multi-mailbox routing — if you have multiple sending servers, each can have its own FBL mailbox:

Server A:  feedback-a@yourdomain.com
Server B:  feedback-b@yourdomain.com

Each server's FBL handler points to its own mailbox. Allows per-server complaint-rate isolation in the panels.

Complaint-rate-driven server disable:

# Daily cron — disable any server with complaint rate >0.3% yesterday
for server in $SERVER_UIDS; do
  cr=$(curl -sH "Authorization: Bearer $TOKEN" \
    "https://acellemail.com/api/v1/admin/sending-servers/$server/stats?day=yesterday" \
    | jq '.complaint_rate')
  if (( $(echo "$cr > 0.003" | bc -l) )); then
    # Disable + alert
    curl -X POST -H "Authorization: Bearer $TOKEN" \
      -d "{\"server_uid\": \"$server\"}" \
      "https://acellemail.com/api/v1/admin/sending-servers/disable"
    notify_slack "Server $server auto-disabled — complaint rate $cr"
  fi
done

FBL message inspection — periodically open the feedback@ mailbox + read messages directly. Useful for:

  • Confirming ISPs are still sending FBL (drop = something broke)
  • Understanding WHY complaints happen (content, frequency, consent issues — sometimes in the FBL body)
  • Verifying complaining subscriber matches what AcelleMail processed

Suppression list export — after AcelleMail processes FBL complaints, the suppression list is the cumulative pool of all-time complainers + bounced + manually-suppressed.

curl -sH "Authorization: Bearer $TOKEN" \
  "https://acellemail.com/api/v1/admin/suppression?format=csv" \
  > suppression-snapshot-$(date +%Y%m%d).csv

Backup periodically. If you ever migrate AcelleMail installs, the suppression list MUST come too.

ISP-specific quirks:

  • Microsoft JMRP: also need SNDS for full picture
  • Yahoo: some delays; complaints can arrive 5-7 days after sending
  • AOL: very low volume; expect 5-20 complaints/month from large lists
  • Comcast/Xfinity: form-based; AcelleMail FBL parser handles it

Privacy / GDPR notes:

FBL messages contain the complaining subscriber's email. Treat them as personal data:

  • Don't share or export externally
  • Retain only as long as needed for unsubscribe + statistics
  • Honor GDPR right-to-erasure if the complainer later requests

Related articles

9 条评论

6 条评论

  1. sobrien.kw
    This is the clearest IP warmup schedule I've found. The volume table at the top is what I'm referencing daily.
  2. jmorrison.itop…
    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.
  3. linhvu.dev
    Does engagement-based segmentation help during warmup? E.g. only sending to the most-engaged 20% during week 1?
    1. admin
      honest answer: it depends on your provider. ses handles it gracefully; mailgun is stricter. well add a provider-by-provider table in the next revision.
  4. linhpm.devs
    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
    1. admin
      Good tip. The Cloudflare-outbound-rate-limit case is something we hadn't documented.
  5. i.rossi.mil
    We hit a Spamhaus listing once. Self-service delisting was actually fast (< 24h) but the reputation recovery took weks. Not the listing itself that hurt — the user complaints that caused it.
    1. admin
      Appreciate the data point. Your numbers align with what our larger-volume customers report; helpful to see a third confirmation.
  6. m.schmidt78
    Confirming the Postmaster Tools data lag — sometimes 48 hours, sometimes longer. Don't make decisions on a single day's data...

More in Sending & Deliverability