Email: Настройка собственного from-домена

Требования крупных почтовых провайдеров

Крупные почтовые провайдеры (Gmail, Yahoo, Outlook и др.) требуют, чтобы почтовый ящик, указанный в поле From, реально существовал на почтовом сервере. Кроме того, рекомендуется, чтобы домен этого ящика имел A-запись, указывающую на реальный ресурс.

Например, если From: info@example.com, то на example.com должна быть A-запись, и ящик info@example.com должен быть создан на почтовом сервере этого домена.

Настройка SPF

Sender Policy Framework (SPF) — технология, позволяющая проверить, не подделан ли домен отправителя. Для её работы необходимо добавить на отправляющий домен (сендер домен, фром домен) специальную TXT-запись, которая определяет политику разрешения отправки этого домена с различных хостов.

Мы рекомендуем внести записи разных версий:

Домен	Тип записи	Содержимое
example.com.	TXT	v=spf1 include:spf.akmta.net ~all
example.com.	TXT	spf2.0/pra include:spf.akmta.net ~all

На домене spf.akmta.net содержится актуальный список IP-адресов сендеров Altcraft.

примечание

Если вы используете Cloud-версию, SPF покрывается записью include:spf.akmta.net автоматически.

Если вы используете On-premises-версию, домен, с которого уходит MAIL FROM, определяется в настройках сендера и пула. Убедитесь, что SPF-запись домена разрешает отправку с этого домена.

У домена может быть только одна SPF-запись

Если на домене уже есть SPF-запись, не создавайте новую — она затрет существующую. Вместо этого добавьте include:spf.akmta.net в уже имеющуюся запись.

Проверьте текущую запись командой:

dig example.com TXT

Пример вывода, если запись уже существует:

; <<>> DiG 9.18.28 <<>> example.com TXT
;; ANSWER SECTION:
example.com.            300     IN      TXT     "v=spf1 include:sendgrid.net ~all"

Хороший результат: в ANSWER SECTION есть одна запись, начинающаяся с v=spf1. Плохой результат: NXDOMAIN (запись не найдена) или несколько записей v=spf1 (это нарушает стандарт).

Если запись найдена, объедините механизмы в одну строку:

Было	Стало
v=spf1 include:sendgrid.net ~all	v=spf1 include:sendgrid.net include:spf.akmta.net ~all

Директива ~all (или -all) должна оставаться одной и находиться в конце записи.

Настройка DKIM

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

Необходимо внести следующие записи. Выберите селектор — например, ak. Селектор — это префикс в имени поддомена DKIM-записи. Селекторы позволяют использовать разных отправщиков на одном домене: например, ak._domainkey.example.com для Altcraft и mail._domainkey.example.com для другого сервиса.

Домен	Тип записи	Пример содержимого
ak._domainkey.example.com.	TXT	v=DKIM1; k=rsa; p=<ваш персональный ключ>
_domainkey.example.com.	TXT	o=-;

примечание

Селектор в DNS должен совпадать с селектором, указанным в настройках сендера платформы. From-домен определяется из поля Email отправителя — оно задаётся в настройках ресурса, шаблона или рассылки. Приоритет: рассылка, затем шаблон, затем ресурс.

подсказка

Для облачных клиентов Altcraft селектор всегда akru2022. Для On-premises-версии селектор может быть любым — он задаётся в настройках сендера платформы.

Настройка DMARC

Технология DMARC позволяет почтовому серверу решить, что делать с почтой, если с DKIM и SPF-записями что-то не так.

Мы рекомендуем установить правила, запрещающие принимать сообщения, которые получены с чужих IP-адресов, либо неправильно подписаны.

Домен	Тип записи	Пример содержимого
_dmarc.example.com.	TXT	v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com

примечание

DMARC проверяет согласованность домена в From с результатами SPF и DKIM. Убедитесь, что from-домен (определяется из поля Email отправителя в рассылке, шаблоне или ресурсе) совпадает с доменом, для которого настроены SPF и DKIM.

