Пересилання електронної пошти ламає DMARC — виправте це за допомогою SRS (і інших варіантів)

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

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

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

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

Чому пересилання ламає DMARC (механічна відмова)

DMARC простий у концепції й жорсткий на практиці. Він ставить питання приймаючій системі:

Чи автентифікується це повідомлення через SPF і/або DKIM?
Чи співпадають автентифіковані ідентифікатори з доменом у полі «From:», яке бачить користувач?
Якщо ні — що робити згідно з опублікованою політикою DMARC від відправника?

Пересилання ламає першу частину цього ланцюга дуже конкретним способом: змінює IP-адресу з’єднання, що доставляє повідомлення, залишаючи видимий заголовок «From:» незмінним.

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

SPF оцінюється за IP-адресою підключення і доменом у конверті SMTP (Return-Path). Коли пересильник ретранслює повідомлення, саме він стає IP-адресою підключення. Якщо початковий відправник не уповноважив IP-адреси пересильника в SPF (а він цього не робив), SPF не проходить.

На цьому багато хто каже «але ж є DKIM». Так. І DKIM може вас врятувати — поки не перестає:

Якщо DKIM-підпис зберігається недоторканим і вирівнюється з доменом у From, DMARC може пройти, навіть якщо SPF не пройшов.
Якщо пересильник змінює повідомлення (підвал, теги в темі, перенесення рядків, повторне кодування MIME), DKIM може зламатися.

DMARC потребує лише одного із SPF або DKIM, щоб пройти і вирівнятися. Пересилання зазвичай призводить до відмови SPF. Розсилки та деякі «допоміжні» шлюзи часто ламають DKIM також. Ось вам і поломка DMARC.

Вирівнювання: частина, яку люди пропускають, а потім шкодують

Навіть коли SPF технічно проходить, DMARC може все одно не пройти через невідповідність вирівнювання. Вирівнювання порівнює домен, що автентифікувався (домен SPF або d= у DKIM), з доменом у видимому заголовку From.

Якщо ваш пересильник переписує відправника конверта, але робить це доменом, який не вирівнюється з доменом у From, DMARC все одно не пройде, якщо тільки DKIM не пройде і не вирівняється. Саме тому іноді кажуть «ми ввімкнули SRS, але це не допомогло»: SRS виправляє результати SPF, але не вирівнювання з From, якщо ви також не забезпечите вирівнювання DKIM або не погодитесь, що вирівнювання SPF буде з доменом пересильника.

Суха правда: DMARC не був створений, щоб полегшити пересилання. Він створений, щоб зробити підробку дорожчою. Пересилання — побічна шкода.

Жарт №1: Пересилання листів — це як пересилати чужу пошту вручну — рано чи пізно вас звинуватять у фальсифікації почерку.

Факти та коротка історія, що пояснюють нинішній безлад

Трохи контексту корисне, бо дебати про DMARC швидко стають емоційними, як спорт, релігія і формат конфігурації MTA, який вважається «читабельним». Ось конкретні факти, що формують проблему пересилання:

SPF перевіряє шлях, а не вміст. Він перевіряє звідки насправді надійшла пошта (IP підключення) відносно домену відправника в конверті.
DKIM перевіряє вміст, а не шлях. Підписує заголовки/тіло повідомлення; пересилання може зберегти підпис, якщо нічого не змінюється.
DMARC опубліковано як RFC у 2015 році (7489). Він уніфікував політику та звітність навколо SPF/DKIM і вирівнювання.
Пересилання існувало задовго до SPF/DKIM. Початковий модель SMTP припускала довіру між операторами. Той час минув.
Yahoo і AOL посилили DMARC у 2014 році. Розсилки зламалися голосно; індустрія почала серйозніше ставитись до DMARC, бо поштові скриньки раптово спорожніли.
Багато корпоративних шлюзів модифікують пошту «з міркувань безпеки». Дисклеймери, DLP-теги і повторне кодування контенту рутинно інвалідовують DKIM-підписи.
SRS існує до того, як DMARC став масовим. Воно створене, щоб зберегти SPF при пересиланні шляхом переписування відправника конверта.
ARC (Authenticated Received Chain) — більш новий. Це спосіб для проміжних вузлів підтвердити результати автентифікації, коли повідомлення трансформується.
Застосування політики DMARC керується приймачем. Навіть при «p=none» приймачі можуть застосовувати локальні політики; при «quarantine» або «reject» ваша переслана пошта під загрозою.

