Перейти к основному содержимому
Altcraft Docs LogoAltcraft Docs Logo
Пользователям iconПользователям
Разработчикам iconРазработчикам
Администраторам iconАдминистраторам
Русский
  • Русский
  • English
Войти
    Документация пользователя
    С чего начать
    FAQ
    Термины
      Обновления платформыarrow
    • v2026.1.76
      v2025.4.75
      v2025.4.74
      v2025.3.73
      v2025.2.72
      v2025.1.71
      v2024.4.70
      v2024.3.69
      v2024.2.68.2
      v2024.1.68
      Хранение и сбор данныхarrow
    • Ресурсы подписок
      Работа с базами данных
      Профиль подписчика
      Импорт профилей клиентов и обновление данных
      Импорт данных по расписанию
      Автоматизация сбора данных о профиле
      Массовое обновление профилей клиентов
      Double opt-in подписка
      Стоп-списки
      Связи между профилями
      Экспорт истории профилей
      Экспорт профилей
      Автоматическое создание статического сегмента при импорте
      Как открыть CSV-файл
      Матчинг
      Типы полей в базе данных
      Глобальные контрольные группы
      Менеджер подписок
      Каналы коммуникацииarrow
      • Email-каналarrow
      • Рекомендации по взаимодействию с ISP
        Настройка собственного from-домена
        Настройка и использование постмастеров
        Быстрый старт
        Push-каналarrow
        • Mobile Pusharrow
        • Настройка и подключение
            Интеграция приложения с Altcraftarrow
          • Провайдеры: структура push сообщения
            Обработка и добавление подписки
            Регистрация событий
          Web Pusharrow
        • Предварительные настройки
            Настройка для различных браузеровarrow
          • Apple Safari
            Mozilla Services
            Firebase Cloud Messaging
          Подключение Web Push на сайт
          Передача данных в платформу
          Методы Web Push SDK
            Миграция и перенос подписокarrow
          • Перенос push-подписок из стороннего сервиса
            Как перенести push-подписки, настроенные для Safari
            Миграция с OneSignal
      SMS-канал
        Создание рассылки с нуляarrow
      • Email
        SMS
        Web Push
        Mobile Push
        WhatsApp
        Viber™
        Руководство: SMS-рассылка через VK Notify
        MAX Bot
        MAX Group
        Notify
        Telegram Bot
        Telegram Group
      Схема работы каналов коммуникации
      Руководство: SMS-рассылка через УТШ
      Руководство: push-рассылка через сервис от "Согласие"
      Сегментацияarrow
    • Статические сегменты
      Динамические сегменты
      Обновляемые сегменты
        Условия сегментацииarrow
      • Сегментация по данным профиля
        Сегментация по взаимодействиям с сущностями
        Сегментация по активности в каналах коммуникации
        Сегментация по внешним данным
        Сегментация по внешним SQL-таблицам
        Сегментация по структуре профиля
      Лучшее время отправки (BST)
      Логические операторы "И" и "ИЛИ"
      Рекомендации по работе с сегментами
      Шаблоны сообщенийarrow
      • Работа с шаблонами сообщенийarrow
      • Работа в редакторе
        Email-шаблон
        SMS-шаблон
        Push-шаблон
        MAX-шаблон
        Telegram-шаблон
        WhatsApp-шаблон
        Viber™-шаблон
        Notify-шаблон
        Визуальный редактор для email-шаблонаarrow
      • Интерфейс редактора
        Добавление элементов
        Элементы и их настройки
        Пользовательские блоки
        Стили элемента
        Структура элементов
      Блочный редактор для email-шаблона
      Фрагменты шаблонов
      Изображения в сообщениях
      Персонализация контента в сообщениях
      Формирование таблиц на основе элементов массива
        Переменные и функции Altcraftarrow
      • Использование логических выражений в сообщениях
        Использование циклов в сообщениях
        Использование переменных маркета в сообщениях
        Использование функционала JSONPath
        Динамический контент сообщенийarrow
      • Использование API-контента в сообщениях
        Использование HTML-контента в сообщениях
        Использование JSON-контента в сообщениях
        Использование контента из SQL базы данных в сообщениях
      Импорт и экспорт шаблона сообщения
      Экспорт шаблона из Pixcraft
      Импорт шаблона из стороннего сервиса
      Рассылкиarrow
    • Календарь рассылок
      Броадкаст рассылка
      Регулярная рассылка
      Триггерная рассылка
      Мультивариантный тест (A/B/n)
      Тестирование расылок
      Расписание рассылок
      Размещения
      Кампанииarrow
    • Работа с Кампаниями
      Локальные контрольные группы (ЛКГ)
      Расширение аудитории в кампании
      Разметка аудитории в кампаниях
      Сценарии автоматизацииarrow
    • Работа со Сценариями автоматизации
      Узлы сценария
      Классические сценарии автоматизации маркетинга
      Приветственный сценарий: пошаговая настройка
      Автоматическое оповещение менеджера через сценарий
      Сценарий брошенной корзины
      Маркетarrow
    • Настройки маркета
        Продуктыarrow
      • Создание продукта вручную
        Импорт продукта из файла
        Импорт по расписанию
        Сегменты продуктов и SKU
        Подготовка YML-файла
      Заказы
      Переменные маркета в шаблонах
      Руководство: как отправить письмо подтверждения заказа
      Лояльностьarrow
    • Создание и настройка программы лояльности
      Интеграция лояльности с внешними системами
      Быстрый старт
      Базовые кейсы использования программы лояльности
      Сегменты заказов
      Промокоды
      Веб-слойarrow
      • Формыarrow
      • Создание формы
        Конструктор формы
        Оформление формы
        Действия при активации формы
        Аналитика данных
        Связывание данных канала и формы
        Условная постраничная логика в формах и опросах
        NPS-тестирование
        Пикселиarrow
      • Целевые действия клиентов и скоринг
        Попапыarrow
      • Создание и публикация попапа
        Настройка попапа в редакторе кода
        Управление попапами вручную через скрипт
        Аналитика попапов
        Руководство: попап для подписки на push
        Базовые кейсы размещения попапа через Менеджер тегов
        Кейс: Создание попапа с виджетом "Колесо фортуны"
        Менеджер теговarrow
      • Настройка и установка Менеджера тегов
        Типы триггеров
        Типы переменных
        Связывание пикселя и Менеджера тегов
      Отчеты и аналитикаarrow
    • Отчет по каналам
      Отчёт по трафику
        Сводный отчётarrow
      • Все показатели сводного отчета
      Когортный отчёт
      Время жизни
      Воронка конверсии
      Цели
      Прирост аудитории
      Карта кликов (Email)
      Отчет по программам лояльности
      Отчёт о возвратах
      Отчёт о недоставках
      Отчет по глобальным контрольным группам
      Интеграцииarrow
    • Синхронизация статических сегментов
      MAX
      Яндекс.Аудитории™
      Аудитории Google Ads
      Facebook Ads Manager™
      Область видимости интеграции
      WhatsApp
      Viber™
      Tilda™
      Yandex AppMetrica™
      Lpgenerator™
      VK Реклама™
      Передаваемые при синхронизации данные
        Интеграция сторонних сервисов с Altcraft через Albatoarrow
      • Подключение Altcraft к Albato
        Запуск приветственного сценария через Albato
        Передача данных о событии
        Отправка триггерной рассылки
        Регистрация событий
        Импорт данных из Google Sheets через Albato
        Передача данных из Altcraft
      Notify
        Захват событийarrow
      • Захват событий Altcraft
        Типы событий для захвата
        Структуры сообщений захвата событий
        Отправить JSON-запрос батчем
        Отправить сообщение в очередь RabbitMQ
        Отправить сообщение в exchange RabbitMQ
        Отправить сообщение в Kafka broker
        Предварительное тестирование события
      Настройкиarrow
    • Настройки аккаунта
      Настройки атрибутов
      Поисковые теги: создание и применение
      Пользовательские ссылки
      Виртуальные сендеры
      Политики отправки
        Пользователи и разграничение доступаarrow
      • Двухфакторная аутентификация (2FA)
        Подключенияarrow
      • Подключение к Facebook Ads
        Подключение к Google Ads
        Подключение к Яндекс.Аудиториям™
        Подключение к 360dialog
        Подключение к Edna
        Подключение к Devino Telecom
        Подключение к SMS Traffic
        Подключение к VK Рекламе™
        Подключение к MTS OmniChannel
        Подключение через OAuth2
        Подключение через Basic Authentication
        Подключение через Token Authentication
        Подключение через Custom Authentication
        Подключение к MAX
        Подключение к Notify
        Подключение к Rapporto
      Журнал аудита
      API-запросы: с чего начатьarrow
    • Импорт и обновление профиля
      Запуск триггерной рассылки
      Отправка профиля клиента в сценарий
    Архив документации
    Библиотека email-маркетолога
  • Каналы коммуникации
  • Email-канал
  • Рекомендации по взаимодействию с ISP

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

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

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

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

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

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

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

