ARC email: jak Authenticated Received Chain ratuje forwarded maile

Przekierowujesz maile z firmowej skrzynki na prywatny Gmail i nagle połowa wiadomości znika w folderze spam. Znasz ten scenariusz? Winowajcą nie jest złośliwy filtr ani błąd konfiguracji — to strukturalna słabość klasycznych protokołów uwierzytelniania poczty. ARC (Authenticated Received Chain) powstał właśnie po to, żeby ten problem rozwiązać raz na zawsze. W tym poradniku dowiesz się, jak działa ARC email, dlaczego forwarding maili niszczy reputację SPF i DKIM oraz jak krok po kroku wdrożyć Authenticated Received Chain we własnej infrastrukturze.

Dlaczego forwarding maili psuje SPF, DKIM i DMARC?

Zanim zrozumiesz ARC, musisz wiedzieć, co dokładnie się psuje przy przekierowaniu wiadomości. Trzy filary uwierzytelniania poczty — SPF, DKIM i DMARC — działają świetnie w prostym scenariuszu: nadawca → serwer odbiorcy. Problem pojawia się, gdy w drodze stoi pośrednik.

SPF i problem zmiany adresu IP

SPF (Sender Policy Framework) weryfikuje, czy serwer wysyłający wiadomość jest wymieniony w rekordzie DNS domeny nadawcy. Gdy mail trafia do serwera pośredniczącego (np. firmowego forwardera), ten wysyła go dalej ze swojego adresu IP. Serwer docelowy widzi IP pośrednika — a nie oryginalne IP — i stwierdza: „Ten serwer nie jest autoryzowany do wysyłki w imieniu tej domeny". SPF fail gotowy.

DKIM i modyfikacja treści wiadomości

