---
title: Feedback Loops
path: concepts/feedback-loops
status: published
---

# Feedback Loops

When a recipient marks your email as spam in Gmail, Yahoo, Outlook, or AOL, those providers don't tell you directly — they use feedback loops (FBLs). An FBL is an out-of-band mechanism where ISPs forward spam complaints back to senders registered with them. ScaiSend processes these reports automatically.

## What an FBL report looks like

An FBL report is an email. Specifically, it's a multi-part MIME message conforming to the Abuse Reporting Format ([ARF, RFC 5965](https://datatracker.ietf.org/doc/html/rfc5965)). When a recipient hits "Report spam" in their webmail UI, the ISP generates an ARF message and sends it to a pre-registered abuse address at your sending domain.

The ARF message has three parts:

1. **Human-readable text** describing the complaint.
2. **`message/feedback-report`** — machine-readable fields: `Feedback-Type: abuse`, `User-Agent: ...`, `Reported-Domain: ...`, etc.
3. **`message/rfc822` (the original message)** — the message the user complained about, embedded for correlation.

## How ScaiSend processes them

The inbound SMTP server (port 25) accepts ARF messages the same way it accepts DSNs. The parser:

1. Detects the ARF structure (multipart with `Feedback-Type`).
2. Extracts `Original-Rcpt-To` and the embedded original message.
3. Finds the message in ScaiSend's database by `Message-ID` or `X-ScaiSend-Message-Id`.
4. Records a `spam_report` event on that message.
5. Adds the recipient to the tenant's spam-reports suppression list.
6. Fans out a `spam_report` webhook.

That's it. No manual action required. The next send to that address is dropped with reason `suppressed_spam` (unless you bypass with `mail_settings.bypass_spam_management: {enable: true}`, which you should almost never do).

## Registering with ISPs

Not every provider offers public FBLs. The ones that do:

| Provider | Enrollment | Notes |
|----------|------------|-------|
| Gmail | "Spam Feedback Report" via Google Postmaster Tools | Limited; mostly aggregate, not per-complaint |
| Yahoo | [Yahoo Sender Hub](https://senders.yahooinc.com/) | Free; automatic for senders meeting reputation thresholds |
| Microsoft (Outlook, Hotmail) | [JMRP (Junk Mail Reporting Partner Program)](https://sendersupport.olc.protection.outlook.com/snds/JMRP.aspx) | Required enrollment; free |
| AOL | [Postmaster](https://postmaster.aol.com/feedback-loops) | Legacy; AOL has largely merged with Yahoo |

Enrollment typically requires:

- A dedicated abuse address (`abuse@yoursendingdomain.com`).
- Proof of control of the sending domain.
- A publicly accessible website for the domain.

Once enrolled, the ISP sends FBLs for your domain to the registered address. Point that address at your ScaiSend inbound SMTP server — the same server that handles DSNs.

### Example: routing abuse@ to ScaiSend

At your DNS provider, add:

```
abuse.mail.example.com MX 10 scaisend.example.com
```

Then enroll `abuse@mail.example.com` with each provider. Their FBLs will flow to your ScaiSend inbound server, which processes them.

You can also accept FBL reports at a completely different hostname — ISPs don't care which hostname handles `abuse@`, just that it can receive mail.

## Gmail's approach

Gmail doesn't offer per-complaint FBLs for most senders. Instead, they provide aggregate data through [Postmaster Tools](https://postmaster.google.com/):

- Spam rate over time.
- Reputation breakdown.
- Authentication results.

If your spam rate climbs above 0.1% (Gmail's threshold), you'll start seeing deliverability problems — your mail lands in Spam folders, gets delayed, or is outright blocked. Postmaster Tools is where you notice this.

## Interpreting spam complaints

A spam complaint is a strong signal. It means the recipient either:

- Didn't remember signing up (common in B2B marketing).
- Can't find your unsubscribe link (always have one; make it obvious).
- Is annoyed by volume or frequency.
- Genuinely thinks it's spam (typo'd address, forwarded mail they don't recognize).

A healthy complaint rate is **below 0.1%** — one complaint per thousand deliveries. Above 0.3% and ISPs will actively punish you.

To keep it low:

- **Honor unsubscribes immediately.** A recipient who unsubscribed but still receives mail tomorrow will hit "spam" out of frustration.
- **Make unsubscribing easy.** One click, no login. Use subscription tracking with RFC 8058 one-click.
- **Don't send to addresses you can't explain.** If you can't say where the address came from and when the person consented, don't send.
- **Segment.** Recipients who haven't opened in six months are candidates for a sunset flow, not another campaign.

## When an address should be resurrected

Occasionally a legitimate recipient hits "spam" by accident. You can remove them from the suppression list:

```bash
curl -X DELETE https://scaisend.scailabs.ai/v3/suppression/spam_reports/user@example.com \
  -H "Authorization: Bearer $SCAISEND_API_KEY"
```

Do this **only with explicit confirmation from the recipient**. Removing suppressions without consent is the fastest way to a large-scale deliverability failure — the FBL will fire again, the address will be re-suppressed, and your ISP reputation will be worse.

## Monitoring

```bash
# New spam reports in the last week
curl "https://scaisend.scailabs.ai/v3/suppression/spam_reports?start_time=$(date -d '1 week ago' +%s)" \
  -H "Authorization: Bearer $SCAISEND_API_KEY"
```

Or check daily stats:

```bash
curl "https://scaisend.scailabs.ai/v3/stats?start_date=2026-04-01" \
  -H "Authorization: Bearer $SCAISEND_API_KEY"
```

Alert if `spam_reports / delivered` exceeds 0.1%. Investigate the same day. Waiting a week is enough time to damage your reputation materially.

## Related

- [Suppressions](suppressions) — the spam-report list and how to manage it.
- [Bounce Handling](bounce-handling) — DSN processing (same inbound server path).
- [Events and Webhooks](events-and-webhooks) — receiving `spam_report` events.