ARC w e-mail marketingu — kiedy i jak włączyć?

Wysyłasz kampanię e-mail, wszystko skonfigurowane poprawnie — SPF, DKIM, DMARC na miejscu — a mimo to część wiadomości ląduje w spamie po przekierowaniu przez skrzynkę pośrednią. Winowajcą jest mechanizm, o którym rzadko się mówi: zerwanie łańcucha uwierzytelniania podczas forwarding mail. ARC (Authenticated Received Chain) powstał właśnie po to, żeby ten problem rozwiązać. Poniżej znajdziesz odpowiedzi na najczęściej zadawane pytania — bez zbędnej teorii, za to z konkretnymi wskazówkami.

Czym właściwie jest ARC?

ARC to standard opisany w RFC 8617 (opublikowany przez IETF w 2019 roku). Jego zadanie jest proste: zachować informację o tym, że wiadomość była poprawnie uwierzytelniona przed przekazaniem jej do kolejnego serwera. Każdy pośrednik w łańcuchu dostarczania dodaje własny zestaw nagłówków ARC, tworząc weryfikowalną historię trasy wiadomości.

ARC nie zastępuje SPF, DKIM ani DMARC — uzupełnia je. Działa jak notarialne poświadczenie: „Ten list był autentyczny, gdy przez mnie przechodził, a oto mój podpis to potwierdzający."

Trzy nagłówki ARC — co robią?

• ARC-Authentication-Results (AAR) — kopia wyników uwierzytelniania (SPF, DKIM, DMARC) z danego etapu trasy.
• ARC-Message-Signature (AMS) — podpis kryptograficzny całej wiadomości (wraz z nagłówkami AAR), wystawiony przez pośrednika.
• ARC-Seal (AS) — podpis obejmujący wszystkie poprzednie nagłówki ARC, zamykający łańcuch i chroniący go przed manipulacją.

Każdy kolejny serwer pośredni zwiększa licznik (instance number) i dodaje własną trójkę nagłówków. Serwer docelowy weryfikuje cały łańcuch od pierwszego do ostatniego ogniwa.

Dlaczego forwarding mail psuje SPF i DKIM?

To serce problemu. Gdy wiadomość jest przekazywana dalej (np. przez listę mailingową, aliasy firmowe albo automatyczne reguły przekierowania na skrzynce pracownika), dochodzi do dwóch charakterystycznych uszkodzeń.

SPF break — dlaczego tak często się zdarza?

SPF weryfikuje adres IP serwera wysyłającego względem rekordu DNS domeny nadawcy kopertowego (envelope-from). Gdy pośrednik przekazuje wiadomość dalej, wysyła ją ze swojego własnego adresu IP, który nie figuruje w rekordzie SPF oryginalnego nadawcy. Wynik: spf=fail lub spf=softfail, mimo że oryginalna wiadomość była w pełni legalna.

Nie ma tu żadnego błędu konfiguracyjnego — to strukturalna słabość SPF w scenariuszach wieloskokowych. Dodanie adresów IP wszystkich możliwych pośredników do rekordu SPF jest niewykonalne i niebezpieczne (rozluźnia ochronę).

DKIM chain — kiedy podpis przestaje działać?