Режими відмов: що ламається, що виживає

Випадок 1: Просте пересилання, без змін

Типово: user@forwarder.example пересилає до user@gmail.com.

SPF у Gmail: не проходить (IP пересильника не авторизований доменом початкового Return-Path).
DKIM у Gmail: ймовірно проходить (повідомлення не змінювалося).
DMARC: проходить, якщо DKIM вирівняно з From.

Ось чому деякі пересилки «працюють добре» роками, поки постачальник не змінить селектори DKIM або ви не додасте підвал. Тоді все припиняє працювати.

Випадок 2: Пересильник додає підвал/дисклеймер

Поширено в корпоративній пошті: «Цей лист може містити конфіденційну інформацію…» додається внизу.

SPF: не проходить (з тієї ж причини).
DKIM: не проходить (тіло змінено).
DMARC: сильно не проходить, особливо якщо відправник опублікував «p=reject».

Випадок 3: Розсилки ламають DKIM і SPF

Розсилки часто:

переписують Subject (наприклад, «[list]»),
змінюють тіло (підвал, інфо про відписку),
відправляють через сервери списку.

Це ламає DKIM; SPF не вирівнюється, бо сервери списку не в SPF початкового домену. DMARC не проходить, якщо список не вжив заходів (переписування From, ARC або підпис з вирівнюванням DKIM, якщо можливо).

Випадок 4: «Зберегти From у заголовку, але змінити відправника конверта»

Це те, що робить SRS: воно переписує MAIL FROM / Return-Path, залишаючи заголовок From недоторканим.

Результат:

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

Це момент, який часто неправильно тлумачать на зустрічах. SRS в першу чергу запобігає відмовам на основі SPF і зменшує проблему зворотних повідомлень. Воно не робить вирівнювання DMARC з початковим From магічно правильним. Воно робить пересилання менш ламким, але не ідеальним.

SRS: виправлення, яке відповідає проблемі

SRS (Sender Rewriting Scheme) переписує SMTP-відправника в конверті так, щоб SPF перевірки виконувалися відносно домену пересильника. Це запобігає падінню SPF через те, що пересильник надсилає з власного IP. Також SRS гарантує, що bounce-повідомлення повертаються до пересильника, щоб він міг коректно маршрутизувати DSN назад до початкового відправника, замість створення зворотного спаму (backscatter).

Що конкретно змінює SRS

Перед пересиланням:

MAIL FROM: <alice@sender.example>
From: Alice <alice@sender.example>

Після пересилання з SRS (приклад):

MAIL FROM: <SRS0=hash=timestamp=sender.example=alice@forwarder.example>
From: Alice <alice@sender.example> (без змін)

Тепер приймаюча система оцінює SPF для forwarder.example відносно IP-адреси пересильника, і воно проходить. Ось і мета.

Чому SRS все ще варто впровадити

Бо без нього SPF гарантовано не проходитиме на пересланій пошті, якщо тільки початковий домен не зробив чогось незвичного. Відмова SPF не завжди фатальна для DMARC, але це велика частина історії автентифікації. З SRS ви принаймні припиняєте ламати SPF передбачуваними способами.

SRS не вирішує поломку DKIM

Якщо ваш пересильник змінює повідомлення (дисклеймери, переписування посилань, сканування вкладень із повторним кодуванням), DKIM все одно зламається. SRS тут не допоможе. Виправлення: перестати змінювати чужу пошту, або впровадити ARC, або переписати From (що політично болюче).

Де SRS має бути в архітектурі

SRS має жити на межі пересилання: там, де ви приймаєте повідомлення і потім надсилаєте його в інший домен, зберігаючи початковий From.