Настройка трекинга

На поддомене вашего фром домена необходимо внести следующую запись:

Домен	Тип записи	Пример содержимого
trk.example.com.	CNAME	trk.aksend.net

Дополнительно вы можете использовать сколько угодно трекинг-доменов, настройки будут аналогичные.

примечание

Запись trk.aksend.net используется только для облачного решения Altcraft. Если вы используете On-premises решение, введите собственную запись. В UI при создании ресурса поле Трекинг домен позволяет задать домен для конкретного ресурса.

Настройка CNAME для обработки bounces

Для облачных клиентов необходимо также настроить дополнительную CNAME-запись, направленную на домен akmta.net:

Пример записи:

ac-bounces.example.com IN CNAME akmta.net

Здесь ac-bounces представляет собой поддомен, а example.com — ваш from-домен. Этот поддомен будет использоваться в Return-Path, что позволит проходить SPF-аутентификацию и выполнять «выравнивание» для улучшения доставляемости писем.

Настройка A-записи для from-домена

Крупные почтовые провайдеры (Gmail, Yahoo, Outlook и др.) проверяют, что from-домен имеет A-запись, указывающую на реальный IP-адрес. Без этой записи письма могут не доставляться или попадать в спам.

Добавьте A-запись для вашего from-домена, указывающую на IP-адрес вашего почтового сервера:

Домен	Тип записи	Содержимое
example.com.	A	<IP-адрес вашего почтового сервера>

Например, если From: info@example.com, то example.com должен иметь A-запись, и ящик info@example.com должен быть создан на почтовом сервере этого домена.

примечание

A-запись должна указывать на IP-адрес почтового сервера, где реально существует почтовый ящик из поля From. Это может быть IP вашего корпоративного почтового сервера, Microsoft 365, Google Workspace или другого провайдера хостинга почты.

Настройка MX-записи

MX-запись должна указывать на почтовый сервер компании — той организации, от имени которой отправляются письма.

Она необходима, потому что спам-фильтры проверяют наличие MX-записи у домена отправителя. Запись должна вести на реальный почтовый сервер, иначе письмо может быть отклонено или отправлено в спам.

Кроме того, по адресу из MX-записи направляются ответы от получателей, если не задан заголовок reply-to и отключён захват ответов в настройках аккаунта платформы.

Домен	Тип записи	Содержимое
example.com.	MX	<адрес вашего почтового сервера>

Дополнительные настройки

BIMI (необязательно)

Технология BIMI (Brand Indicators for Message Identification) используется совместно с SPF, DKIM и DMARC для отображения брендового изображения рядом с письмом в инбоксе получателя. Эта настройка необязательна — она нужна, если вы хотите, чтобы логотип компании отображался рядом с письмом в поддерживающих почтовых клиентах.

примечание

Аутентификацию писем BIMI поддерживают такие почтовые сервисы, как Fastmail, Gmail и Yahoo!

Чтобы использовать технологию, вам нужно указать путь до файла в формате svg. Изображение должно быть квадратным и не иметь дополнительных слоёв.

Внесите в настройках домена следующую запись:

Домен	Тип записи	Пример содержимого
default._bimi.example.com	TXT	v=BIMI1; l=https://example.com/bimi/bimi.svg

Вы можете также воспользоваться генератором записи на https://bimigroup.org/bimi-generator/.

Решение часто возникающих проблем

Если после тестовой отправки DKIM, SPF, DMARC или антиспам-заголовки показывают плохие значения, проверьте настройки домена, отправителя и содержимое письма.

DKIM, SPF или DMARC не проходят проверку

Если в заголовках письма указаны значения dkim=fail, spf=fail или dmarc=fail, скорее всего, проблема связана с настройкой домена.

Проверьте:

• DKIM-селектор в панели администратора;
• DKIM-ключ в DNS-записи домена;
• SPF-запись домена;
• DMARC-запись домена;
• домен в поле From;
• домен обратного адреса;
• совпадение доменов для прохождения DMARC.

