Всё происходит как обычно, приходишь на работу и получаешь очень интересную задачу. КПДВ будет немного не в тему, но и непонятно к кому обращаться, кроме как к Санте на Серверный полюс.

Все естественно помнят, что существуют базовые проверки почты:

• SPF "Sender Policy Framework" (фреймворк политики отправителя) - это метод проверки электронной почты, который позволяет проверять, действительно ли отправитель имеет право отправлять электронные письма от имени определенного домена.

• DKIM "DomainKeys Identified Mail" (идентификация почты с помощью домена) - это метод проверки электронной почты, который используется для подтверждения подлинности сообщений, отправленных с определенного домена.

• DMARC "Domain-based Message Authentication, Reporting and Conformance" (доменная аутентификация сообщений, отчетность и соответствие) - это метод проверки электронной почты, который позволяет проверять, соответствуют ли SPF и DKIM домену отправителя, и определяет, что делать с сообщениями, которые не соответствуют этим проверкам.

При правильной настройке можно гарантировать, что отправитель является именно тем, кем представляется. Но сегодня столкнулись с массовой недоставкой писем с данного сервиса нашим пользователям.

У нас настроена проверка SPF записи и уведомление отправителя о том, что с его SPF что-то не так. Внешние отправители с@mail.ru начали получать такие уведомления:
550 5.7.0 SPF record Permerror. Check your spf record

Беглый анализ показал, что за прошедшие сутки в карантин попало ~500 писем только с@mail.ruи эта цифра не включает bk.ru, list.ru, inbox.ru и компании, расместившие свою почту в данном сервисе. Первое письмо, попавшее в карантин датируется 29.05.2023 в 19:46 МСК

Казалось бы, проблема очевидна, измени SPF запись и всё будет хорошо, но почему-то уже более 12 часов никакой реации от сервиса нет. Ах да, чтобы все поняли в чём вопрос, текущая SPF запись выглядит так:

v=spf1 ip4:94.100.176.0/20 ip4:217.69.128.0/20 ip4:128.140.168.0/21 ip4:188.93.58.0/24 ip4:195.211.128.0/22 ip4:188.93.59.0/24 ip4:188.93.56.0/24 ip4:128.140.170.0/24 ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5.61.237.0/26 ip4:5.61.237.128/25 ip4:5.61.236.0/24 ip4:5.61.239.143/32 ip4:5.61.239.144/32 ip4:95.163.216.38/31 ip4:95.163.40.8/29 ip4:45.84.128.0/23 ip4:45.84.131.224/27 ip4:45.84.130.128/25 ip4:79.137.243.64/27 ip4:79.137.242.48/28 ip4:95.163.41.64/26 ip4:79.137.241.236/30 ip4:79.137.243.128/26 ip4:95.163.54.128/26 ip:176.112.170.128/27 ~all

Ошибка закралась в последний IP range: ip:176.112.170.128/27. RFC 7206 пункт 5.6 предполагает, что в случае указания ip диапазонов они должны выглядеть как ip4: или ip6:

Ждёмс реакции... 30.05.2023 12:15 МСК - проблема решена.