Електронна пошта «Адресу відправника відхилено»: виправлення автентифікації та політик

December 9, 2025 • February 3, 2026 • Читання: 6 хв • Views: 6

Було корисно?

Ви натиснули «відправити», і поштовий сервер відповів ударом: «Адресу відправника відхилено». Не відкладено. Не в черзі.
Відхилено. Таке повідомлення зазвичай падає вам на голову саме тоді, коли віце-президент намагається написати клієнту або коли додаток
масово відправляє скидання паролів у нікуди.

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

Що насправді означає «Адресу відправника відхилено»

«Адресу відправника відхилено» — це клас SMTP-відмов, а не одна конкретна помилка. Найчастіше ви побачите це
загорнуте в SMTP-код статусу, наприклад:

550 (постійна помилка): поштова скринька недоступна або політичне відхилення
553 (часто недійсна адреса відправника): «sender address rejected: not owned by user» або подібне
501/502 (синтаксис): неправильно сформована адреса, погані лапки, недозволені символи
554 (транзакція не вдалася): політика або фільтр контенту наклала вето

Ключове — де саме в SMTP-розмові це відбувається. Відмова на етапі MAIL FROM означає, що сервер не сподобався
envelope sender (Return-Path). Відмова на етапі RCPT TO може все ще згадувати відправника, але це часто
правило для конкретного отримувача. Відмова після DATA зазвичай вказує на сканування контенту, застосування DKIM/DMARC або проблему на наступному релеї.

Дивно поширена пастка: ви «виправили» поле From у поштовому клієнті, але відмова стосується envelope sender,
який фактично використовує ваш MTA або додаток. SMTP спочатку дивиться на конверт.

Одна цитата для запису на стікер

Надія — це не стратегія. — Джеймс Кемерон

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

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

Коли продакшн у вогні, ви не починаєте з філософської дискусії про RFC. Ви починаєте з найменшого набору перевірок,
які показують де відбувається відмова і яка ідентичність відхиляється.

Перше: визначте точну SMTP-відповідь і стадію

Отримайте повний текст bounce-повідомлення (DSN) або SMTP-транскрипт з логів вашого MTA/додатку.
Зверніть увагу на числовий код (550/553/554), розширений статус (наприклад 5.7.1) і текст повідомлення.
Підтвердьте, чи відбувається це на MAIL FROM, RCPT TO чи після DATA.

Друге: підтвердіть, про який «відправник» йдеться

Envelope sender (MAIL FROM / Return-Path): використовується для bounce-ів і SPF.
Header From: те, що бачать люди; використовується для DMARC-узгодження.
HELO/EHLO ім’я: іноді перевіряють щодо зворотного DNS та політики.

Третє: проведіть перевірки автентифікації та узгодження

SPF: чи присутній IP відправника у SPF-записі домену?
DKIM: чи підписане повідомлення і чи валідна підпис?
DMARC: чи проходить хоча б SPF або DKIM і чи узгоджується це з Header From?

Четверте: перевірте локальні політики та верифікацію в довідниках

Увімкнено перевірку відправника на приймаючому боці (callout verification, verify_sender)?
Чи вимагає приймач, щоб адреса відправника існувала локально (звично в закритих організаціях)?
Чи ретранслюєте ви через smart host, який несподівано переписує відправників?

Така послідовність швидко знаходить вузьке місце, тому що розділяє: (1) протокол/синтаксис, (2) невідповідність ідентичності, (3) помилку автентифікації,
(4) політичне примусове рішення. Не стрибайте до «це SPF», якщо сервер відкидає синтаксично недійсну адресу. Так, я бачив
user@@example.com у продакшні. Комп’ютери дуже буквальні й іноді дріб’язкові.

Кілька фактів та історія (щоб дивності стали зрозумілі)

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

SPF з’явився на початку 2000-х як спосіб прив’язати IP відправника до домену. Він ніколи не автентифікував «особу», лише шлях.
DKIM з’явився пізніше, широко впроваджувався близько 2007–2009 рр., щоб підписувати заголовки й тіло повідомлення, аби проміжні вузли не могли просто підробити ідентичність.
DMARC (приблизно 2012) зв’язав SPF і DKIM з доменом у Header From, бо користувачі не дивляться Return-Path, а зловмисники це швидко використовують.
Розподіл RFC 5321 vs RFC 5322: адреси конверта SMTP — одне правило, заголовки повідомлення — інше. Багато проблем «адресу відправника відхилено» походять саме від цього розриву.
Розширені коди статусу (RFC 3463) як 5.7.1 існують, щоб людям не доводилося гадати. На жаль, постачальники все ще пишуть поезію в текстовій частині.
Backscatter став великою проблемою, коли сервери перестали приймати пошту, яку не можуть доставити. Раннє відхилення тепер вважається ввічливим і безпечнішим.
Зміни політик Yahoo та AOL неодноразово штовхали індустрію вперед, вимагаючи автентифікацію й обмеження; великі постачальники поштових скриньок встановлюють де-факто стандарти.
Пересилка ламає SPF за визначенням, бо змінює IP відправника. Через це існують DKIM і ARC, і через це «адресу відправника відхилено» часто з’являється в ланцюжках пересилки.
Жорсткий DMARC став звичним, коли фішинг став масовим. Багато доменів публікують p=reject зараз; відмови вже не «м’які попередження».

