Как пересылка email ломает аутентификацию

You set up SPF, DKIM, and DMARC. Everything passes. Then one recipient forwards your message to another mailbox - and authentication breaks. The email lands in spam or gets rejected entirely. This is not a bug in your configuration. It is how forwarding works, and it has been a known problem since authentication protocols were designed.

What happens when an email is forwarded

There are two types of forwarding, and they break different things.

Redirect (server-side forwarding). The intermediary server receives the message and sends it onward without changing the From header. The envelope sender (MAIL FROM) changes to the forwarding server’s address. The body may or may not be altered - some servers add footers, modify headers, or re-encode MIME parts.

Resend (manual forwarding). The user clicks “Forward” in their mail client. A new message is composed with a new envelope, new headers, and the original content quoted or attached. From the authentication standpoint, this is a completely new email. The original sender’s SPF, DKIM, and DMARC no longer apply because the From address belongs to the forwarder. This type is not the problem - server-side redirect is.

SPF: the first thing to break

SPF validates the sending IP against the DNS record of the envelope sender’s domain. When server B forwards a message originally sent by server A, the final destination (server C) sees the connection from server B’s IP. Server B is not listed in the original domain’s SPF record. Result: SPF fail.

Here is what the authentication header looks like after a forward:

Authentication-Results: mx.destination.com;
    spf=fail (sender IP is 203.0.113.50) smtp.mailfrom=forwarder.net;
    dkim=pass header.d=original-sender.com;
    dmarc=fail (p=NONE sp=NONE) header.from=original-sender.com

SPF was designed before widespread forwarding. The protocol has no mechanism to account for intermediary hops. Some forwarding servers rewrite the envelope sender using SRS (Sender Rewriting Scheme), which patches the SPF problem but introduces its own complications - bounce handling becomes harder, and the rewritten address looks unfamiliar in logs.

SRS rewrites the envelope MAIL FROM to something like:

SRS0=HHH=TT=original-sender.com=user@forwarder.net

Now server C checks SPF against forwarder.net, which passes because server B is authorized for that domain. Problem solved - but only for SPF. DMARC alignment is still broken because the From header still says original-sender.com, and SPF now aligns with forwarder.net.

DKIM: survives forwarding - sometimes

DKIM signs specific headers and the body of the message. Since the signature is attached to the content rather than the sending IP, a simple forward that does not alter the message preserves the DKIM signature. The destination server verifies it against the original domain’s DNS, and it passes.

This is why DKIM is the primary authentication mechanism that survives forwarding. But “does not alter the message” is a strong assumption. In practice, forwarding servers frequently modify the content:

• Mailing lists (Mailman, Google Groups, Listserv) add footers, edit the Subject line, or change the Reply-To header.
• Corporate gateways append legal disclaimers to the body.
• Security appliances rewrite URLs for click-time scanning (Proofpoint, Mimecast, Barracuda).
• Some servers re-encode the MIME structure - switching between quoted-printable and base64, or stripping unnecessary parts.

Any of these changes invalidates the DKIM body hash. The header hash may survive if signed headers were not modified, but once the body hash fails, the entire signature fails:

Authentication-Results: mx.destination.com;
    spf=fail smtp.mailfrom=forwarder.net;
    dkim=fail (body hash did not verify) header.d=original-sender.com;
    dmarc=fail header.from=original-sender.com

At this point both SPF and DKIM fail. DMARC requires at least one to pass with alignment. Neither does. The message is treated as unauthenticated.

DMARC: the cascading failure

DMARC checks two things: did SPF or DKIM pass, and does the passing domain align with the From header domain. After forwarding:

• SPF fails (wrong IP) or passes for a different domain (SRS rewriting).
• DKIM fails if the body was modified, or passes if untouched.

If DKIM passes, DMARC alignment works because the DKIM d= domain matches the From header. This is the one scenario where forwarding does not break authentication. Everything else results in DMARC failure.

With p=none, DMARC failure is just a report entry. With p=quarantine, the message goes to spam. With p=reject, it is dropped entirely. And you, the original sender, may never find out - the forwarding recipient just stops receiving your emails.

This creates a real problem for organizations moving from p=none to p=reject. DMARC aggregate reports show a spike in failures. Some of those are phishing attempts being blocked - good. Some are legitimate forwards - bad. Telling them apart requires examining the source IPs and correlating them with known forwarding services.

ARC: the protocol built to fix this

Authenticated Received Chain (ARC, RFC 8617) was designed specifically for the forwarding problem. The idea is simple: each intermediary that handles the message records the authentication state as it was at the time of receipt, then signs that record.

ARC adds three headers at each hop:

• ARC-Authentication-Results - the authentication results as seen by this hop.
• ARC-Message-Signature - a DKIM-like signature over the message at this point.
• ARC-Seal - a signature over all previous ARC headers, creating the chain.

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.net; s=arc-20260101;
    cv=none; b=dGhpcyBpcyBhIHNpbXBsaWZpZWQgZXhhbXBsZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.net;
    s=arc-20260101; h=from:to:subject:date;
    bh=abc123...; b=xyz789...
