Письмо уходит получателю, а через сутки выясняется, что оно лежит в папке « Спам ». Отправитель уверен, что дело в тексте или теме, и начинает переписывать заголовки. На практике фильтры почти никогда не оценивают письмо по одному содержанию: они смотрят на технические сигналы домена, репутацию IP и историю отправок. Именно поэтому легальная рассылка с правильным текстом может стабильно попадать в спам, а короткое уведомление от чужого сервера проходит во « Входящие ».
Проверять нужно инфраструктуру, а не гадать. Шесть шагов ниже закрывают то, что реально влияет на решение фильтра: PTR-запись, SPF с жестким -all, подпись DKIM, политику DMARC, ссылки в теле письма и репутацию IP. Отдельно стоит разобраться с приёмом почты на домене: catch-all домен и catch-all почта часто воспринимаются как удобная функция, но они же становятся источником проблем с доставляемостью, если настроены небрежно. Прежде чем что-то менять, полезно понять, что такое catch-all и зачем он вообще нужен.
Логика простая. MX-запись направляет всю входящую почту домена на один сервер. Catch-all принимает письма на любой нераспознанный адрес домена, тогда как без него почтовый сервер отвечает 550 no such user при отсутствии совпадений. Правило catch-all складывает все письма в единственный ящик, и пользователь забирает почту одним логином по POP3 или IMAP. Удобно для отлова опечаток в адресе и для единого ящика поддержки, но при этом в него попадает весь спам, адресованный несуществующим локальным частям. Если с этого ящика потом отвечают или пересылают письма, репутация домена страдает.
Держите в голове разделение: SPF, DKIM и DMARC влияют только на исходящую почту, а catch-all настраивается на почтовом сервере, а не в DNS. A-запись сопоставляет имя почтового хоста с IP-адресом, и это тоже часть картины, которую видит фильтр. Дальше разберем каждую проверку по порядку, с командами и типичными ошибками.
Почему письма попадают в спам: ключевые причины и логика фильтров
Письмо попадает в спам не потому, что фильтр « не любит » отправителя лично. Провайдер оценивает набор сигналов: совпадает ли IP отправителя с PTR-записью, проходит ли домен проверку SPF, подписано ли письмо DKIM, что говорит DMARC-политика, как давно существует домен и сколько жалоб на него было за последние недели. Каждый сигнал добавляет или снимает баллы. Когда сумма переваливает порог, письмо уходит в « Спам » или отклоняется на SMTP-уровне.
Самая частая причина – рассинхрон между тем, что заявлено в DNS, и тем, что реально отправляет сервер. Условно: домен обещает, что почту шлёт хост mail.example.ru с адреса 203.0.113.10, а рассылка идёт с общего IP хостинга, где рядом сидят ещё сотни сайтов. SPF не сходится, DKIM отсутствует, DMARC молчит. Для приёмного сервера это письмо от неизвестного отправителя с чужого адреса.
Второй пласт – репутация IP и домена. Крупные провайдеры держат собственные репутационные базы и дополнительно опрашивают внешние. Новый IP без истории получает осторожную оценку. IP, с которого месяц назад шёл спам, получает плохую. Даже легальная рассылка с такого адреса будет пробиваться в инбокс с трудом, пока репутация не восстановится. Это занимает недели, иногда месяцы.
Третий пласт – содержание и поведение. Резкие всплески объёма, высокая доля жалоб (даже 0,1% уже плохо), ссылки на домены из чёрных списков, картинка вместо текста, тема письма капсом. Фильтры смотрят и на это, но технические сигналы весят больше. Если PTR, SPF, DKIM и DMARC в порядке, письмо с неудачной темой чаще всего всё равно дойдёт.
Отдельно стоит сказать про входящую сторону, потому что её путают с исходящей. Настройки вида catch-all, MX-записи и маршрутизация на приём никак не влияют на то, попадёт ли ваше письмо в спам у получателя. SPF, DKIM и DMARC влияют только на исходящую почту: они подтверждают, что письмо отправлено с домена, которому вы доверяете право отправлять. Линкбилдинг, холодные письма и массовые рассылки проваливаются в спам не из-за « плохого текста », а из-за отсутствия этих подтверждений и слабой репутации IP.
Что реально проверяет приёмный сервер, когда получает письмо:
- PTR-запись IP отправителя: существует ли она и совпадает ли с именем, которое сервер представляет в HELO.
- SPF: разрешён ли IP в записи домена и с каким квалификатором (-all или ~all).
- DKIM: есть ли валидная подпись, сходится ли хеш тела и заголовков.
- DMARC: что предписывает политика при провале SPF и DKIM, есть ли отчёты.
- Репутация IP и домена по внешним базам и внутренней истории провайдера.
- Поведенческие признаки: объём, частота, доля жалоб, ссылки в теле.
Практический вывод простой: если письма регулярно оказываются в спаме, начинать надо не с текста, а с технического аудита. Проверьте, что PTR-запись указывает на почтовый хост, что A-запись сопоставляет имя этого хоста с IP-адресом отправки, что SPF заканчивается на -all и не содержит лишних include. Дальше – DKIM и DMARC. Пока эти четыре вещи не сходятся, любые правки в письме будут лечением симптома.
Что такое catch-all домен и catch-all почта: роль в доставляемости
Catch-all домен – это домен, на почтовом сервере которого включено правило « принимать всё ». Если письмо приходит на адрес, которого нет в списке ящиков, сервер не отвечает отказом, а кладёт его в заранее указанный ящик. Именно так работает catch-all почта: любая нераспознанная локальная часть превращается в получателя по умолчанию.
Без этого правила почтовый сервер отвечает 550 no such user. Отправитель получает bounce, письмо теряется. С catch-all оно доходит до администратора, который уже решает, что с ним делать. Для одних это страховка от опечатки в адресе, для других – источник мусора.
Как работает catch-all почта и где она настраивается
Разберём цепочку доставки по шагам. MX-запись направляет всю входящую почту домена на один сервер. A-запись сопоставляет имя почтового хоста с IP-адресом, чтобы отправитель мог достучаться до этого сервера. Дальше вступает маршрутизация почты внутри сервера: он ищет совпадение локальной части с существующим ящиком или алиасом.
Если совпадения нет, срабатывает резервное правило сервера. Оно и есть catch-all. Важный момент: catch-all настраивается на почтовом сервере, а не в DNS. В DNS вы задаёте только MX и A. Само правило живёт в почтовой панели хостинга, в конфиге Postfix или Exim, в настройках Google Workspace или Яндекс 360. Поэтому фраза « пропишите catch-all в DNS » – ошибка.
Схема работы выглядит так:
- Письмо приходит на адрес вроде info@, sales@ или вовсе на случайный набор символов.
- Сервер проверяет список ящиков и алиасов.
- При промахе срабатывает правило catch-all и складывает все письма в единственный ящик.
- Пользователь забирает почту одним логином по POP3 или IMAP, без отдельных учёток.
Настройка catch-all занимает минуты, но требует аккуратности. В панели обычно есть поле « адрес получателя по умолчанию » или галочка « принимать почту на несуществующие адреса ». Некоторые сервисы позволяют указать несколько адресов или включить фильтры по адресу получателя, чтобы раскладывать поток по папкам.
Теперь про доставляемость. Здесь легко перепутать причины и следствия. SPF, DKIM и DMARC влияют только на исходящую почту: они подтверждают, что письмо отправлено с вашего домена и не подделано. Catch-all на эти проверки не влияет никак. Он относится к входящей почте.
Но косвенная связь есть, и она неприятная. Включённый catch-all собирает весь спам, который летит на угаданные адреса. Если с этого же ящика потом отвечают или пересылают письма, растёт риск попасть в блок-листы. Второй риск – обратные рассылки (backscatter): сервер принимает письмо, потом не может доставить его дальше и шлёт bounce на поддельный обратный адрес. Такие bounce-сообщения бьют по репутации домена.
Для линкбилдинга и сбора контактов catch-all удобен: письма от площадок, которые придумывают адрес на ходу, не теряются. Для домена, с которого идёт регулярная исходящая почта, правило лучше держать выключенным либо закрывать его фильтрами и лимитами. Практика простая: catch-all – инструмент приёма, а не способ улучшить доставляемость. Доверие к домену отправителя строится на аутентификации и репутации IP, а не на том, принимаете вы письма на любой адрес или нет.
Настройка catch-all почты: пошаговый порядок действий
Настройка catch-all выполняется на почтовом сервере или в панели почтового сервиса, а не в DNS. Зону DNS вы трогаете один раз: MX-запись направляет всю входящую почту домена на один сервер, A-запись сопоставляет имя почтового хоста с IP-адресом. Дальше всё решается в интерфейсе, где живут ящики и правила маршрутизации. Ниже порядок действий, который работает на большинстве платформ.
Шаг 1. Определите ящик-приёмник. Правило catch-all складывает все письма в единственный ящик, поэтому сначала создайте его и решите, кто будет забирать почту одним логином по POP3 или IMAP. Не назначайте приёмником личный ящик руководителя: поток нераспознанных адресов быстро превратит его в свалку.
Шаг 2. Включите функцию в панели. В cPanel ищется раздел Email Deliverability или Default Address, где выбирается домен и указывается ящик для нераспознанной локальной части. В Plesk это Mail Settings, вкладка Catch-all Address, с переключателем на конкретный адрес. В Яндекс 360 и Mail.ru для домена опция называется « ловушка » или « принимать почту на любой адрес » и включается в настройках домена. В Google Workspace функции нет: там её имитируют через правила маршрутизации или группы, а штатный catch-all отсутствует принципиально.
Шаг 3. Проверьте, что MX-запись смотрит на нужный сервер. Если домен обслуживается внешним фильтром спама, catch-all настраивается на стороне фильтра, иначе письма до него просто не дойдут. https://allmail.one/ru/what-is-catch-all-email/ даёт больше информации по этому вопросу. Убедитесь, что приоритет MX корректен и вторичных записей, указывающих на старый хостинг, не осталось.
Шаг 4. Отправьте тестовые письма. Пошлите сообщения на три адреса: несуществующий (например, qwerty123@ваш-домен), адрес с опечаткой в популярном имени и реальный ящик. Все три должны оказаться в приёмнике. Если отправитель получил отказ 550 no such user, правило не применилось: проверьте, не перекрывает ли его фильтр по адресу получателя или отключённый ящик-приёмник.
Шаг 5. Настройте фильтры по адресу получателя. В приёмнике имеет смысл разложить поток по папкам: отдельно письма на info@, отдельно на случайные адреса. Так вы увидите, откуда приходит основной мусор, и не пропустите письмо от клиента, который ошибся в написании адреса.
| Платформа | Где искать | Особенность |
|---|---|---|
| cPanel | Default Address | Правило действует на весь домен |
| Plesk | Mail Settings, Catch-all | Можно указать внешний адрес |
| Яндекс 360 | Настройки домена | Требует подтверждения домена |
| Google Workspace | Нет штатной опции | Только через маршрутизацию |
Риски. Главный: объём спама вырастает в разы, потому что адрес-ловушка принимает всё подряд, включая словарные переборы. Второй: исходящая почта с такого ящика выглядит подозрительно, если вы отвечаете с несуществующего адреса. Третий: catch-all не влияет на SPF, DKIM и DMARC, эти записи касаются только исходящей почты, но наивно думать, что ловушка улучшит репутацию домена. Для линкбилдинга и сбора ответов на холодные письма ловушка удобна, для основного корпоративного домена чаще вредна: отказы 550 честнее показывают отправителю, что адрес неверный.
Как проверить корректность. Отправьте письмо с внешнего ящика (Gmail, Mail.ru) на заведомо несуществующий адрес и посмотрите заголовки: в поле Delivered-To должен стоять ящик-приёмник, в Received быть ваш MX. Затем проверьте обратный сценарий: письмо на реальный адрес не должно уходить в приёмник catch-all. Если оба теста прошли, настройка catch-all завершена.
Шесть проверок перед отправкой: PTR, SPF с -all, DKIM, DMARC, ссылки и репутация IP
Прежде чем нажимать « Отправить », прогоните домен по шести пунктам. Каждый проверяется за пару минут через открытые резолверы и веб-инструменты, и каждый закрывает конкретную причину попадания в спам. Пропустите хоть один, и фильтры получателя увидят неполную картину.
1. PTR-запись: имя, которое видит чужой сервер
Обратная зона (PTR) должна указывать на то же имя хоста, что и A-запись. A-запись сопоставляет имя почтового хоста с IP-адресом, PTR делает обратное. Проверка: dig -x 203.0.113.10 +short и dig mail.example.ru +short. Имена должны совпасть. Если PTR нет или он ведёт на провайдерский шаблон вида static-203-0-113-10.isp.ru, крупные провайдеры снизят оценку сразу. PTR меняется только через хостера, в панели DNS его не выставить.
2-4. SPF, DKIM и DMARC: три подписи одного письма
SPF перечисляет IP, которым разрешено отправлять от имени домена. Запись вида v=spf1 ip4:203.0.113.10 include:_spf.example.ru -all с жёстким -all означает: всё, что не перечислено, отклоняется. Мягкий ~all оставляет лазейку для подделок, поэтому для боевого домена берите -all. Ограничение: не больше 10 DNS-запросов при раскрытии include, иначе SPF ломается.
DKIM подписывает тело и заголовки приватным ключом, получатель сверяет публичный ключ в DNS по селектору. Проверьте, что селектор реально опубликован: dig selector._domainkey.example.ru TXT. Подпись должна стоять на каждом исходящем письме, включая транзакционные и автоответы.
DMARC связывает SPF и DKIM с доменом в поле From и задаёт политику: p=none для наблюдения, p=quarantine или p=reject для боевого режима. Начните с none и отчётов rua=mailto:dmarc@example.ru, через две-три недели переключайте на reject. SPF, DKIM и DMARC влияют только на исходящую почту, входящую они не фильтруют, и путать эти роли не стоит.
| Проверка | Что смотреть | Частая ошибка | Риск при провале |
|---|---|---|---|
| PTR | совпадение с A-записью хоста | PTR провайдера, имя не совпадает | отказ на этапе HELO |
| SPF | наличие -all, не более 10 DNS-запросов | две SPF-записи в домене | permerror, письма в спам |
| DKIM | селектор в DNS, подпись на письме | ключ отозван, селектор не опубликован | подпись не проверяется |
| DMARC | политика и адрес для отчётов | p=none оставлен навсегда | нет защиты от подделок |
| Ссылки | домены в теле письма | короткие ссылки, свежие домены | фильтр по URL-репутации |
Пятый пункт: ссылки. Фильтры разворачивают редиректы и смотрят на конечный домен. Сокращатели, домены младше пары месяцев и адреса из чёрных списков тянут письмо вниз даже при идеальной аутентификации. Держите в письме 1-3 ссылки на собственный домен, без редирект-цепочек.
Шестой пункт: репутация IP. Проверьте адрес через MXToolbox по разделам Blacklists и SMTP, заодно посмотрите историю отправки. Свежий IP без прогрева или адрес из подсети, где раньше рассылали спам, даст блокировки. Для рассылок берите отдельный IP, не смешивайте с корпоративной почтой.
Отдельно про приём: если на домене настроена catch-all почта, письма на любой нераспознанный адрес складываются в единый ящик. Это удобно для отслеживания опечаток в адресе и линкбилдинга, но приём почты на любой адрес привлекает спам, а ответы из такого ящика бьют по репутации основного домена. Лучше держать catch-all на поддомене, не на основном.
Регулярный мониторинг доставляемости и исправление типичных ошибок
Разовая настройка ничего не гарантирует. Репутация IP и домена меняется, чёрные списки обновляются ежедневно, а провайдеры корректируют фильтры без предупреждения. Поэтому доставляемость нужно измерять, а не предполагать. Минимальный набор: доля писем, попавших во « Входящие », жалобы на спам, доля отказов и позиция IP в публичных блок-листах. Смотрите эти метрики хотя бы раз в неделю, а при старте новой рассылки – ежедневно.
Практический способ отслеживать попадание в спам – завести ящики у Gmail, Mail.ru, Yandex и Outlook и включить в рассылку seed-адреса. Если письмо пришло в « Спам », вы увидите это раньше клиентов. Дополнительно проверяйте заголовки: строка Authentication-Results показывает, прошли ли SPF, DKIM и DMARC. Результат fail хотя бы по одному протоколу при живых записях – сигнал, что сломалась подпись или DNS.
Теперь о типичных ошибках. Первая и самая частая связана с catch-all. Администратор включает catch-all, чтобы не терять письма на нераспознанную локальную часть, и забывает, что резервное правило сервера складывает в единый ящик вообще всё: письма на любой адрес, включая опечатки в адресе при линкбилдинге и обращения к давно удалённым сотрудникам. Через месяц в ящике десятки тысяч сообщений, среди них спам и вирусы, а легитимные письма теряются в общем потоке. Лечение простое: заведите отдельный ящик только под catch-all, не смешивайте его с рабочей перепиской и раз в неделю просматривайте поступления.
Вторая ошибка – путаница между входящей и исходящей почтой. SPF, DKIM и DMARC влияют только на исходящую почту, то есть на то, поверят ли получатели вашему домену. На приём они не действуют. Если письма от вас уходят в спам, а catch-all настроен идеально, проблема не в приёме. Проверяйте подпись DKIM на реальном отправленном письме, а не в панели: селектор в DNS должен совпадать с тем, которым сервер подписывает сообщения.
Третья ошибка – неверная маршрутизация после смены хостинга. MX-запись направляет всю входящую почту домена на один сервер, A-запись сопоставляет имя почтового хоста с IP-адресом. Если A-запись указывает на старый IP, сервер отвечает 550 no such user или молчит, и письма теряются ещё до фильтров спама. Сверьте MX и A через dig или MXToolbox после любого переезда.
Четвёртая ошибка – отсутствие DMARC-политики или политика p=none без отчётности. Начните с p=none и rua-адреса, соберите отчёты за две недели, убедитесь, что все легальные источники проходят аутентификацию, затем переходите на p=quarantine. Резкий переход на p=reject без анализа отчётов отрезает часть легальной почты.
Пятая ошибка – игнорирование блок-листов. Проверяйте IP и домен в MXToolbox, Spamhaus и Barracuda. Попадание в список снимается заявкой на делистинг, но сначала устраните причину: открытый релей, взломанный ящик, слишком высокую частоту отправки. Иначе IP вернётся в список через несколько дней.
И последнее: не удаляйте письма из catch-all ящика автоматически. Сначала настройте фильтры по адресу получателя и выгрузите статистику, на какие адреса приходит больше всего мусора. Так вы увидите, где опечатки клиентов, а где атака, и отключите catch-all осознанно, а не по факту потери переписки.
Начните с одного действия, которое займёт пять минут: отправьте тестовое письмо с рабочего адреса на свой ящик у Gmail, Mail.ru и Яндекс.Почты и посмотрите заголовки. В Gmail нажмите « Показать оригинал », найдите строки SPF, DKIM и DMARC – все три должны содержать pass, а не neutral или none. Если хотя бы одна проверка провалилась, остальные шаги по настройке рассылки не имеют смысла: фильтры уже получили сигнал, что отправителю нельзя доверять. Заодно проверьте, что PTR-запись вашего IP резолвится в имя хоста, совпадающее с HELO, иначе часть провайдеров поставит письму лишний балл ещё до чтения темы.
Дальше заведите привычку раз в месяц прогонять домен через MXToolbox и Google Postmaster Tools. Смотрите на три цифры: долю писем в спаме, количество жалоб и объём входящей почты на catch-all. Если правило catch-all складывает в единый ящик больше сотни писем в сутки, а среди них половина – спам и опечатки в адресах, это повод сузить правило или отключить его: мусор в едином ящике повышает риск, что вы случайно ответите с того же домена на фишинговое письмо, а репутация домена просядет вместе с ним. Держите отдельный ящик для роботов (no-reply) и не отвечайте с него на входящие. И последнее: заведите журнал, куда записываете дату, IP и результат каждой проверки. Когда письма снова начнут падать в спам, вы будете сравнивать с известной точкой отсчёта, а не гадать, что сломалось. Настройка catch-all и аутентификации – это не разовая акция, а регламент, который либо работает, либо тихо разваливается.