Жарт #1: Безпека пошти — як швейцар на вході в нічний клуб: якщо ваше посвідчення розмите, ви не заходите, навіть якщо ви на обкладинці платівки гурту.

Таксономія відмов: який шар говорить «ні»

1) Синтаксис і валідність адреси

Це найчистіші помилки. Приймач відхиляє, бо адреса відправника має неправильний синтаксис або порушує локальні правила.
Поширені випадки: подвійний @, недозволені символи, відсутній домен, кінцева крапка, незакриті пробіли або домен, що не резолвиться.

2) Локальна авторизація відправника («вам заборонено надсилати від цього»)

Деякі приймачі приймають MAIL FROM тільки якщо він відповідає існуючому локальному користувачу, або вимагають автентифікованої відправки для використання домену.
Це з’являється як 553 5.7.1 Sender address rejected: not owned by user або схоже.

3) Перевірка відправника / callout checks

Приймач намагається перевірити вашу адресу відправника, підключаючись назад до MX вашого домену і перевіряючи, чи існує адреса.
Це крихке, повільне й іноді неправильне (greylisting, tarpitting, тимчасові помилки). Але така практика все ще зустрічається.

4) Політика автентифікації (SPF/DKIM/DMARC)

Приймач не подобаються результати автентифікації, або результати не узгоджуються з тим, що бачить користувач у From.
Це може відхилити на SMTP-етапі або прийняти й потім відкинути/карантинувати залежно від політики.

5) Репутація та антизловживальні бар’єри

«Адресу відправника відхилено» іноді є ввічливим замінником для «ваш IP у чорному списку» або «у домену погана репутація».
Деякі системи згортають кілька політичних відхилень у один загальний текст.

6) Внутрішній relay / переписування smart-host

Ваш додаток відправляє на ваш релей; релей переписує envelope sender; апстрім відкидає переписану адресу.
Ви годинами налагоджуєте додаток, а проблема у поштовій сантехніці.

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

Нижче — практичні завдання, які я реально виконую. Кожне містить (a) команду, (b) реалістичний вивід і (c) яке рішення прийняти.
Виконуйте їх з хоста відправника, релея або діагностичної машини. Мета — замінити здогади на докази.

Завдання 1: Зловіть SMTP-відмову в логах Postfix

cr0x@server:~$ sudo grep -E "reject:|Sender address rejected" /var/log/mail.log | tail -n 5
Jan 04 10:12:11 mailgw postfix/smtpd[18422]: NOQUEUE: reject: RCPT from app01[10.20.30.41]: 553 5.7.1 Sender address rejected: not owned by user; from=<alerts@corp.example> to=<user@partner.example> proto=ESMTP helo=<app01>
Jan 04 10:12:42 mailgw postfix/smtpd[18422]: NOQUEUE: reject: MAIL FROM<bounce@corp.example>: 550 5.1.8 Sender address rejected: Domain not found; from=<bounce@corp.example> proto=ESMTP helo=<mailgw>

Що це означає: Перше — політичне відхилення на етапі RCPT; друге — відхилення на етапі MAIL FROM через невіднайдений домен.
Рішення: Якщо текст «not owned by user», зосередьтеся на локальній авторизації відправника/submit auth. Якщо «Domain not found», виправте DNS для домену відправника.

Завдання 2: Відтворіть ручну SMTP-сесію (щоб побачити точну стадію)

cr0x@server:~$ nc -nv mx.partner.example 25
(UNKNOWN) [203.0.113.55] 25 (smtp) open
220 mx.partner.example ESMTP
EHLO mailgw.corp.example
250-mx.partner.example
250 PIPELINING
MAIL FROM:<alerts@corp.example>
553 5.7.1 Sender address rejected: not owned by user
QUIT
221 2.0.0 Bye

Що це означає: Відмова на MAIL FROM. Це не DMARC після DATA; це політика на рівні конверта.
Рішення: Припиніть крутити DKIM-заголовки. Виправте авторизацію envelope sender або використайте автентифіковану відправку, якщо це потрібно.

Завдання 3: Перевірте MX та A/AAAA записи домену відправника