ARC-Authentication-Results: i=1; forwarder.net;
    spf=pass smtp.mailfrom=original-sender.com;
    dkim=pass header.d=original-sender.com;
    dmarc=pass header.from=original-sender.com

When the final destination receives the message with broken SPF and DKIM, it can look at the ARC chain and see that the first hop verified everything successfully. If the destination trusts the forwarding server (and its ARC signature validates), it can override the DMARC failure.

Gmail, Microsoft 365, and Yahoo all evaluate ARC when making DMARC override decisions. Google has stated explicitly that ARC results factor into their delivery decisions for forwarded mail. But ARC is not a guarantee - the receiving server decides whether to trust the intermediary, and not every forwarder implements ARC.

Mailing lists: the worst case

Mailing lists (Mailman, Google Groups, LISTSERV) are the most aggressive type of forwarder. They typically modify the Subject (adding a prefix like [list-name]), add or replace the Reply-To header, append a footer with unsubscribe instructions, and sometimes rewrite the From header entirely.

This breaks DKIM because the signed headers and body no longer match. SPF fails because the list server’s IP is not in the original sender’s SPF record. DMARC fails on both counts.

The common workaround: the mailing list software rewrites the From header to its own domain and puts the original sender in Reply-To. Mailman 3 and Google Groups do this by default when the sender’s domain has a strict DMARC policy. It works but confuses recipients who expect to see the actual sender’s address.

What senders can actually do

You cannot control what happens after your message leaves your infrastructure. But you can minimize the damage.

Sign with DKIM correctly. Use a 2048-bit key (1024 is still accepted but provides less margin). Sign the headers that matter: From, To, Subject, Date, MIME-Version, Content-Type. Avoid over-signing headers that intermediaries routinely modify - if you sign a header that gets changed, the entire signature fails.

Use l= tag with caution. The DKIM l= (body length) tag allows a signature to cover only the first N bytes of the body. Content appended after that point does not invalidate the signature. In theory, this lets footers be added without breaking DKIM. In practice, it opens a security hole - an attacker can append arbitrary content to a signed message. Most security guidance recommends against using it.

Monitor DMARC reports. Aggregate reports (rua) show you exactly which IPs are sending mail on your behalf and whether authentication passed. If you see consistent failures from known forwarding services (university mail systems, corporate gateways, mailing list servers), you know the failures are from forwarding, not from spoofing.

Ramp up DMARC policy gradually. Move from p=none to p=quarantine; pct=10, then increase pct over weeks while watching reports. This limits the blast radius of forwarding-related failures during the transition.

Communicate with your recipients. If you know parts of your audience use university or corporate email that forwards to Gmail or Outlook, let them know. A simple note in onboarding (“add our address to your contacts”) does not fix authentication, but it reduces the chance of manual spam reports that compound the problem.

Diagnosing forwarding failures

When a recipient reports missing emails, ask them to check raw headers. The key fields:

# Check authentication results
Authentication-Results: ...
  spf=fail ...
  dkim=fail (body hash did not verify) ...
  dmarc=fail ...

# Look for ARC headers - presence means
# an intermediary tried to preserve auth state
ARC-Authentication-Results: i=1; ...
  spf=pass ...
  dkim=pass ...

# Check Received headers to trace the path
Received: from forwarder.net (203.0.113.50) by mx.destination.com ...
Received: from mta.original-sender.com (198.51.100.25) by forwarder.net ...

If you see ARC headers with passing results at hop 1 but failing results at the destination, the forwarding server is doing its part. The destination server chose not to trust the ARC chain - or does not support ARC at all.

If there are no ARC headers, the forwarding server is not ARC-aware. The authentication state from the first hop is lost entirely.

How big is the problem

Forwarding is common. Alumni email addresses at universities forward to personal Gmail or Outlook accounts. Small businesses use domain email that redirects to a shared inbox. Users set up auto-forwarding between accounts. IT departments configure gateway relay rules.

Google reported in their DMARC deployment analysis that forwarding is the leading cause of legitimate DMARC failures. If you send to B2B audiences in higher education or corporate environments, expect 5-15% of your recipients to receive your email through at least one forwarding hop.

For senders with strict DMARC policies, this means a measurable portion of legitimate recipients may not receive their messages - unless DKIM survives intact and the forwarding path does not modify the email body.

Protocol behavior after forwarding

The critical takeaway: DKIM is your only real defense against forwarding-induced authentication failure. If DKIM holds, DMARC passes via DKIM alignment. If DKIM breaks, you depend entirely on the receiving server trusting the ARC chain - something you cannot control.

Русская версия

Что происходит при пересылке письма

