Електронна пошта: «554 spam detected» — очистіть репутацію без тижнів марнування

Що насправді означає «554 spam detected» (і чого не означає)

SMTP 554 — це постійна помилка. Фактично це означає, що сервер отримувача вирішив, що ваше повідомлення не варте прийняття — часто через спам-фільтри, збої автентифікації, політики, репутацію, моделі контенту або аномалії трафіку. «Spam detected» — дружнє пояснення; підставна причина може бути будь-якою — від невідповідного підпису DKIM до скомпрометованого хоста, що розсилає на неіснуючі адреси.

554 — це не корінна причина, це вирок

Уявіть 554 як «HTTP 403 Forbidden». Він каже, що запит відхилено, але не пояснює, чи це через облікові дані, репутацію IP чи вашу поведінку, що спричинила відмову. Деякі провайдери дають більше деталей в розширеному коді статусу (наприклад 5.7.1) і в текстовому рядку. Багато хто — ні. Ваше завдання — зіставити їхнє відхилення з вашими доказами: логи, DNS, заголовки, швидкості, відскоки та скарги користувачів.

Чого це не означає

• Не «скринька отримувача переповнена» (зазвичай це 552 або дефери 4xx).
• Не тимчасовий спайк у черзі, який можна «просто ретраїти завжди». Повторне надсилання 5xx як 4xx перетворює проблему доставляння на самонанесений DDoS для вашої ж репутації.
• Не вирішується купівлею нового домену щоразу. Ви можете це зробити, але тоді клієнти сприйматимуть вас як компанію, яка щотижня змінює ідентифікатор відправника.

І жарт, тому що нам доведеться тут посидіти: Доставляння — як гідрація — якщо ви чекаєте, поки спрагнієте, ви вже все зіпсували.

Плейбук швидкої діагностики (перші/другі/треті перевірки)

Це послідовність «маю 30 хвилин, щоб зупинити кровотечу». Не імпровізуйте. Не починайте з «переписати шаблон листа». Почніть з доказів, які розділяють ідентичність, репутацію і поведінку.

Перше: визначте, що відкидається (обсяг)

• Це один провайдер (тільки Gmail, тільки Microsoft), чи всі вони?
• Це один потік (маркетингова масова розсилка) чи все (транзакційні скидання)?
• Це один IP (новий вузол) чи весь вихідний пул?
• Це один домен (новий vanity-домен) чи всі домени відправника?

Рішення: якщо це один провайдер — зосередьтеся на політиці й сигналах саме цього провайдера. Якщо це всі — припускайте проблему з автентифікацією або відправним хостом.

Друге: перевірте вирівнювання автентифікації (SPF, DKIM, DMARC)

• Підтвердьте, що домен у полі From: вирівняний зі щонайменше SPF або DKIM (DMARC). Невирівнювання — найшвидший шлях виглядати як шахрай.
• Підтвердьте, що DNS правильний, публічний і не застарілий у випадках split-horizon.

Рішення: якщо вирівнювання не проходить — виправте DNS і підписування перед усіма іншими діями. «Прогрівання» зламаної ідентичності лише швидше навчить фільтри вам не довіряти.

Третє: перевірте репутацію та якість списків

• Шукайте сплески в обсязі, сплески в відскоках і спамні патерни одержувачів (рольові акаунти, збирані списки, випадкові домени).
• Перевірте попадання в блок-листи і чи має ваш IP коректний зворотний DNS та стабільний HELO/EHLO.

Рішення: якщо відскоки високі або ви потрапили в важливу блок-листу — призупиніть масовий трафік і ізолюйте транзакційну пошту на найчистішому шляху.

Четверте: лише потім дивіться на контент

Контент може мати значення, особливо для фішингових шаблонів, скорочувачів URL та дивного MIME. Але контент зазвичай не перший доміно. Розглядайте його як множник, а не корінь.

Цікаві факти та історія: чому поштові сервіси так поводяться