cr0x@server:~$ dig +short MX corp.example
10 mx1.corp.example.
20 mx2.corp.example.
cr0x@server:~$ dig +short A mx1.corp.example
192.0.2.10

Що це означає: Домен резолвиться і має MX. Якби це було порожнім, деякі приймачі відхиляють з повідомленням «Domain not found» або провалюють перевірку відправника.
Рішення: Якщо MX/A відсутні або неправильні, виправте DNS перед тим, як міняти налаштування пошти.

Завдання 4: Перевірте зворотний DNS для відправного IP (поширений політичний бар’єр)

cr0x@server:~$ dig +short -x 192.0.2.25
mailgw.corp.example.
cr0x@server:~$ dig +short A mailgw.corp.example
192.0.2.25

Що це означає: FCrDNS збіг. Багато приймачів не відкинуть лист без цього, але деякі можуть.
Рішення: Якщо PTR/A відсутні або не збігаються, виправте PTR/A. Це дешевий спосіб підвищити довіру.

Завдання 5: Перевірте SPF-запис для домену, що використовується в `MAIL FROM`

cr0x@server:~$ dig +short TXT corp.example
"v=spf1 ip4:192.0.2.0/24 include:_spf.relayvendor.example -all"

Що це означає: SPF присутній і суворий (-all). Чудово — якщо тільки ваш відправний IP покритий.
Рішення: Якщо ваш вихідний IP або релей не включено, оновіть SPF або перенаправляйте пошту через авторизований релей.

Завдання 6: Оцініть SPF для конкретного IP за допомогою місцевого інструменту

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null
cr0x@server:~$ spfquery -ip 192.0.2.25 -sender alerts@corp.example -helo mailgw.corp.example
pass SPF check for alerts@corp.example: 192.0.2.25 is authorized to use 'corp.example'

Що це означає: SPF пройшов для домену envelope sender.
Рішення: Якщо SPF не проходить, або (a) виправте SPF, або (b) змініть MAIL FROM на домен, який авторизує відправника, або (c) відправляйте через правильний релей.

Завдання 7: Підтвердьте, який envelope sender фактично використовується (перевірка черги)

cr0x@server:~$ mailq | head -n 12
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
7C8F21A03B      2142 Fri Jan  4 10:20:01  alerts@corp.example
                                         user@partner.example

Що це означає: Черга показує envelope sender. Якщо ви очікували no-reply@corp.example, а бачите щось інше, ви знайшли невідповідність.
Рішення: Виправте налаштування MAIL FROM у додатку або правила переписування відправника у MTA.

Завдання 8: Перевірте переписування відправника в Postfix, яке може вас підводити

cr0x@server:~$ sudo postconf | grep -E "sender_canonical|smtp_generic_maps|masquerade|canonical_maps"
sender_canonical_maps = hash:/etc/postfix/sender_canonical
smtp_generic_maps = hash:/etc/postfix/generic
masquerade_domains = corp.example

Що це означає: Canonical і generic-мапи можуть переписувати відправників. Маскарадування також може змінити домени.
Рішення: Якщо переписування відправника веде до домену без коректного DNS/автентифікації, або оновіть DNS/автентифікацію, або зупиніть переписування.

Завдання 9: Подивіться вміст canonical-мапи (щоб знайти «допоміжне» переписування)

cr0x@server:~$ sudo postmap -q alerts@corp.example /etc/postfix/sender_canonical
alerts@corp.mail.invalid

Що це означає: Ви переписуєте в домен, що явно вказує на «хтось робив міграцію».
Рішення: Видаліть/підкоригуйте мапу. Потім перебудуйте мапи і перезавантажте Postfix.

Завдання 10: Безпечно перезапустіть Postfix після змін мап

cr0x@server:~$ sudo postmap /etc/postfix/sender_canonical
cr0x@server:~$ sudo postfix check
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ systemctl is-active postfix
active

Що це означає: Карти скомпільовано, конфіг перевірено, сервіс перезавантажено без рестарту.
Рішення: Якщо postfix check скаржиться, зупиніться і виправте перед перезавантаженням. Зламаний reload MTA під час інциденту — запобіжна трагедія.

Завдання 11: Перевірте, чи відбувається DKIM-підписування (приклад OpenDKIM)

cr0x@server:~$ sudo journalctl -u opendkim --since "10 minutes ago" | tail -n 5
Jan 04 10:25:10 mailgw opendkim[912]: 7C8F21A03B: DKIM-Signature field added (s=mail, d=corp.example)
Jan 04 10:25:10 mailgw opendkim[912]: 7C8F21A03B: signed message

Що це означає: Повідомлення підписуються для d=corp.example з селектором s=mail.
Рішення: Якщо підписування не відбувається, виправте підключення milтеру або конфіг ключів/таблиць перед тим, як звинувачувати DMARC.

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