ДоменТипЗапись
mx2.s1.example.comA1.1.1.1
mx2.s1.example.comA1.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.PTRmx1.s1.example.com
2.1.1.1.in-addr.arpa.PTRmx2.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
AOLhttps://postmaster.info.aol.com/fbl-request
Comcasthttp://feedback.comcast.net/
Coxhttp://fbl.cox.net/
Earthlinkfblrequest@abuse.earthlink.net
Excite (Bluetie)http://feedback.bluetie.com/
Fastmailhttp://fbl.fastmail.fm/
Hotmailhttps://postmaster.live.com/snds/
Outblazepostmaster@outblaze.com
Rackspacehttp://fbl.apps.rackspace.com/
Road Runnerhttp://feedback.postmaster.rr.com/
Spamcophttp://www.spamcop.net/reported.shtml
Synacorhttp://fbl.synacor.com/
Terra (Brazil)http://fbl.mail.terra.com.br/
Tucowshttp://fbl.hostedemail.com/
USA.nethttp://fbl.usa.net/
Yahoo!http://feedbackloop.yahoo.net/
ZOHOhttp://www.zoho.com/fbl/index.html
Mail.ruhttps://postmaster.mail.ru/
Yandex.ruhttp://yandexfbl.senderscore.net/
GmailSupport 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 и прочие.

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

