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). 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:

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:

1

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:

• 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:

1
2

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#

1
2
3

# 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:

1
2

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 — the spam-report list and how to manage it.
• Bounce Handling — DSN processing (same inbound server path).
• Events and Webhooks — receiving spam_report events.