Dostarczalność

Ten rozdział wyjaśnia, dlaczego Twój e‑mail trafia do skrzynki odbiorczej albo do folderu ze spamem oraz co z tym zrobić. Dostarczalność to nie jedno ustawienie, które się włącza. To skumulowany efekt tego, kto ma prawo wysyłać w imieniu Twojej domeny, jak wiarygodnie wygląda Twoja historia wysyłki oraz jak reagujesz, gdy coś idzie nie tak.

Model myślowy: dostawcy skrzynek pocztowych (Gmail, Yahoo, Microsoft) traktują każdego nadawcę jako winnego, dopóki nie udowodni, że jest godny zaufania. Uwierzytelnianie potwierdza Twoją tożsamość. Reputacja potwierdza Twoje zachowanie. Potrzebujesz obu.

Ten przewodnik jest neutralny względem dostawców. Wszędzie tam, gdzie pojawiłby się konkretny dostawca, przykłady używają generycznej abstrakcji emailClient / provider albo surowych standardów (rekordy DNS, Node crypto, zwykłe nagłówki SMTP, schemat Standard Webhooks). Prawdziwi dostawcy, Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo, SparkPost, Mandrill, są wymieniani wyłącznie jako wymienne przykłady w listach. Możesz podstawić dowolnego z nich, nie zmieniając architektury opisanej w tym rozdziale.

Szybkie odpowiedzi na pytania omawiane tutaj:

• Czym są SPF, DKIM i DMARC i dlaczego są teraz obowiązkowe?
• Jak odczytać każdy rekord DNS i uniknąć typowych błędów konfiguracji?
• Jak wdrożyć DMARC, nie psując legalnej poczty?
• Jak zweryfikować konfigurację za pomocą dig i narzędzi testowych?
• Czym jest reputacja nadawcy i jak rozgrzać nowe IP lub domenę?
• Jaki wskaźnik odrzuceń (bounce) i skarg jest zbyt wysoki?
• Jak ustrukturyzować subdomeny i TTL DNS?
• Czym są BIMI, ARC, MTA-STS i TLS-RPT i czy ich potrzebuję?
• Czego dokładnie wymagają zasady dla masowych nadawców Gmail/Yahoo/Microsoft z 2024 roku?
• Mój e‑mail trafia do spamu: co sprawdzić najpierw?

Dlaczego mój e‑mail trafia do spamu zamiast do skrzynki odbiorczej?

Bo coś w jednym z czterech filarów zawodzi. Każdy filar decyduje o tym, czy Twoja poczta zostanie dostarczona:

1. Uwierzytelnianie: udowodnienie serwerom odbierającym, że poczta naprawdę pochodzi od Ciebie (SPF, DKIM, DMARC).
2. Reputacja nadawcy: długoterminowy wskaźnik zaufania, który dostawcy skrzynek przypisują Twojej domenie i IP.
3. Obsługa odrzuceń i skarg: prawidłowe reagowanie na niepowodzenia i rozgniewanych odbiorców, zanim zatrują Twoją reputację.
4. Infrastruktura: architektura DNS i domen, która sprawia, że problemy marketingu nie zatapiają poczty transakcyjnej.

Napraw je z grubsza w tej kolejności. Najpierw uwierzytelnianie, bo nic dalej nie ma znaczenia, jeśli Twoja poczta nie potrafi udowodnić, kto ją wysłał.

Podróż jednej wiadomości, od początku do końca

Warto wiedzieć, co naprawdę dzieje się między wywołaniem send() a skrzynką odbiorczą, bo każdy filar odpowiada jakiemuś etapowi:

1. Twoja aplikacja wywołuje API dostawcy poczty (albo przekazuje wiadomość do własnego MTA).
2. Wychodzący MTA dostawcy łączy się z hostem MX domeny odbiorcy przez SMTP, najlepiej po TLS. MTA-STS i DANE decydują o tym, czy ten TLS jest wymuszony.
3. MTA odbierający uruchamia kontrole na etapie połączenia: czy łączące się IP jest na liście blokad (RBL)? Czy domena MAIL FROM (nadawca koperty, zwany też Return-Path) publikuje SPF i czy to IP go przechodzi?
4. Odbiorca akceptuje DATA i uruchamia kontrole na etapie treści: czy podpis DKIM się weryfikuje? Czy DMARC przechodzi i jest zgodny (alignment)? Jeśli wiadomość została przekierowana, czy łańcuch ARC poświadcza wcześniejszy pozytywny wynik?
5. Odbiorca sprawdza reputację: reputację domeny, reputację IP, własną historię zaangażowania odbiorcy wobec Ciebie oraz trafienia w pułapki spamowe (spam traps).
6. Odbiorca stosuje politykę: skrzynka odbiorcza, folder spam, zakładka typu „Oferty”, albo wprost odrzucenie (bounce). Tutaj wchodzą w grę zasady dla masowych nadawców (one-click unsubscribe, limity wskaźnika skarg).

Niepowodzenia uwierzytelniania są rozstrzygane na krokach 3–4, są binarne i tanie do naprawienia. Reputacja (krok 5) jest analogowa, wolno się zmienia i jest najtrudniejsza do naprawy. Niemal każdy incydent „nagle trafiamy do spamu” to regresja na kroku 3–4 (edycja DNS, wygasły klucz, nowy dostawca), którą możesz znaleźć w kilka minut.

Dlaczego uwierzytelnianie e‑maili jest teraz nienegocjowalne?

Bo od lutego 2024 roku Gmail, Yahoo i Microsoft wymuszają uwierzytelnianie dla masowych nadawców. Nieuwierzytelnione e‑maile będą odrzucane lub filtrowane jako spam.

E‑mail, który nie przejdzie uwierzytelniania, nie jest już „prawdopodobnie spamem”. Coraz częściej jest traktowany jako z całą pewnością niechciany i albo wprost odrzucany, albo kierowany do spamu. Uwierzytelnianie to fundament: nic innego w tym rozdziale nie ma znaczenia, jeśli Twoja poczta nie potrafi udowodnić, kto ją wysłał.

Są trzy rekordy i budują na sobie nawzajem. SPF i DKIM każdy niezależnie mówi „ten serwer lub ten podpis jest autoryzowany”. DMARC wiąże je z widocznym adresem From: i mówi odbiorcom, co robić, gdy żaden z nich nie przechodzi.

„Masowy nadawca” w tym kontekście oznacza zwykle mniej więcej 5000 lub więcej wiadomości dziennie do jednego dostawcy, ale traktuj wszystkie trzy rekordy jako obowiązkowe niezależnie od wolumenu. Dostawcy coraz częściej stosują te same kontrole także wobec małych nadawców.

Jak te trzy rekordy się ze sobą wiążą

Kluczowe słowo to zgodność (alignment). SPF i DKIM każdy uwierzytelniają jakąś domenę, ale niekoniecznie tę, którą Twój odbiorca widzi w From:. DMARC jest jedynym z tej trójki, który wiąże uwierzytelnianie z widocznym nagłówkiem From:, a to jedyna tożsamość, którą czyta człowiek. Dlatego DMARC jest warstwą polityki, a SPF/DKIM jego danymi wejściowymi.

Czym jest SPF i dlaczego go potrzebuję?

SPF (Sender Policy Framework, RFC 7208) to opublikowana lista serwerów, które mogą wysyłać pocztę w imieniu Twojej domeny. Serwer odbierający porównuje IP wysyłające z tą listą. Jeśli IP nie jest autoryzowane, SPF zawodzi.

SPF uwierzytelnia nadawcę koperty (SMTP MAIL FROM, ujawniany jako nagłówek Return-Path), a nie widoczny nagłówek From:. To rozróżnienie ma znaczenie później przy zgodności (alignment): wielu dostawców używa własnej domeny zwrotnej jako Return-Path, więc SPF przechodzi dla ich domeny, a nie Twojej, co jest w porządku dla samego SPF, ale oznacza, że musisz polegać na DKIM dla zgodności DMARC.

Dodaj to jako rekord TXT w swoim DNS. Przykład używa include jednego dostawcy; podstaw token include opublikowany przez własnego dostawcę:

; TXT record at yourdomain.com
yourdomain.com.   IN   TXT   "v=spf1 include:amazonses.com ~all"

• Dodaj rekord TXT do DNS.
• Użyj ~all (soft fail) jako rekomendowanej wartości domyślnej.

Jak odczytać ten rekord