Не чіпляйте SRS скрізь на всі натягнуті шляхи вихідної пошти. Воно ускладнить налагодження і може заплутати обробку bounce-повідомлень. Використовуйте його лише для потоків пересилання.

Інші варіанти: збереження DKIM, ARC і «не пересилати»

Варіант A: Зберегти DKIM, не змінюючи повідомлення

Якщо ви можете пересилати пошту без змін, робіть це. Багато організацій ламають DKIM без потреби.

Приклади уникнутих дій, що ламають DKIM:

Додавання юридичних дисклеймерів до кожного вхідного повідомлення (ви не є власником контенту).
Переписування URL для трекінгу кліків у пересланій пошті (особливо для зовнішніх відправників).
Конвертування MIME-структур «для нормалізації».

Виберіть нудьгування. Нудне — надійне.

Варіант B: ARC для проміжних вузлів, що мають трансформувати пошту

ARC (Authenticated Received Chain) дозволяє проміжному вузлу зафіксувати результати автентифікації, які він побачив при отриманні повідомлення, і підписати цей запис. Нижчестоячий приймач може вирішити довіряти ARC-утвердженням проміжного вузла, навіть якщо DKIM згодом зламався.

ARC — не панацея:

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

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

Варіант C: Переписування From (як у розсилок)

Розсилки часто переписують заголовок From на домен, яким вони контролюють (наприклад «alice via list.example»). Це вирівнює автентифікацію з доменом, який список може підписати і авторизувати.

Технічно це «працює». Але змінює ідентичність, видиму користувачу, ламає роботу «Відповісти» і викликає політичні суперечки з інтенсивністю, звичною для планування офісних місць.

Варіант D: Припинити пересилання; використовувати належний делегований доступ

Якщо бізнес-процес пересилання базується на «я хочу читати корпоративну пошту в персональній скриньці», правильне рішення зазвичай — делегований доступ або налаштування клієнта, а не SMTP-пересилання.

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

Жарт №2: Єдина річ, що ще наполегливіша за пересланий лист, — це запрошення на зустріч, яке переслідує його скрізь.

Швидка діагностика — план дій

У вас є повідомлення: «переслані листи зникають» або «клієнти кажуть, що не отримали повідомлення». Не починайте з тривалого аналізу агрегатних DMARC-звітів. Почніть з одного невдалого повідомлення і пройдіть ланцюг.

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

Чи було воно прийняте вхідним MTA пересильника?
Чи було воно ретранслюване назовні пересильником?
Чи було воно відхилене або поміщене в карантин у кінцевого отримувача?

Другий крок: перевірте результати автентифікації на фінальному хопі

Результат SPF (pass/fail/softfail/neutral).
Результат DKIM (pass/fail, який d= домен підписав).
Результат DMARC (pass/fail, який ідентифікатор вирівняний).

Третій крок: підтвердіть, чи змінив пересильник вміст

Порівняйте заголовки і тіло до/після пересилання, якщо можливо.
Шукайте дисклеймери, теги в темі, зміни MIME-границь.
Перевірте, чи «переписував посилання» якийсь пристрій безпеки.

Четвертий крок: оберіть виправлення залежно від відмови

SPF не проходить, DKIM проходить: можна впровадити SRS для підвищення стійкості, але можливо ви вже проходите DMARC через DKIM. Вирішуйте залежно від частоти поломок DKIM у вашому середовищі.
SPF не проходить, DKIM не проходить: потрібно припинити змінювати вміст або впровадити ARC чи переписати From. SRS сам по собі не допоможе.
SPF проходить, DMARC не проходить: проблема вирівнювання — ваш автентифікований домен не вирівнюється з заголовком From. Виправте вирівнювання DKIM або змініть стратегію переписування.

Парафразована ідея (Werner Vogels): «Усе ламається; проектуйте так, щоб можна було швидко виявити і автоматично відновитися». Це більше стосується поштових потоків, ніж кому б не хотілось.

Практичні завдання з командами, виводом і рішеннями

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

Завдання 1: Підтвердити політику DMARC для домену відправника

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

