SendGrid Chinese is not a decree

Today I would like to tell you about a story related to using SendGrid . In the process of investigating the reasons, I had to talk with the support service, and the problem, in general, did not dare, but I continue to understand and hope that someone from the readers will offer a good solution to this problem. Well, and those who are just going to use systems that advertise themselves as transactional mail delivery ( transactional email - SendGrid, MailGun, Mandrill), I hope this post will help you understand what problems they help to solve and which not, and will give an understanding about the expediency of using such systems in principle.

Since last year, we have been developing and supporting one of the project management systems with a team of developers located in America, Australia, Bulgaria and Ukraine. SendGrid is used to send notifications. It is quite obvious what kind of notifications are sent by such a system — registration, confirmation of mail, password recovery — but basically they are notifications about system updates by other users — a new comment, a new task, etc. etc. I have to say that we had some experience with SendGrid. When adding the functionality of functional monitoring in Nerrvana, we began to use SendGrid, but the amount of mail sent by us is incommensurably less than that sent by the project management system, and therefore here we first encountered problems when using it.

The client is located in China, and, ironically, is the leading email marketing company. Domain .asia Twenty employees from this company are registered in our project management system. Some employees complained that they did not receive the notification. Then I got into the SendGrid interface and began my investigation.
It turned out that some users receive notifications, others do not. Unsent notifications SendGrid puts a mark “Drop” with the cause “Bounce”. It was very strange - how are these users different for the mail server of this domain from others? The concept of "Bounce" turned out to be new for me and I also decided to first understand what it means. If this is a generally accepted standard, understand it; if not, then read the meaning of SendGrid.

It turned out that “Bounce” means that the mail server accepted the mail, but could not deliver it. It remains to find out why these “Bounce” occur, and I contacted the support service of SendGrid asking why this happens and how the two types of Bounce differ, which I found on the sendgrid.com/logs/index page, playing with filters:
')


In response, I received a link to the documentation page - sendgrid.com/docs/Delivery_Metrics/index.html , and also learned that SendGrid divides Bounces into soft (soft) and hard (hard). I was also pointed to the sendgrid.com/bounces page, which I had not reached by that time. You can find it on it, when the address is in the Bounce list, and you can delete the addresses in this list. Here, for the first time, I thought that there should be an automatic way to do this, since it would be unrealistic for our volumes to look through the lists, analyze and clean them manually. I was told that SendGrid does not send all subsequent letters to addresses that are in such a list until we ourselves remove it from this list. “Gee!” - I thought in a non-literary form, and again wrote to the support service. There were a lot of questions - although, it would seem, SendGrid could also describe it in detail in the documentation. The lack of means, as it were, they should not be, according to CrunchBase .

In my opinion, it would be quite logical to say this in the activity log:
- this attempt to send to the addressee “bruce.lee@our_client_domain.asia” led to the answer “such and such” -> I put the address in the “Hard bounce” list
- this attempt to send to the addressee “bruce.lee@our_client_domain.asia” is ignored with the status “Drop”, since the address is already in the “Hard bounce” list. In order to view all attempts that were dropped and the primary response of the server, go to sendgrid.com/bounces/bruce.lee@our_client_domain.asia .

Then everything is simple and clear - you can see why, when and where everything has got and how much is already there. You can see how soft and hard bounce is indicated and as the interface shows the result of past hitting one of the bad lists. A link will appear between the activity log and the invalid, bounce, spam lists available on the Email Reports page. That is, in all cases there is a root cause and consequences. So show it humanly! The questions that I have, just will not appear in this case.

To prevent the mail from falling into the list, I was advised to add domains to the Address Whitelist application, available for our subscription level - Silver, but this is also not an option. Continue to send mail to the provider who added you to the black listed (black listed you) without clarifying the reasons for how the approach did not suit us.

Further it was even more interesting. In the reports I found the root cause - “550 Connection frequency limited”. From the client, I knew that their ESP is the largest ISP in China, QQ.com, and also that the client added our domain to the white list, and that did not help. The client threatened to go to Basecamp (which, of course, is unpleasant). Further, the client shared the information that QQ has a limit on the amount of mail received by each user. This explained why some users received mail from us and others did not. The client explained that QQ does not allow small ESPs (in this case, us) to send large amounts of mail to their users. There was a reasonable question - who is ESP in this case, we or SendGrid? It turned out that we, and this is completely our problem. QQ found, for example, that all senders (except those they consider large) can send no more than 10 letters per day to each user. Apparently, as soon as one of our users receives these normalized QQ-Kovka 10 letters from us, we get further [550 Connection frequency limited] a “little sabbat”, as Erast Fandorin's servant Mas would say, and wait for the new day in the Celestial to send another ten. In addition to this, we also fall into the SendGrid bounce list and the sending of mail to this user stops until we remove the address from this list (we know that we will go there regularly).

By the way, if you make a search for the string “550 Connection frequency limited” in Google, then you will immediately see that all the links either mention QQ.com, or are pages of QQ.com itself. That is a known problem. One would like to say - "I will recognize a nice gait, and QQ - by Connection frequency limited".



Why does SendGrid not know anything about it and not warn - “you guys send QQ mail, damn it, mean what ....”? Why SendGrid does not agree with QQ that for their (SendGrid-a) clients QQ accepts mail without restrictions, or at least assumes the role of an intermediary, being a major player in this market?

Further, a client from China advised us to forecast (?!) The amount of mail sent to all our clients serviced by QQ so as not to send many emails to the same users. How do you imagine that? I - no way. Or ask SendGrid for help, which we did.

SendGrid replied that, unfortunately, the QQ page is in Chinese (that is, they first learned from us about this problem, but they still don’t know about the existence of online translators). They also said that we ourselves need to contact QQ and send them our outgoing IP address, and ask them to remove restrictions on incoming emails from us. Another SendGrid offered to buy additional IP addresses for $ 20 a month in order to send part of the mail from them. “Good” solution, only what is the probability of blocking by IP from QQ (maybe they block by domain)? That was the end of it.

I wrote to QQ, but no one answered from there and nothing changed on their part. I added this client’s domain to the White list in SendGrid so that bounce errors do not add recipient mail to stop lists. As you understand, this did not solve the problem. We just try to send QQ users after receiving the “550 Connection frequency limited” in the hope that at least something will come when the QQ counter is reset for this user to zero.

It is this and other cases that led us to the decision to keep mail sending status for analysis and future automation of problem solving. It became clear that you need to collect information about the status of sent letters in your database, and then return to the issue of automating the solution of postal problems on your own.

What conclusions can be drawn from the situation described above:

1) Sendrgid does not protect you from blocking on the side of the user's mail server at all. If your customers complain that they are not receiving notifications, check to see if their ESP has restrictions like QQ.

2) Sendgrid employees do not know Chinese

3) When sending emails via Sendgrid, you must use the Event webhook , or regularly check your account in the service in order to respond quickly to placing your users on the Bounced list.