Смена исходящего IP без падения доставляемости: постепенный перенос, повторный прогрев и мониторинг репутации
Смена sending IP — это не переключение A-записи за ночь, а управляемая миграция репутации. Разбираем параллельную работу двух IP в Postfix, взвешенное расщепление трафика, кривую прогрева с потолками на провайдера и приборную панель из Postmaster Tools, SNDS и разбора кодов отказа.
EvilMail Team28 июля 2026 г.11 мин чтения
Вы решили сменить исходящий IP: старый попал в UCEPROTECT, провайдер выделил чистый /32, или вы переезжаете на новую MTA. Инженер меняет smtp_bind_address, правит PTR, обновляет SPF, перезапускает Postfix и уходит домой. К утру очередь забита 421 4.7.0, Gmail кладёт письма в спам, а домен, который годами показывал High reputation, просел до Medium — и утянул за собой старый IP тоже.
Причина одна: репутация не переносится с адреса на адрес. Она набирается заново у каждого mailbox-провайдера в отдельности и привязана к паре «IP + From-домен». Новый /32 стартует с нуля доверия. Если в первый же час вылить на него 50k писем, Gmail и Outlook видят незнакомый источник с аномальным объёмом — классический паттерн скомпрометированного хоста — и включают троттлинг. Миграцию ведёт не DNS. Её ведут очередь MTA и графики репутации, а переключение должно оставаться обратимым в любой момент до самого конца.
Что переносится, а что нет
Прежде чем трогать конфиги, разделите две группы сущностей. Всё, что зависит от IP, придётся отстраивать заново. Всё, что не зависит, — переезжает бесплатно, и трогать его нельзя.
Не зависит от IP (не трогаем):
Миграция исходящего IP без потери доставляемости — прогрев и Postfix — EvilMail Blog
DKIM-подпись. Ключ и селектор живут в DNS домена, подпись проверяется по телу и заголовкам. IP отправителя в криптографию не входит.
DMARC-политика. Работает поверх выравнивания DKIM/SPF по домену, а не по адресу.
MTA-STS и TLS-RPT. Политика на mta-sts.evilmail.pro и репорты _smtp._tls завязаны на домен и хостнейм, не на конкретный IP.
Привязано к адресу (набираем заново):
Репутация IP у Gmail, Microsoft, Yahoo — у каждого своя, независимая.
PTR / FCrDNS — обратная зона нового адреса.
Присутствие в блок-листах (Spamhaus ZEN, Barracuda, SpamCop, UCEPROTECT).
Warmup-история — накопленный объём и паттерн отправки.
Практический вывод: домен не трогаем вообще. Селекторы DKIM те же, DMARC тот же, From тот же. Меняется только транспорт — физический адрес, из которого уходит TCP-соединение. Это единственная переменная миграции, и именно поэтому её можно вести плавно.
Подготовка нового IP до первого письма
Ни одно письмо не должно уйти с нового адреса, пока не закрыт весь чек-лист ниже. Провайдеры отбивают несогласованный FCrDNS ещё на этапе HELO, до всякой репутации.
Первое — замкнутый FCrDNS. PTR нового IP должен резолвиться в хостнейм, а A-запись хостнейма — обратно в этот же IP:
bash
# PTR: адрес -> имя
dig -x 198.51.100.20 +short
# mail.evilmail.pro.
# Прямая запись: имя -> адрес (должен совпасть с исходным IP)
dig +short mail.evilmail.pro
# 198.51.100.20
host 198.51.100.20
# 20.100.51.198.in-addr.arpa domain name pointer mail.evilmail.pro.
Если хотя бы одно звено не сходится — Gmail и Outlook отвечают 550-5.7.1 ... does not have a valid PTR record. HELO/EHLO, который анонсирует Postfix (smtp_helo_name), обязан совпадать с PTR буква в букву.
Второе — блок-листы. Свежий адрес из пула провайдера может уже висеть в UCEPROTECT L3 (он листит целые ASN) или в BRBL. Проверьте до старта и потом ежедневно:
bash
IP=198.51.100.20
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
for bl in zen.spamhaus.org b.barracudacentral.org bl.spamcop.net dnsbl-1.uceprotect.net; do
echo -n "$bl: "; dig +short $REV.$bl A | grep -q . && echo LISTED || echo clean
done
Третье — SPF. Расширяем запись заранее, чтобы оба адреса были валидны одновременно на всём протяжении миграции:
v=spf1 ip4:203.0.113.10 ip4:198.51.100.20 -all
SPF спокойно держит несколько ip4: — они не считаются DNS-запросами, так что лимит в 10 lookups вам тут не угрожает. Старый 203.0.113.10 остаётся до самого конца. И заранее опустите TTL PTR и релевантных записей до 300 секунд — на финале это сэкономит часы ожидания.
Архитектура параллельной отправки в Postfix
Суть подхода: один MTA гонит трафик через два IP одновременно, а вы регулируете долю нового адреса. Это делается двумя транспортами в master.cf, каждый со своим smtp_bind_address:
Отдельный syslog_name критичен: он даёт чистое разделение в mail.log, и весь мониторинг ниже строится именно на нём. Дальше нужен маршрутизатор. На старте прогрева, пока объёмы малы, проще всего гнать самые тёплые сегменты на новый IP явно — через transport_maps по домену получателя:
# main.cf
transport_maps = hash:/etc/postfix/transport
# /etc/postfix/transport — точечно на новый IP (не забыть postmap)
gmail.com smtp-newip:
Для взвешенного расщепления (когда нужно не «весь Gmail», а «10% всего трафика») ставьте перед Postfix балансировщик — рандомизированный роутер, который выбирает транспорт по хешу message-id с заданной вероятностью. Ключевой принцип: расщеплять по получателю/провайдеру, а не только глобальным процентом. Репутация считается per-provider, поэтому «10% на новый IP» должны означать «10% писем к Gmail, 10% к Outlook» — иначе вы прогреете адрес у Gmail, но так и не покажетесь Microsoft.
Кривая прогрева и расщепление трафика
Прогрев нового IP — это не «подождать неделю», а конкретное расписание с воротами-метриками между ступенями. Стартовая ставка — 50 писем в сутки на провайдера. Если по итогам суток spam rate ниже 0.1% и bounce ниже 2%, объём удваивается: 50 → 100 → 200 → 400. К концу первой недели здоровый IP держит порядка 1–2k писем в сутки на Gmail; Microsoft заметно консервативнее и любит 421-троттлинг даже на умеренных объёмах, поэтому его потолок держите ниже.
Параллельно растёт доля трафика, уходящая через новый транспорт. Рабочий график — 5 → 10 → 25 → 50 → 75 → 100% за 14–21 день. Первыми на новый IP переводите самые тёплые сегменты: получателей, которые стабильно открывают письма и не жмут «спам». Их вовлечение — тот сигнал, который строит репутацию быстрее всего. Холодные и реактивационные рассылки оставляйте на старом IP до последних ступеней.
Главное правило — откат на предыдущую ступень при деградации. Если у любого одного провайдера spam rate перевалил 0.3% или доля deferred по нему превысила 5% — возвращаетесь на прошлый процент, держите сутки, разбираете причину и только потом идёте дальше. Ступени существуют именно для того, чтобы откат стоил один день, а не всю миграцию.
Мониторинг репутации в реальном времени
Пока идёт прогрев, приборная панель проверяется каждый день. Четыре источника.
Google Postmaster Tools. Зарегистрируйте домен, следите за IP reputation и Domain reputation (шкала Bad/Low/Medium/High) и за User-reported spam rate. Рабочий порог — держать спам ниже 0.3%, тревога начинается уже при 0.1%. Падение IP reputation до Low на новом адресе во время прогрева — сигнал притормозить, а не ускориться.
Microsoft SNDS + JMRP. Обязательно зарегистрируйте новый IP в Smart Network Data Services и подпишите его на Junk Mail Reporting Program. Без этого вы не увидите жалобы пользователей Outlook и будете слепы к половине проблем. Microsoft отвечает на незнакомый IP 421 4.7.500-699 даже на малых объёмах — это ожидаемо на старте, но рост доли таких ответов означает, что вы давите слишком быстро.
Разбор `mail.log`. Благодаря отдельному syslog_name вы считаете deferred и bounce по каждому IP и провайдеру напрямую. Вот основной конвейер — топ доменов, которым письма откладываются:
452 4.2.2 — почтовый ящик получателя переполнен; не ваша проблема, из статистики репутации исключить.
DMARC RUA и TLS-RPT. Агрегатные отчёты подтверждают, что после смены IP SPF по-прежнему выравнивается (оба ip4: в записи), а TLS-соединения к новому хостнейму не деградировали.
Финализация и откат
Старый IP выводится только тогда, когда новый минимум 7 дней держит 100% трафика с зелёными метриками у всех провайдеров. Порядок финала строго такой:
1.Убедиться, что за неделю на 100% нет просадок reputation и всплесков 421.
2.Убрать старый ip4:203.0.113.10 из SPF, оставив только новый адрес.
4.Держать старый IP горячим ещё 2–3 недели как аварийный откат: конфиг транспорта smtp-oldip не удалять, минимальный трафик через него не прекращать, чтобы адрес не остыл.
Обратимость — главное свойство всей схемы. На каждой ступени откат сводится к возврату веса на предыдущий процент; на финале — к возврату старого ip4: в SPF и переводу веса обратно. Пока старый IP жив и прогрет, любая деградация нового лечится за минуты, а не за новую двухнедельную кампанию прогрева.
Чек-лист миграции
1.FCrDNS нового IP замкнут: dig -x → hostname → dig +short hostname возвращает тот же IP.
2.HELO/EHLO (smtp_helo_name) совпадает с PTR буква в букву.
3.Новый IP чист по Spamhaus ZEN, Barracuda, SpamCop, UCEPROTECT L1–L3.
4.SPF содержит обаip4: одновременно; TTL PTR/DNS снижен до 300s.
5.DKIM, DMARC, MTA-STS, TLS-RPT не тронуты — они IP-независимы.
6.Два транспорта в master.cf с раздельными smtp_bind_address и syslog_name.
7.Новый IP зарегистрирован в Google Postmaster Tools, Microsoft SNDS и JMRP.
8.Старт 50 писем/сутки/провайдер; удвоение только при spam <0.1% и bounce <2%.
9.Расщепление по провайдеру, не глобальным процентом; тёплые сегменты — первыми.
10.Ежедневный разбор mail.log по deferred/bounce на транспорт; ворота-метрики между ступенями.
11.Откат на шаг назад при spam >0.3% или deferred >5% у любого провайдера.
12.100% + 7 дней зелёного → чистим SPF от старого ip4: → старый IP горячим ещё 2–3 недели.
Смена IP надёжна ровно настолько, насколько вы готовы вести её медленно и с приборами перед глазами. DNS переключается за секунду — репутация строится неделями, и именно она, а не A-запись, определяет, увидят ли ваши письма адресаты.