cr0x@server:~$ dig +short TXT mail._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Що це означає: Селектор існує в DNS. Якщо його немає, приймачі не зможуть пройти DKIM.
Рішення: Опублікуйте правильний публічний ключ, перевірте відсутність проблем з розділеним DNS (split-horizon) і зачекайте TTL, якщо потрібно.

Завдання 13: Перевірте політику DMARC і очікування узгодження

cr0x@server:~$ dig +short TXT _dmarc.corp.example
"v=DMARC1; p=reject; rua=mailto:dmarc@corp.example; aspf=s; adkim=s"

Що це означає: Суворе узгодження для SPF і DKIM, і політика reject. Приймачі будуть суворими, якщо узгодження не відбувається.
Рішення: Якщо ви використовуєте сторонніх відправників, переконайтеся, що вони підписують вашим доменом (або делегованим піддоменом) або використайте узгоджений envelope domain.

Завдання 14: Підтвердьте, що приймаюча сторона виконує перевірку відправника (Postfix)

cr0x@server:~$ sudo postconf | grep -E "reject_unknown_sender_domain|reject_unverified_sender|verify_sender"
smtpd_sender_restrictions = reject_unknown_sender_domain, reject_unverified_sender
address_verify_map = btree:/var/lib/postfix/verify

Що це означає: reject_unverified_sender запускає callout verification/кешування. Це може відхилити легітимних відправників під час тимчасових DNS/MX збоїв.
Рішення: Якщо ви управляєте приймачем і бачите хибнопозитиви, розгляньте видалення reject_unverified_sender або звуження його дії.

Завдання 15: Проаналізуйте поведінку кешу верифікації адрес (щоб діагностувати хибні відхилення)

cr0x@server:~$ sudo postmap -s /var/lib/postfix/verify | head
sender@corp.example OK
bounce@corp.example DEFER
missing@corp.example REJECT

Що це означає: Кеш запам’ятовує результати. «DEFER» може перетворитися на «REJECT» залежно від політики й логіки повторних спроб.
Рішення: Якщо ви бачите багато DEFER/REJECT для валідних доменів під час збоїв, пом’якшіть перевірку або збільшіть таймаути обережно.

Завдання 16: Перевірте, чи відхиляють вас через політику HELO/EHLO

cr0x@server:~$ sudo postconf | grep -E "smtpd_helo_restrictions|reject_invalid_helo_hostname|reject_unknown_helo_hostname"
smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_unknown_helo_hostname

Що це означає: Приймачі іноді вимагають адекватності HELO. Якщо ваш додаток каже EHLO localhost з публічної IP, ви виглядатимете як спам.
Рішення: Встановіть коректне ім’я хоста в MTA і в SMTP-бібліотеці вашого додатку, якщо вона контролює HELO.

Виправлення автентифікації: SPF, DKIM, DMARC, узгодження

Почніть з моделі ідентичності: «Який домен ми стверджуємо?»

У вашої пошти щонайменше три ідентичності, які мають значення операційно:

Домен конверта (MAIL FROM): використовується SPF і для bounce-ів.
Домен у Header From: використовується для узгодження DMARC і це те, що бачать користувачі.
DKIM d= домен: домен підпису, який DMARC може узгодити з Header From.

«Адресу відправника відхилено» часто виникає через те, що ці ідентичності не синхронізовані. Чистий шаблон:

MAIL FROM використовує bounce@corp.example або bounces.mail.corp.example з SPF, що включає вашу інфраструктуру відправки.
Header From — corp.example (або послідовна політика піддоменів).
DKIM підписує з d=corp.example (або узгодженого піддомену) зі стабільним селектором.

SPF: зробіть його правильним, тримайте малим і не грайтеся з include

SPF перевіряє IP підключення проти SPF-запису домену envelope sender (або домену HELO у деяких випадках).
Приймач питає: «Чи дозволений цьому IP надсилати від імені цього домену?»

Практичні поради:

Віддавайте перевагу виділеним доменам конверта для масової/додатківської пошти (наприклад, bounce.mail.corp.example), щоб можна було змінювати інфраструктуру без торкання апекс-домену.
Тримайте лічильник DNS-запитів під контролем. SPF має ліміт у 10 DNS-пошуків для механізмів, що викликають запити (include, a, mx тощо). Перевищення — це permerror, яке багато приймачів трактують як провал.
Використовуйте «-all» лише коли впевнені. Якщо ви опублікували -all і забули одного відправника, ви створите власний інцидент.

DKIM: підписуйте те, що відправляєте, і не дозволяйте проміжним вузлам це мутувати