• v=spf1: deklaruje, że to rekord SPF w wersji 1.
• include:amazonses.com: deleguje autoryzację do własnego rekordu SPF dostawcy. Każdy dostawca publikuje swój własny mechanizm include, na przykład include:amazonses.com, include:sendgrid.net, include:spf.mandrillapp.com, include:_spf.mx.cloudflare.net, include:spf.messagingengine.com. Użyj dokładnie tego tokena, który dokumentuje Twój dostawca.
• ~all: soft fail. Wszystko, co nie pasuje powyżej, jest podejrzane, ale nie jest twardo odrzucane. To rekomendowana wartość domyślna. -all (hard fail) jest bardziej restrykcyjny, ale ryzykowny podczas konfiguracji, bo pojedyncza błędna konfiguracja po cichu zabija dostarczanie.

Mechanizmy i kwalifikatory SPF, przewodnik

Praktyczne ostrzeżenia

• Limit 10 zapytań. SPF ogranicza liczbę mechanizmów odpytujących DNS (include, a, mx, ptr, exists, redirect) do 10. Przekrocz go, a SPF zwróci permerror, który DMARC traktuje jako niepowodzenie SPF. Każdy include: dostawcy może sam rozwinąć się do kilku zagnieżdżonych zapytań, więc dwóch lub trzech dostawców może po cichu wyczerpać budżet. Audytuj rozwiniętą liczbę, a nie tylko dosłowne include.
• Jeden rekord SPF na domenę. Na domenę przypada dokładnie jeden rekord TXT SPF. Dwa rekordy TXT SPF to permerror i SPF zawodzi całkowicie. Jeśli używasz kilku nadawców, scal ich include w jeden rekord.
• SPF łamie się przy przekierowaniu. Gdy skrzynka przekierowuje Twoją wiadomość, IP serwera przekierowującego nie ma na Twojej liście, więc SPF zawodzi na kolejnym hopie. To dokładnie dlatego istnieją DKIM (który podróżuje z wiadomością) i DMARC (który może przejść na samym DKIM) oraz dlaczego później dodano ARC do naprawy przekierowanej poczty.
• Limit pustych zapytań (void-lookup). Poza limitem 10 zapytań RFC 7208 ogranicza też „puste” zapytania (zwracające brak rekordów lub NXDOMAIN) do 2. Dostawca, który wycofa nazwę hosta, może zepsuć Twój SPF, choć go nie tknąłeś.

Spłaszczanie (flattening), by zmieścić się w limicie zapytań

Jeśli rzeczywiście potrzebujesz więcej include, niż pozwala budżet, możesz „spłaszczyć”: rozwiązać include każdego dostawcy do dosłownych zakresów ip4:/ip6: i opublikować je zamiast nich. To wymiana łatwości utrzymania na zapas miejsca, musisz ponownie spłaszczać, gdy dostawca zmieni IP. Użyj zarządzanej usługi spłaszczania SPF albo zaplanowanego zadania, które ponownie rozwiązuje i porównuje różnice, i nigdy nie spłaszczaj dostawcy, który często rotuje IP.

Typowy błąd

Publikowanie drugiego rekordu SPF, gdy dodajesz nowego dostawcę. Zawsze edytuj istniejący rekord i dodaj do niego nowy include:. Objawem są przerywane przejścia SPF, które w tajemniczy sposób przestają działać, bo niektóre resolwery łączą wiele łańcuchów TXT, a inne nie.

Czym jest DKIM i czym różni się od SPF?

DKIM (DomainKeys Identified Mail, RFC 6376) to podpis kryptograficzny potwierdzający autentyczność e‑maila. SPF autoryzuje IP; DKIM dowodzi, że sama wiadomość została podpisana kluczem, który kontrolujesz, i nie została zmieniona w drodze.

Twój dostawca poczty da Ci rekord TXT z kluczem publicznym do opublikowania (albo, u niektórych dostawców, rekord CNAME wskazujący na klucz, który oni hostują i rotują za Ciebie).

Jak to działa: DKIM dołącza do każdej wiadomości podpis kryptograficzny wygenerowany kluczem prywatnym, który posiada Twój dostawca wysyłki. Pasujący klucz publiczny żyje w Twoim DNS jako rekord TXT pod selektorem. Odbiorca czyta nagłówek DKIM-Signature, pobiera klucz publiczny wskazany przez tagi s= (selektor) i d= (domena podpisująca) i weryfikuje podpis. Pozytywny wynik potwierdza dwie rzeczy: poczta naprawdę pochodzi od nadawcy posiadającego klucz, a podpisane części wiadomości nie zostały zmienione w drodze.

Anatomia nagłówka DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com;
  s=s1; t=1700000000; bh=<body hash>;
  h=from:to:subject:date:message-id;
  b=<signature>

• d=: domena podpisująca. Dla zgodności DMARC musi pasować do domeny From: (lub być jej domeną nadrzędną w trybie relaxed).
• s=: selektor, który nazywa rekord DNS przechowujący klucz publiczny: s1._domainkey.yourdomain.com.
• a=: algorytm, zwykle rsa-sha256. Ed25519 (ed25519-sha256) jest zdefiniowany, ale nie wszędzie jeszcze weryfikowany, więc dostawcy publikują RSA jako podstawowy.
• c=: kanonikalizacja dla nagłówka/treści. relaxed/relaxed toleruje zmiany białych znaków i zawijania wprowadzane przez przekaźniki; simple/simple jest kruchy. Preferuj relaxed.
• bh=: hash treści (body hash). Jeśli przekaźnik dokleja stopkę albo lista mailingowa przepisuje treść, bh przestaje pasować i DKIM się łamie, choć kryptografia jest poprawna.
• h=: lista nagłówków objętych podpisem. Nagłówki spoza tej listy mogą być dodawane przez przekaźniki bez łamania podpisu. Co istotne, podpisanie From jest obowiązkowe.

Opublikowany rekord klucza publicznego

; TXT record at s1._domainkey.yourdomain.com
s1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...<base64 public key>...IDAQAB"

Wielu dostawców zamiast tego każe Ci opublikować CNAME, aby mogli rotować bazowy klucz bez edytowania przez Ciebie DNS:

s1._domainkey.yourdomain.com.  IN  CNAME  s1.dkim.provider.example.

Praktyczne uwagi

• Rekord żyje pod subdomeną selektora, na przykład s1._domainkey.yourdomain.com, gdzie s1 to selektor przypisany przez Twojego dostawcę. Różni dostawcy, a nawet różne klucze, używają różnych selektorów. Publikuj wiele selektorów, gdy wysyłasz od wielu dostawców.
• DKIM przetrwa przekierowanie, bo podpis podróżuje z wiadomością. To czyni go bardziej odpornym niż SPF, i to mechanizm, na którym DMARC zwykle polega przy zgodności.
• Użyj 2048-bitowego klucza RSA, gdy dostawca go oferuje. Starsze klucze 1024-bitowe nadal działają, ale są słabsze i są wycofywane. Zwróć uwagę, że 2048-bitowy klucz publiczny może przekroczyć limit 255 znaków pojedynczego łańcucha TXT DNS i musi zostać podzielony na wiele cytowanych łańcuchów w jednym rekordzie (większość interfejsów DNS robi to automatycznie).
• Rotuj klucze okresowo i zawsze, gdy dostawca to wspiera. Trzymaj stary selektor opublikowany przez co najmniej kilka dni po rotacji, aby poczta w drodze i w kolejce nadal się weryfikowała. Nigdy nie ujawniaj klucza prywatnego.
• DKIM podpisuje migawkę wybranych nagłówków i treści. Jakakolwiek modyfikacja podpisanego nagłówka lub treści (stopka listy mailingowej, baner antywirusa „scanned by”, przepisanie treści) unieważnia podpis. To najczęstsza pojedyncza przyczyna niepowodzenia DKIM na skądinąd poprawnej poczcie.

Typowe błędy

• Podpisywanie z d=, które nie jest zgodne z From: (np. własna domena dostawcy). To przechodzi DKIM, ale zawodzi DMARC. Zawsze podpisuj własną domeną.
• Opublikowanie rekordu, ale nigdy nie włączenie podpisywania u dostawcy, więc wiadomości wychodzą niepodpisane.
• Pozwolenie, by jednorazowy testowy selektor wygasł, podczas gdy produkcyjna poczta nadal się do niego odwołuje.

Czym jest DMARC i co oznacza „zgodność” (alignment)?