• Факт 1: SMTP передував сучасним контролям від зловживань; рання електронна пошта припускала дружню мережу. Антиспам додавали пізніше як двигуни політик і системи репутації.
• Факт 2: Перші широко вживані DNS-базовані блок-листи з’явилися наприкінці 1990-х як реакція на відкриті ретранслятори — системи, які пересилали пошту для будь-кого.
• Факт 3: SPF набув популярності на початку 2000-х як спосіб сказати «ці IP можуть надсилати від мого домену», але він ніколи не автентифікував вміст повідомлення — лише шлях конверту.
• Факт 4: Ідея DKIM — криптографічний підпис на рівні домену, щоб провайдери могли будувати репутацію на стабільній ідентичності, навіть якщо IP змінюються.
• Факт 5: DMARC (епоха близько 2012) змусив галузь піклуватися про вирівнювання — не просто «SPF пройшов десь», а «SPF/DKIM пройшли для того ж домену, який бачить користувач».
• Факт 6: Багато провайдерів вважають скарги на спам більш сильним сигналом, ніж відскоки. Один сердитий клієнт, що натиснув «Report spam», може перекреслити десятки доставок.
• Факт 7: Gmail та Microsoft використовують масивні поведінкові моделі: патерни відправлення, залученість, відсоток скарг та репутація по суміжних доменах і діапазонах IP.
• Факт 8: Доставляння по IPv6 досі неоднорідне; деякі отримувачі суворіші до IPv6, бо зловживання там легше масштабуються через великі адресні простори.

Реальні режими відмов, що стоять за 554

1) Автентифікація технічно «присутня», але оперативно зламана

Найболючіші інциденти — це коли SPF є, DKIM є, DMARC є… і ви все ще провалюєтесь через маленьке невідповідність: неправильний селектор, помилкова канонізація, невірна ротація ключів, шлях пересилання або невинний вендор, що надсилає від вашого імені без прав.

2) Репутація впала через поведінку трафіку, а не через контент

Провайдери ненавидять несподіванки. Новий IP, що зростає від 0 до 50k/день, виглядає як ботнет. Стабільний IP, що раптом починає надсилати на багато неіснуючих отримувачів, виглядає як покупка списків. Хост, що агресивно повторює 5xx, виглядає як такий, що не поважає політики або зламаний.

3) Зворотні NDR і віддача від неправильно налаштованих відскоків

Якщо ваша система генерує повідомлення про недоставку (NDR) на підроблені адреси, ви непомітно розсилаєте спам. Отримувачі це помічають. Вони не в захопленні.

4) Невідповідність ідентичності інфраструктури (PTR, HELO, TLS)

Поштові сервери судять як підозрілих мандрівників: ім’я, документи і історія мають збігатися. Якщо ваш зворотний DNS каже одне, ваш HELO — інше, а сертифікат TLS виглядає як виданий у підвалі, вам дадуть більше уваги.

5) Компроміс: один сервер, один ключ, один «корисний» скрипт

Класика: вебсервер зламано, атакувальник надсилає пошту через localhost або вкрадені SMTP-облікові дані, і ваш домен стає світовим джерелом неприємностей. Ви побачите сплески, дивні адресати і сердиті відмови. Розглядайте це насамперед як інцидент безпеки.

Другий жарт (і останній, за правилами): Нічого так не підвищує вашу «спамність», як надсилання 30 000 скидань пароля, яких ніхто не просив.

Практичні завдання: команди, виводи і рішення (12+)

Нижче — практичні завдання, які ви можете виконати на типовому Linux MTA-хості (приклади для Postfix, але більшість концепцій застосовні). Кожне завдання включає: команду, що означає вивід, і рішення, яке потрібно прийняти.

Завдання 1: Підтвердити точний текст відмови й розширений код статусу

cr0x@server:~$ sudo grep -E "status=bounced|status=deferred" /var/log/mail.log | tail -n 20
Jan 03 10:14:12 mx1 postfix/smtp[21844]: 3A1B012345: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=1.2, delays=0.1/0.0/0.4/0.7, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[142.250.102.26] said: 554 5.7.1 Message rejected as spam (in reply to end of DATA command))

Значення: Це жорстка відмова (5.7.1 політика/спам). «end of DATA» підказує, що SMTP-оболонку прийняли, але відкинули після оцінки контенту/політики.