DKIM перевіряє, що вибрані заголовки й тіло були підписані доменом, який опублікував публічний ключ у DNS.
Воно витримує пересилання краще, ніж SPF, бо пересилка змінює IP, але не обов’язково контент.

Що ламає DKIM у реальному житті:

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

DMARC: узгодження — місце, де мрії вмирають

DMARC не цікавиться, якщо SPF проходить для випадкового домену конверта й DKIM проходить для випадкового домену підпису.
Їй потрібно, щоб принаймні одне з них було пройдене і узгоджене з доменом у видимому From.

Правила узгодження:

Розслаблене узгодження: піддомени можуть узгоджуватися (наприклад, mail.corp.example узгоджується з corp.example).
Суворе узгодження: має точно збігатися; піддомени не узгоджуються, якщо не однакові.

Якщо ви публікуєте aspf=s і adkim=s, ви обираєте життя, де кожен сторонній відправник має бути дуже ретельно налаштований.
Це нормально. Просто не робіть цього в п’ятницю.

Коли відмови відбуваються на етапі `MAIL FROM`, DMARC може бути не винуватцем

Багато хто звинувачує DMARC, бо це найновіша абревіатура. Але «Адресу відправника відхилено» на етапі MAIL FROM часто означає:

домен не резолвиться
приймач відмовляє у неавтентифікованому використанні домену
callout verification каже, що адреса відправника недійсна
локальна політика «приймаємо лише від наших партнерів»

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

Виправлення політик: перевірка відправника, allowlist, переписування і ліміти

Виправляйте переписування envelope sender із наміром, а не з надією

Переписування потужне і небезпечне. Це те, як ви мігруєте домени, стандартизуєте адреси і маршрутуєте bounce-и.
Це також спосіб випадково відправляти пошту від домену, яким ви більше не володієте.

Якщо переписування необхідне:

Переписуйте на домен, яким ви контролюєте, з коректним DNS (MX/A/PTR, де це важливо).
Переконайтеся, що SPF авторизує переписаний MAIL FROM домен.
Переконайтеся, що DKIM/DMARC узгодження залишається послідовним із Header From.

Перевірка відправника на приймачах: звучить добре, але зіпсує вам післяобід

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

Режими відмов:

Ваш MX тимчасово повільний: приймач вирішує, що ваш відправник недійсний.
Greylisting: приймач неправильно інтерпретує тимчасову відмову як «адреси не існує».
Ліміти: перевіркові запити виглядають як зловживання і потрапляють під обмеження.
Catch-all: перевірка марна, але додає затримку і ризик.

Allowlist: використовуйте точково, документуйте й видаляйте після закінчення

Якщо політика партнера надто сувора і потрібно відновити потік листів негайно, allowlist може бути практичним пластирем.
Але пластирі мають коріння. Робіть їх тимчасовими і підконтрольними.

Submission vs relay: припиніть дозволяти додаткам говорити з портом 25 у відкритий інтернет

Для корпоративних відправників використовуйте автентифіковану submission (зазвичай порт 587 з SMTP AUTH) до контрольованого релея.
Цей релей має бути єдиним, хто говорить з зовнішнім світом. Це спрощує політики, зменшує випадкове спуфінгування
і робить вашу історію SPF/DKIM послідовною.

Жарт #2: SMTP AUTH — як пропускна система; без неї будівля думає, що ви є єнотом з ноутбуком.

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

1) «553 Sender address rejected: not owned by user»

Симптом: Відхилено негайно на MAIL FROM з «not owned by user» або «sender unknown».
Причина: Приймач вимагає автентифікованої відправки для використання цього From/envelope домену або застосовує політику локальної власності відправника.
Виправлення: Використовуйте порт 587 з SMTP AUTH до приймача (якщо це ваш сервер), або ретранслюйте через організаційний автентифікований smart host. Якщо ви керуєте приймачем, пом’якшіть політику «owned by user» для довірених джерел.

2) «550 5.1.8 Sender address rejected: Domain not found»

Симптом: MAIL FROM домен відхилено, бо «не існує».
Причина: Домен envelope sender не має DNS, має зламану делегацію або використовує домен, що був виведений під час міграції.
Виправлення: Встановіть MAIL FROM на домен, що резолвиться. Додайте A/MX записи, якщо потрібно. Не використовуйте внутрішні домени у публічному інтернеті.

3) «550 5.7.1 SPF fail / Sender rejected»

Симптом: Приймач прямо вказує на провал SPF і відкидає або карантинує.
Причина: Підключений IP не авторизований у SPF для домену envelope; або SPF у стані permerror через надто багато запитів.
Виправлення: Додайте правильні IP/включення; зфлетуйте SPF, якщо потрібно; або змініть envelope домен на такий, що відповідає інфраструктурі відправки.

4) «550 5.7.1 DMARC policy reject»