Що це значить: Відправник просить приймачів відхиляти повідомлення, що не пройшли; суворе вирівнювання для DKIM і SPF.

Рішення: Якщо ви пересилаєте пошту з цього домену, потрібно зберегти вирівнювання DKIM або очікувати відхилення. SRS не вирівнює SPF з sender.example.

Завдання 2: Перевірити SPF запис відправника (щоб зрозуміти, чому пересилання не працює)

cr0x@server:~$ dig +short TXT sender.example
"v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example -all"

Що це значить: Дозволені лише перелічені IP-діапазони і провайдер. Ваш пересильник там відсутній.

Рішення: Очікуйте невдачу SPF після пересилання, якщо не застосуєте SRS (або поки відправник не додасть ваш пересильник, чого зазвичай не станеться).

Завдання 3: Переконатися, що домен пересильника має SPF, що дозволяє його власні вихідні IP

cr0x@server:~$ dig +short TXT forwarder.example
"v=spf1 ip4:198.51.100.10 -all"

Що це значить: Ваш пересильник має право надсилати пошту від свого домену.

Рішення: SRS можна прив’язати до forwarder.example, бо SPF пройде для вашого вихідного IP.

Завдання 4: Перевірити Authentication-Results у фінальному отримувачі

cr0x@server:~$ grep -iE 'authentication-results|dmarc=|spf=|dkim=' message.eml | head -n 8
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of alice@sender.example does not designate 198.51.100.10 as permitted sender) smtp.mailfrom=alice@sender.example;
       dkim=pass header.i=@sender.example header.s=s1 header.b=abc123;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sender.example

Що це значить: SPF не пройшов через IP пересильника, але DKIM пройшов і вирівнявся, тому DMARC пройшов.

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

Завдання 5: Перевірити логи Postfix на відмови у наступному хопі

cr0x@server:~$ sudo grep -E "status=bounced|reject:|dmarc" /var/log/mail.log | tail -n 10
Jan 03 10:22:11 mx postfix/smtp[24190]: 9C2B81234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=1.2, delays=0.1/0.0/0.6/0.5, dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[142.250.102.27] said: 550-5.7.26 This message does not pass authentication checks (SPF and DKIM both fail) 550-5.7.26 and has a DMARC policy of reject. (in reply to end of DATA command))

Що це значить: Кінцевий отримувач відхилив через невдачу DMARC; і SPF, і DKIM не пройшли.

Рішення: Якщо DKIM ламається через модифікацію, SRS цього не вирішить. Знайдіть, що змінило повідомлення, або впровадьте ARC / припиніть трансформації.

Завдання 6: Підтвердити, чи ви модифікуєте повідомлення (заголовки/тіло) в транзиті

cr0x@server:~$ sudo postconf -n | egrep 'header_checks|body_checks|milter|content_filter'
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
header_checks = regexp:/etc/postfix/header_checks
content_filter = smtp-amavis:[127.0.0.1]:10024

Що це значить: Milters і контент-фільтри активні; header_checks можуть переписувати; amavis може повторно кодувати.

Рішення: Припустіть, що DKIM іноді ламається. Або обходьте фільтри для пересилань, або зберігайте DKIM, або додавайте ARC і приймайте операційні витрати.

Завдання 7: Перевірити, чи header_checks додають дисклеймери або теги

cr0x@server:~$ sudo sed -n '1,120p' /etc/postfix/header_checks
/^Subject:/ PREPEND X-Company-Notice: scanned
/^From:/    PREPEND X-Forwarded-By: forwarder.example

Що це значить: Ви змінюєте заголовки. Модифікація заголовків може інвалідовувати DKIM, якщо змінений заголовок був підписаний.

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

Завдання 8: Переконатися, що потік пересилання використовує виділений транспорт (щоб застосувати SRS вибірково)

cr0x@server:~$ sudo postconf -n | egrep 'transport_maps|sender_dependent_default_transport_maps'
transport_maps = hash:/etc/postfix/transport