Рішення: Припиніть повторні спроби для цих отримувачів; переключіться на перевірки автентифікації/репутації й ізолюйте потоки.

Завдання 2: Порахувати відмови по домену призначення (швидко знайти охоплення)

cr0x@server:~$ sudo awk -F'to=<' '/status=bounced|status=deferred/ {print $2}' /var/log/mail.log | awk -F'>' '{print $1}' | awk -F'@' '{print $2}' | sort | uniq -c | sort -nr | head
  412 gmail.com
  133 outlook.com
   58 yahoo.com
   21 icloud.com
    9 example-corp.com

Значення: Концентрація на великих провайдерах вказує на проблеми з репутацією/автентифікацією. Якби це був переважно один корпоративний домен, можливо, справа в політиці конкретного шлюзу.

Рішення: Пріоритезуйте виправлення для Gmail/Microsoft і перевірте глобальні сигнали ідентичності.

Завдання 3: Перевірити тренд вихідного обсягу (спайк?)

cr0x@server:~$ sudo grep "postfix/qmgr" /var/log/mail.log | awk '{print $1,$2,$3}' | uniq -c | tail -n 5
   98 Jan 03 10:10:01
  101 Jan 03 10:11:01
  544 Jan 03 10:12:01
  610 Jan 03 10:13:01
  588 Jan 03 10:14:01

Значення: Раптовий стрибок з ~100/хв до ~600/хв — ризик для репутації, особливо на новому IP.

Рішення: Обмежте швидкість зараз; якщо потрібно доставити критичну пошту, ізолюйте її на повільніший шлях з чистими списками.

Завдання 4: Підтвердити публічний IP, з якого ви справді відправляєте

cr0x@server:~$ curl -s ifconfig.me
203.0.113.45

Значення: Підтверджує IP NAT/egress. Багато команд дебагують неправильну адресу, бо egress хмари відрізняється від IP інстансу.

Рішення: Використовуйте цей IP для PTR-перевірок, перевірок блок-листів і інструментів postmaster-провайдерів.

Завдання 5: Перевірити зворотний DNS (PTR) — чи відповідає вашій ідентичності відправника

cr0x@server:~$ dig +short -x 203.0.113.45
mx1.mail.example.com.

Значення: У вас є PTR. Добре. Тепер переконайтеся, що пряма DNS для цього імені вказує на той же IP (наступне завдання).

Рішення: Якщо PTR відсутній або загальний, виправте з постачальником. Відсутність PTR не завжди фатальна, але часто множить «спамні» бали.

Завдання 6: Підтвердити Forward-confirmed reverse DNS (FCrDNS)

cr0x@server:~$ dig +short mx1.mail.example.com A
203.0.113.45

Значення: PTR і A запис узгоджуються. Така послідовність знижує підозри й уникає частини евристик приймача.

Рішення: Якщо не збігається — уніфікуйте. Уникайте PTR на одне ім’я й HELO на інше.

Завдання 7: Перевірити ім’я HELO/EHLO (має бути реальне й вирішуване)

cr0x@server:~$ sudo postconf -n | grep -E '^myhostname|^smtp_helo_name'
myhostname = mx1.mail.example.com
smtp_helo_name = $myhostname

Значення: Ім’я HELO стабільне й збігається з DNS-ідентичністю. Якщо HELO — «localhost» або випадкове внутрішнє ім’я, деякі приймачі вас оштрафують.

Рішення: Встановіть myhostname на ім’я з PTR і переконайтеся, що воно вирішується.

Завдання 8: Підтвердити SPF-запис для видимого From-домену

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g'
v=spf1 ip4:203.0.113.45 include:_spf.mailvendor.example -all

Значення: SPF явно дозволяє ваш IP та вашого вендора. -all — суворо (добре, коли правильно).

Рішення: Якщо ваш IP не авторизовано — додайте його (або виправте маршрут, щоб відправляти з дозволеної інфраструктури). Не залишайте SPF як ~all вічно зі страху — будьте коректні.

Завдання 9: Перевірити наявність публічного ключа DKIM (селектор)