Симптом: Повідомлення відхилено після DATA або прийнято, а потім відкинуто з посиланням на DMARC.
Причина: Домен Header From має p=reject; ні SPF, ні DKIM не проходять з узгодженням.
Виправлення: Забезпечте DKIM-підписання, яке узгоджується з Header From, або забезпечте, щоб SPF пройшов і узгоджувався (domен envelope). Якщо сторонній відправник — налаштуйте їх підписувати вашим доменом або використовуйте делегований піддомен.

5) «Sender rejected» лише при відправленні з додатку, а не з поштового клієнта

Симптом: Outlook/Apple Mail працює; додаток дає відмову.
Причина: Додаток використовує інший шлях SMTP, часто пряме підключення до MX через порт 25 без автентифікації, неправильний HELO і дивний envelope sender.
Виправлення: Змусьте додаток використовувати той самий автентифікований релей, що й користувачі (587), встановіть адекватний HELO/hostname і визначте стабільний envelope sender.

6) «Адресу відправника відхилено» після увімкнення шлюзу безпеки або додавання футера

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

7) Періодичні відмови під час збоїв

Симптом: Працює більшість днів; провали під час DNS-гіків або пікових навантажень на пошту.
Причина: Приймач використовує callout verification або жорсткі DNS-перевірки з агресивними таймаутами.
Виправлення: Якщо ви керуєте приймачем — налаштуйте або вимкніть перевірку відправника. Якщо ви відправник — зробіть DNS надійним і уникайте шаблонів, що викликають провали перевірки.

Чеклісти / покроковий план

Покроково: безпечно відновити потік пошти (режим інциденту)

Зберіть докази: зніміть SMTP-код, стадію і текст з логів або DSN.
Підтвердьте envelope sender з логів черги (не те, що показує ваш UI).
Підтвердьте наявність DNS для домену конверта: A/AAAA і/або MX, і що резолвери їх бачать.
Підтвердьте вихідний IP і що він відповідає очікуваному egress (без несподіваного NAT).
Перевірте SPF для домену конверта і авторизуйте вихідні IP/релей.
Перевірте DKIM-підписання на вихідному вузлі і наявність селекторів у DNS.
Перевірте DMARC-політику для Header From; переконайтеся, що стратегія узгодження підходить вашим відправникам.
Виправте переписування відправника, що вказує на застарілі/недійсні домени.
Тимчасово маршрутуйте через відомий робочий релей, якщо потрібно стабілізувати продакшн, поки ви лагодите DNS/автентифікацію.
Перевірте контрольовано (один отримувач у постраждалому домені) і спостерігайте логи.
Задокументуйте корінну причину і приберіть екстрені allowlist-и або винятки.

Чекліст для укріплення (щоб не переживати це знову)

Один санкціонований вихідний шлях для додатків (submission до релея), а не пряме підключення до MX.
Виділені домени конверта для масової/додатківської пошти з обмеженим SPF і стабільним DNS.
DKIM-підписування на фінальному вихідному вузлі, план ротації ключів і керування селекторами.
DMARC політика поетапно (none → quarantine → reject) з моніторингом, особливо після поглинань і підключення вендорів.
Зворотний DNS у відповідності з HELO; HELO не повинен бути «localhost» або випадковим ідентифікатором контейнера.
Контроль змін для будь-яких правил переписування і транспорт-мап. Рахуйте їх як конфігурацію маршрутизації, бо так воно й є.

Три міні-історії з корпоративного світу

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

Середня компанія мігрувала з локального релея до хмарного сервісу електронної пошти. План міграції покривав облікові записи користувачів і зміни вхідного MX.
Всі вітали одне одного. Графіки виглядали нормально. Потім система оповіщень перестала надсилати тригери on-call.

Хибне припущення було простим: «Якщо Outlook працює, значить SMTP працює». Outlook використовував автентифіковану submission до хмарного сервісу.
Система оповіщень була старим додатком, який надсилав напряму до MX партнерів через порт 25, з envelope sender у старому локальному домені.
Цей домен існував лише в чиїйсь пам’яті, але не в DNS.

Отримувачі відкидали на MAIL FROM з «Domain not found». Тим часом внутрішні користувачі не помітили, бо їхня пошта не йшла тим шляхом.
Команда додатку змінила видимий From, побачила це в логах і оголосила перемогу — тоді як envelope sender залишався поламаним.

Виправлення було нудним і миттєвим: направити додаток через офіційний релей на порт 587 з SMTP AUTH і встановити стабільний envelope sender,
що мав DNS і SPF. Справжнє виправлення було культурним: «пошта» — це не одна система, це кілька взаємодіючих систем. Ваш клієнт — не ваш додаток.

Міні-історія 2: Оптимізація, що відкотилась