Вы настроили SPF, DKIM, DMARC. Всё проходит проверки. Потом получатель пересылает ваше письмо на другой ящик - и аутентификация ломается. Письмо попадает в спам или отклоняется. Это не баг вашей настройки. Так работает пересылка, и это известная проблема со времён появления протоколов аутентификации.

Есть два типа пересылки. Серверный редирект - промежуточный сервер принимает письмо и отправляет дальше, не меняя заголовок From. Конверт (MAIL FROM) меняется на адрес пересылающего сервера. Тело может быть изменено: добавлены подписи, перекодированы MIME-части, переписаны ссылки. Ручная пересылка - пользователь нажимает «Переслать» в почтовом клиенте. Создаётся новое письмо с новым конвертом. С точки зрения аутентификации это совершенно другое сообщение. Проблему создаёт именно серверный редирект.

SPF: ломается первым

SPF проверяет IP отправителя по DNS-записи домена конвертного адреса. Когда сервер B пересылает письмо, отправленное сервером A, получающий сервер C видит подключение с IP сервера B. Этого IP нет в SPF-записи исходного домена. Результат: SPF fail.

Некоторые пересылающие серверы используют SRS (Sender Rewriting Scheme) - перезаписывают конвертный адрес на свой домен. Это решает проблему SPF, но ломает alignment для DMARC: SPF теперь проходит для домена пересылателя, а не для домена в заголовке From.

DKIM: выживает, но не всегда

DKIM подписывает заголовки и тело сообщения. Подпись привязана к содержимому, а не к IP. Если письмо не было изменено при пересылке, подпись остаётся валидной. Принимающий сервер проверяет её через DNS исходного домена - проходит.

Но «не было изменено» - сильное допущение. На практике пересылающие серверы часто модифицируют письмо: списки рассылки добавляют префикс в тему и футер в тело, корпоративные шлюзы дописывают юридические дисклеймеры, системы безопасности перезаписывают ссылки для проверки при клике. Любое такое изменение инвалидирует хеш тела в DKIM-подписи.

DMARC: каскадный отказ

DMARC требует, чтобы хотя бы один протокол (SPF или DKIM) прошёл проверку и совпал с доменом в заголовке From. После пересылки SPF провален или совпадает с чужим доменом (SRS). DKIM - либо прошёл (если тело не трогали), либо провален.

Если DKIM проходит, DMARC тоже проходит - домен в подписи (d=) совпадает с From. Это единственный сценарий, где пересылка не ломает аутентификацию. Во всех остальных случаях - DMARC fail. При политике p=reject письмо будет отброшено, и вы как отправитель можете об этом не узнать.

ARC: протокол для решения проблемы

Authenticated Received Chain (ARC, RFC 8617) создан специально для пересылки. Каждый промежуточный сервер записывает состояние аутентификации на момент получения и подписывает эту запись. Формируется цепочка доверия.

ARC добавляет три заголовка на каждом хопе: ARC-Authentication-Results (результаты проверки), ARC-Message-Signature (DKIM-подобная подпись сообщения) и ARC-Seal (подпись поверх всех предыдущих ARC-заголовков).

Gmail, Microsoft 365 и Yahoo учитывают ARC при принятии решений о доставке пересланных писем. Но ARC - не гарантия. Принимающий сервер сам решает, доверять ли промежуточному узлу. И не каждый пересылатель поддерживает ARC.

Списки рассылки: самый тяжёлый случай

Mailman, Google Groups, LISTSERV - самые агрессивные пересылатели. Они добавляют префикс в тему, меняют Reply-To, дописывают футер с инструкцией по отписке, иногда полностью перезаписывают From. Это ломает и DKIM (тело изменено), и SPF (другой IP), и DMARC (оба протокола провалены).

Типичное решение: софт списка рассылки перезаписывает From на свой домен, а оригинального отправителя помещает в Reply-To. Mailman 3 и Google Groups делают это по умолчанию, когда у домена отправителя строгая политика DMARC. Работает, но получатели видят не тот адрес, который ожидают.

Что может сделать отправитель

Вы не контролируете, что происходит с письмом после отправки. Но можно снизить ущерб.

• Правильно подписывайте DKIM. Ключ 2048 бит. Подписывайте заголовки From, To, Subject, Date, MIME-Version, Content-Type. Не подписывайте заголовки, которые промежуточные серверы часто меняют.
• Не используйте тег l= в DKIM без острой необходимости. Он позволяет добавлять контент в конец тела без поломки подписи, но создаёт дыру для атакующих.
• Анализируйте DMARC-отчёты. Aggregate-отчёты показывают, с каких IP идут отправки и прошла ли аутентификация. Постоянные failure с IP известных пересылающих сервисов - это пересылка, а не спуфинг.
• Повышайте политику DMARC постепенно. От p=none к p=quarantine; pct=10, затем увеличивайте pct неделями. Это ограничивает радиус поражения при проблемах с пересылкой.