cr0x@server:~$ dig +short TXT s1._domainkey.example.com | head -n 2
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Значення: Селектор DKIM s1 опубліковано. Якщо ви ротували ключі й забули DNS — DKIM мовчатиме про свої невдачі.

Рішення: Якщо відсутній — опублікуйте правильний ключ і впевніться, що ваш MTA підписує з тим самим селектором.

Завдання 10: Проінспектувати заголовки доставленого листа на результати SPF/DKIM/DMARC

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature" -n sample-headers.txt | head -n 20
12: Authentication-Results: mx.google.com;
13:        dkim=pass header.i=@example.com header.s=s1 header.b=abc123;
14:        spf=pass (google.com: domain of bounce@example.com designates 203.0.113.45 as permitted sender) smtp.mailfrom=bounce@example.com;
15:        dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
28: DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/relaxed; ...

Значення: Це золотий стандарт: SPF pass, DKIM pass, DMARC pass. Якщо ви бачите dmarc=fail, тоді як SPF/DKIM пройшли, вирівнювання зламане (звично з третіми відправниками, що використовують власний bounce-домен).

Рішення: Якщо DMARC не проходить — виправте вирівнювання: переконайтеся, що DKIM d= відповідає From-домену, або що MAIL FROM вирівняний.

Завдання 11: Перевірити DMARC-політику та адреси звітів

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g'
v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=s; aspf=s

Значення: Суворе вирівнювання (adkim=s, aspf=s) — чудово, якщо ви послідовні. Це болісно, якщо у вас є легасі-системи, що відправляють із субдоменів, або вендори без вирівнювання.

Рішення: Якщо ви провалюєтесь через суворе вирівнювання — або виправте відправників, щоб вирівняти, або тимчасово послабте до r під час міграції. Не залишайте його послабленим назавжди.

Завдання 12: Перевірити TLS-позицію, яку представляє ваш SMTP-сервер

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mail.example.com:25 -servername mx1.mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mx1.mail.example.com
issuer=CN = R3, O = Let's Encrypt, C = US
notBefore=Dec 10 00:00:00 2025 GMT
notAfter=Mar 10 23:59:59 2026 GMT

Значення: Дійсний сертифікат із адекватним CN і датами. Деякі приймачі оцінюють якість TLS. Більше того, зламааний TLS може спричинити пониження маршруту або дивні збої доставки.

Рішення: Якщо сертифікат прострочений або невідповідний — виправте це негайно — це проста гігієна репутації.

Завдання 13: Виявити backscatter (чи надсилаєте ви відскоки на підроблені відправники?)

cr0x@server:~$ sudo grep -E "postfix/bounce|postfix/local" /var/log/mail.log | grep -i "Undelivered Mail Returned to Sender" | tail -n 10
Jan 03 10:08:44 mx1 postfix/bounce[21201]: 9FEEA12345: sender non-delivery notification: 0ABCD12345
Jan 03 10:08:44 mx1 postfix/local[21202]: 0ABCD12345: to=<random.person@foreign-domain.tld>, relay=local, delay=0.1, dsn=2.0.0, status=sent (delivered to mailbox)

Значення: Ви генеруєте NDR. Ключове питання: ці NDR доходять до легітимних відправників чи до підроблених адрес? Якщо ваша система прийняла пошту, яку не мала б приймати (відкритий ретранслятор, відсутність валідації отримувача) — буде backscatter.

Рішення: Якщо є backscatter — посильте вхідну політику SMTP і валідацію отримувачів. Backscatter може викликати 554-реакції в інших місцях, бо ви стаєте «тим сервером».

Завдання 14: Перевірити, чи ваш сервер не є відкритим ретранслятором (найшвидший шлях усе зруйнувати)

cr0x@server:~$ sudo postconf -n | grep -E 'smtpd_recipient_restrictions|mynetworks|smtpd_relay_restrictions'
mynetworks = 127.0.0.0/8 [::1]/128 10.10.0.0/16
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain

Значення: reject_unauth_destination присутній: добре. Якщо його немає — можливо, ви ретранслюєте пошту для сторонніх.

Рішення: Якщо обмеження ретрансляції неправильні — виправте негайно і ротируйте будь-які скомпрометовані облікові дані. Припускайте компроміс, поки не доведено протилежне.