cr0x@server:~$ sudo postmap -q user@forwarder.example /etc/postfix/transport
forward-srs:

Що це значить: Цей отримувач маршрутується через спеціальний транспорт з назвою forward-srs.

Рішення: Добре. Ви можете застосувати SRS тільки до цього транспорту, замість переписування всього і створення нових загадок.

Завдання 9: Встановити та увімкнути підтримку SRS (приклад: postsrsd)

cr0x@server:~$ sudo apt-get update
...output...
cr0x@server:~$ sudo apt-get install -y postsrsd
...output...
Setting up postsrsd (1.10-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/postsrsd.service → /lib/systemd/system/postsrsd.service.

Що це значить: postsrsd встановлено і увімкнено як системну службу.

Рішення: Продовжуйте конфігурувати Postfix, щоб викликати демон SRS, але тільки для шляхів пересилання, якщо можна.

Завдання 10: Перевірити, що postsrsd працює і слухає

cr0x@server:~$ systemctl status postsrsd --no-pager
● postsrsd.service - PostSRSd
     Loaded: loaded (/lib/systemd/system/postsrsd.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-01-03 10:12:44 UTC; 8min ago
   Main PID: 1827 (postsrsd)
     Tasks: 1
     Memory: 1.2M
     CGroup: /system.slice/postsrsd.service
             └─1827 /usr/sbin/postsrsd -d -p 10001 -s forwarder.example

Що це значить: Демон запущено і налаштовано з SRS-доменом forwarder.example, слухаючи порт 10001.

Рішення: Ви можете вказати Postfix sender_canonical_maps або виділений сервіс cleanup на нього.

Завдання 11: Налаштувати Postfix для використання SRS для переписування відправника конверта (приклад шаблону)

cr0x@server:~$ sudo postconf -n | egrep 'sender_canonical_maps|sender_canonical_classes|recipient_canonical_maps'
sender_canonical_classes = envelope_sender
sender_canonical_maps = tcp:127.0.0.1:10001

Що це значить: Postfix переписуватиме відправника конверта через TCP-меп (postsrsd) для всієї пошти, що використовує sender_canonical_maps.

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

Завдання 12: Перезавантажити Postfix і підтвердити коректність конфігурації

cr0x@server:~$ sudo postfix check
...output...
cr0x@server:~$ sudo systemctl reload postfix
...output...

Що це значить: Postfix прийняв конфігурацію.

Рішення: Перейдіть до контрольованого тесту: пересилайте підписане повідомлення з домену зі суворим DMARC і перевіряйте Return-Path та результати автентифікації.

Завдання 13: Надіслати тестове повідомлення і підтвердити, що переписування SRS відбулося

cr0x@server:~$ sudo grep -E "from=<|to=<|srs" /var/log/mail.log | tail -n 20
Jan 03 10:28:01 mx postfix/cleanup[25102]: 1A2B312345: message-id=<test-170428@sender.example>
Jan 03 10:28:01 mx postfix/qmgr[901]: 1A2B312345: from=<SRS0=HHH=TT=sender.example=alice@forwarder.example>, size=18234, nrcpt=1 (queue active)
Jan 03 10:28:02 mx postfix/smtp[25106]: 1A2B312345: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, dsn=2.0.0, status=sent (250 2.0.0 OK ...)

Що це значить: Відправник конверта був переписаний в SRS0=…@forwarder.example, і повідомлення було прийняте Gmail.

Рішення: Ви зменшили поломки пов’язані зі SPF. Тепер перевірте результат DMARC на боці отримувача; якщо DKIM ламається через модифікації, SRS не вирішить проблему.

Завдання 14: Переконатися, що ви не створюєте умови відкритого ретранслятора під час «виправлення пересилання»

cr0x@server:~$ sudo postconf -n | egrep '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, defer_unauth_destination

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

Рішення: Залишайте так. SRS додає легітимність вашій вихідній пошті; не бажаєте, щоб зловмисники скористалися цією легітимністю.

Завдання 15: Шукати ознаки, що DKIM ламається через трансформаційні пристрої

cr0x@server:~$ grep -iE 'amavis|altered|footer|disclaimer|repack|mime' /var/log/mail.log | tail -n 15
Jan 03 10:25:33 mx amavis[2201]: (02201-11) Passed CLEAN, but modified headers: added X-Virus-Scanned
Jan 03 10:25:33 mx amavis[2201]: (02201-11) body modified: appended disclaimer

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

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

Завдання 16: Перевірити наявність ARC-заголовків (якщо ви впровадили ARC)

cr0x@server:~$ grep -iE '^ARC-Seal:|^ARC-Message-Signature:|^ARC-Authentication-Results:' message.eml | head -n 10
ARC-Authentication-Results: i=1; mx.forwarder.example; spf=pass smtp.mailfrom=alice@sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; ...
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; ...

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

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

Три корпоративні міні-історії (біль, жаль і одна перемога)

Міні-історія 1: Інцидент через неправильне припущення

Компанія мала «прості» правила пересилання: вся пошта на acquisitions@corp.example пересилалась команді угод на іншого провайдера. Це працювало роками. Усі вважали, що все гаразд, бо не було тикетів.

Потім важливий партнер посилив автентифікацію: DMARC перейшов з p=none на p=reject зі строгим вирівнюванням. Пересильник і далі ретранслював пошту як раніше. SPF не пройшов у нового провайдера (як і завжди). DKIM міг би врятувати — якби не корпоративний шлюз, що додав дисклеймер до всієї вихідної пошти, включно з пересланою. DKIM зламався.

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

Виправлення було гірким: вони відключили інжекцію дисклеймерів для транспорту пересилання, впровадили SRS для переписування відправника конверта і ввели правило: усе, що пересилається назовні, не мутаціювати, якщо бізнес не погодив ризик. Не було магічного «увімкнути DMARC» перемикача. Було конкретне інженерне налаштування.

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

Інша організація хотіла зменшити затримки й зовнішні залежності. Вони консолідували кілька малих MTA в один «smart relay», який виконував антивірусне сканування, DLP-тегування, переписування URL і нормалізацію заголовків. Це була акуратна коробка: менше систем, менше оповіщень, панель, що виглядала впевнено.

Потім вони ввімкнули агресивне переписування URL для захисту від загроз. Це регулярно змінювало тіла повідомлень. DKIM-підписи зовнішніх відправників почали падати. Більшість прямих доставок вижили, бо SPF вирівнювався і проходив. Переслані повідомлення — ні: SPF не проходив після пересилання, DKIM не проходив через переписування, DMARC не проходив, і суворі відправники отримували відмови.

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

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

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

Команда фінансових послуг мала правило: будь-яка зміна обробки пошти має тестуватися відомим набором зовнішніх доменів зі строгими політиками DMARC. Вони тримали невеликий корпус тестових повідомлень (підписані DKIM, з різними MIME-типами) і проганяли їх через релєї перед і після змін.

Одного дня вони оновили пакет milter. Від нотаток щодо релізу зміна виглядала незначною. Їхній тест негайно показав DKIM-помилки на пересланих повідомленнях: milter почав перепаковувати довгі рядки і нормалізувати пробіли. SPF на пересланій пошті вже падав, тож DMARC тепер також ламається.

Оскільки вони виявили проблему до продакшен-роллауту, у них були варіанти: зафіксувати версію milter, налаштувати його так, щоб уникнути змін канонізації, і застосувати SRS де потрібно. Жодного інциденту. Жодної ескалації керівництва. Ніякого банера «пошта не працює» в чаті.

Практика була нудною: тестовий стенд, чекліст і трохи параної. Вона врятувала їх від публічного уроку.

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

1) Симптом: Переслана пошта зникає, без bounce

Корінна причина: Кінцевий отримувач тихо поміщає в карантин або відхиляє через DMARC; bounces можуть йти на переписаний або недійсний Return-Path, або бути підтиснуті.

Виправлення: Перевірте логи Postfix на DSN 5.7.26/5.7.1. Додайте моніторовану скриньку для bounce-повідомлень і налаштуйте SRS, щоб DSN поверталися вам. Якщо DKIM модифікується — припиніть модифікації або впровадьте ARC.

2) Симптом: SPF fail на кожному пересланому повідомленні