Wersja standardu. Ta sekcja opisuje DMARC według RFC 7489 (2015), wciąż powszechnie wdrożonego i w pełni działającego. W maju 2026 opublikowano jego następcę, DMARCbis (RFC 9989), który porządkuje i rozszerza standard. Twoje obecne rekordy działają dalej bez zmian; co dokładnie się zmienia, opisuje sekcja DMARCbis (RFC 9989): co zmienia najnowszy standard? niżej.

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) to polityka obsługi niepowodzeń SPF/DKIM oraz raportowanie. Wymaga zgodności (alignment): domena, która przechodzi SPF lub DKIM, musi pasować do domeny w widocznym nagłówku From:.

DMARC przechodzi, jeśli którekolwiek:

• SPF przechodzi i domena Return-Path jest zgodna z domeną From:, lub
• DKIM przechodzi i domena podpisująca d= jest zgodna z domeną From:.

Wystarczy, że jeden przejdzie i będzie zgodny. Dlatego DKIM jest koniem roboczym: przetrwa przekierowanie i jest zgodny z Twoją domeną nawet wtedy, gdy dostawca posiada Return-Path.

Dodaj to jako rekord TXT pod _dmarc.yourdomain.com:

; TXT record at _dmarc.yourdomain.com
_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1"

Dlaczego to ważne: SPF i DKIM uwierzytelniają technicznego nadawcę, ale spamer wciąż może przejść SPF/DKIM dla własnej domeny, podszywając się przy tym pod Twoją markę w widocznym From:. DMARC zamyka tę lukę, wymagając zgodności. Prosi też odbiorców, by raportowali, co widzą, dzięki czemu zyskujesz wgląd w to, kto wysyła jako Ty.

Jak odczytać ten rekord (pełny przewodnik po tagach)

• p=none: nie podejmuj żadnych działań (tylko monitoruj). Tu zaczynasz.
• rua=mailto:...: skieruj to na skrzynkę lub procesor raportów DMARC, który faktycznie czytasz. Odbiorcy wysyłają jeden raport XML dziennie na źródło.
• Zgodność relaxed (domyślna) traktuje mail.yourdomain.com i yourdomain.com jako zgodne. Strict wymaga dokładnego dopasowania etykiety. Zacznij od relaxed.

Dowiedz się więcej: https://dmarc.org/overview/

Czytanie raportów zbiorczych (RUA)

Raporty zbiorcze to skompresowany gzipem XML, jeden na źródło raportujące dziennie. Każdy blok <record> raportuje IP wysyłające, liczbę wiadomości, zastosowaną dyspozycję oraz wyniki SPF/DKIM/zgodności. Surowy XML jest nieczytelny przy skali; podaj go do procesora analityki DMARC (istnieją zarówno parsery open-source, jak i hostowane pulpity), który grupuje według źródła wysyłki, abyś mógł odpowiedzieć na jedyne pytanie, które ma znaczenie podczas wdrażania: które legalne źródła jeszcze nie przechodzą zgodnie?

Minimalny model myślowy jednego rekordu:

<record>
  <row>
    <source_ip>198.51.100.7</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>yourdomain.com</header_from></identifiers>
  <auth_results>
    <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
    <spf><domain>bounce.provider.example</domain><result>pass</result></spf>
  </auth_results>
</record>

Tutaj SPF „przechodzi” dla domeny zwrotnej dostawcy, ale nie jest zgodny z header_from, więc policy_evaluated/spf=fail. DKIM przechodzi i jest zgodny, więc DMARC przechodzi ogólnie. To normalny, zdrowy wzorzec dla poczty przekazywanej przez dostawcę.

Jak wdrożyć DMARC, nie psując poczty?

Wdrażaj w trzech etapach, nigdy nie przeskakując od razu do p=reject. Etapowa ścieżka to: p=none (monitorowanie), następnie p=quarantine; pct=25, a potem p=reject.

Przeskoczenie od razu do p=reject, zanim zrozumiesz własną wysyłkę, po cichu zniszczy legalną pocztę, o której zapomniałeś (CRM, narzędzie do fakturowania, stara platforma marketingowa, helpdesk, zaproszenia kalendarzowe). Bezpieczna ścieżka to:

1. p=none (monitorowanie). Zbieraj raporty zbiorcze przez kilka tygodni. Zidentyfikuj każde legalne źródło wysyłające jako Twoja domena i doprowadź je wszystkie do przechodzenia SPF/DKIM ze zgodnością.
2. p=quarantine; pct=25 (kwarantanna wycinka). Niezgodna poczta trafia do spamu, ale tylko dla 25% ruchu, ograniczając zasięg rażenia, gdy obserwujesz skutki. Stopniowo zwiększaj pct w kierunku 100.
3. p=reject (wymuszenie). Niezgodna poczta jest wprost odrzucana. To stan docelowy, który faktycznie powstrzymuje podszywanie się pod Twoją markę.

Realistyczny harmonogram:

Nie zapomnij o tagu sp. p=reject na wierzchołku bez sp wciąż pozostawia dowolne subdomeny *.yourdomain.com podatne na podszywanie się w wartości domyślnej (subdomeny dziedziczą p, ale jeśli kiedyś zluzujesz wierzchołek, musisz to przemyśleć). Ustawienie jawnie sp=reject zamyka podszywanie się pod subdomeny.

Problem przekierowań i list mailingowych

DMARC przy p=reject łamie dwa legalne przypadki: zwykłe przekierowanie (SPF zawodzi na kolejnym hopie; DKIM może przetrwać) oraz listy mailingowe, które przepisują treść lub temat (bh/nagłówek DKIM się łamie; SPF należy do listy). Standardową odpowiedzią jest ARC (RFC 8617), omawiany niżej: pozwala przekaźnikowi poświadczyć, że uwierzytelnianie przeszło, zanim tknął wiadomość. Dopóki ARC nie jest powszechny, spodziewaj się, że niewielka ilość legalnej przekierowanej poczty ucierpi przy reject, co jest jednym z powodów, dla których strumienie marketingowe i transakcyjne intensywnie przekierowywane wymagają szczególnej uwagi.

Typowy błąd

Pozostanie na p=none na zawsze. Samo monitorowanie nie chroni Cię przed podszywaniem się; chroni tylko quarantine lub reject. Drugim częstym błędem jest włączenie p=reject, podczas gdy zapomniane narzędzie zewnętrzne nadal wysyła niezgodną pocztę jako Twoja domena, zlikwiduj to źródło albo doprowadź je do zgodności zanim wymusisz.

DMARCbis (RFC 9989): co zmienia najnowszy standard?

W maju 2026 IETF opublikowało DMARCbis jako RFC 9989 (status Proposed Standard), zastępując informacyjny RFC 7489 z 2015 roku jako autorytatywne źródło dla DMARC. Raportowanie wydzielono do dwóch osobnych dokumentów: RFC 9990 (raporty zbiorcze) i RFC 9991 (raporty o niepowodzeniach).

Najważniejsze: to nie jest zmiana łamiąca zgodność. Twoje istniejące rekordy v=DMARC1 działają dalej i nie musisz nic republikować. DMARCbis głównie porządkuje niejednoznaczności, standaryzuje zachowanie odbiorców i domyka luki, które RFC 7489 pozostawiał interpretacji.

Co się zmienia w praktyce

• Odkrywanie domeny organizacyjnej przez „DNS Tree Walk" zamiast Public Suffix List. RFC 7489 polegał na Public Suffix List (PSL), by ustalić granicę domeny organizacyjnej. DMARCbis zastępuje to przechodzeniem drzewa DNS w górę (odpytywaniem _dmarc na kolejnych poziomach nazwy), daje to spójne, przewidywalne granice także przy zagnieżdżonych subdomenach, bez zależności od zewnętrznej, ręcznie utrzymywanej listy.
• Nowy tag np, polityka dla nieistniejących subdomen. Pozwala jawnie odrzucać pocztę z subdomen, które nie mają rekordów (nigdy nie były używane do wysyłki). Domyka to popularny wektor podszywania się: np=reject blokuje sfałszowane subdomeny, nie ruszając istniejących strumieni.
• Nowy tag psd, flaga domeny publicznego sufiksu. Dla operatorów rejestrów / PSD (Public Suffix Domain), którzy chcą publikować DMARC na poziomie sufiksu. Zwykły nadawca go nie ustawia.
• Nowy tag t (testing) w miejsce pct. t=y oznacza tryb testowy (odbiorcy nie egzekwują polityki, nawet przy p=reject), a t=n, pełne egzekwowanie. Zastępuje to nieprzewidywalny mechanizm procentowy dawnego tagu pct.
• Usunięte tagi: pct, rf, ri. pct (procent poczty objętej polityką) był stosowany przez odbiorców niespójnie, a wartości inne niż 0 i 100 były zawodne, stąd zastąpienie go binarnym t. rf (format raportów o niepowodzeniach) i ri (interwał raportów) usunięto; szczegóły raportowania żyją teraz w RFC 9990/9991.
• SPF liczy się do DMARC tylko z MAIL FROM. DMARCbis usuwa dawny wariant awaryjny oparty o HELO, do zgodności (alignment) SPF liczy się wyłącznie domena MAIL FROM (Return-Path).