Завдання 15: Подивитися топ відправників/додатків (хто генерує пошту)

cr0x@server:~$ sudo grep "sasl_username=" /var/log/mail.log | awk -F"sasl_username=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  902 app-prod@example.com
  117 crm-sync@example.com
   44 legacy-batch@example.com

Значення: Один принципал відповідає за більшість трафіку. Якщо цей обліковий запис скомпрометований або неправильно налаштований — ви знайшли джерело проблеми.

Рішення: Обмежте швидкість або призупиніть топ-правопорушника; вимагайте ротацію облікових даних і розслідуйте шаблони відправлення.

Завдання 16: Обмежити одночасність виходу в Postfix (стабілізувати поведінку)

cr0x@server:~$ sudo postconf -e "default_destination_rate_delay = 2s"
cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 5"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf -n | grep -E "default_destination_rate_delay|smtp_destination_concurrency_limit"
default_destination_rate_delay = 2s
smtp_destination_concurrency_limit = 5

Значення: Ви зменшили сплески. Провайдери часто ставляться до плавнішого трафіку менш підозріло, і ви знижуєте побічну шкоду, поки ремонтуєте репутацію.

Рішення: Тримайте обмеження під час усунення неполадок. Потім підвищуйте обережно, орієнтуючись на рівень прийняття й сигнали скарг.

Три корпоративні міні-історії (як команди обпікаються)

Міні-історія 1: Інцидент через хибні припущення

Середня SaaS-компанія перевела вихідну пошту від керованого провайдера до «нашого власного Postfix», щоб заощадити. Припущення було щире: «Пошта — це просто SMTP; якщо вона виходить з нашого сервера, то все добре». Вони оновили SPF. Навіть опублікували DKIM-ключ. Потім почалися 554 — спочатку на скидання паролів, потім на рахунки, потім на onboarding.

On-call команда ганялася за контентом. Видаляли посилання. Переписували теми. Зробили листи менш привабливими, що вже досягнення. Відмови продовжувалися. Справжня проблема була в невидимій «водопровідній системі»: вони відправляли з From: example.com, але їхній bounce-домен (envelope MAIL FROM) був субдоменом вендора, що використовувався легасі-системою. SPF проходив для bounce-домену, DKIM проходив для іншого домену, і DMARC провалював вирівнювання. Для великих провайдерів це виглядало як підміна бренду в маскуванні.

Коли вони витягнули заголовки з кількох доставлених тестових повідомлень і порівняли з відкинутими — патерн сплив: маркетингова платформа була вирівняна; додаткова пошта — ні. Вони виправили envelope sender, щоб вирівняти з From-доменом, підписали DKIM з правильним d= і оновили DMARC до суворого лише після верифікації всіх відправників.

Втрата репутації не зникла миттєво, але кровотеча зупинилася за день. Урок залишився: доставляння — це не «пошта вийшла з сервера». Це «пошта прийшла з когерентною ідентичністю».

Міні-історія 2: Оптимізація, що повернулась бумерангом

Рітейл-компанія мала солідну репутацію і стабільний IP. Потім підійшов Black Friday і хтось зробив «правильну» оптимізацію: підвищити одночасність і прибрати затримки, щоб «черга швидше очистилась». MTA перейшов із рівномірного потоку в пожежний шланг. Кампанії закінчилось раніше. Усі були задоволені.

За кілька годин домени Microsoft почали відповідати 554 і варіантами 5.7.1. Gmail почав дефирити, а потім відкидати. Внутрішні консолі показували «успішно відправлено», бо додаток відстежував тільки передачу в MTA. Клієнти не бачили квитанцій. Підтримка загорілась. Фінанси помітили раніше за інженерів, що завжди весело.

