Google банит почту. Ошибка 421-4.7.28

Google банит почту. Ошибка 421-4.7.28

Ошибка в логе:

said: 421-4.7.28 [111.111.111.111 15] Our system has detected an unusual rate of 421-4.7.28 unsolicited mail originating from your IP address. To protect our 421-4.7.28 users from spam, mail sent from your IP address has been temporarily 421-4.7.28 rate limited. Please visit 421-4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to 421 4.7.28 review our Bulk Email Senders Guidelines. y20si3483860eds.419 - gsmtp (in reply to end of DATA command))

Начинаю проверку тут — https://toolbox.googleapps.com/apps/checkmx/check

Потом тут — https://www.mail-tester.com. И здесь показало ошибки:

Проверка DMARC — dmarcian.com

[SPF] mail.my-domain.com.com не позволяет Вашему серверу 111.222.111.222 использовать SRS0=hH99=SB=my-domain.com=myname@mail.my-domain.com

и вторая:

We check if there is a mail server (MX Record) behind your domain name mail.my-domain.com.

You may want to publish a DNS record (MX type) for the domain name mail.my-domain.com or use a different bounce email address.

Результат теста был 6/10.

Можно ещё проверить тут какие записи видно - https://www.reg.ru/nettools/dig. Всё это можно проверить командой dig в командной строке сервера, но я сравнивал несколько доменов и было удобнее в браузере это делать через сервис.

Принялся устранять. Поменял spf запись, хоть она и была (раньше всё работало, проверки проходило).

Запись была вида:

"v=spf1 mx:mail.my-domain.com ip4:111.222.111.222 ~all"

Сменил на:

"v=spf1 a mx ip4:111.222.111.222 ~all"

Это не помогло. Значит дело скорее всего не в замой записи, а в том что она как-то неправильно прописана или расположена. Хотя через https://www.reg.ru/nettools/dig как spf, так и dig запись по почтовому домену было видно.

Нашёл разницу в записи доменного имени у регистратора. Оно было с www и была запись вида CNAME. При этом через команду dig @8.8.8.8 www.my-domain.com MX было два ответа (графа ANSWER) с именами почтовых серверов. Один вёл на ip адрес, где было основное доменное имя, а другой на почтовый сервер.

По команде nslookup -q=mx www.my-domain.com в секции Authoritative answers can be found from тоже было две ссылки на почтовые сервера по аналогии как в описано выше: два ip адреса, но один ведёт на домен my-domain.com, а другой уже на почтовый сервер mail.my-domain.com.

Путь выше был ложный. Главное, чтобы основной домен имел запись A, а не CNAME (такая рекомендация есть в мануале googgle).

Проверить, отдаёт ли домен TXT записи:

dig +short TXT my-domain.com

Решение

Найти причину удалось, разбирая заголовки письма (сделать это можно в любом почтовике скорее всего, найдя опцию «посмотреть полный текс письма», там и будут служебные заголовки). У меня бала возможность сравнить приходящие письма с аналогично настроенным по dns-записям сервером. На проблемном сервере в исходном тексте письма фигурировала такая часть «SRS0=hH99=SB=my-domain.com=myname@mail.my-domain.com«. На сервере, где проблемы не было, прежде всего не фигурировала часть типа «SRS0=hH99=SB». Это было связано с тем, что проблемном сервер я установил службу postsrsd. Она работала и даже принесла улучшения по пересылке почты на google, но оказалось, что она пересылала имя почтового домена вида mail.my-domain.com, от чего отправитель делался таким: user@mail.my-domain.com, а на самом деле это user@mail.my-domain.com (без mail).

Как это правится. В файле /etc/default/postsrsd (на debian) есть строка SRS_DOMAIN, где и автоматически у меня прописалась запись вида mail.my-domain.com. Я поменял её на my-domain.com, перезапустил сервис и проблемы с SPF записью решились, ровно как и с определением mx сервера.

 

 

Добавить комментарий