Co z tym zrobić teraz

• Nie panikuj i nie republikuj wszystkiego. Istniejące rekordy pozostają ważne.
• Przestań polegać na pct. Jeśli używasz go do stopniowego wdrożenia, zaplanuj przejście na t=y / t=n oraz etapowanie przez p i sp (patrz ścieżka wdrożenia w sekcji o RFC 7489 wyżej).
• Rozważ dodanie np=reject. To tania i mocna ochrona przed podszywaniem się pod nieużywane subdomeny.
• Nie traktuj p=none jako stanu docelowego. Intencją standardu (i regułami dla masowych nadawców) jest dojście do egzekwowania (quarantine / reject).

Dowiedz się więcej: RFC 9989, RFC 9990, RFC 9991 oraz podsumowanie zmian na https://dmarc.org/.

Jak zweryfikować konfigurację SPF, DKIM i DMARC?

Sprawdź rekordy DNS bezpośrednio za pomocą dig:

# rekord SPF (szukaj dokładnie jednego łańcucha v=spf1)
dig TXT yourdomain.com +short

# rekord DKIM (zamień 's1' na selektor swojego dostawcy)
dig TXT s1._domainkey.yourdomain.com +short

# rekord DMARC
dig TXT _dmarc.yourdomain.com +short

# podążaj za CNAME DKIM do hostowanego klucza dostawcy
dig CNAME s1._domainkey.yourdomain.com +short

# odpytaj konkretny autorytatywny resolwer, by ominąć lokalne buforowanie
dig TXT _dmarc.yourdomain.com @8.8.8.8 +short

Oczekiwane wyjście: każda komenda powinna zwrócić Twój skonfigurowany rekord. Brak wyjścia oznacza, że rekord nie istnieje.

Jak używać tego w praktyce

• Uruchamiaj te komendy z maszyny poza Twoją siecią, by zobaczyć to, co widzi publiczny internet. dig odpytuje żywy DNS, więc wyniki odzwierciedlają to, co rozwiążą serwery odbierające pocztę.
• Puste wyjście niemal zawsze oznacza jedno z: rekord nigdy nie został opublikowany, jest pod złym hostem lub selektorem, albo DNS jeszcze się nie rozpropagował (zobacz TTL DNS niżej).
• Odpytanie bezpośrednio @8.8.8.8 lub @1.1.1.1 pokazuje Ci widok publicznego resolwera, omijając nieaktualny lokalny bufor.
• Jeśli dig jest niedostępny, te same wyszukiwania działają przez narzędzia webowe jak MXToolbox (zobacz rozwiązywanie problemów).
• Po każdej zmianie DNS pamiętaj, że propagacja jest ograniczona przez TTL rekordu. Rekord z TTL 3600 s może być buforowany do godziny, zanim Twoja edycja stanie się widoczna wszędzie.

Weryfikacja całego łańcucha za pomocą nagłówków wiadomości

Najszybsza funkcjonalna kontrola to wysłanie prawdziwej wiadomości do dowolnej skrzynki i odczytanie nagłówka Authentication-Results, który dodaje odbiorca:

Authentication-Results: mx.google.com;
  dkim=pass header.d=yourdomain.com;
  spf=pass (google.com: domain of bounce@provider.example designates 198.51.100.7) smtp.mailfrom=bounce@provider.example;
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Potwierdź wszystkie trzy: dkim=pass z header.d = Twoja domena, spf=pass oraz dmarc=pass z header.from = Twoja domena. Jeśli dmarc=pass, ale dkim jest zgodny z domeną dostawcy, a nie Twoją, czyli DMARC przechodzi tylko na zgodnym Return-Path SPF, przejdziesz DMARC dziś, ale stracisz zgodność w chwili, gdy przekierowanie usunie SPF, bo nic zgodnego nie przetrwa hopa. Napraw d= DKIM, aby trwały mechanizm niósł zgodność.

Lista kontrolna uwierzytelniania

• Dokładnie jeden rekord TXT SPF, z ~all, poniżej limitu 10 zapytań DNS (licz rozwinięte zapytania)
• Klucz publiczny DKIM opublikowany pod selektorem dostawcy i zweryfikowany w panelu dostawcy
• DKIM podpisuje z d=yourdomain.com (zgodnie), a nie z domeną dostawcy
• Rekord DMARC obecny, zaczynający się od p=none z działającą skrzynką rua i fo=1
• dig zwraca każdy rekord spoza Twojej sieci
• Wysyłka testowa pokazuje dkim=pass, spf=pass i dmarc=pass w Authentication-Results (lub oceń to przez mail-tester.com)
• Polityka sp ustawiona, gdy osiągniesz wymuszenie

Czym jest reputacja nadawcy i dlaczego ma znaczenie?

Reputacja nadawcy odzwierciedla, jak zachowujesz się w czasie, podczas gdy uwierzytelnianie dowodzi tylko, kim jesteś. Dostawcy skrzynek śledzą, per domena i per IP, jak odbiorcy reagują na Twoją pocztę: otwarcia, usunięcia bez przeczytania, kliknięcia „to jest spam”, odrzucenia oraz jak często trafiasz w znane pułapki spamowe.

Silna reputacja kupuje umieszczenie w skrzynce odbiorczej. Uszkodzona wysyła nawet idealnie uwierzytelnioną pocztę do spamu. Reputacja przypisuje się zarówno do domeny wysyłającej, jak i do IP wysyłającego, i odzyskuje się ją powoli, więc dużo łatwiej ją chronić niż naprawiać.

Reputacja domeny vs. reputacja IP

Te dwie są śledzone osobno i należy je rozważać osobno.

• Reputacja domeny podąża za domeną From:/d= DKIM, gdziekolwiek wysyła. To dźwignia, którą kontrolujesz na współdzielonej infrastrukturze (większość dostawców umieszcza małych nadawców w pulach współdzielonych IP). Nie da się od niej uciec, zmieniając IP.
• Reputacja IP podąża za IP wysyłającym. Na współdzielonym IP dziedziczysz reputację puli, dobrą, gdy dostawca pilnuje puli, złą, gdy hałaśliwy sąsiad ją spali. Na dedykowanym IP posiadasz reputację w całości, co opłaca się tylko powyżej stałego wolumenu (często podawanego jako dziesiątki tysięcy wiadomości dziennie), bo dedykowane IP, które wysyła zbyt mało, nigdy nie zgromadzi wystarczająco sygnału, by zbudować zaufanie.

Pułapki spamowe (spam traps)

Pułapki spamowe to adresy, które nigdy nie powinny otrzymać poczty. Pułapki czyste (pristine) to adresy nigdy nieużywane przez człowieka; trafienie w jedną oznacza, że pozyskałeś adresy bez zgody. Pułapki recyklingowane (recycled) to dawniej prawdziwe adresy, które dostawca odzyskał po długim uśpieniu; trafienie w jedną oznacza, że nie usuwasz nieaktywnych subskrybentów. Obie są trucizną dla reputacji i obu unika się tymi samymi dyscyplinami: prawdziwą zgodą przy pozyskiwaniu (zobacz Pozyskiwanie adresów) i agresywnym usuwaniem nieaktywnych adresów (zobacz Zarządzanie listą).

Jak rozgrzać nowe IP lub domenę?

Stopniowo zwiększaj wolumen, aby dostawcy mogli zaobserwować pozytywne zaangażowanie, zanim zaczniesz wysyłać na dużą skalę. Nowe IP lub domena nie ma reputacji. Świeży nadawca, który nagle wysadza 100 000 e‑maili, wygląda dokładnie jak spamer, który właśnie kupił nowe IP.

Zacznij od zaangażowanych użytkowników. Wysyłaj konsekwentnie. Nie spiesz się.