Справжня шкода була не лише в обсязі — а в формі. Провайдери помітили раптову зміну поведінки: той же відправник, ті самі шаблони, але радикально інша швидкість і одночасність. Їхні моделі сприйняли це як скомпрометованого відправника, що намагається вистрілити, поки його не заблокували. Відкат одночасності допоміг, але відновлення репутації тривало довше, бо сплеск спричинив хвилю скарг («чому я отримую так багато листів одразу?»). Виправлення було непоказне: повернули ліміти, сегментували трафік за важливістю та планували маркетингові хвилі так, щоб вони виглядали як доросла система, а не панікуючий стажер з мегафоном.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Платіжна компанія мала два шляхи виходу: один для маркетингу, інший для транзакційних подій. Це здавалося зайвим. Трохи дорожче. Але це також запобігло великому класу відмов.

Одного дня CRM-інтеграція імпортувала брудний список. Відскоки зросли, і за кілька годин маркетинговий IP почав бачити блокування. Транзакційний потік — скидання паролів, квитанції, сповіщення про чарджбеки — продовжував доставлятись, бо використовував інший IP, інший envelope sender і суворіший allowlist систем, які могли надсилати пошту.

Тому що вони були дисципліновані, у них також були DMARC-звіти, що йшли на моніторовану пошту, і невеликий скрипт, що підсумовував рівні pass/fail. Команда помітила збільшення невирівняної пошти рано і призупинила інтеграцію до того, як петлі зворотного зв’язку провайдерів розхиталися. Вони почистили список, виправили шлях подачі інтеграції і відновили з графіком розігріву.

Ніхто не писав постмортем, що став вірусним. Ось у чому суть. Практика була нудною, правильною і тихо прибутковою.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: 554 тільки в Gmail, в інших переважно нормально

Корінна причина: Gmail особливо чутливий до репутації домену, залученості та вирівнювання. Часто це питання прогріву нового IP/домену або поганої гігієни списків.

Виправлення: Сповільніть відправлення, сегментуйте на найбільш зацікавлених одержувачів спочатку, перевірте вирівнювання DMARC, видаліть неактивні/неверифіковані адреси і тримайте транзакційну пошту чистою та стабільною.

2) Симптом: 554 починається відразу після переміщення на новий сервер/IP

Корінна причина: Холодна репутація IP. Провайдери не мають позитивної історії для вас, і ваш трафік виглядає як масова розсилка або скомпрометований сервер.

Виправлення: Прогрівайте: починайте з малого обсягу, з найякісніших одержувачів, поступове нарощування, стабільна ідентичність (PTR/HELO/TLS) і уникайте раптових стрибків.

3) Симптом: SPF проходить, але DMARC в заголовках провалюється

Корінна причина: SPF-прохід стосується домену envelope sender, а не вирівнюється з From-доменом; або DKIM підписує інший домен.

Виправлення: Вирівняйте ідентичності: зробіть DKIM d= відповідним From-домену або вирівняйте MAIL FROM з From-доменом і впевніться, що SPF авторизує відправний IP.

4) Симптом: Microsoft домени відкидають з 554/5.7.1 після маркетингової розсилки

Корінна причина: Рівень скарг і «вибухоподібний» трафік. Microsoft чутливий до раптових змін і поведінки «кампанії» від інфраструктури, що зазвичай надсилає транзакції.

Виправлення: Розділіть потоки. Не надсилайте маркетинг з інфраструктури транзакцій. Впровадьте обмеження на відправлення по домену і моніторинг скарг/відскоків.

5) Симптом: багато відскоків на неіснуючі одержувачі, потім блокування всюди

Корінна причина: Погана гігієна списку або скомпрометований відправник, що переліковує адреси. Високий відсоток неіснуючих адрес — сильний спам-сигнал.

Виправлення: Припиніть відправлення на невідомі адреси. Негайно приглушуйте hard-bounce’и. Впровадьте double opt-in або верифікацію для нових підписок. Розслідуйте компроміс.

6) Симптом: відмови кажуть «HELO/EHLO» або проблеми з hostname

Корінна причина: HELO-ім’я не вирішується, PTR відсутній або невідповідність між HELO і reverse DNS.

Виправлення: Встановіть myhostname в DNS-ім’я з A-записом, що відповідає IP, і переконайтеся, що PTR на нього вказує. Тримайте його стабільним.

7) Симптом: раптом вас вважають «відправником спаму», хоча ви нічого не змінювали