DKIM (DomainKeys Identified Mail) podpisuje kryptograficznie nagłówki i treść wiadomości. Jeśli serwer pośredniczący doda własny nagłówek, zmieni temat (np. dodając prefix „[FWD]") albo zmodyfikuje stopkę, podpis DKIM przestaje być ważny. Weryfikacja kończy się błędem, nawet jeśli wiadomość jest w 100% legalna.

DMARC — efekt domina

DMARC (Domain-based Message Authentication, Reporting and Conformance) wymaga, żeby przynajmniej jeden z mechanizmów — SPF lub DKIM — przeszedł weryfikację i był wyrównany (aligned) z domeną w nagłówku From:. Gdy oba zawiodą przez forwarding, polityka DMARC p=reject lub p=quarantine skutecznie zablokuje lub wrzuci wiadomość do spamu. Efekt domina: legalna poczta traktowana jak atak phishingowy.

Czym jest ARC i jak rozwiązuje ten problem?

Authenticated Received Chain to standard opisany w RFC 8617 (opublikowanym w lipcu 2019 roku). Jego zadanie jest proste w założeniu, choć technicznie złożone: zachować i przekazać dalej informację o tym, jakie wyniki uwierzytelniania miała wiadomość, zanim trafiła do pośrednika. Dzięki temu serwer końcowy może ocenić, czy wiadomość była autentyczna na wcześniejszym etapie dostarczania, nawet jeśli teraz SPF i DKIM nie przechodzą.

Trzy nagłówki ARC

Każdy serwer uczestniczący w łańcuchu ARC dodaje do wiadomości trzy nagłówki. Tworzą one kolejną „warstwę" łańcucha (instance number, oznaczany jako i=1, i=2 itd.):

• ARC-Authentication-Results (AAR) — kopia wyników uwierzytelniania (SPF, DKIM, DMARC) z danego etapu. Serwer zapisuje tu to, co sam zmierzył, zanim zmodyfikował wiadomość.
• ARC-Message-Signature (AMS) — podpis kryptograficzny całej wiadomości (razem z nagłówkami) w momencie, gdy serwer ją otrzymał. Analogiczny do DKIM, ale tworzony przez pośrednika.
• ARC-Seal (AS) — podpis obejmujący wszystkie poprzednie nagłówki ARC oraz nowy AAR. Gwarantuje integralność całego łańcucha — nikt nie mógł podmienić wcześniejszych wpisów.

Kluczowa różnica wobec DKIM: ARC-Seal celowo nie obejmuje treści wiadomości, więc modyfikacje stopki czy tematu nie psują weryfikacji łańcucha.

Jak wygląda ARC w praktyce — przykład krok po kroku

1. Nadawca (np. jan@firma.pl) wysyła mail podpisany DKIM. SPF przechodzi, DMARC pass.
2. Serwer pośredniczący (np. korporacyjny forwarder relay.firma.pl) odbiera wiadomość, weryfikuje SPF/DKIM/DMARC i zapisuje wyniki w nagłówku ARC-Authentication-Results: i=1. Następnie podpisuje wiadomość własnym kluczem DKIM (AMS) i uszczelnia łańcuch (AS). Dopiero potem przekazuje mail dalej.
3. Serwer docelowy (np. Gmail) odbiera wiadomość. SPF fail (bo IP forwardera), DKIM fail (bo treść zmodyfikowana). Ale widzi nagłówki ARC z i=1 podpisane przez relay.firma.pl. Sprawdza: czy ufam temu pośrednikowi? Jeśli tak — akceptuje wiadomość, bo łańcuch ARC potwierdza, że na wcześniejszym etapie wszystko było w porządku.

ARC a zaufanie do pośrednika — model „trusted forwarder"

ARC nie jest magicznym rozwiązaniem, które ufa każdemu. Serwer odbiorcy sam decyduje, którym pośrednikom ufa — na podstawie ich reputacji, historii i ewentualnych białych list. Google, Microsoft i inni duzi dostawcy prowadzą wewnętrzne listy zaufanych forwarderów. Jeśli relay.firma.pl ma dobrą reputację i poprawnie implementuje ARC, jego podpis będzie respektowany.

Ważne: ARC nie zastępuje SPF, DKIM ani DMARC. To uzupełnienie — mechanizm zachowania historii uwierzytelniania w łańcuchu przekierowań. Wszystkie cztery protokoły powinny działać razem.

Porównanie: co weryfikuje każdy protokół

Jak wdrożyć ARC — wymagania i konfiguracja krok po kroku

Wdrożenie ARC po stronie serwera pośredniczącego wymaga kilku elementów. Poniżej praktyczny przewodnik dla administratorów.

Krok 1: Sprawdź wsparcie w swoim MTA

ARC jest obsługiwany przez najpopularniejsze serwery pocztowe. Przed konfiguracją upewnij się, że używasz odpowiedniej wersji:

• Postfix — wsparcie przez moduł opendkim + bibliotekę arc lub zewnętrzny milter (np. arc-milter)
• Exim — wbudowane wsparcie ARC od wersji 4.91
• Rspamd — natywna obsługa ARC od wersji 1.6; wystarczy włączyć moduł arc w konfiguracji
• Amavis / SpamAssassin — wymagają zewnętrznych pluginów lub integracji z Rspamd

Krok 2: Wygeneruj parę kluczy RSA dla ARC

ARC używa podpisów kryptograficznych, więc potrzebujesz pary kluczy — prywatnego (na serwerze) i publicznego (w DNS). Możesz użyć tego samego klucza co DKIM lub wygenerować osobny (zalecane dla większej kontroli):

openssl genrsa -out arc_private.key 2048
openssl rsa -in arc_private.key -pubout -out arc_public.key

Klucz publiczny umieść w rekordzie TXT DNS pod selektorem, np. arc._domainkey.twojadomena.pl — w tym samym formacie co rekord DKIM (v=DKIM1; k=rsa; p=KLUCZ_PUBLICZNY).

Krok 3: Konfiguracja Rspamd (przykład)

Rspamd to jeden z najprostszych sposobów na wdrożenie ARC. W pliku /etc/rspamd/local.d/arc.conf dodaj:

sign_authenticated = true;
sign_local = true;
use_domain = "header";
selector = "arc";
path = "/etc/rspamd/keys/arc_private.key";
domain {
  twojadomena.pl {
    path = "/etc/rspamd/keys/arc_private.key";
    selector = "arc";
  }
}

Po restarcie Rspamd zacznie automatycznie dodawać nagłówki ARC do przekazywanych wiadomości.

Krok 4: Weryfikacja działania

Po wdrożeniu wyślij testową wiadomość przez swój forwarder do skrzynki Gmail lub Outlook. W nagłówkach wiadomości (opcja „Pokaż oryginał" / „View source") powinieneś zobaczyć:

• Nagłówki ARC-Authentication-Results, ARC-Message-Signature i ARC-Seal z i=1
• W sekcji Authentication-Results serwera docelowego wpis arc=pass

Jeśli widzisz arc=fail, sprawdź poprawność klucza prywatnego, selektor DNS i czy nagłówki nie są modyfikowane po podpisaniu.

Najczęstsze błędy przy wdrożeniu ARC

Wdrożenie ARC to nie rocket science, ale kilka pułapek potrafi skutecznie zepsuć konfigurację.

• Podpisywanie po modyfikacji — ARC-Message-Signature musi być dodany przed jakimikolwiek zmianami w wiadomości przez serwer pośredniczący. Kolejność operacji w MTA ma krytyczne znaczenie.
• Brak rekordu DNS dla selektora ARC — bez publicznego klucza w DNS serwer odbiorcy nie może zweryfikować podpisu. Efekt: arc=fail (no key).
• Używanie tego samego selektora co DKIM bez separacji — możliwe, ale ryzykowne. Rotacja klucza DKIM zepsuje też ARC. Lepiej utrzymywać osobne selektory.
• Brak SPF dla serwera pośredniczącego — ARC ratuje dostarczalność, ale sam pośrednik też powinien mieć poprawnie skonfigurowany SPF i DKIM dla własnej domeny.
• Przekierowanie przez wiele niepodpisanych węzłów — jeśli w łańcuchu jest serwer, który nie dodaje nagłówków ARC, łańcuch się urywa. Każdy węzeł musi implementować ARC.

ARC w kontekście deliverability i RODO

Z perspektywy dostarczalności (deliverability) ARC to jeden z elementów, które Google i Microsoft aktywnie weryfikują przy ocenie reputacji nadawcy. Od lutego 2024 roku Gmail wymaga od nadawców masowych poprawnej konfiguracji SPF, DKIM i DMARC — ARC staje się de facto standardem dla każdej infrastruktury, która obsługuje przekierowania.

Warto też pamiętać o aspekcie zgodności z RODO. Artykuł 32 RODO nakłada obowiązek wdrożenia odpowiednich środków technicznych zapewniających bezpieczeństwo przetwarzania danych. Poprawna konfiguracja uwierzytelniania poczty — w tym ARC — jest elementem ochrony przed phishingiem i spoofingiem, co bezpośrednio wpisuje się w ten wymóg. Nieautoryzowane przekierowania lub brak weryfikacji tożsamości nadawcy mogą prowadzić do naruszenia danych osobowych przesyłanych e-mailem.

Jeśli korzystasz z narzędzi do masowego mailingu, takich jak MailerPRO, upewnij się, że Twoja konfiguracja SMTP uwzględnia wszystkie cztery warstwy uwierzytelniania. Narzędzia wysyłające przez własne serwery SMTP dają pełną kontrolę nad nagłówkami i podpisami — co jest niezbędne do prawidłowego działania ARC w środowiskach z forwardingiem.

Podsumowanie: kiedy ARC jest niezbędny?

ARC nie jest potrzebny każdemu — ale jeśli w Twojej infrastrukturze poczty dzieje się cokolwiek z poniższej listy, wdrożenie Authenticated Received Chain powinno być priorytetem:

• Używasz przekierowań skrzynek (np. firmowa → prywatna, alias → kilka odbiorców)
• Masz serwer relay lub smarthost w łańcuchu dostarczania
• Korzystasz z list mailingowych (mailing lists modyfikują wiadomości przed rozsyłką)
• Obsługujesz wiele domen z centralnym serwerem pocztowym
• Otrzymujesz raporty DMARC z dużą liczbą fail przy przekierowaniach

ARC to nie kolejny protokół do odhaczenia na liście. To realne rozwiązanie problemu, który od lat frustrował administratorów poczty i użytkowników przekierowujących maile. Zaimplementuj go na serwerze pośredniczącym, zadbaj o poprawny rekord DNS i monitoruj wyniki w nagłówkach — a forwarding maili przestanie oznaczać automatyczny wyrok spamu.