ТипПример содержимого
SPFspf2.0/pra include:spf.akmta.net ip4:A.B.C.D -all
TXTspf2.0/pra include:spf.akmta.net ip4:A.B.C.D -all
TXTv=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 домене должен оказаться примерно следующий набор записей:

ПоддоменТипЗаписьКомментарии

SPFspf2.0/pra include:spf.akmta.net ip4:A.B.C.D -allДанный тип записи возможно не получится добавить на домен, так как он считается устаревшим. В таком случае просто пропустите его добавление, мы указываем его для дополнительной совместимости.

TXTspf2.0/pra include:spf.akmta.net ip4:A.B.C.D -allВ случае, если домен уже используется для рассылок, то необходимо добавить в SPF правило существующие рассыльные ресурсы (IP-Адреса)

TXTv=spf1 include:spf.akmta.net ip4:A.B.C.D -all
trkCNAMEtrk.aksend.net
_dmarcTXTv=DMARC1; p=none; rua=mailto:dmarc@example.com; sp=noneУкажите email ответственного лица за рассылки.
_domainkeyTXTo=-;
_policy._domainkeyTXTo=-;
ak._domainkeyTXTv=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.

Последнее обновление 4 дек. 2025 г.
Предыдущая страница
Email-канал
Следующая страница
Настройка собственного from-домена
  • Инфраструктура
  • Настройка обратной зоны (PTR)
  • Настройка сервера входящей почты для FBL/CFL
    • Список веб-страниц с формами регистрации FBL в ISP
  • Настройка цифровой подписи (DKIM)
  • Настройка Sender Policy Framework
  • Типичная настройка From домена
  • Репутация отправителя
© 2015 - 2026 Altcraft. Все права защищены.