Команда безпеки ввімкнула callout verification на вхідному шлюзі. Ідея була проста: менше підроблених відправників, менше сміття в черзі,
менше backscatter. Це працювало тиждень. Потім телефон служби підтримки почав виглядати як DDoS.

Постачальники рахунків почали періодично провалюватися. Декілька днів було все нормально; інші — «Sender address rejected» скрізь.
Шлюз перевіряв відправників, підключаючись до MX відправника і відправляючи RCPT TO перевірки — у масштабі, з агресивними таймаутами.

Сучасні MTA захищаються від збору адрес, тимчасово відхиляючи невідомих отримувачів, або застосовують greylisting на перше звернення.
Шлюз інтерпретував тимчасові відмови як докази того, що адреса відправника недійсна і кешував «REJECT». Вітаємо: ви оптимізували себе
в позицію відхилення легітимної ділової пошти.

Відкат був болючим, але необхідним. Остаточний підхід був сучаснішим: покладатися на SPF/DKIM/DMARC, репутацію і сканування контенту,
і залишити перевірку адрес тільки для вузьких випадків, де ви контролюєте обидва кінці. Перевірка шляхом зондування інтернету — не «безпека», це вгадування з сокетами.

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

Велика організація мала суворий процес змін для вихідних ідентичностей: кожен новий SaaS-відправник повинен був використовувати делегований піддомен
(наприклад notify.mail.corp.example) зі своїм SPF і DKIM-ключами під контролем компанії. Це було нудно. Це була паперова робота.
Люди скаржилися, звісно.

Потім вендор мав інцидент і почав надсилати з несподіваних IP-діапазонів. Приймачі почали відкидати ці повідомлення, бо SPF більше не збігався.
Це могло стати проблемою для бренду й служби підтримки. Натомість зона ураження була малою: постраждав лише піддомен вендора.

Вони тимчасово відключили цей піддомен, жорсткіше налаштувавши SPF, тоді як решта корпоративної пошти продовжувала текти.
Через сегментацію ідентичностей їм не довелося торкатися апекс-SPF або DKIM-ключів і не ризикувати зламати пошту керівництва.

Та практика не здавалася героїчною, коли її впроваджували. Вона здавалася бюрократією. Під час інциденту вона відчувалася як захисні ремені.
Найкращі операційні перемоги часто непомітні, поки не настане їхній день.

Глибока діагностика: зіставлення повідомлень про помилки з правильним виправленням

Розумійте різницю: envelope sender vs Header From

Якщо ви запам’ятаєте одну річ: envelope sender — це не те саме, що Header From.
Envelope sender є частиною SMTP-транзакції; його використовують для bounce-ів і SPF. Header From — частина повідомлення;
його використовують для відображення користувачу і для узгодження DMARC.

Багато систем охоче дозволять вам поставити красивий Header From, водночас залишивши нісенітний envelope sender.
Приймачі, що застосовують політики перевірки відправника, відхилять цю нісенітницю. І вони праві.

Розширені коди статусу мають значення

Якщо ви можете дістати розширений код статусу (частина 5.X.Y), робіть це. Він каже категорію:

5.1.x: проблеми з адресацією/статусом (домен не знайдено, неправильна адреса)
5.7.x: проблеми безпеки/політики/автентифікації (SPF/DKIM/DMARC, relay denied, sender not permitted)

Текст від постачальника різниться. Коди — це найщиріша підказка, яку ви отримаєте.

Практичні виправлення за середовищем (що змінити і де)

Postfix: типові ручки, що викликають «sender rejected»

smtpd_sender_restrictions: може містити reject_unknown_sender_domain, reject_unverified_sender або кастомні політики.
smtpd_recipient_restrictions: може приховувати перевірки відправника всередині політичних сервісів або access-мап.
sender_canonical_maps / smtp_generic_maps / masquerading: можуть переписувати відправників у недійсні домени.
smtpd_helo_restrictions: може відкидати через неадекватність HELO; в логах це все ще іноді фігурує як «sender rejected».

Exchange / Microsoft 365: патерни

В екосистемах Microsoft «sender rejected» часто пов’язане з:

спробою надіслати від адреси, для якої у вас немає права «Send As»
обмеженнями connector-ів, які вимагають автентифікованої відправки або конкретних IP
DMARC-спрямуванням вгорі при використанні кастомного домену зі суворою політикою

Операційно виправлення — те саме: визначити, яка ідентичність відхиляється (envelope чи header), потім узгодити дозволи,connector-и й автентифікацію.

Провайдери поштових сервісів і SaaS-відправники

Платформи SaaS люблять ставити Header From, що виглядає як ваш домен, одночасно використовуючи свої домени в envelope sender.
Це може працювати — поки ваша DMARC-політика сувора або приймач вимагає узгодження чи наявності домену.