Корінна причина: Хтось інший змінив поведінку: нова інтеграція, петля повторів, відтворення черги або витік облікових даних.

Виправлення: Знайдіть топ-відправників, заморозьте підозрілі облікові записи, ротируйте облікові дані і перегляньте логи пошти за патернами (цілі, швидкість, помилки).

8) Симптом: «554 spam detected» після включення нового трекінгу або скорочувача посилань

Корінна причина: Репутація URL. Деякі домени редіректів сильно зловживані, і ваш контент успадковує цю погану репутацію.

Виправлення: Використовуйте брендові домени трекінгу з коректним DNS/автентифікацією; уникайте сумнівних скорочувачів; переконайтеся, що цільові домени мають добру репутацію і TLS.

Контрольні списки / покроковий план (повернення в inbox)

Фаза 0: Зупинити кровотечу (перші 1–2 години)

1. Розділіть критичну й некритичну пошту. Призупиніть маркетинг/масові розсилки. Тримайте транзакційну лише якщо вона чиста. Якщо не можете розділити — призупиніть усе й використайте тимчасово довіреного провайдера.
2. Обмежте швидкість виходу. Мета — «передбачувані, з низьким рівнем скарг», а не «швидко». Впровадьте destination rate delays і concurrency limits.
3. Перестаньте ретраїти жорсткі відмови. Трактуйте 5xx як кінцеві. Повторні спроби 5xx роблять вас виглядати як машина, що не вчиться.
4. Підтвердьте сигнали ідентичності. PTR, HELO, TLS сертифікат, SPF, DKIM, вирівнювання DMARC. Виправте очевидні розриви негайно.

Фаза 1: Тріаж доказів (той же день)

1. Витягніть вибірку відкинутих логів і згрупуйте за провайдером та текстом відмови.
2. Отримайте заголовки успішно доставлених повідомлень до кожного великого провайдера (seed-акаунти допомагають). Порівняйте результати автентифікації.
3. Обчисліть рівень відскоків і список жорстких відмов. Якщо ви вище низького одноцифрового відсотка в масових розсилках — припускайте проблеми списків. Для транзакційних — жорсткі відскоки мають бути рідкісними.
4. Визначте топ-відправників і шляхи коду. Шукайте одного винуватця: джоб, що вийшов з-під контролю, петля, скомпрометований токен або вендор, що неправильно маршрутизує пошту.

Фаза 2: Відновлення ідентичності (1–3 дні, часто швидше)

1. Виправте SPF, щоб він був правильним і мінімальним. Авторизуйте лише реальних відправників. Тримайте DNS-запити під лімітами, видаляючи зайві include.
2. Уніфікуйте підписування DKIM. Один-два селектори, ротація ключів за графіком, впевніться, що всі системи підписують з вирівняним d=.
3. Використовуйте DMARC навмисно. Якщо його немає — почніть з p=none для звітності і рухайтесь до quarantine/reject після верифікації вирівнювання. Якщо у вас вже p=reject — не панікуйте і не послаблюйте без потреби.
4. Стабілізуйте ідентичність інфраструктури. rDNS, HELO, стабільні вихідні IP і адекватний TLS.

Фаза 3: Відновлення репутації (дні-тижні, але можна скоротити)

1. Прогрівайте, як слід. Починайте з зацікавлених одержувачів. Поступово збільшуйте обсяг. Уникайте сплесків і раптових кампаній.
2. Чистіть списки агресивно. Негайно приглушуйте hard-bounce’и. Видаляйте неактивні адреси з масових розсилок. Віддавайте перевагу підтвердженому opt-in для нових підписок.
3. Постійно розділяйте потоки. Транзакційна пошта не повинна ділити IP/домени з маркетинговими вибухами. Якщо мусите ділити домен — сегментуйте принаймні за субдоменами та ключами підпису.
4. Інструментуйте доставляння як production. Відстежуйте acceptance rate, розподіли причин відскоків, результати по провайдерах і затримки в черзі. «Ми відправили» — не метрика успіху.

Фаза 4: Запобігання повторенню (постійно)

