Данный инструмент тоже пригодиться - https://seolik.ru/dkim

Ох уж этот DKIM, в первый раз возни столько же, сколько с сертификатом для домена.
Накатил opendkim и его утилиты opendkim-tools. Покрасноглазил в терминале, вписал TXT-запись в DNS домена...
И таки да, теперь вижу у своей рассылки "отправитель письма подтверждён".

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

согласен. Но лучше одни раз нормально сделать, и дело в сторону.

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

Как исправить ошибку SPF
Данные отправителя скорее всего подделаны.

Начал делать с чего попроще, начал с SPF (Sender Policy Framework).
SPF - способ проверки подлинности писем, когда домену назначается запись обозначающая "почта этого домена на этом сервере".

Регистратор домена перекладывал это на себя. Мне нужно только для своего сервера, почтой от регистратора домена пользоваться не буду, поэтому - имевшуюся запись удалил.


На свой сервер назначил такой TXT-записью в NS домена.


Одна строка в настройке домена. Попить чаю пока DNS домена обновятся. Тестирование. Проблема решена.
Просто понять теорию и просто реализовать на практике. ;)

Домен из обратной DNS-зоны не соответствует домену отправителя
Из коробки, хостеры обычно дают какой-нибудь домен третьего уровня вместе с VDS. Нельзя сказать, что это плохо, какой-никакой, а домен. Но есть нюанс - именно этот домен занимает обратную зону DNS. Вот и причина ошибки...

Ваш IP адрес 123.123.123.123 связан с доменом бесплатный-домен-от-хостера-123-123-123-123.хостер.ru
Однако Ваше сообщение будет отображаться как отправленное с site.ru

Чтобы решить эту проблему - нужно именить PTR запись.

Как изменить PTR запись
С одной стороны - легко и просто. С другой - иногда невозможно. Повлиять на неё может владелец IP адреса, то есть - хостер.
Это настраивается в панели у хостера. Не в панели вашего сервера (на моём сервере вообще нет панели), а в панели управления вашими серверами у хостера.

В общем, в биллинге хостера, что-то такое:
1.) открываете список ваших серверов
2.) выбираете сервер, который будете настраивать
3.) выбираете в меню ip (скорее всего это там же, где можно докупать ip)
4.) меняете host напротив ip (было бесплатный-домен-от-хостера-123-123-123-123.хостер.ru стало site.ru)

Чтобы не тратить попытку проверки (сервис из шапки даёт бесплатно 3 попытки в сутки), вступление в силу можно проверить сторонним сервисом или выполнить в терминале команду:

В выхлопе должно появиться примерно такое:

Если видите свой домен, а не бесплатный хостерский - изменения вступили в силу.

Важное примечание: один ip - один домен (нельзя назначить несколько доменов одному ip). Если нужно несколько доменов - придётся докупить ip и тратить деньги, а ещё при смене ip домена могут отвалиться HTTPS-сертификаты.

DKIM подпись не действительна
Если проверка показывает жёлтым -1 балл (по тому что подпись появилась, но DNS ещё не успели обновиться), а после обновления страницы (с этим же результатом теста) вы в том же результате видите красным -3 балла (по тому что подпись нихрена не совпадает)...

Яндекс-почта в таких случаях ругается "письмо изменено после отправки".

Это ещё не значит, что вы накосячили именно с подписью! Проблема может быть совсем не в подписи!

Победил нюанс быстро, но выявлял причину очень-очень долго.

Итак, если в письме есть строки (в программном смысле) длиннее некоторого количества символов, почтовый сервер рубит их на части. Таким образом, происходит вот что:
- письмо подписывается
- письмо передаётся на отправку
- сервер отправитель рубит длинные строки на части
- письмо приходит не соответствуя подписи

Ну сами подумайте, будет ли внимательный пользователь рад "возможно поддельному" письму с паролем или ссылкой?

Решается проблема простым костылём - напихать разрывов строки после тэгов. Визуально это никак не отразится на письме, только на его исходном коде. Разрывы как в винде, то есть \r\n (возврат каретки и конец строки).

У меня это примерно так. Не смотрите, что на скриншоте мало текста, это шаблон с подстановкой длинных абзацев через переменные.

Домен не зашифровал это сообщение
Читая раздел "помощь" у яндекс и гугл почты, так и не вкурил, как шифровать-то. Может быть я тупой (скорее не компетентный) и фирменная помощь не помогла понять причину проблемы.

Как оказалось, нужно было просто включить в программе-отправителе (в моём случае Postfix) использование отправки по зашифрованному каналу.

В файл

Добавить этого (последняя строка, скорее всего, уже есть там)


Перезапустить Postfix


И теперь, для отправленных писем в почте яндекса и гугла будем видеть желаемое "шифрование: да".

Замечание модератора: Эта тема была закрыта автоматически ввиду отсутствия активности в ней на протяжении 100+ дней. Если Вы считаете ее актуальной и хотите оставить сообщение, то воспользуйтесь кнопкой или обратитесь к любому из модераторов.