Dowiedz się więcej: wytyczne dla nadawców Google (https://support.google.com/mail/answer/81126) oraz harmonogram rozgrzewania IP/domeny Twojego dostawcy. Zasada, zacznij od małego, zwiększaj stopniowo, jest uniwersalna.

Jak zrobić to dobrze

• Zacznij od najbardziej zaangażowanych użytkowników. Ludzie, którzy otwierają i klikają, wysyłają najsilniejsze pozytywne sygnały. Rozgrzewanie na najlepszej publiczności uczy dostawców, że Twoja poczta jest pożądana.
• Wysyłaj konsekwentnie. Nieregularny wolumen (duży skok, potem cisza, potem kolejny skok) czyta się jako nieprzewidywalny i niegodny zaufania. Stała dzienna kadencja jest celem.
• Nie przyspieszaj rampy. Jeśli metryki zaangażowania spadają lub skargi rosną w trakcie tygodnia, utrzymaj wolumen na stałym poziomie (albo cofnij się) zamiast eskalować. Tabela to wskazówka, a nie termin.
• Rozgrzewaj parę, która ma znaczenie. Reputacja przypisuje się zarówno do IP wysyłającego, jak i do domeny wysyłającej. Jeśli jesteś na współdzielonych IP (większość dostawców), rozgrzewanie domeny jest dźwignią, którą kontrolujesz.
• Rozgrzewaj per dostawca odbierający. Gmail, Yahoo/AOL i Microsoft (Outlook/Hotmail/Office 365) każdy utrzymuje niezależną reputację. Rampa, która zadowala Gmail, wciąż może potknąć się o bardziej restrykcyjny throttling Microsoftu. Obserwuj sygnały postmaster każdego z nich osobno.

Odczytywanie sygnałów throttlingu podczas rozgrzewania

W trakcie rampy odbiorcy powiedzą Ci, kiedy idziesz zbyt szybko, przez odpowiedzi SMTP. Traktuj je jako przeciwciśnienie (backpressure), a nie błędy:

• 421 4.7.0 / „too many connections” / „rate limited” → zwolnij tempo wysyłki; nie ponawiaj agresywnie.
• 4.2.1 „mailbox temporarily disabled” lub odroczenie (deferral) → wycofaj się; odbiorca Cię testuje.
• Nagły wzrost wiadomości trafiających do spamu (widoczny w narzędziach postmaster) → utrzymaj wolumen na stałym poziomie przez kilka dni, zanim ruszysz ponownie z rampą.

Jeśli widzisz odroczenia, zmniejszenie wolumenu na kilka dni, a potem wznowienie rampy, naprawia szybciej niż przepychanie się na siłę.

Jak utrzymać reputację w dobrym stanie, gdy już ją zbuduję?

Wysyłaj do ludzi, którzy chcą Twojej poczty, i reaguj na każde odrzucenie oraz skargę. Krótka wersja:

Rób:

• Wysyłaj do zaangażowanych użytkowników.
• Utrzymuj wskaźnik odrzuceń poniżej 4%.
• Utrzymuj wskaźnik skarg poniżej 0,1%.
• Usuwaj nieaktywnych subskrybentów.

Nie rób:

• Nie wysyłaj do kupionych list.
• Nie ignoruj odrzuceń ani skarg.
• Nie wysyłaj niespójnych wolumenów.

Dlaczego każda zasada istnieje

• Wysyłaj do zaangażowanych użytkowników: zaangażowanie (otwarcia, kliknięcia, odpowiedzi) to pojedynczo największy pozytywny sygnał. Wysyłanie do ludzi, którzy Cię ignorują, ciągnie reputację w dół, nawet jeśli nigdy się nie skarżą. Wiele zespołów przyjmuje politykę wygaszania (sunset policy): przestań wysyłać do adresów bez zaangażowania przez, powiedzmy, 90–180 dni i usuń je po próbie ponownego pozyskania zgody.
• Utrzymuj odrzucenia poniżej 4%, skargi poniżej 0,1%: to progi, przy których dostawcy zaczynają throttlować lub blokować. Traktuj je jako twarde sufity, a nie cele. Sekcje o odrzuceniach i skargach niżej definiują ostrzejsze cele.
• Usuwaj nieaktywnych subskrybentów: martwe i niezaangażowane adresy obniżają Twój wskaźnik zaangażowania i ryzykują trafieniem w recyklingowane pułapki spamowe. Usuwanie ich poprawia dostarczalność dla wszystkich, którzy pozostają.
• Nigdy nie wysyłaj do kupionych list: kupione listy są pełne pułapek spamowych i ludzi, którzy nigdy się nie zapisali. Generują skargi i odrzucenia, które mogą umieścić Cię na czarnej liście w jednej wysyłce.
• Nigdy nie ignoruj odrzuceń ani skarg: nadawca, który nadal wysyła do adresów odrzucających lub skarżących się, to najwyraźniejszy podpis spamera. Zautomatyzowana supresja (zobacz Zarządzanie listą) jest obowiązkowa.

Czym jest odrzucenie (bounce) i jak obsługiwać twarde kontra miękkie odrzucenia?

Odrzucenie to serwer odbierający informujący Cię, że nie mógł dostarczyć Twojej wiadomości. Jak zareagujesz, zależy od tego, czy niepowodzenie jest trwałe, czy tymczasowe.

Twarde odrzucenia (hard bounces) są trwałe. Skrzynka nie istnieje, domena jest nieprawidłowa, albo adres został wyłączony. Nie ma sensu ponawiać; adres nigdy nie przyjmie poczty. Dalsze wysyłanie do niego to jeden z najgłośniejszych sygnałów „nie czyszczę swojej listy”, jakie dostawca może zobaczyć, więc zsupresuj go natychmiast i na stałe.

Miękkie odrzucenia (soft bounces) są tymczasowe. Pełna skrzynka, serwer, który nie działa, chwilowy greylisting. Te mogą się powieść później, więc ponawiaj z rosnącym opóźnieniem (1h, potem 4h, potem 24h). Ale uporczywe miękkie odrzucenia (3 do 5 niepowodzeń) zachowują się w praktyce jak twarde: zsupresuj adres zamiast ponawiać w nieskończoność.

Odczytywanie kodów statusu SMTP

Wiadomość o odrzuceniu niesie kod odpowiedzi SMTP i zwykle bogatszy rozszerzony kod statusu RFC 3463 (class.subject.detail). Użyj kodu rozszerzonego do klasyfikacji:

5.7.1 „message rejected due to policy” to nie nieprawidłowy adres; supresja odbiorcy ukrywa problem po stronie nadawcy (niepowodzenie DMARC, IP na liście blokad, treść). Rozróżniaj niepowodzenia adresu (supresuj odbiorcę) od niepowodzeń nadawcy (napraw swoją konfigurację).

Klasyfikacja odrzuceń w kodzie (neutralna względem dostawcy)

Większość dostawców dostarcza zdarzenia odrzucenia na webhook. Znormalizuj zdarzenie, a potem rozgałęź na podstawie klasyfikacji, nigdy nie wpisuj na sztywno nazw pól jednego dostawcy poza cienkim adapterem, który produkuje ten kształt:

type BounceEvent = {
  email: string;
  type: "hard" | "soft" | "block"; // znormalizowane w adapterze dostawcy
  smtpCode?: string;               // np. "550 5.1.1"
  diagnostic?: string;
};

async function handleBounce(e: BounceEvent) {
  switch (e.type) {
    case "hard":
    case "block":
      // Trwałe niepowodzenie adresu: nigdy więcej tu nie wysyłaj.
      await suppressionList.add(e.email, { reason: e.type, code: e.smtpCode });
      break;
    case "soft": {
      const failures = await softBounceCount.increment(e.email);
      if (failures >= 5) {
        await suppressionList.add(e.email, { reason: "repeated-soft", code: e.smtpCode });
      }
      // w przeciwnym razie: harmonogram ponawiania dostawcy spróbuje ponownie; nic do zrobienia.
      break;
    }
  }
}

Lista supresji musi być sprawdzana w momencie wysyłki, w Twojej aplikacji, niezależnie od własnej supresji dostawcy, zobacz Zarządzanie listą po model supresji oraz Niezawodność wysyłki po mechanikę ponawiania/opóźnień.

Jaki wskaźnik odrzuceń jest zbyt wysoki?

Użyj tych celów: poniżej 1% jest dobrze, 1 do 3% jest akceptowalne, 3 do 4% jest niepokojące, a powyżej 4% jest krytyczne.

Jak czytać te cele: wskaźnik odrzuceń poniżej 1% jest zdrowy i wskazuje na czystą, niedawno zweryfikowaną listę. 1 do 3% jest tolerowalne, ale warte obserwacji. Powyżej 3% dostawcy zaczynają Ci nie ufać. Powyżej 4% ryzykujesz aktywnym throttlingiem i blokadami. Nagły skok zwykle oznacza zły import, nieaktualny segment listy albo krok walidacji, który się zepsuł. Zbadaj źródło adresów, a nie tylko objaw.

Praktyczna wskazówka: nie czekaj do momentu wysyłki, by odkryć złe adresy. Waliduj przy pozyskiwaniu (zobacz Pozyskiwanie adresów) i uruchamiaj kontrole supresji przed wysyłką. Przetwarzanie odrzuceń powinno być zautomatyzowane przez webhooki, aby supresja działa się w czasie rzeczywistym, a nie w cotygodniowym ręcznym przeglądzie, zobacz Webhooki i zdarzenia po odbieranie i weryfikowanie tych zdarzeń.

Czym jest skarga i jaki wskaźnik skarg jest zbyt wysoki?

Skarga to odbiorca klikający „zgłoś spam”. Skargi są dużo bardziej szkodliwe per zdarzenie niż odrzucenia, bo są bezpośrednim sygnałem napędzanym przez odbiorcę, że Twoja poczta jest niechciana.

Użyj tych celów: poniżej 0,01% jest doskonale, 0,01 do 0,05% jest dobrze, a powyżej 0,05% jest krytyczne.

Zwróć uwagę, o ile ostrzejsze są te progi niż progi odrzuceń. Nawet wskaźnik skarg 0,05% (1 na 2000) to czerwona linia. Zasady dla masowych nadawców z 2024 roku czynią to konkretnym: Gmail wymaga, by masowi nadawcy utrzymywali skargi spamowe poniżej 0,3% i mocno zaleca pozostanie poniżej 0,1%, a nagradza nadawców, którzy utrzymują się blisko 0,01%. Microsoft i Yahoo stosują porównywalne oczekiwania. Traktuj 0,3% jako urwisko, a 0,1% jako swój prawdziwy sufit.

Uwaga o pomiarze: wskaźnik spamu, który ma znaczenie, to ten, który raportuje Google Postmaster Tools (skargi jako ułamek poczty, która dotarła do populacji kwalifikującej się do skrzynki odbiorczej), a nie Twoje własne oszacowanie oparte na otwarciach. Śledź liczbę dostawcy, bo to ta liczba jest używana przeciwko Tobie.

Jak zredukować skargi?

Zadbaj, by ludzie pamiętali zapisanie się i mogli łatwo odejść:

• Wysyłaj tylko do użytkowników, którzy wyrazili zgodę (opt-in).
• Uczyń rezygnację łatwą i natychmiastową.
• Używaj jasnych nazw nadawcy i adresów From.

Dlaczego to działa:

• Wysyłaj tylko do użytkowników opt-in: najczęstszy powód, dla którego ludzie klikają „spam”, to to, że nie pamiętają zapisania się. Prawdziwa, jawna zgoda (idealnie double opt-in, zobacz Pozyskiwanie adresów) zapobiega zaskoczeniu, które wywołuje skargi.
• Uczyń rezygnację łatwą i natychmiastową: jeśli odejście jest trudne, przycisk spamu staje się przyciskiem rezygnacji, a to jedno kliknięcie szkodzi Ci dużo bardziej niż cicha rezygnacja. Widoczna rezygnacja jednym kliknięciem, która działa natychmiast, jest zarówno wymogiem prawnym, jak i ochroną dostarczalności (zobacz one-click unsubscribe niżej i Zgodność prawna).
• Używaj jasnych nazw nadawcy i adresów From: odbiorcy skarżą się na pocztę, której nie rozpoznają. Spójna, rozpoznawalna nazwa i adres From: budują znajomość i zaufanie.

Czym jest pętla zwrotna (feedback loop) i jak ją skonfigurować?

Pętla zwrotna (FBL) to program, w którym dostawca skrzynki przekazuje Ci powiadomienie za każdym razem, gdy odbiorca oznaczy Twoją pocztę jako spam. Zarejestruj się w nich i usuwaj skarżących się natychmiast:

• Google nie prowadzi FBL per wiadomość; ujawnia wskaźniki skarg przez Postmaster Tools i oferuje FBL oparty na nagłówku dla nadawców o dużym wolumenie, którzy tagują pocztę nagłówkiem Feedback-ID.
• Yahoo / AOL (Verizon Media) prowadzą programy Complaint Feedback Loop (CFL), do których zapisujesz się przez domenę wysyłającą.
• Microsoft oferuje SNDS (Smart Network Data Services) oraz pętlę zwrotną JMRP (Junk Mail Reporting Program).

Rejestracja w nich to sposób, w jaki w ogóle dowiadujesz się o skargach. Bez nich lecisz na ślepo. Dodaj nagłówek Feedback-ID do masowej poczty, aby Google mógł przypisać skargi z powrotem do kampanii/strumienia:

Feedback-ID: newsletter:campaign42:streamA:yourdomain

W chwili, gdy nadejdzie skarga, supresuj ten adres na zawsze; nigdy nie daj skarżącemu się szansy poskarżenia się dwa razy. Podłącz zdarzenia FBL/skarg do tego samego potoku supresji co odrzucenia (zobacz Webhooki i zdarzenia).

Czego dokładnie wymagały zasady dla masowych nadawców Gmail/Yahoo/Microsoft z 2024 roku?

Z mocą obowiązującą od lutego 2024, Gmail i Yahoo (z Microsoftem podążającym w tym samym kierunku) nałożyły wymuszone wymagania na masowych nadawców, z grubsza tych wysyłających 5000+ wiadomości dziennie do danego dostawcy, choć wymagania uwierzytelniania coraz bardziej dotyczą wszystkich. Wyróżniają się trzy wymagania:

1. Uwierzytelniaj wszystko. Masowi nadawcy muszą przechodzić SPF i DKIM oraz opublikować rekord DMARC (co najmniej p=none) ze zgodnością. Nieuwierzytelniona masowa poczta jest odrzucana lub kierowana do śmieci.
2. Pozostań poniżej sufitu skarg spamowych. Utrzymuj wskaźnik spamu raportowany przez Postmaster poniżej 0,3%, a najlepiej poniżej 0,1%. Przekrocz 0,3%, a czeka Cię throttling i kierowanie do folderu spam, dopóki nie wrócisz do normy.
3. Oferuj rezygnację jednym kliknięciem (one-click unsubscribe). Masowa poczta marketingowa/promocyjna musi zawierać działającą rezygnację jednym kliknięciem (RFC 8058) i honorować rezygnacje w ciągu 2 dni.

Rezygnacja jednym kliknięciem (RFC 8058) wykonana poprawnie

Rezygnacja jednym kliknięciem wymaga dwóch współpracujących nagłówków. Nagłówek List-Unsubscribe (RFC 2369) musi oferować adres URL HTTPS, a nagłówek List-Unsubscribe-Post (RFC 8058) sygnalizuje, że pojedynczy HTTP POST na ten URL, bez dalszej interakcji użytkownika, bez logowania, bez strony potwierdzenia, musi wykonać rezygnację.

List-Unsubscribe: <https://yourdomain.com/u/abc123>, <mailto:unsubscribe@yourdomain.com?subject=unsub-abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Zasady, które ludzi zaskakują:

• Wariant HTTPS musi akceptować POST (dostawca skrzynki wykonuje POST w imieniu użytkownika). Nie wymagaj GET, strony docelowej ani uwierzytelniania.
• Dołącz też wariant mailto:, jako mechanizm zapasowy.
• Nagłówki muszą być objęte Twoim podpisem DKIM (h=...:list-unsubscribe:list-unsubscribe-post), bo inaczej przekaźnik mógłby je usunąć/zmienić.
• Honoruj rezygnację w ciągu 2 dni (w praktyce zrób to natychmiast).
• Rezygnacja jednym kliknięciem jest dla poczty masowej/marketingowej. Prawdziwie transakcyjna poczta (resety hasła, potwierdzenia) jest zwolniona, ale zobacz Typy maili i Zgodność prawna, gdzie naprawdę przebiega granica; wmieszanie promocji w potwierdzenie może wciągnąć całą wiadomość pod ten wymóg.

Minimalny handler neutralny względem dostawcy:

// POST /u/:token , endpoint rezygnacji jednym kliknięciem (bez auth, idempotentny)
app.post("/u/:token", async (req, res) => {
  const sub = await tokens.resolve(req.params.token); // nieprzejrzysty, podpisany, jednorazowego przeznaczenia
  if (!sub) return res.sendStatus(404);
  await suppressionList.add(sub.email, { reason: "unsubscribe", stream: sub.stream });
  // Odpowiedz 200 natychmiast; nigdy nie przekierowuj na stronę logowania ani potwierdzenia.
  return res.sendStatus(200);
});

Ten sam endpoint powinien też akceptować GET dla ludzi, którzy klikają widoczny link rezygnacji w treści, ale to ścieżka POST spełnia RFC 8058.

BIMI: pokazywanie logo w skrzynce odbiorczej

BIMI (Brand Indicators for Message Identification) pozwala zgodnym dostawcom skrzynek wyświetlać logo Twojej marki obok uwierzytelnionej poczty. Nie jest mechanizmem uwierzytelniania i sam w sobie nie dodaje wzrostu dostarczalności, ale wymaga DMARC na poziomie wymuszenia (p=quarantine lub p=reject), więc jest użytecznym wymuszaczem i widoczną nagrodą za osiągnięcie wymuszenia.

Wymagania:

• Polityka DMARC p=quarantine (z pct=100) lub p=reject. p=none nie kwalifikuje się.
• Logo jako SVG Tiny PS (profil Portable/Secure), kwadratowe, hostowane po HTTPS.
• Dla większości dostawców (zwłaszcza Gmail i Apple Mail), VMC (Verified Mark Certificate) lub CMC (Common Mark Certificate), certyfikat od autoryzowanego CA poświadczający, że posiadasz znak. To kosztowna, powolna część.

; TXT record at default._bimi.yourdomain.com
default._bimi.yourdomain.com.  IN  TXT  "v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/vmc.pem"

• l=: adres URL HTTPS logo SVG.
• a=: adres URL HTTPS pakietu PEM VMC/CMC. Pomiń tylko wtedy, gdy celujesz w dostawców akceptujących BIMI bez certyfikatu (jest ich mniej).

Traktuj BIMI jako zwieńczenie ukończonego programu uwierzytelniania, a nie wczesne zadanie.

ARC: przetrwanie przekierowań i list mailingowych

ARC (Authenticated Received Chain, RFC 8617) naprawia problem DMARC-kontra-przekierowanie. Gdy pośrednik (lista mailingowa, usługa przekierowująca, brama bezpieczeństwa) modyfikuje wiadomość i tym samym łamie SPF/DKIM, ARC pozwala temu pośrednikowi zapisać „uwierzytelnianie przeszło, gdy ją otrzymałem” w odpornym na manipulacje łańcuchu nagłówków. Odbiorca dalej w łańcuchu, który ufa pośrednikowi, może wtedy honorować oryginalny pozytywny wynik, choć SPF/DKIM teraz zawodzą.

ARC dodaje trzy nagłówki na hop: ARC-Authentication-Results, ARC-Message-Signature oraz ARC-Seal. Każdy hop pieczętuje dotychczasowy łańcuch, więc odbiorca może zweryfikować, że łańcuch nie został sfałszowany.

Co właściwie robisz z ARC:

• Jako nadawca źródłowy: nic bezpośrednio, nie możesz zmusić odbiorcy, by zaufał pośrednikowi. Twoim zadaniem jest utrzymać własny DKIM nienaruszony (kanonikalizacja relaxed, podpisywanie stabilnych nagłówków), aby mniej wiadomości w ogóle potrzebowało ARC.
• Jako przekaźnik/pośrednik (np. prowadzisz usługę, która ponownie wysyła cudzą pocztę): zaimplementuj pieczętowanie ARC, aby odbiorcy dalej w łańcuchu mogli zachować oryginalny wynik DMARC.
• Jako odbiorca: weryfikuj łańcuchy ARC od nadawców, którym ufasz, przed zastosowaniem polityki DMARC.

ARC jest powodem, dla którego przekierowana wiadomość wciąż może dotrzeć do skrzynki odbiorczej pod Twoim p=reject. To nie coś, co „włączasz” w DNS; to się implementuje w MTA.

MTA-STS i TLS-RPT: wymuszanie szyfrowania transportu

Oportunistyczny TLS w SMTP (STARTTLS) jest trywialnie degradowany przez aktywnego atakującego, który usuwa zdolność STARTTLS, wymuszając tekst jawny. Dwa standardy zamykają to dla poczty przychodzącej do Twojej domeny.

MTA-STS (RFC 8461)

MTA-STS pozwala opublikować politykę mówiącą „nadawcy muszą używać TLS z ważnym certyfikatem, aby dostarczyć do moich hostów MX”. Jest ogłaszana przez rekord TXT DNS, który kieruje nadawców do pliku polityki hostowanego po HTTPS.

; TXT record at _mta-sts.yourdomain.com
_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20240601000000"

Sama polityka jest serwowana pod https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.mail.yourdomain.com
max_age: 604800

• mode: testing najpierw (niepowodzenia są raportowane, ale poczta wciąż płynie), potem mode: enforce, gdy TLS-RPT pokaże czyste raporty.
• id= zmienia się, gdy zmieniasz politykę; podbij go, by unieważnić bufory.
• max_age to czas, przez jaki nadawcy buforują politykę (sekundy). Typowy jest jeden tydzień.

MTA-STS chroni pocztę przychodzącą do Ciebie. To kuzyn z warstwy aplikacji wobec DANE/DNSSEC (który chroni to samo za pomocą podpisanych DNSSEC rekordów TLSA); MTA-STS jest zwykle łatwiejszy do wdrożenia, bo nie wymaga DNSSEC.

TLS-RPT (RFC 8460)

TLS-RPT prosi nadawców, by raportowali niepowodzenia negocjacji TLS i problemy polityki, abyś dowiedział się zanim enforce MTA-STS zacznie gubić pocztę.

; TXT record at _smtp._tls.yourdomain.com
_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

Wdróż TLS-RPT razem z MTA-STS w trybie testing, czytaj raporty JSON przez kilka tygodni, napraw wszelkie problemy z certyfikatem/MX, które ujawnią, a potem przełącz MTA-STS na enforce.

Jak ustrukturyzować domeny i subdomeny wysyłające?

Używaj różnych subdomen do różnych celów wysyłki, na przykład t.yourdomain.com dla e‑maili transakcyjnych i m.yourdomain.com dla e‑maili marketingowych. Sposób, w jaki strukturyzujesz domeny wysyłające, decyduje o tym, jak problemy w jednym strumieniu wpływają na inne. Trochę architektury z góry zapobiega temu, by marketingowa wpadka położyła e‑maile resetu hasła.

Dlaczego separacja subdomen ma znaczenie: reputacja jest śledzona per domena wysyłająca. Poczta marketingowa jest z natury bardziej ryzykowna, o wyższym wolumenie, więcej skarg i więcej rezygnacji. Jeśli wysyłasz marketing z tej samej domeny co poczta transakcyjna, uderzenie w reputację marketingu może wciągnąć Twoje resety hasła i potwierdzenia do spamu. Izolowanie strumieni na osobnych subdomenach (t. transakcyjna, m. marketingowa) odgradza ryzyko: nawet jeśli m.yourdomain.com dostanie uderzenie w reputację, t.yourdomain.com pozostaje czysta. To odzwierciedla separację list transakcyjnych i marketingowych w Zarządzaniu listą.

Przepracowana architektura subdomen

Kluczowe zasady:

• Nigdy nie wysyłaj żadnej poczty programowej z wierzchołka, jeśli możesz tego uniknąć. Trzymaj reputację wierzchołka nieskazitelną i chroń ją p=reject, aby trudno było ją podrobić w phishingu.
• Każda subdomena dostaje własny SPF, DKIM i DMARC. Subdomena dziedziczy DMARC poziomu organizacji tylko przez sp; publikuj jawne rekordy, abyś mógł dostroić zgodność i raportowanie per strumień.
• d= DKIM powinno pasować do subdomeny wysyłającej (d=m.yourdomain.com), aby reputacja narastała na właściwym strumieniu.
• Ponieważ zgodność DMARC jest domyślnie relaxed, poczta m.yourdomain.com wciąż jest zgodna z From: news@m.yourdomain.com. Trzymaj From: na tej samej subdomenie, którą podpisujesz.

Jakiego TTL DNS używać dla rekordów e‑mail?

Ustaw niski TTL (300 s) podczas konfiguracji, a potem wysoki TTL (3600 s lub więcej), gdy wszystko jest stabilne. TTL (time-to-live) kontroluje, jak długo resolwery buforują rekord DNS.

Podczas konfiguracji będziesz wielokrotnie edytować rekordy i chcesz, by zmiany propagowały się szybko, więc ustaw niski TTL (300 s), a Twoje poprawki wchodzą w życie w ciągu minut. Gdy wszystko jest stabilne, podnieś TTL (3600 s lub więcej). Wysoki TTL oznacza mniej zapytań DNS, szybsze rozwiązywanie dla odbiorców i mniejsze obciążenie. Pamiętaj, że każda przyszła zmiana zajmie wtedy aż tyle czasu, by się rozpropagować, więc obniż TTL z powrotem do 300 s dzień przed planowaną edycją rekordu.

TTL według typu rekordu

Wzorzec jest zawsze ten sam: obniż TTL dzień przed planowaną zmianą, dokonaj zmiany, potwierdź propagację za pomocą dig wobec publicznego resolwera, a potem podnieś go z powrotem.

Moje e‑maile trafiają do spamu: co sprawdzić i w jakiej kolejności?

Sprawdzaj w tej kolejności, od najczęstszego i najłatwiejszego do naprawy do najbardziej subtelnego:

1. Uwierzytelnianie (SPF, DKIM, DMARC).
2. Nagłówek List-Unsubscribe / rezygnacja jednym kliknięciem, wymagana przez Gmail/Yahoo od lutego 2024 (zobacz Zgodność prawna).
3. Reputacja nadawcy (czarne listy, wskaźniki skarg).
4. Treść.
5. Wzorce wysyłki (nagłe skoki wolumenu).

Dlaczego ta kolejność: przytłaczająca większość problemów „trafiania do spamu” to niepowodzenia uwierzytelniania (numer 1), więc napraw je najpierw, bo nic dalej nie ma znaczenia, dopóki poczta się nie uwierzytelnia. Nagłówek List-Unsubscribe (numer 2) jest teraz obowiązkowy dla masowych nadawców do Gmail/Yahoo, a jego brak sam w sobie może skierować Cię do spamu. Dopiero gdy tożsamość i nagłówki są poprawne, powinieneś zbadać reputację (numer 3), potem treść (numer 4), a na końcu wzorce wysyłki (numer 5), takie jak nagłe skoki wolumenu, które wyglądają jak przejęte konto.

Drzewo decyzyjne rozwiązywania problemów

• Poczta do wszystkich dostawców nagle zawodzi? → Niemal zawsze DNS/uwierzytelnianie. Sprawdź dig dla SPF/DKIM/DMARC; sprawdź wygasły selektor DKIM lub zduplikowany rekord SPF. Sprawdź IP wobec RBL.
• Poczta do jednego dostawcy (np. tylko Microsoft) zawodzi? → Reputacja lub throttling specyficzny dla dostawcy. Czytaj sygnały postmaster tego dostawcy (SNDS/JMRP dla Microsoftu, Postmaster Tools dla Google). Szukaj odrzuceń 4.7.x/5.7.x.
• dkim=pass, ale dmarc=fail? → Zgodność. Twoje d= DKIM lub domena Return-Path SPF nie pasuje do From:. Napraw domenę podpisującą lub From:.
• Przechodziło, zepsuło się po edycji? → Porównaj różnice w DNS. Drugi rekord SPF, literówka w selektorze, TTL wciąż serwujący starą wartość, albo ktoś „posprzątał” rekord TXT.
• Tylko przekierowana poczta zawodzi? → Modyfikacja treści/nagłówka DKIM albo brak ARC. Potwierdź kanonikalizację relaxed i to, że podpisujesz stabilne nagłówki.
• Wysokie skargi przy dobrym uwierzytelnianiu? → Problem zgody/treści, a nie techniczny. Zaudytuj swoje źródło opt-in i ścieżkę rezygnacji.
• Nowa domena/IP, niski wskaźnik trafienia do skrzynki? → Niewystarczające rozgrzewanie. Zwolnij i zwiększaj rampę na zaangażowanych użytkownikach.

Jakich narzędzi użyć do diagnozy dostarczalności?

Użyj tych, każdego do innego zadania:

• Google Postmaster Tools: reputacja domeny/IP, wskaźniki spamu i wskaźniki przejść uwierzytelniania z perspektywy Gmaila.
• mail-tester.com: wyślij testowy e‑mail, dostań wynik dostarczalności 0–10 plus rozbicie na treść/uwierzytelnianie/czarne listy.
• MXToolbox: sprawdź status na czarnych listach (RBL) i uruchamiaj wyszukiwania SPF/DKIM/DMARC bez dig.
• Microsoft SNDS / JMRP: dane IP i pętla zwrotna skarg dla Outlook/Hotmail/Office 365.
• Procesor raportów zbiorczych DMARC: zamienia surowy XML RUA w widok per źródło tego, kto jest zgodny, a kto nie.

Jak używać każdego:

• Google Postmaster Tools: podłącz swoją domenę, by zobaczyć prosto z Gmaila reputację domeny i IP, wskaźnik spamu, wskaźniki przejść uwierzytelniania oraz dane FBL. To najbliższa rzecz do zobaczenia siebie oczami Gmaila; sprawdzaj to, gdy dostarczanie do Gmaila spada.
• mail-tester.com: wyślij jeden e‑mail na adres, który Ci poda, i otrzymaj wynik od 0 do 10 plus rozbicie problemów z uwierzytelnianiem, treścią i czarnymi listami. Idealne do szybkiej kontroli zdrowego rozsądku przed startem.
• Kontrola czarnych list MXToolbox: potwierdza, czy Twoje IP lub domena wysyłająca pojawia się na głównych czarnych listach (RBL). Jeśli jesteś na czarnej liście, podążaj za procesem usuwania każdej listy po naprawieniu zachowania, które to spowodowało, usunięcie przed naprawą wraca Cię na listę.

Typowe błędy, które wysyłają dobrą pocztę do spamu

• Dwa rekordy SPF, albo jeden rekord SPF powyżej limitu 10 zapytań (permerror).
• DKIM podpisujący domeną dostawcy, więc DMARC nigdy nie jest zgodny.
• Pozostawanie na p=none na zawsze i zakładanie, że jest się „zgodnym z DMARC”.
• Mieszanie marketingu i transakcji na jednej domenie, a potem patrzenie, jak kampania zatapia potwierdzenia.
• Brak supresji w momencie wysyłki, więc adresy odrzucone i skarżące się są ponownie obsyłane.
• Brakujący lub tylko GET unsubscribe, niespełniający RFC 8058.
• E‑maile wyłącznie obrazkowe, skracacze linków, niedopasowane nazwy wyświetlane From:, albo domena From:, która nie pasuje do domeny podpisującej.
• Wysadzanie na zimno nowego IP/domeny bez rozgrzewania.
• Traktowanie odrzuceń z polityki 4.7.x/5.7.x jako złych adresów i supresowanie odbiorcy zamiast naprawiania przyczyny po stronie nadawcy.

Jaka jest pełna lista kontrolna dostarczalności?

• SPF, DKIM i DMARC wszystkie przechodzą ze zgodnością (dkim=pass, spf=pass, dmarc=pass w Authentication-Results)
• Dokładnie jeden rekord SPF, poniżej limitu 10 zapytań, ~all (lub -all przy wymuszeniu)
• DKIM podpisuje własną domeną (d=) i kluczem 2048-bitowym
• DMARC na p=quarantine/p=reject z ustawionym sp, monitorowanym rua
• List-Unsubscribe + List-Unsubscribe-Post (RFC 8058) na masowej poczcie; honorowane w ciągu 2 dni
• Wskaźnik skarg spamowych poniżej 0,3% (cel poniżej 0,1%); wskaźnik odrzuceń poniżej 1–2%
• Twarde odrzucenia i skargi supresowane automatycznie w czasie rzeczywistym
• Transakcyjna i marketingowa izolowane na osobnych subdomenach, nigdy na wierzchołku
• Postmaster Tools, SNDS/JMRP i FBL podłączone i monitorowane
• Nowe IP lub domena rozgrzane stopniowo przed wysyłką o wysokim wolumenie
• (Opcjonalnie, zwieńczenie) MTA-STS + TLS-RPT dla przychodzącego TLS; BIMI po osiągnięciu wymuszenia

Co powinienem przeczytać dalej?

• Zarządzanie listą: obsługa odrzuceń i skarg, by chronić reputację.
• Niezawodność wysyłki: logika ponawiania i obsługa błędów.
• Webhooki i zdarzenia: odbieranie i weryfikowanie zdarzeń odrzuceń/skarg zasilających supresję.
• Zgodność prawna: nagłówek List-Unsubscribe, rezygnacja jednym kliknięciem i wymogi prawne.
• Pozyskiwanie adresów: waliduj adresy, zanim w ogóle odbiją.
• Typy maili: granica transakcyjne kontra marketingowe, która decyduje, które zasady obowiązują.
• Indeks: powrót do przeglądu przewodnika.