1. Керування змінами для пошти. Конкурентність, політики ретраїв, нові інтеграції, зміни шаблонів — це зміни в production. Переглядайте їх.
2. Моніторинг зловживань і компромісів. Алерт на аномалії обсягу, нові домени призначення і сплески невалідних отримувачів.
3. Runbook ротації ключів. Ротація DKIM має бути рутинною, а не раз на рік «генерацією проблеми».

Цитата з надійності, що застосовується

Сподівання — не стратегія — перефразована ідея, часто вживана в інженерії та операціях. Застосуйте її до пошти також.

FAQ

1) Чи завжди «554 spam detected» стосується контенту?

Ні. Контент може тригерити фільтри, але більшість «раптом 554» подій — це ідентичність або поведінка: провал вирівнювання, холодний IP, сплески відскоків або бурхливий трафік.

2) Чи варто негайно переходити на новий IP?

Лише якщо ви можете також виправити поведінку, що спричинила блокування. Новий IP з тими самими поганими списками, тим же невирівнюванням або тим же режимом сплесків буде знищений знову — часто швидше.

3) Чи можна «прогріти» шляхом надсилання всім адресам, що є?

Це не прогрівання; це підпал репутації. Прогрів працює, коли одержувачі реальні, залучені й очікують ваші листи. Починайте з найкращої когорти.

4) У чому різниця між SPF pass і DMARC pass?

SPF pass означає, що відправний IP авторизовано для домену envelope sender. DMARC pass означає, що SPF або DKIM пройшли і вирівнюються з видимим From-доменом.

5) Чому я бачу «in reply to end of DATA command» у відмові?

Це означає, що отримувач дочекався заголовків/тела (і інколи виконав перевірки контенту + репутації) перед відмовою. Це спрямовує вас до політики/репутації/контенту, а не до базової SMTP-зв’язності.

6) Якщо в мене DMARC p=reject, чи це спричинить 554-відмови?

Може — якщо ваші повідомлення провалюють вирівнювання. DMARC p=reject сам по собі не викликає відмову; відмова від DMARC — так. Виправлення — вирівнювання відправників, а не видалення DMARC.

7) Як захистити транзакційну пошту, коли маркетинг блокується?

Розділіть інфраструктуру й ідентичності. Принаймні: окремі IP та облікові дані подачі. Краще — окремі субдомени та селектори DKIM. Тримайте транзакційний обсяг стабільним і чистим.

8) Чому деякі одержувачі отримують пошту, а інші повертають 554?

Провайдери персоналізують фільтри. Історія взаємодії, локальні правила користувача і політики різні. Тому потрібна телеметрія на рівні домену і seed-тестування, а не анекдоти.

9) Чи варто знизити розмір ключа DKIM, щоб «покращити доставляння»?

Ні. Використовуйте сучасне, безпечне підписування (зазвичай 2048-bit RSA там, де підтримується). Доставляння не покращиться від ослаблення крипто; покращується від послідовності й довіри.

10) Скільки часу триває відновлення репутації?

Якщо проблема — зламана автентифікація або очевидні помилки — прийняття може покращитись того ж дня. Якщо ви зіпсували репутацію поганими списками або обсягами — очікуйте днів до тижнів, залежно від дисципліни ваших дій.

Висновок: наступні кроки, що справді працюють

Якщо ви дивитесь на «554 spam detected», ваш найшвидший виграш — не новий шаблон або тема листа. Це когерентна ідентичність плюс передбачувана поведінка:

1. Використайте плейбук швидкої діагностики: охоплення → вирівнювання → репутація/поведінка → контент.
2. Виправте вирівнювання SPF/DKIM/DMARC, щоб From-домен автентифікувався так, як очікують приймачі.
3. Стабілізуйте ідентичність інфраструктури: PTR, HELO, TLS, стабільний egress IP.
4. Обмежуйте швидкість і сегментуйте трафік. Призупиніть масове, захищаючи транзакційне.
5. Чистіть списки, ніби від цього залежить ваша робота — бо так і є.

Зробіть це, і ви припините марнувати тижні на свавільні переговори з фільтрами. Довіру доведеться заробляти заново, але ви робитимете це навмисно — а не випадково поглиблюючи проблему.