aaPanel: настройка почты и почтовых серверов Postfix, Dovecot, безопасное соединение TLS/SSL и сертификаты для получения/отправки email

[sitecreator]

Рассмотрим настройку почты на примере ОС Centos 7 (актуальна на данный момент Centos 7.9 ) и панели управления aaPanel версии 6.8.29 (6.8.35 или новее).

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

Спойлер: достаточно ли стандартных средств aapanel для работы почты?

Почти - это потому, что даже для единственного ящика не предусмотрено использование SSL сертификата с авто-продлением (надо не забывать его перевыпускать или копировать сертификат для аналогичного сайта/домена регулярно самостоятельно).
Если доменов много и много почтовых ящиков (@e-mail), то пользоваться встроенными (в панель управления сервера aaPanel ) средствами управления почтой (точнее, почтовыми серверами Postfix - для отправки, Dovecot - для приема почты) может быть неудобно и проблематично. Управление ящиками не работает идеально, есть принципиальные ошибки, которые не позволяют делать максимально гибкие и необходимые настройки. Позже я рассмотрю альтернативный вариант создания и управления почтовыми ящиками вместо средств панели aaPanel. В случае нестандартных настроек почты (с точки зрения aaPanel как оболочки, а не самих почтовых серверов) возможны баги в aaPanel, даже если вы задаете верные настройки, но они неведомы aaPanel, тогда настроить можно через альтернативные средства управления почтой.
Если подытожить коротко, то aaPanel предполагает только простые варианты настройки почтовых ящиков, хоть и в этом случае в плане безопасности будет все в порядке. Если у вас один домен и один ящик, то средств панели aaPanel для почты будет достаточно.

"Почтовый сервер" в aaPanel состоит из 3-х сервисов/серверов:

• Postfix (отправка почты)
• Dovecot (прием почты)
• Rspamd (фильтрация спама и подписание писем DKIM подписью)

Необходимо установить для начала СУБД Redis. Она необходима для работы Rspamd - системы фильтрации спама. Кроме того Rspamd используется для подписи DKIM исходящих писем.
Сам Postfix работает с sqlite при установке средствами aaPanel. Т.е. никаких серверов БД для самого Postfix в таком случае не требуется, т.к. по-сути sqlite использует обычные файлы. (Но Postfix может работать, например, с MySQL/MariaDB, но этот вариант мы не рассматриваем).

Итак, установите Redis через app/Software Store панели управления aaPanel. Задайте пароль для Redis. На этом установка Redis для работы почтовых серверов закончена.

В Centos 7 обычно уже установлен Postfix. Можно проверить его версию (если установлено) :

postconf -d mail_version

результат:

Версия Postfix довольно старая (2.10.1). aaPanel позволит установить из своего репозитория (для Centos 7) более свежую версию Postfix - это 3.4.7 на текущий момент.

Также можете узнать установленную (если установлено) версию Dovecot

dovecot --version

Если dovecot не установлен, то получите сообщение:

-bash: dovecot: command not found

В aaPanel перейдите в App Store, найдите Mail Server.
Делайте запуск (Install) установки Mail Server. В данном случае "Mail Server" не является каким-то почтовым сервером в прямом смысле слова. Это лишь оболочка для установки и управления:

• Postfix
• Dovecot
• Rspamd

После того, как в App Store обозначится Mail Server как уже установленный (можно определить по появлению ссылки для настройки "Setting"), нужно нажать на Setting для окончания установки.

Вы увидите список компонентов, для которых в графе "Details" должно быть указано состояние "Ready" (т.е. "готов" зеленым цветом). Если какой-то компонент не готов, то будет предложено устранить проблему. Если все отмечено зеленым "Ready", то осталось нажать "Submit" для завершения установки.

Собственно саму установку программного обеспечения можно считать законченной на этом. Необходимый минимум установлен. Далее необходимо делать настройку.

