Spam complaints
A complaint is never answered automatically. The intent is hard-escalated to a person whatever the autonomy setting says, and the address usually ends up on the sending provider's suppression list, which refuses it thereafter. Separately, the provider's own complaint rate feeds a reputation state that can hold or stop outreach entirely.
Two different things called a complaint#
- A person complaining to you
- A message whose intent is a grievance — a failed deployment, a refund, a dispute. Escalated to a human, never answered on its own.
- A spam complaint
- Someone pressing the report button in their mail client. It goes to the provider through a feedback loop rather than to your inbox, and its effect is on the address and on the sending reputation.
They are handled by different parts of the system and this page covers both, because in practice the same afternoon produces one of each and the response to them is not the same.
A grievance is escalated, not answered#
The classifier is told to mark anything legal, contractual, a complaint about an existing deployment, a refund or payment dispute, or a data-protection question. Two intents — complaint and legal — are then hard-escalated in code: whatever the workspace's autonomy is set to, these do not receive an autonomous reply. A workspace can add its own intents to the always-review list; it cannot remove these.
A draft may still be written. What changes is that it is held for a person with the reason stated, so somebody reads the words before a customer does. The escalation reason travels with it — see Held drafts for how a hold is presented and Needs You for where it queues.
What a spam complaint changes#
| Effect | Where it lands | What Connect does with it |
|---|---|---|
| The address is suppressed | The sending provider's account-level list. | The compliance check reads it back before a live outreach send and refuses a suppressed destination. |
| The complaint rate rises | The provider's own reputation metrics. | Read from the metric series rather than guessed at, and turned into a reputation state. |
| Enforcement changes | The provider's account status. | Anything other than healthy makes the state red, which stops outreach. |
| A feedback notice arrives | Sometimes, in a mailbox. | Visible as diagnostics only. It never moves the reputation state on its own. |
That last row is a correction of an earlier design worth stating plainly. Reputation used to be inferred from mail that *looked* like a bounce or a complaint sitting in the inbox, which counted test messages and simulator traffic as though they were real. The authoritative source is the provider's own enforcement status and its published bounce and complaint rate metrics; local inbox signals are kept because they are useful when diagnosing, and they are given no authority at all.
The reputation governor#
The state has three values. Green is ordinary. Yellow means a rate has passed its warning threshold, the provider's status could not be verified, or a configured alarm is firing; a workspace can choose to hold live outreach while yellow, and by default it does. Red means a rate has passed its red threshold or the provider is no longer treating the account as healthy, and outreach stops.
Both thresholds are settings rather than constants, and the lookback window over the metrics is a setting too. What is not a setting is where the numbers come from: an unverifiable reputation is treated as yellow rather than assumed to be green, which is the same fail-closed rule the suppression check uses.
Customer replies are not governed by this. The gate applies to outreach, which is the traffic that earns complaints; answering somebody who wrote to you is a different path with different rules, set out in Outreach email versus a customer reply.
What to do about one#
- Read the escalated message yourself. It is in the queue precisely so that it is not answered by a machine.
- Leave the do-not-contact mark in place rather than clearing it to send an apology; an apology to someone who reported you as spam is another unwanted message.
- Look at what was being sent, not only at who complained — Deliverability covers the sending-side factors.
- If outreach has stopped, treat the reputation state as the message it is rather than as an obstacle to route around.
Nothing on this page is a promise about whether mail reaches an inbox. Reputation, authentication and content all matter, none of them is under Connect's sole control, and no configuration here entitles a business to delivery.
Questions#
Will Connect apologise automatically for a complaint?
No. Complaint and legal intents are escalated to a person in code, so a reply of any kind waits for somebody to read the message first.
Can I send to an address that complained?
Not through outreach: the compliance check refuses a suppressed destination, and where the suppression state cannot be verified a live send is refused rather than attempted.
Why did outreach stop when only one person complained?
A rate, not a count, drives the state — and on low volume a single complaint moves a rate a long way. That is a property of the metric rather than an overreaction by the gate.