Если на домене используется один DKIM-селектор, в панели администратора должен быть указан тот же селектор. Например, если в DNS опубликована запись:

mail._domainkey.example.com

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

mail

Если в панели администратора указан другой селектор, почтовый сервер не найдёт нужный DKIM-ключ или проверит письмо по другой DNS-записи.

Также проверьте сам DKIM-ключ. Значение публичного ключа в DNS должно соответствовать ключу, который используется для подписи письма. Если ключ был заменён в DNS, но не обновлён в панели администратора, DKIM может не пройти проверку.

SPF не проходит проверку

Если в заголовках указано значение spf=fail, проверьте SPF-запись домена, который используется в обратном адресе.

Обратный адрес обычно отображается в заголовке:

Return-Path: <bounce@example.com>

или в результате проверки SPF:

spf=fail smtp.mailfrom=bounce@example.com

SPF проверяется не по видимому адресу отправителя в From, а по домену из smtp.mailfrom / Return-Path.

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

example.com. TXT "v=spf1 include:spf.example.net -all"

Если отправка идёт через внешний сервис, он должен быть добавлен в SPF-запись через include или другой рекомендованный механизм.

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

v=spf1

DMARC не проходит проверку

Если DKIM и SPF имеют значение pass, но DMARC показывает fail, чаще всего проблема связана с несогласованными доменами.

Пример проблемной ситуации:

From: News <news@example.com>
Return-Path: <bounce@mailer-service.com>

Authentication-Results: mx.example.com;
 dkim=pass header.i=@mailer-service.com;
 spf=pass smtp.mailfrom=mailer-service.com;
 dmarc=fail header.from=example.com

В этом случае DKIM и SPF проходят проверку, но не для домена example.com, который указан в From.

Чтобы DMARC прошёл проверку, должно выполняться хотя бы одно условие:

• DKIM проходит проверку, а домен DKIM согласован с доменом в From;
• SPF проходит проверку, а домен smtp.mailfrom согласован с доменом в From.

Если используется другой домен в поле From, он тоже должен быть настроен: для него нужны DKIM, SPF и DMARC-записи.

Используется другой From-домен

Проблемы могут возникнуть, если в письме используется один домен отправителя, а настройки выполнены для другого домена.

Например, в панели администратора настроен домен:

example.com

а письмо отправляется с адреса:

From: News <news@promo.example.net>

В этом случае для домена promo.example.net тоже должны быть настроены DKIM, SPF и DMARC. Если этот домен не настроен, проверка может завершиться ошибкой.

Перед тестовой отправкой убедитесь, что домен в From совпадает с доменом, который настроен в панели администратора, или является его корректно настроенным поддоменом.

У домена или IP-адреса не настроены DNS-записи

Для корректной отправки нужны DNS-записи домена и отправляющего IP-адреса.

Проверьте:

• A-запись для домена;
• MX-запись для домена;
• PTR-запись для отправляющего IP-адреса;
• корректность обратного адреса;
• доступность домена в DNS.

PTR-запись особенно важна для отправляющего IP-адреса. Она связывает IP-адрес с доменным именем и используется почтовыми системами как один из репутационных сигналов. PTR-запись настраивается не в DNS-зоне домена, а у провайдера хостинга (или в панели управления IP-адресом).

Проверка записей через dig

Проверьте базовые записи:

dig example.com A
dig example.com MX
dig example.com TXT

Пример успешного вывода для A-записи:

; <<>> DiG 9.18.28 <<>> example.com A
;; ANSWER SECTION:
example.com.            300     IN      A       192.0.2.4

Хороший результат: в ANSWER SECTION есть запись с IP-адресом. Плохой результат: NXDOMAIN (домен не найден) или пустой ANSWER SECTION.

Проверьте PTR-запись (обратное DNS) для IP-адреса отправщика:

dig -x 192.0.2.4

Пример успешного вывода:

; <<>> DiG 9.18.28 <<>> -x 192.0.2.4
;; ANSWER SECTION:
4.2.0.192.in-addr.arpa. 300     IN      PTR     mta-1.example.com.

Хороший результат: PTR указывает на домен, совпадающий с A-записью (mta-1.example.com). Плохой результат: NXDOMAIN (PTR не настроена) или PTR указывает на другое имя.

Проверьте DKIM-запись (замените ak на ваш селектор):

dig ak._domainkey.example.com TXT

Пример успешного вывода:

; <<>> DiG 9.18.28 <<>> ak._domainkey.example.com TXT
;; ANSWER SECTION:
ak._domainkey.example.com. 300  IN      TXT     "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Хороший результат: запись найдена, начинается с v=DKIM1; k=rsa; p=. Плохой результат: NXDOMAIN (селектор не найден) или ключ p= пустой.

Проверьте DMARC-запись:

dig _dmarc.example.com TXT

Пример успешного вывода:

; <<>> DiG 9.18.28 <<>> _dmarc.example.com TXT
;; ANSWER SECTION:
_dmarc.example.com.     300     IN      TXT     "v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com"

Хороший результат: запись найдена, содержит v=DMARC1 и политику p=. Плохой результат: NXDOMAIN (DMARC не настроен) или политика p=none (не рекомендуется для продакшена).

Домен или IP-адрес ещё не прогреты

Даже при корректных DKIM, SPF и DMARC письмо может получить плохую антиспам-оценку, если отправка началась с высокой скорости на непрогретый домен или IP-адрес.

Для нового домена или нового IP-адреса нужен постепенный прогрев. Начинайте с небольшого объёма отправок и увеличивайте скорость постепенно.

Если сразу запустить массовую отправку на высокой скорости, почтовые системы могут начать отклонять письма, отправлять их в спам или снижать репутацию отправителя.

При прогреве следите за:

• доставляемостью;
• открытиями и кликами;
• жалобами на спам;
• отказами;
• попаданием в спам;
• репутацией домена и IP-адреса.

Письмо не проходит антиспам-фильтры

Если DKIM, SPF и DMARC проходят проверку, но письмо получает высокий SCL, BCL или попадает в спам, проблема, скорее всего, связана не с аутентификацией домена, а с содержимым письма или репутацией отправителя.

Разные почтовые провайдеры используют разные антиспам-фильтры с разными заголовками и оценками. Например, SpamAssassin использует X-Spam-Status и X-Spam-Score, Microsoft 365 — SCL и BCL, а Gmail не выставляет публичных числовых оценок. Для универсальной проверки используйте онлайн-тестеры (см. ниже).

Проверьте:

• тему письма;
• текст письма;
• HTML-разметку;
• соотношение текста и изображений;
• ссылки;
• домены в ссылках;
• вложения;
• наличие сокращателей ссылок;
• репутацию домена;
• репутацию IP-адреса;
• частоту отправки;
• историю жалоб и отказов.

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

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

Для диагностики можно использовать внешние сервисы:

• Mail-Tester.com — отправьте тестовое письмо на уникальный адрес, получите оценку 0–10 с подробным разбором DNS, заголовков, SPF, DKIM, DMARC и содержимого.
• MXToolbox — проверка DNS-записей, SPF, DKIM, DMARC, PTR и чёрных списков.
• Google Postmaster Tools — мониторинг репутации домена, IP-адресов, ошибок доставки и жалоб у Gmail.
• Postmaster Mail.ru — мониторинг репутации и качества отправок в Mail.ru.
• Microsoft SNDS — мониторинг репутации IP-адресов в инфраструктуре Microsoft.

После исправлений выполните повторную тестовую отправку и снова проверьте заголовки письма. Нормальный результат проверки аутентификации:

dkim=pass
spf=pass
dmarc=pass

Если используются Microsoft 365 или Outlook, дополнительно проверьте:

compauth=pass
SCL:0
BCL:0