Состояние почтовых сервисов (а это три вы можете посмотреть на вкладке "Service Status". Должно быть состояние "Running", это означает, что все установлено нормально.
При необходимости можно осуществить переустановку - "Repair" или перезапуск службы - "Restart".
После переустановки Postfix созданные ранее ящики сохраняются, но любые подобные действия нужно делать аккуратно, т.к. некоторые настройки могут измениться, хотя по идее установки возвращаются к состоянию "по-умолчанию", но в любом случае настройки требуют контроля.

 

[sitecreator]

Как обновить Postfix до актуальной (самой свежей) версии на Centos 7

Убедитесь в установленной версии postfix.

postconf -d mail_version

Стандартный репозиторий Centos 7 не располагает самой свежей версией Postfix, поэтому попытка обновления системы не приведет к обновлению Postfix, в нашем случае средствами aaPanel была установлена относительно свежая версия Postfix 3.4.7. Можно использовать эту версию и не делать дополнительных установок. Это стабильная ветка, последний релиз состоялся в апреле 2023, более данная ветка поддерживаться и развиваться не будет.

Можно при желании обновить postfix до наиболее свежей версии.
О том, как обновить уже установленный панелью управления aaPanel (под ОС Centos 7) postfix пойдет речь ниже.

добавляем репозиторий EPEL и yum-utils, позволяющий более гибко управлять репозиториями.

yum -y install epel-release yum-utils

добавляем репозиторий Ghettoforge в операционную систему Centos 7.

yum --nogpg install https://mirror.ghettoforge.org/distributions/gf/gf-release-latest.gf.el7.noarch.rpm

смотрим имеющиеся в системе репозитории и убеждаемся, что новые были успешно добавлены.

yum repolist

делаем доступным gf-plus репозиторий :

yum-config-manager --enable gf-plus

Обновляем информацию об установленных репозиториях.

yum clean all
yum makecache

Проверяем доступные репозитории.

yum repolist

Запускаем обновление системы и ее компонентов с зависимостями. Postfix будет обновлен при этом.

yum update

Либо можно обновить только postfix. Зависимости также будут обновлены.

yum update postfix

после обновления желательно сделать перезагрузку:

reboot

Проверьте версию postfix после обновления.

postconf -d mail_version

На данный момент была установлена самая свежая версия Postfix 3.8.1

Учтите, что если вы через панель управления решите восстановить (или исправить какие-то ошибки) Postfix, то будет снова установлена версия Postfix 3.4.7, т.е. произойдет откат к более старой версии. Восстановление произойдет после нажатия "Repair".

Даже если вы не обновляли Postfix до самой свежей версии, а воспользовались версией, которую вам предоставила aaPanel, то нужно все равно внести изменения в config для Postfix, как минимум, для одной строчки (myhostname = ...)
В конфиге Postfix (конфигурационный файл можно поправить прямо из панели управления из вкладки "Service Status" нажав на "Config" для Postfix) желательно сделать одну правку (подставьте свой почтовый домен):

myhostname = mail.site.su

Для myhostname нужно задать правильный домен, этот домен должен совпадать с вашим почтовым доменом, а мы условились, что такой домен будет только один для любых почтовых ящиков на сервере. Первоначально для конфига (pstfix config file) берется имя хоста, прописанного в операционной системе, а там может быть что угодно, вплоть до несуществующего доменного имени. Поэтому рекомендуется для сервера также задать правильное имя хоста. На примере Centos 7 это делается так:

hostnamectl set-hostname mail.site.su

Перезапускаете службу:

systemctl restart systemd-hostnamed

Проверяете установленное имя хоста:

hostnamectl

Получаете информацию об имени хоста (Static hostname) для операционной системы Linux Centos 7:

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

 

[sitecreator]

Создание почтовых ящиков e-mail для доменов и сертификатов SSL для почты с автоматическим продлением

Нужен ли сертификат для работы с почтовым серсером?

Спойлер: Нужен ли сертификат для работы с почтовым серсером?

Да, нужен, чтобы не возникало никаких проблем. Теоретически можно работать с почтой и без сертификата, несколько лет назад и сайты могли не использовать сертификат, но в настоящее время требования к повышенной безопасности только возрастают, а потому работа без сертификата рассматривается как небезопасная, следовательно, может быть потеря почты (писем) или будет невозможно отправить или принять почту (письма). Если ваш почтовый сервер будет работать без сертификата SSL, то доверие к такому серверу со стороны других почтовых серверов будет крайне снижено со всемы втекающими неприятными последствиями.
Итак, для вашего сайта обязательно нужен сертификат в настоящее время. Все сайты сейчас работают (должны работать - так точнее) исключительно по безопасным протоколам, т.е. ссылка на сайт всегда начинается, точнее, должна начинаться с https://. Незащищенный протокол http:// допускается использовать только как временное решение.
Тоже самое касается и доступа к почтовым серверам, к ним доступ должен быть только по защищенным протоколам, а потому для почтового сервера (почтового домена) сертификат SSL должен использоваться обязательно.
Любые варианты без использования сертификатов и, соответственно, без защищенных протоколов должны остаться в прошлом, допускается их использования как временное решение для настройки, отладки и т.п., но не более, иначе в случае почты есть риск не получить почту (письмо/сообщение) и есть риск того, что ваш адресат не получит ваше письмо.

Кстати, большинство почтовых клиентов (почтовых программ) при попытке подключения к почтовому серверу без сертификата будут ругаться (точнее, будет ругаться антивирус, следящий за почтовым клиентом) и просто приостановят свои действия (по приему/отправке почтовых сообщений "@e-mail") пока пользователь явно не укажат, что нужно игнорировать отсутствие сертификата безопасности SSL у почтового сервера. Но игнорирование в данном случае на постоянной основе - это дурная практика.

Сразу скажу, что панель aaPanel не позволяет создавать (только своими средствами) сертификаты SSL/TLS для почты с автоматическим продлением (автообновлением) если вы используете свои ns-серверы (на вашем же VDS или предоставленные хостингом/провайдером). В таком случае нужно вручную вносить сертификат и вручную вносить новый каждые 3 месяца, например, если используете бесплатные SSL сертификаты Let`s Encrypt.

Это в отличие от сертификатов SSL для доменов, которые могут продлеваться автоматически, и вся настройка автопродления делается средствами панели управления aaPanel.

Но можно ли сделать все же автопродление сертификатов SSL для почты/e-mail? Да, можно. При этом можно использовать любое количество ящиков (e-mail) для любого количества доменов. И можно забыть про головную боль с ручным обновлением и продлением сертификатов, а это особенно проблематично если доменов несколько на вашем VDS/VPS (выделенном сервере: виртуальном или в виде физического "железного" сервера).

Итак, для примера, у вас есть сайт site.su.
И нужна почта для данного сайта/домена. Ящиков может быть сколько угодно.
Например:

[email protected]
[email protected]

В официальной документации к панели управления сервером aaPanel нет описания возможности работы сертификатов для почты с автопродлением.

Чтобы избавить себя от многих потенциальных сложностей и проблем создайте поддомен для своего сайта/домена:
mail.site.su.
Замечу, что у вас может быть много доменов и, соответственно, много почтовых ящиков на разных доменах.
Но, "почтовый поддомен" нужен только один, соответственно, сертификат SSL тоже нужен только один именно для этого доменного имени:
mail.site.su.
Достаточно одного сертификата SSL для работы сайта mail.site.su и всей почты вашего сервера (почтовых ящиков для разных доменов).
Конечно, можно создавать для почты каждого домена свой сертификат, но в этом нет никакого смысла, это лишь усложнило бы продление сертификатов.

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

Использование одного домена (точнее, поддомена mail.*) также еще полезно тем, что вы можете использовать обратную (реверсивную) DNS запись на ns-серверах, сокращенно PTR DNS запись. Если у вас один IP, то и такая запись (PTR) может быть только одна для вашего VDS, да и в принципе возможность иметь такую запись (и корректировать ее) зависят от вашего провайдера.
Если у вас хостинг VDS firstvds.ru с PTR , то вы можете задать/поменять PTR для вашего VDS/VPS firstvds.ru .
Задать обратную запись (PTR) можно в личном кабинете в настройках вашего сервера (VPS/VDS)
в настройках "IP-адреса". Название сервера будет совпадать с названием почтового сервера. Обратная запись доменной зоны PTR будет полезна для борьбы против спама и будет служить дополнительным подтверждением того, что ваши письма отправлены с правильного сервера, а не являются попыткой указать ложного отправителя. Анти-спам фильтры используют проверку PTR для большей надежности совместно с другими проверками на спам.

Спойлер: задать PTR

проверить PTR можно здесь, например: https://mxtoolbox.com/SuperTool.aspx
Вводите IP сервера (в данном случае почтового сервера) и выбирайте тест "Reverse Lookup"
Пример успешной проверки PTR (вы узнали точно доменное имя почтового сервера по IP адресу):

Но PTR-запись DNS не является обязательной. При наличии возможности можете добавить ее потом.
---------------------------------------


Итак, вы создали технический домен/сайт (точнее, поддомен) mail.site.su. Как сайт вы его использовать не будете, этот поддомен (а не сам сайт) нужен для почты. Но сайт позволит сделать автопродление сертификата SSL/TLS для почты , т.к. проверка владения доменом будет производиться путем автоматичекской записи тестового файла в специальную папку сайта.

Повторюсь, что если доменов у вас несколько, то вам необходимо выбрать лишь один (любой) домен, для которого вы создадите поддомен mail.
Для примера вы создали поддомен
mail.site.su.
Создайте для этого технического сайта сертификат SSL Let`s Encrypt. Он будет автоматически продляться, для этого в aaPanel все уже есть.
Этот же сертификат будем использовать для почты.

Повторюсь, достаточно одного сертификата для нескольких доменов, конечно, если у вас их несколько.
Пример нескольких уже добавленных доменов (для работы с почтой), но сертификата достаточного одного:

Прежде того, как вы будете добавлять первый домен для почты, вам будет необходимо прописать записи на ns-сервера для этого домена, которые необходимы для работы почты.
Должна быть запись для домена типа A с именем
mail.site.su.

И должны быть две (или одна) записи типа MX с именем
site.su.
и значением
mail.site.su.

Записи для домена прописываются с использованием dnsmanager, доступ к которому предоставляет ваш хостинг-провайдер. Это в случае если вы используете ns-серверы вашего хостинг-провайдера. Вы можете использовать и другые ns-серверы, например, собственные на вашем VDS/VPS сервере (нужно 2 IP, как минимум) или ns-серверы от cloudflare.com, но сейчас конкретно рассматриваем вариант использования ns-серверов вашего хостера.

Домен для почты добавляется так, если пользуетесь aaPanel и встроенными средствами для создания почтовых ящиков . Вы всегда в первом поле (Domain name) вводите название домена, а во втором поле (a-record) вводите поддомен mail для этого же домена. Для первого домена (он же основной, который используется для почтовых серверов, далее почтовый сервер будет представляться именно как mail.site.su) важно сделать именно так.

Для второго домена site2.su (и последующих) можно также указывать, соответственно, a-record mail.site2.su, mail.site3.su и т.д.
Но можно, это даже проще, в a-record вносить просто тот же самый домен, который указали в Domain name, например, site2.su, т.е. оба поля будут одинаковые. Это не имеет значения потому, что вы будете использовать только один почтовый домен, а именно - mail.site.su.

Заполнение полей для первого вносимого домена:

Для первого (ОСНОВНОГО) почтового домена вы должны внести записи для домена на NS-серверах по рекомендации панели управления aaPanel и ее модуля "Mail Server".
Для записи с именем "_dmarc" можно сделать более короткое значение, без необходимости отсылать какие-либо отчеты вам на специальный ящик.
Рекомендуется для "_dmarc":

v=DMARC1;p=quarantine

или (более жесткие условия)

v=DMARC1;p=reject

quarantine — предлагает считать получающей стороне почту с невалидными SPF и DKIM подозрительной и проводить дополнительные проверки;
reject — рекомендует отклонять любую почту с невалидными SPF/DKIM.

Запись типа MX можно добавить позже. Главное чтобы была запись типа A. Если записи типа MX пока нет, то вы получите отметку красного цвета о ее отсутствии.
Правда, даже если запись MX присутствует, и присутствует верная запись, но на другом домене, то aaPanel ошибочно отметит такую верную запись красным цветом.

Внимание! Записи для последующих доменов будут отличаться от рекомендованных панелью управления.

Для первого (основного) домена вы внесли записи на ваших NS-серверах в соответствии с рекомендациями aaPanel.
Это касется именно первого, возможно, единственного домена, для которого вы будете использовать почтовые ящики.
Для последующих доменов некоторые записи будут выглядеть иначе.

Вот, что будет рекомендовать панель управления:

Мы НЕ должны следовать этой рекомендации, а должны сделать для ВСЕХ последующих доменов (т.е. начиная со второго домена) запись MX следующего вида:

MX    @    mail.site.su   10

Т.е. в качестве значения записи вы должны указать ваш адрес почтового домена. Он будет для всех ваших доменов одинаковый, будет выглядеть как mail.site.su - это адрес (доменное имя) вашего почтового домена.

Пример:

Панель управления предложит нам внести SPF (spf1) запись для домена. Для всех доменов. начиная со ВТОРОГО, мы игнорируем это предложение, т.к. оно будет неверное в нашем случае.

Для всех доменов, начиная со второго мы вносим такую запись SPF:

TXT         @          v=spf1 redirect=site.su

redirect является модификатором. Он сообщает, что должны применять настройки SPF другого домена. В нашем случае - это настройки для вашего основного (первого домена).

В качестве конкретного примера ниже показано, что для домена sitecreator.pro используется значение следующее SPF:

v=spf1 redirect=sitecreator.su

А вот значения для DKIM записи нужно брать те, которые предлагает панель управления. Это открытые ключи DKIM , они должны быть прописаны в точности, как предлагает панель управления.

Сертификаты SSL/TLS для работы почтовых служб Postfix, Dovecot

По умолчанию панель управления предполагает ручное внесение и обновление сертификата для почты. Не смотря на то, что для сайта сертификат может обновляться автоматически. К тому же, если для сайта используется такой же домен, как и для почтового сервера, то нам достаточно одного сертификата SSL/TLS для сайта и почты.
Итак, сделаем удобное добавление и обновление сертификата для почты.

Для домена сайта (именно веб-сайта!) mail.site.su у вас сертификаты (приватный и полная цепочка) находятся здесь и автоматически обновляются по cron-у:

/www/server/panel/vhost/cert/mail.site.su/privkey.pem
/www/server/panel/vhost/cert/mail.site.su/fullchain.pem

В папке, где хранятся (но не обновляются автоматически!) сертификаты для почты, мы создадим символьные ссылки на сертификаты, которые приведены выше.

Ранее у вас сертификаты для почты располагались в папке как обычные файлы. Эти сертификаты вы добавили вручную (скопировав и вставив их из "сайта") ранее.

После создания символьных ссылок у вас папка с сертификатами для почты выглядеть будет так:

В cron (ежедневно или еженедельно) нужно добавить:

нужно переписать сертификаты в базе самого postfix с перечитыванием хеша и перечитать сертификаты в dovecot.

postmap -F hash:/etc/postfix/vmail_ssl.map && systemctl reload postfix && systemctl reload dovecot

Один раз запустите на выполнение это задание сразу после создания. После успешного выполнения вы можете проверить через панель управления, что сертификат для почты у вас действителен и дата его окончания превышает текущую дату.

 

[sitecreator]

Проверка сертификатов SSL/TLS для почтовых ящиков

Ваш почтовый сервер (домен) для вашего домена указан в MX-записях для домена. В общем случае названия этих доменов не обязательно совпадают, т.к. в качестве почтового может быть использован какой угодно домен (например, почта для вашего домена может использовать почтовый сервер яндекса). Почтовый домен (значение MX-записи) не обязан быть поддоменом по отношению к домену, для которого настраивается почта.
Обычно, если у вас, например, есть один домен site.su, то почтовый сервер будет иметь адрес mail.site.su. Т.е. с одним доменом все довольно просто.

В терминале ввести команду (указав название нужного для проверки домена/поддомена почты, не путать с доменом сайта)
Порт либо 587, либо 465. Именно на этих портах выполняется защищенное соединение с использованием сертификата SSL/TLS.
Указывайте реальный домен (свой почтовый домен из записи MX, а не тот, который указан ниже как пример)

openssl s_client -connect mail.site.su:587 -starttls smtp

или

openssl s_client -connect mail.site.su:465 -starttls smtp

Можно вводить из терминала любого сервера или компьютера, т.е. это вовсе не обязательно должен быть именно ваш сервер.
В зависимости от операционной системы информация может быть более полной или менее полной. Нас интересует дата окончания действия сертификата SSL/TLS для почты.
В ОС Ubuntu 22, например, эта информация (дата) выводится по умолчанию, в ОС Centos 7 - нет.

Можно также сделать проверку сертификата в windows 10/11, если установить openssl.

Спойлер: сделать проверку сертификата в windows 10/11

Проверка сертификата SSL в windows с использованием OpenSSL
Переходите: https://slproweb.com/products/Win32OpenSSL.html
Скачиваете Light версию установщика OpenSSL, например, Win64 OpenSSL v3.2.1 Light (Win64OpenSSL_Light-3_2_1.exe) или более свежую.
Устанавливаете.
После установки программы, необходимо добавить путь к ней как системную переменную. Для этого перейдите в Панель управления → Система → Дополнительные параметры системы → Переменные среды.

В разделе Системные переменные выберите переменную Path и нажмите Изменить. В открывшемся окне нажмите Создать и введите путь к папке bin установленного приложения (C:\Program Files\OpenSSL-Win64\bin по умолчанию). Нажмите ОК.
В windows команду нужно вводить в командной строке (запустить сперва cmd)

Результат проверки выглядит так:

В панели управления сервером срок окончания действия сертификата SSL/TLS для почтового сервера должен совпадать с результатом, который вы увидели выше при проверке через терминал.

Если сертификат SSL/TLS для почты истек, то вы увидите в панели управления соответствующую надпись и дату окончания действия сертификата:

Видна ошибка сертификата и срок его завершения:

verify error:num=10:certificate has expired
notAfter=Dec 30 18:36:43 2023 GMT

 

[sitecreator]

Как проверить, что ваши отправляемые письма содержат подпись (сигнатуру) DKIM и данная подпись прошла валидацию принимающей стороны

Для того, чтобы исключить попадание ваших писем в спам, необходимо в каждом отправляемом письме иметь подпись DKIM.
DKIM (Domain Keys Identified Mail) — это цифровая подпись (сигнатура), которая служит подтверждением того факта, что письмо было отправлено именно с того ящика, который указан в заголовке "от/from", т.е. эта подпись исключает поддельное содержание в графе "отправитель".

DKIM сигнатура добавляется в качестве служебного заголовка письма.
Вы можете отправить тестовое письмо на какой-либо ваш ящик, используемый на yandex.ru.
Yandex обеспечивает хорошую фильтрацию входящих писем на предмет спама и добавляет в проверенное письмо дополнительную информацию (отчет) о результате такой проверки.

Итак, если вы используете почтовый клиент Thunderbird, то для интересующего письма выбираете в меню вид --> исходный текст. Тем самым вы сможете увидеть все служебные заголовки в письме.

Вы увидите строку, начинающуюся с DKIM-Signature, это и есть DKIM-подпись, которую добавил ваш почтовый сервер в письмо при его отправке.
То, что ваша DKIM-подпись прошла успешно проверку свидетельствует заголовок "Authentication-Results:", содержащий
dkim=pass.

Если у вас в полученном письме нет служебного заголовка DKIM-Signature, то это означает, что DKIM-подпись не была добавлена вашим почтовым сервером. Необходимо в таком случае разбираться с настройками и корректировать их.

Почтовый сервер в aaPanel предлагает создавать для каждого домена (для использования почтовых ящиков на этом домене) свою запись для домена (на NS-серверах), отвечающую за проверку DKIM-подписи. Это запись текстового типа (TXT), ее имя - это "default._domainkey".
Значение этой записи содержит публичный ключ для проверки принимающей письмо стороной.
В служебном заголовке письма DKIM-Signature можно найти "d=sitecreator.pro;s=default;", это дает понять принимающей (и проверяющей) стороне, где брать публичный ключ для проверки DKIM-подписи, т.е. нужно искать среди записей (на NS-серверах) для конкретного домена (для примера указан sitecreator.pro) запись с именем "default._domainkey".

Вы можете проверить наличие и доступность на NS-серверах DKIM записи домена для конкретного домена здесь:

DKIM Check- DomainKeys Identified Mail (DKIM) Record Lookup - MxToolBox

mxtoolbox.com

В качестве селектора вносите "default", это означает, что будет осуществлен поиск записи TXT на NS-серверах с именем "default._domainkey" для конкретного домена.

Результат тестирования DKIM записи на NS-сервере:

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

• DKIM Record Published DKIM Record found
• DKIM Syntax Check The record is valid
• DKIM Public Key Check Public key is present

Но это лишь проверка наличия корректной записи DKIM для домена на NS-серверах. Наличие такой записи обязательно для функционирования механизма DKIM, но не является достаточным. Т.е. ваш почтовый сервер должен еще и добавлять служебную запись DKIM-Signature в письмо, а этого может и не быть, даже указанный выше тест для NS-сервера прошел успешно.

 

[sitecreator]

Проблемы, возникающие с почтой.

Почта отправляется, но в служебные заголовки не добавляется запись DKIM,

т.е. отсутствует служебный заголовок DKIM-Signature в письме.
При этом тест наличия DKIM-записи на NS-серверах может быть успешным.

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

Публичные и приватные ключи для каждого домена находятся здесь:

/www/server/dkim/

Для каждого сайта ключи находятся в соответствующих папках, совпадающих по названию с соответствующим доменом, пример ниже:

Проблема может состоять в том, что приватный ключ (default.private) содержит права доступа chmod=600, а должно быть chmod = 644.

Неверно (600):

Верно (644):