Email: Рекомендации по взаимодействию с ISP

Инфраструктура

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

• оптимизации доставки в папку входящие
• обхода блокировок
• ускорения доставки для определенных категорий писем
• сокращения расходов на отправку

Для развертывания инфраструктуры рекомендуется выбрать отдельный от from домен (здесь и далее — сендер домен). Это удобно, если вы захотите использовать несколько разных from доменов, но не обязательно. В любом случае для каждого рассыльного IP адреса вы должны будете выбрать какой-либо поддомен для идентификации, регистрации PTR и составления SPF записей.

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

Для каждого IP заведите отдельную A запись на сендер домене:

Домен	Тип	Запись
mx2.s1.example.com	A	1.1.1.1
mx2.s1.example.com	A	1.1.1.2

Настройка обратной зоны (PTR)

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

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

Например у вас есть сервер (s1), имеющий несколько IP адресов (1.1.1.1 и 1.1.1.2), тогда для вашего домена (example.com) заводятся следующие записи:

Домен	Тип	Запись
1.1.1.1.in-addr.arpa.	PTR	mx1.s1.example.com
2.1.1.1.in-addr.arpa.	PTR	mx2.s1.example.com

Обратите внимание что IP адрес в имени домена перевернут, это необходимо для возможности делегирования поддомена конечному владельцу / арендатору.

Настройка сервера входящей почты для FBL/CFL

FBL/CFL (FeedBack Loop) – это стандарт выдачи информации о жалобах на спам от провайдера услуг электронной почты отправителю писем. Крайне рекомендуется пользоваться этой технологией на всех ISP где она доступна в том или ином виде. Обычно сервис формирует отчет в специальном формате ARF (Abuse Reporting Format), который содержит исходное письмо и электронный адрес пользователя, а также другие данные позволяющие отправляющей стороне среагировать (пометить жалобу в статистике, деактивировать подписчика).

FBL поддерживает большинство крупных мировых email-провайдеров, таких, как Hotmail, Yahoo и AOL. Для использования FBL обычно необходимо указать и подтвердить электронный адрес с того же домена (на него будут приходить отчеты), и подтвердить диапазон IP-адресов, с которых вы отправляете почту. В случае с Microsoft, например, необходимо еще заключить специальный договор.

Gmail не предоставляет FBL, но использует специальный заголовок List-Unsubscribe для отписки пользователя от рассылки. С помощью этого заголовка можно создать аналог FBL, отслеживая на своей стороне, какие письма кому были отправлены.

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

примечание

Вы можете использовать для этой цели существующий корпоративный сервер, обслуживающий почту по протоколу POP3 и SMTP.

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

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

Ящик	Назначение
abusemaster@<domain>	Автоматические ARF отчеты
postmaster@<domain>	Письма подтверждения; необходим при регистрации FBL
abuse@<domain>	Ящик рекомендуемый к использованию abuse.net

В AKMTA сендер уже встроен сервер входящей почты. Вам необходимо указать на NS домена что его почту обслуживает хост (MX) настроенный в AKMTA. Таким образом он будет получать всю почту для любых ящиков этого домена. Почта не содержащая ARF отчетов будет переправлена на ящик указанный в конфиге.

Если такой вариант вам по каким-то причинам не подходит (основной домен, корпоративные политики), то необходимо все равно организовать поддомен для обслуживания почты на AKMTA и перенаправлять туда сообщения с abusemaster@ ящика основного домена. Обе схемы изображены на рисунке.

Список веб-страниц с формами регистрации FBL в ISP

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

• У вас есть имя ответственного лица, его телефон и контактный email
• Известен список IP и доменов сендера
• Настроен abusemaster@ ящик и туда доставляется почта
• Имеется доступ к postmaster@ ящику и туда доставляется почта