Корінна причина: Нормальна поведінка. IP пересильника не авторизований SPF початкового домену.

Виправлення: Впровадьте SRS на межі пересилання. Не просіть треті сторони додавати ваші IP в їхній SPF; це не працює в масштабі.

3) Симптом: DKIM падає тільки після включення «юридичного дисклеймеру»

Корінна причина: Додавання підвалу змінює тіло; DKIM-підпис більше не збігається.

Виправлення: Вимкніть додавання підвалу для пересланої пошти і розсилок, або застосовуйте його тільки до пошти, яку ви генеруєте. Якщо треба додавати повідомлення, робіть це на рівні клієнта/UI, а не в SMTP-плеє.

4) Симптом: DMARC не проходить, хоча SPF проходить

Корінна причина: SPF проходить для домену, який не вирівнюється з заголовком From (наприклад, домен bounce або домен стороннього реле).

Виправлення: Переконайтеся, що домен, який використовується для автентифікації SPF, вирівнюється з заголовком From (рівень вирівнювання залежить від політики відправника). Інакше покладайтеся на вирівняний DKIM.

5) Симптом: Деякі провайдери приймають переслану пошту, інші відхиляють

Корінна причина: Різні приймачі по-різному оцінюють DKIM/SPF/ARC; дехто застосовує суворіший DMARC або має локальні антизловживальні політики.

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

