Acceptable Spam Complaint Rates

We commonly receive inquiries from prospective customers and existing clients asking to provide more specific information about our tolerance for spam complaints. One reason this question comes up is because the SocketLabs Acceptable Use Policy states:

Your email must not generate excessive complaints as determined by the sole discretion of SocketLabs.

This ambiguity in our policy is by design. Spam complaints are only a single point of measurement about a stream of email messages. A full analysis of the messages including looking at type (marketing vs. transactional vs. person-to-person), content, volume, failure rate, engagement rate (opens and clicks), and other factors are required to determine what we find acceptable.

To provide more insights we can look at a few different metrics and statistics from our platform and apply insights from mailbox providers.

Mailbox providers like Gmail, Yahoo, Hotmail, and AOL all give senders an amount of leeway with complaints. Talking to providers we commonly hear that they acknowledge a false-positive report rate of 3 complaints per 10,000 messages delivered to the inbox. This translates to a 0.03% complaint rate being deemed acceptable to allow for false-positives. Any complaints at a rate above that will begin to negatively impact your sender reputation, which in turn affects your inbox placement with that mailbox provider, as each mailbox provider keeps track of complaints separately.

Each mailbox provider reacts differently when complaint rates increase beyond 0.03%. Yahoo and AOL are famous for delaying (deferring) messages by issuing temporary SMTP errors. Google and Microsoft react in a less noticeable manner and start filtering more messages to junk.

For many senders a complaint rate of 3 per 10,000 or less should be easily obtained. Looking across aggregated customer data over the last two weeks most customers fall well under this number. Over 80% of customers who’ve sent more than 1,000 messages in the last 30 days have spam complaint rates under 0.03%. In fact, across the last one billion messages processed via our platform we have a complaint rate of 0.0296%.

There are a few things that are important to note that are different between the SocketLabs calculated complaint rates and those calculated by individual mailbox providers. Messages sent to mailbox providers that do not support feedback loops are counted in the SocketLabs complaint rate. For example, GMail does not return recipient specific feedback loops. This means that if half of your list is GMail and the other half is mixed between Yahoo and Hotmail, the SocketLabs calculated complaint rate will be skewed lower by about 50%. A total complaint rate of 0.05% as calculated by SocketLabs in this case would mean Yahoo and Hotmail likely saw about 0.1% of recipients complain.

The other important factor to note is that messages filtered immediately to the spam folder cannot be marked as spam by the recipient. That means if 100% of your mail gets filtered to the spam folder, you will have a 0% complaint rate. This conundrum is summarized best by Laura Atkins from WordToTheWise - “Bad senders who do not get email to the inbox have very low complaint rates.”


Complaint Rates

Putting all this together we can make some general recommendations. We suggest that you try and keep your SocketLabs calculated spam complaint rates below 0.1% or 1 complaint per 1000 total messages sent. The likelihood that our Compliance team will reach out or take action with your account significantly increases as your rates increases beyond 0.1%.

Monitoring your complaint rate is key for ensuring that your messages retain high inbox placement. The complaint rate is also a major factor of the SocketLabs Stream Score. Changes to the complaint rate and stream score may be something to talk about more in-depth with our team of email experts.

If you have concerns about changes to the complaint rate within your SocketLabs account please reach out to our support team immediately for assistance in diagnosing and triaging the issue.