Feedback loops at major mailbox providers: how to read spam complaints
What a feedback loop is and where spam complaints come from
A feedback loop is a return channel between a mailbox provider and a sender. A recipient clicks “this is spam”, and you get a separate message about it. The complaint usually arrives as an ARF report, sent to an address you registered with the provider beforehand. But not every major provider shares data per message. Some only offer aggregated reputation metrics for your domain and IP address, without pointing to a specific send.
People mix up two signals all the time. Clicking “spam” and unsubscribing through the footer link are not the same thing. For a filter, the difference is fundamental: the first hurts the sender’s reputation, the second is neutral. Complaints apply to mail sent from your domains whether you send from your own servers or use a provider’s fleet. The domain collects the complaints, not the machine.
Signing up for a feedback loop: what to prepare before you apply
There is one hard prerequisite: authentication has to work before you submit your application. Without it, applications get rejected automatically.
- SPF covering every IP address that actually sends your mail.
- DKIM with your domain in the d= field, not the provider’s domain.
- DMARC with a published policy and an address for aggregate reports.
- Return-Path under your control - providers use it to match complaints to the sender.
- PTR for the IP address matching the hostname in EHLO, resolvable both ways.
- A dedicated mailbox for reports, on the same domain you send from, not a general company contact.
- An up-to-date abuse contact in the domain whois and in the IP address registry.
For the application itself, prepare: a list of domains, IP addresses or whole ranges, DKIM selectors, and the address for receiving reports. Authentication setup and separate sending domains are handled by the sending platform’s built-in features, so you don’t have to put it together by hand on a server.
Tip: register every DKIM selector you use, including those from transactional subdomains. A missed selector means reports that will never reach you. It’s an easy mistake to make.
Anatomy of an ARF report: which fields actually tell you something
A report has three parts: a short text description, a message/feedback-report block with metadata, and a copy of the original message. All the value sits in the middle block and in the headers of the copy. The rest is packaging.
Fields to read first
Feedback-Type tells you the kind of report: a spam complaint is different from a technical report or an abuse report. Original-Mail-From, Reported-Domain and Source-IP point to the server and sending domain that got the complaint. With a fleet of several IP addresses, this is the only way to pin the problem to a machine.
Arrival-Date compared with the send date gives you the time gap. And that is genuinely useful. A complaint after two minutes says something about the subject line and the sender. A complaint after a week points more to frequency or a forgotten signup.
What the report will be missing
The recipient address is often masked or removed entirely. That’s why you add the campaign and subscriber ID yourself, in your own X- header on the outgoing message. Without it, you’re left with a report you can’t tie to a specific send. In other words, with nothing.
From report to decision: automatic unsubscribe and triage
The first response is always the same: the address comes off the list immediately, with no questions and no confirmation email. Sending again to someone who reported spam costs you reputation and is a legal problem, because consent has effectively been withdrawn.
- Remove the address from the list, permanently and without confirmation.
- Flag the campaign and the template the message was sent from.
- Check where the address came from: a form, an import, an integration.
- Compare the result with nearby sends to the same segment.
- Hold the next round until you’ve found the cause.
Group complaints by campaign, template, address source and segment. Only that breakdown shows the cause. A spike after a single send usually means the content, the subject line or the sender name. A steady background of complaints means a problem with the list. And there’s no point fooling yourself here, because lists don’t fix themselves. If addresses come in from an external store, CRM or form, check which integrations with address-collecting systems you have connected - that’s usually where the complaints start.
Tip: keep complaints, hard bounces and engagement signals together in one view. A single metric never explains the whole picture.
What a feedback loop won’t show and how to fill the gaps
A filter can put a message in spam without any action from the recipient. In that case there’s no complaint at all, and the send is lost anyway. Major providers define the acceptable complaint threshold differently and don’t publish it as a hard rule, so planning “to the limit” is guesswork. Neat guesswork, but guesswork.
Supplement ARF reports with DMARC aggregate reports and sender reputation dashboards wherever the provider offers them. Seed mailboxes and inbox placement monitoring show what complaints won’t - just remember it’s a sample, not a measurement of your whole list. Read soft and hard bounces together with complaints. The same campaigns usually light up in both places at once.
To be honest: part of our work on more detailed complaint reporting in the dashboard is still ahead of us. What I describe here is industry practice and how we run sending ourselves, not a ready-made screen to click through.
Getting out of a block: what we do when complaints grow
A block at a major filter usually doesn’t start with the whole infrastructure, but with a single IP address and a single customer.
The first step is to stop the source, not to write to the provider. A delisting request without fixing the cause gets you nothing but wasted time. It’s a rule worth sticking to. Then you split the traffic: transactional and marketing on separate IP addresses and subdomains, so one campaign can’t sink your system notifications. You come back through warm-up - smaller volumes, the most active recipients, and growth only once the metrics settle.
The rule we stick to: customers with a list of unknown origin don’t send from our infrastructure. Because nothing we do on our side bypasses filters. It only reduces the number of reasons a filter has to stop you.
Consent and the law: complaints as a sign of a list problem
A high number of complaints usually means one thing: the recipient doesn’t remember signing up, or never signed up at all. GDPR requires you to prove consent, and that means specific data - the date, the consent wording, the signup IP address, the form source. An export of addresses on its own proves nothing.
The Polish Electronic Communications Law, Article 398, also covers business addresses. In B2B, consent is required just as it is when sending to consumers. For many companies with inherited lists, that comes as a big surprise. A visible unsubscribe link in every message really does lower complaints, because it gives the recipient an easier way out than the “spam” button.
A common source of complaints is lists carried over from a previous tool and purchased addresses. If you want to pair this with a solid technical foundation, see how GDPR-compliant sending on own infrastructure works.
Summary: a routine instead of reacting after the fact
A feedback loop only works when reports feed into a process, not into a mailbox nobody checks. The minimum routine looks like this: receive reports, unsubscribe the address immediately, assign the complaint to a campaign, and do an aggregate review once a week. Set up authentication and clean up your list before you register for a feedback loop, not after the first block. And one last thing worth remembering: complaints measure how you collect addresses first, and only then how you write your emails.