Почтовый провайдер	FBL
AOL	https://postmaster.info.aol.com/fbl-request
Comcast	http://feedback.comcast.net/
Cox	http://fbl.cox.net/
Earthlink	fblrequest@abuse.earthlink.net
Excite (Bluetie)	http://feedback.bluetie.com/
Fastmail	http://fbl.fastmail.fm/
Hotmail	https://postmaster.live.com/snds/
Outblaze	postmaster@outblaze.com
Rackspace	http://fbl.apps.rackspace.com/
Road Runner	http://feedback.postmaster.rr.com/
Spamcop	http://www.spamcop.net/reported.shtml
Synacor	http://fbl.synacor.com/
Terra (Brazil)	http://fbl.mail.terra.com.br/
Tucows	http://fbl.hostedemail.com/
USA.net	http://fbl.usa.net/
Yahoo!	http://feedbackloop.yahoo.net/
ZOHO	http://www.zoho.com/fbl/index.html
Mail.ru	https://postmaster.mail.ru/
Yandex.ru	http://yandexfbl.senderscore.net/
Gmail	Support only List-Unsubscribe — технология, позволяющая добавить специальный заголовок, по которому осуществляется отчет о жалобе по e-mail каналу или по ссылке. Полностью поддерживается системой Altcraft.

Настройка цифровой подписи (DKIM)

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

Для подписи письма используется приватный ключ, который устанавливается на стороне отправщика и более никому не известен. Публичный ключ располагается в виде специальной TXT записи на поддомене From домена.
Поддомен выбирается исходя из используемого селектора. Селекторы выбираются самостоятельно отправщиком, рекомендутся делать селектор уникальным для одного ключа, чтобы несколько отправщиков могли использовать свои собственные ключи.
На данный момент в технологии чаще всего используется RSA-SHA256 и RSA-SHA1 алгоритмы. Рекомендуемая длина ключа — 1024 бит.

Проверить наличие ключевой записи на домене можно командой dig:

dig TXT ak1024._domainkey.akmta.net +short
# "v=DKIM1\; k=rsa\; p=MIGfMA0G......QAB"

Создать DKIM ключ для AKMTA сендера можно из Панели администратора системы. Затем ключ и селектор нужно будет указать в настройках сендера.

Настройка Sender Policy Framework

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

Помимо перечисления IP адресов можно использовать директиву include, позволяющую забрать правила с другого домена. Её имеет смысл использовать если для отправки используется множество доменов, а IP сендера иногда меняются. Также имеются директивы a, mx, ptr и прочие.

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

Тип	Пример содержимого
SPF	spf2.0/pra include:spf.akmta.net ip4:A.B.C.D -all
TXT	spf2.0/pra include:spf.akmta.net ip4:A.B.C.D -all
TXT	v=spf1 include:spf.akmta.net ip4:A.B.C.D -all

В примере разрешается использование хостов домена spf.akmta.net, а также IP адреса A.D.C.D. Директивой ip4, вы можете перечислять как каждый IP так и целую подсеть. -all однозначно указывает на то что отправка с других хостов не будет валидной. Если вы хотите разрешить отправку с любых хостов используйте +all (не рекомендуется). Проверить наличие и содержимое SPF записей можно также командой dig.

Типичная настройка From домена

Учитывая все вышеописанное, на вашем From домене должен оказаться примерно следующий набор записей:

Поддомен	Тип	Запись	Комментарии
	SPF	spf2.0/pra include:spf.akmta.net ip4:A.B.C.D -all	Данный тип записи возможно не получится добавить на домен, так как он считается устаревшим. В таком случае просто пропустите его добавление, мы указываем его для дополнительной совместимости.
	TXT	spf2.0/pra include:spf.akmta.net ip4:A.B.C.D -all	В случае, если домен уже используется для рассылок, то необходимо добавить в SPF правило существующие рассыльные ресурсы (IP-Адреса)
	TXT	v=spf1 include:spf.akmta.net ip4:A.B.C.D -all