DKIM podpisuje wybrane nagłówki i treść wiadomości kluczem prywatnym nadawcy. Problem pojawia się, gdy pośrednik modyfikuje wiadomość — zmienia temat (np. dodaje „[LISTA]"), przepisuje nagłówki lub zmienia kodowanie treści. Nawet drobna zmiana sprawia, że weryfikacja podpisu kończy się wynikiem dkim=fail.

Listy mailingowe (Mailman, Sympa, Google Groups) są klasycznym przykładem: prawie zawsze modyfikują wiadomość, zrywając tym samym oryginalny podpis DKIM. To właśnie dlatego ARC stał się standardem obsługiwanym przez duże platformy pocztowe.

Kiedy włączyć ARC — konkretne scenariusze

ARC nie jest potrzebny każdemu. Poniższa tabela pomoże ocenić, czy Twoja infrastruktura wymaga tego mechanizmu.

* Security gateway zazwyczaj nie zmienia koperty ani treści, ale warto sprawdzić logi uwierzytelniania po jego stronie.

Czy ARC pomaga przy kampaniach masowych?

Jeśli wysyłasz kampanie bezpośrednio ze swojego serwera SMTP (tak jak robi to MailerPRO, korzystając z własnych skrzynek klientów), ARC nie jest konieczny po stronie nadawcy. Mechanizm działa po stronie pośredników i serwerów odbierających — to one podpisują łańcuch ARC, nie nadawca kampanii. Warto natomiast upewnić się, że Twój serwer pocztowy weryfikuje ARC przy odbiorze, by nie odrzucać legalnych wiadomości przekazanych przez zaufane pośredniki.

Jak włączyć ARC — krok po kroku

Konfiguracja ARC zależy od używanego serwera pocztowego (MTA). Poniżej znajdziesz ogólny schemat dla najpopularniejszych rozwiązań.

Postfix + OpenARC

1. Zainstaluj pakiet openarc (dostępny w repozytoriach Debian/Ubuntu od wersji 20.04).
2. Wygeneruj parę kluczy RSA (minimum 1024 bity, zalecane 2048): opendkim-genkey -b 2048 -d example.com -s arc.
3. Opublikuj klucz publiczny w DNS jako rekord TXT: arc._domainkey.example.com.
4. Skonfiguruj /etc/openarc.conf — wskaż domenę, selektor i ścieżkę do klucza prywatnego.
5. Podłącz milter OpenARC do Postfiksa w main.cf: smtpd_milters = inet:localhost:8893.
6. Zrestartuj usługi i zweryfikuj nagłówki ARC w testowej wiadomości.

Microsoft Exchange / Exchange Online

Exchange Online (Microsoft 365) obsługuje ARC natywnie od 2018 roku. Administratorzy mogą dodawać zaufanych sygnatariuszy ARC w centrum administracyjnym Exchange (EAC) lub przez PowerShell:

Set-ArcConfig -Identity Default -ArcTrustedSealers "pośrednik.example.com"

Dzięki temu Exchange Online będzie honorować łańcuch ARC wystawiony przez wskazanego pośrednika, nawet jeśli SPF lub DKIM zawiodły po drodze.

Google Workspace (Gmail)

Gmail weryfikuje ARC przy odbiorze automatycznie i honoruje zaufane łańcuchy przy ocenie reputacji wiadomości. Po stronie administratora domeny nie ma osobnych ustawień do włączenia — wystarczy, że pośrednicy w łańcuchu poprawnie podpisują nagłówki ARC.

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

1. Brak rekordu DNS z kluczem publicznym

ARC-Seal i ARC-Message-Signature są bezużyteczne, jeśli serwer odbierający nie może pobrać klucza publicznego do weryfikacji. Rekord TXT musi być opublikowany przed uruchomieniem podpisywania. Sprawdź propagację DNS narzędziem dig TXT arc._domainkey.example.com.

2. Podpisywanie bez weryfikacji

Wiele poradników skupia się wyłącznie na dodawaniu nagłówków ARC, pomijając konfigurację weryfikacji przychodzącej. Tymczasem serwer powinien robić obie rzeczy: weryfikować łańcuch ARC w wiadomościach przychodzących i podpisywać wiadomości przekazywane dalej.

3. Zbyt krótki klucz RSA

Klucze 512 lub 768 bitów są odrzucane przez nowoczesne serwery pocztowe. Minimum to 1024 bity, standard branżowy to 2048 bity. Klucze 4096-bitowe są obsługiwane, ale mogą powodować problemy z limitami rozmiaru rekordów DNS TXT.

4. Zaufanie do wszystkich sygnatariuszy ARC

ARC nie jest mechanizmem zaufania bezwzględnego. Serwer odbierający powinien honorować łańcuch ARC tylko od znanych, zaufanych pośredników. Akceptowanie ARC od dowolnego źródła otwiera drzwi do nadużyć — atakujący mógłby sfabrykować łańcuch uwierzytelniania.

ARC a DMARC — jak się uzupełniają?

DMARC (opisany w RFC 7489) wymaga, żeby co najmniej jeden z mechanizmów — SPF lub DKIM — był wyrównany (aligned) z domeną nadawcy. W scenariuszach forwarding mail oba mogą zawieść jednocześnie, co skutkuje odrzuceniem wiadomości przy polityce p=reject.

ARC pozwala serwerowi odbierającemu podjąć decyzję: „Wiem, że DMARC zawiodło, ale widzę wiarygodny łańcuch ARC od zaufanego pośrednika — przyjmę tę wiadomość." To nie jest ominięcie DMARC, lecz świadome rozszerzenie polityki przez administratora serwera docelowego. Decyzja zawsze leży po stronie odbiorcy, nie nadawcy.

Praktyczna wskazówka: jeśli prowadzisz listę mailingową i stosujesz DMARC z polityką p=reject, rozważ zmianę nagłówka From: na adres listy (tzw. From rewriting) jako alternatywę lub uzupełnienie ARC. Oba podejścia mają swoje wady i zalety — ARC zachowuje oryginalny adres nadawcy, co jest korzystniejsze dla odbiorców.

Podsumowanie — czy włączyć ARC w swojej firmie?

ARC jest niezbędny wszędzie tam, gdzie wiadomości przechodzą przez pośredników modyfikujących kopertę lub treść: listy mailingowe, aliasy przekierowujące, bramki bezpieczeństwa. Jeśli wysyłasz kampanie bezpośrednio ze swojego serwera SMTP bez pośredników — np. korzystając z dedykowanego narzędzia do mailingu — ARC nie wymaga konfiguracji po Twojej stronie, ale warto sprawdzić, czy Twój serwer pocztowy weryfikuje przychodzące łańcuchy ARC i honoruje zaufanych sygnatariuszy. Zacznij od audytu logów uwierzytelniania: jeśli widzisz regularne wyniki spf=fail lub dkim=fail przy wiadomościach, które powinny być legalne — ARC to właściwy następny krok.