6) Симптом: Шторми bounce або backscatter після пересилання

Корінна причина: Пересильник зберігає початковий MAIL FROM, тому DSN йдуть початковому відправнику навіть якщо проблема виникла через пересильник, або йдуть на підроблених відправників, коли йдеться про спам.

Виправлення: SRS. Також відкидайте неавтентифіковану пошту на SMTP-етапі, щоб уникати генерації DSN для сміття.

7) Симптом: Додали ARC, але нічого не покращилось

Корінна причина: Приймачі не довіряють вашому ARC-ланцю (репутація), або ви неправильно ставите seal, або ваші модифікації надмірні.

Виправлення: Перевірте ARC-підписи, тримайте релєї чистими, і не вважайте ARC універсальним. Якщо можна уникнути модифікацій — робіть це натомість.

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

План A: Ви керуєте пересильником і хочете, щоб пересилання «переважно працювало»

Зробіть інвентар шляхів пересилання. Перелічіть усі правила, псевдоніми і пересилки на рівні скриньки, що надсилають назовні.
Відокремте трафік пересилання. Використовуйте виділений транспорт Postfix або окремий інстанс для пересилань.
Впровадьте SRS на цьому шляху. Переконайтеся, що ваш домен пересильника має SPF, що авторизує його IPи.
Припиніть модифікувати переслану пошту. Без підвалів, без тегів у темі, без переписування URL. Якщо потребуєте сканування безпеки — робіть це так, щоб зберегти байти повідомлення.
Тестуйте зі строгими DMARC-доменами. Використовуйте повторюваний набір тестових повідомлень і перевіряйте Authentication-Results у кінцевих отримувачів.
Моніторьте відхилення за DSN-кодами. Сповіщайте при сплесках 5.7.26, 5.7.1 і «DMARC policy of reject».
Тримайте план відкату. SRS і фільтри змінюють базову поведінку пошти. Нехай це буде оборотним без героїчних зусиль.

План B: Ви керуєте розсилкою або шлюзом, що мусить модифікувати повідомлення

Вирішіть питання ідентичності. Або переписуйте From (працює, але видно користувачу), або інвестуйте в ARC і сподівайтеся, що приймачі вам довірять.
Якщо використовуєте ARC: керуйте ключами, безпечно обертайте, моніторьте валідацію. Працюйте з цим як з TLS сертифікатами: нудно, за розкладом, документовано.
У будь-якому випадку мінімізуйте модифікації. Кожна трансформація — лотерея з поломки DKIM.
Надайте інструкції користувачам. Для строгих доменів порадьте пряме підписання або внесення в allowlist.