trk	CNAME	trk.aksend.net
_dmarc	TXT	v=DMARC1; p=none; rua=mailto:dmarc@example.com; sp=none	Укажите email ответственного лица за рассылки.
_domainkey	TXT	o=-;
_policy._domainkey	TXT	o=-;
ak._domainkey	TXT	v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCldFYh3Rfrmeov+WqYYpwfW2bVUzxXPy9dSVoUCGLKCn+vgY/pdKIIBFitkvZJXGLnHqreqwGzoriEWf9ZRd+cL2LdA4UrDKheMeorBd2NSIqihkTaKz8PA+SIBFxFGm2Z0Krh5ZDF2NtFVhtD4YvqmrFqk2muzZ0tFEko8zP30wIDA

Здесь для примера указан домен example.com. А все записи предназначены для рассылок через облачный сервис ru.altcraft.com.

Обратите внимание, что если вы захотите использовать поддомен для отправки писем через Altcraft, например ak.example.com, то все записи необходимо заводить именно на поддомене ak (например trk.ak CNAME ...). При этом на корневом домене example.com SPF и policy записи не должны запрещать отправку с поддомена.

Репутация отправителя

Репутационная составляющая самая важная для доставки в инбокс. Правильная настройка не гарантирует вам 100% доставку. Поэтому важно следить за всеми составляющими процесса.

Репутация затрагивает в отдельности и совокупно следующие сущности:

• Sender IP
• Sender domain
• From domain
• From email
• Tracking IP
• Tracking domain

Чистота данных — вы должны знать откуда к вам приходят пользователи и быть уверены что данные верные и свежие. Обязательно делайте валидацию email адреса на формах. Если вы работаете со схемой double option, это многократно увеличивает ваши шансы на то что попавшие к вам лиды не создадут проблем. Все проблемы с чистотой данных делятся на несколько видов:

HardBounces. Емейлы, на которые доставка невозможна по причине отсутствия такого емейла или домена. Большой hardbounce rate говорит о том что данные не актуальны. Нормально держать этот показатель около 0.5% от всех отправленных писем.

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

Complaints. Большинство крупных почтовых провайдеров ввели кнопку "Это спам". Такая кнопка не только перекладывает письмо в папку "Спам", но и учитывается при расчете репутации в сильной мере, в не зависимости от того настроили вы FBL или нет. Обычно не рекомендуется превышать этот показатель более чем на 0.10% от отправленных писем. Мы рекомендуем не превышать его в среднем на 0.07%, так как могут возникнуть всплески жалоб от отдельных рекламных рассылок. Чтобы сократить этот показатель нужно повышать узнаваемость письма подписчиком, не затрагивать в содержимом писем темы, обсуждение которых может показаться неприемлемым для ваших подписчиков.

Abuse. Некоторые пользователи могут написать жалобу владельцу хостинга, IP или доменов которые вы используете. Также есть организации в сети следящие за соблюдением правил, например SpamCop. Сложно избежать подобных жалоб, и даже единицы их могут вызвать негативные последствия (отзыв IP, разделегирование доменных зон). Скорее всего хостер потребует от вас подтверждение того, что подписчик действительно дал согласие на подписку (оптин информацию). Поэтому важно хранить точную дату и время подписки, IP с которого она была совершена и URL по которому она была совершена.

Behavioral. Помимо кнопки "Это спам" провайдеры могут учитывать поведение пользователя при просмотре письма. Например переход по ссылке добавит положительный скоринг к вашей репутации. Рекомендуется максимально вовлекать подписчика в обратную связь с отправителем.

SoftBounces. Большое количество 4XX ошибок, вызванных из-за неадекватной реакции на них, могут вызвать снижение репутации IP. Необходимо грамотно установить правила блокировки и досыла писем.

Content. Содержимое писем также оказывает влияние. Наличие ссылок на скачивание вредоносных программ, запрещенная реклама (содержимое) может вызвать негативные последствия как для доменов, так и для IP.