Following CAN SPAM isn't enough to reach the inbox

One of the top entries on the list of things deliverability folks hear all the time is, “But my mail is all CAN SPAM compliant!” The thing is… no one handling inbound mail really cares. Seriously. CAN SPAM is a law that is little more than don’t lie, don’t hide, and heed the no. Even more importantly, the law itself states that there is no obligation for ISPs to deliver CAN SPAM compliant mail.

15 U.S.C. § 7707(8)(c)
NO EFFECT ON POLICIES OF PROVIDERS OF INTERNET ACCESS SERVICE.—Nothing in this Act shall be construed to have any effect on the lawfulness or unlawfulness, under any other provision of law, of the adoption, implementation, or enforcement by a provider of Internet access service of a policy of declining to transmit, route, relay, handle, or store certain types of electronic mail messages.

Many companies do list on their postmaster pages that they expect senders to comply with the law. (AOL, Yahoo, Microsoft). But just because email complies with CAN SPAM doesn’t mean it will be accepted or delivered.
Complying with the law is the bare minimum. And the way CAN SPAM is written it’s such a low bar it may as well be lying on the ground. Everyone sending unsolicited mail should be complying with CAN SPAM. But don’t expect the compliance to win you a path to the inbox. That’s just not how it works.

Related Posts

Thinking about deliverability

I was chatting with folks over on one of the email slack channels today. The discussion was about an ESP not wanting to implement a particular change as it would hurt deliverability. It led me down a path of thinking about how we think of deliverability and how that informs how we approach email.
The biggest problem I see is the black and white thinking.
There’s an underlying belief in the deliverability, receiving, and filtering communities  that the only way to affect sending behavior is to block (or threaten to block) mail.

This was true back in the ancient times (the late 90’s). We didn’t have sophisticated tools and fast CPUs. There weren’t a lot of ways to handle bad mail other than to block. Now the landscape is different. We have many more tools and the computing capacity to quickly sort large streams of data.
At most places these days, blocking is an escalation, not a warning shot. Many places rate limit and bulk folder questionable mail as a first strike against problem mail. Sometimes the mail is bad enough to result in a block. Other times, it’s not bad enough to block, so it disappears into the bulk folder.
There’s a corresponding belief in the sending community that if their behavior doesn’t result in blocking then they’re acting acceptably. This isn’t true either. There are a lot of things you can do (or not do) that don’t help delivery, but will actively harm delivery. Likewise, there are things you can do that don’t actively harm delivery, but will help. All of these things add up to reaching the inbox.

Read More

Oh, Microsoft

Things have been a little unsettled at Microsoft webmail properties over the last few months. A number of ESPs reported significantly increased deferrals from Microsoft properties starting sometime late in November. Others saw reduced open rates across their customer base starting in late October. More recently, people are noticing higher complaint rates as well as an increase in mail being dropped on the floor. Additionally, Return Path announced certification changes at the end of November lowering the Microsoft overall complaint rate to 0.2%, half of what is was previously.

Overall, sending mail to Microsoft is a challenge lately. This is all correlated with visible changes which may seem unrelated to deliverability, but actually are. What are the changes we know about?

Read More

Still with the Microsoft problems

We took a quick trip to Dublin last week. I had every intention of blogging while on the trip, but… oops. I did get to meet with some clients, and had a great dinner while discussing email and delivery.

Coming back, I see a lot of folks still reporting delivery problems to Microsoft properties. I’ve been operating under the assumption this was temporary as kinks were worked out after the migration. I’m still pretty convinced not all of the problems are intentional. Even the best tested code can have issues that only show up under real load with real users. Reading between-some-lines tells me that the tech team is hard at work identifying and fixing issues. There will be changes and things will continue to improve.
With all that being said, I think it’s important to realize that delivering to the new system is not the same as delivering to the old system. This is a major overhaul of their email handling code, representing multiple years worth of planning and development inside Microsoft. It’s very likely that not all of the current delivery problems are the result of deployment. Some of the problems are likely a result of new standards and thresholds for reaching the inbox. What worked a year ago to get into the inbox just doesn’t any more.

Read More