План C: Ви корпоративна IT-команда і люди хочуть пересилати пошту на персональні акаунти

Не робіть цього за замовчуванням. Пересилання — ексфільтрація плюс ризик доставлюваності, замасковані під зручність.
Пропонуйте підтримувані альтернативи. MDM, делегований доступ, безпечний вебмейл або налаштовані клієнти.
Якщо треба дозволити: вимагаєте MFA, застосуйте SRS і забороніть модифікацію повідомлень на цій дорозі пересилання.
Зробіть це видимим. Логи та аудит зовнішнього пересилання. Ставте їх як контролі витоку даних — бо саме це вони й є.

Питання та відповіді

1) Чи «виправляє» SRS DMARC для пересланої пошти?

Ні. SRS робить SPF стійким при пересиланні через переписування відправника конверта. DMARC все одно може не пройти, якщо DKIM не проходить і вирівнювання SPF не співпадає з видимим доменом From.

2) Якщо DKIM проходить, чи потрібен мені ще SRS?

Часто так, для стійкості і обробки bounce-повідомлень. DKIM може бути крихким, коли шлюзи змінюють пошту. SRS також зменшує backscatter і робить вашу поведінку при пересиланні більш стандартизованою.

3) Чому початковий відправник не може просто «додати» мій пересильник у SPF?

Бо SPF — це механізм публікації дозволених відправників для домену. Додавати довільні пересильники було б операційно неможливо і збільшувало б поверхню для зловживань.

4) А як щодо пересилання в межах одного провайдера?

Залежить. Деякі провайдери реалізують внутрішнє пересилання збереженням контексту автентифікації, іноді за власними механізмами. Але коли ви переходите межі адміністрацій і використовуєте нові вихідні IP, SPF покаже себе.

5) Можу я перепідписати DKIM на пересильнику, щоб DMARC пройшов?

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

6) Чи широко підтримується ARC?

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

7) Який найважливіший операційний ризик SRS?

Неправильне охоплення застосування. Якщо ви переписуєте відправників конверта для пошти, яка цього не потребує, ви можете зламати обробку bounce-повідомлень і ускладнити налагодження. Застосовуйте SRS лише для шляхів пересилання.

8) Як зрозуміти, чи моя система ламає DKIM?

Шукайте трансформації: дисклеймери, переписування URL, нормалізація MIME, теги в темі. Потім підтвердіть, порівнявши Authentication-Results при отриманні і після релєя, або спостерігаючи DKIM=fail далі в ланцюгу.

9) Якщо я припиню модифікувати пошту, чи пересилання завжди працюватиме?

Не завжди. DKIM може бути відсутній, неправильно налаштований або використовувати нестабільну канонізацію. Але припинення модифікацій усуває велику самостійно створену причину відмов і суттєво підвищує шанси.

10) Що сказати бізнесу, коли переслані листи від суворих відправників все одно не доходять?

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

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

Якщо ви керуєте пересиланням у продакшені, ставтеся до нього як до будь-якої іншої поверхні надійності: вимірюйте, ізолюйте і припиняйте «невеликі безпечні зміни» у payload.

Візьміть одне невдале повідомлення і простежте його end-to-end. Підтвердіть, чи SPF, DKIM або вирівнювання — справжня причина.
Припиніть мутації контенту у потоках пересилання. Дисклеймери на чужій пошті — не виграш у комплаєнсі, а борг у доставлюваності.
Впровадьте SRS на межі пересилання, щоб запобігти передбачуваним SPF-помилкам і впорядкувати обробку bounce-повідомлень.
Вирішіть, чи потрібен ARC для потоків, що мають трансформувати пошту. Якщо можна уникнути трансформацій — робіть це.
Задокументуйте політику: які пересилки підтримуються, які заборонені і що користувачам робити натомість.

Пересилання не стало гіршим; екосистема стала менш терпимою до неоднозначної ідентичності. Це прогрес. Просто сантехніку тепер треба проектувати як інженери.