Професійне рішення: дайте кожному вендору делегований піддомен з явними SPF і DKIM-контролями. Не дозволяйте їм підробляти ваш апекс-домен.

Поширені запитання

1) Чи завжди «Адресу відправника відхилено» — це проблема SPF/DKIM/DMARC?

Ні. Якщо відмова відбувається на MAIL FROM і згадується «domain not found» або «not owned by user», це може бути DNS або локальна авторизація.
Автентифікація — поширена, але не універсальна причина.

2) Який найшвидший спосіб відрізнити envelope sender від Header From?

Envelope sender видно в SMTP-транскрипті (MAIL FROM) і в чергах як «Sender». Header From — у заголовках повідомлення.
Якщо у вас є отримана копія, подивіться на Return-Path (envelope) проти From: (header).

3) Навіщо приймач відхиляє адресу відправника до того, як побачить вміст?

Політика. Деякі системи блокують невідомі/погані домени раніше, щоб зекономити ресурси і зменшити зловживання. Вони також можуть робити callout verification.
Ранні відмови — нормальна частина сучасного дизайну проти зловживань.

4) Мій SPF проходить, але мене все одно відхиляють. Чому?

SPF може проходити для домену envelope, тоді як DMARC все ще провалюється, якщо Header From не узгоджується. Також приймач може відкинути через репутацію,
синтаксис, авторизацію відправника або політику HELO/PTR навіть при проходженні SPF.

5) Чи ламається DKIM, коли ми додаємо дисклеймер-футер?

Може. Якщо футер вставляється після DKIM-підпису, підпис стає недійсним. Виправлення — підписувати після модифікації
(на фінальному egress) або припинити модифікувати підписаний контент.

6) Чи варто вмикати callout verification на вхідному шлюзі?

Зазвичай ні. Це створює крихкі залежності і хибні відхилення, особливо з greylisting і захистами від збору адрес.
Використовуйте SPF/DKIM/DMARC плюс репутацію і сканування контенту. Залиште верифікацію для вузьких внутрішніх випадків.

7) Чому пересилка викликає відхилення відправника?

Пересилка змінює IP відправника, тому SPF може провалитися. DKIM може пережити, якщо форвардер не змінює повідомлення.
DMARC може провалитися, якщо ні SPF, ні DKIM не проходять з узгодженням. Тому деяка переслана пошта відхиляється при суворих політиках.

8) Чи можемо виправити це, змінюючи лише видимий Header From?

Іноді так, але часто ні. Якщо приймач відкидає на MAIL FROM, зміна заголовка From не допоможе.
Виправте envelope sender і пов’язані з ним механізми автентифікації.

9) Що робити, якщо приймач помиляється і відкидає легітимних відправників?

Таке трапляється. Надішліть їм SMTP-транскрипт, докази DNS/автентифікації і запитайте, яка саме політика спрацювала (SPF/DMARC/sender verify).
Якщо ви контролюєте шлях відправлення, зазвичай ви можете адаптуватися швидше, ніж переконати партнера змінити свої правила шлюзу.

10) Чи варто використовувати окремий піддомен для транзакційної пошти?

Так, у більшості організацій. Це ізолює репутацію й політику, спрощує SPF і дозволяє змінювати вендорів без торкання основного домену.
Класичний «нудний, але правильний» крок.

Висновок: наступні кроки, які ви можете зробити сьогодні

«Адресу відправника відхилено» — це сигнал, що ідентичність і політика не узгоджуються десь між вашим додатком,
релеєм, DNS і правилами приймача. Сприйміть це як інцидент маршрутизації: знайдіть точний хоп і точну ідентичність,
потім виправте найменший зламаний контракт.

Зніміть один чистий SMTP-транскрипт і визначте стадію відмови.
Підтвердьте envelope sender, що використовувався на каналі (не в UI).
Спочатку виправте проблеми з існуванням DNS (MX/A, PTR/HELO).
Узгодьте SPF для домену конверта з реальними egress IP.
Переконайтеся, що DKIM-підписування відбувається на фінальному egress і селектори опубліковані в DNS.
Перевірте DMARC-політику й узгодження; сегментуйте вендорів у делеговані піддомени.
Вимкніть ризикову серверну верифікацію відправника на приймачі, якщо вона не потрібна.

Потім запишіть це. Не як постмортем-роман — лише стільки, щоб наступна людина не «виправила» заголовок From і не оголосила інцидент вирішеним.

Схожі статті

Зворотній DNS (PTR): чому ваша пошта страждає і як правильно виправити rDNS DMARC-звіти: як їх читати та вчасно виявляти підробки Електронна пошта: DKIM не проходить — чому підпис ламається (і як швидко виправити)