Co to jest raportowanie TLS SMTP (TLS-RPT)?

Ponieważ organizacje w coraz większym stopniu polegają na poczcie elektronicznej jako podstawowym środku komunikacji, nie można przecenić znaczenia wzmocnienia tych kanałów przed potencjalnymi zagrożeniami. Transport Layer Security(TLS) zapewnia poufność i integralność danych przesyłanych przez sieci. 

SMTP TLS Reporting (TLS-RPT) to krytyczny protokół, który współpracuje z MTA-STS w celu zapewnienia bezpiecznego dostarczania wiadomości e-mail. Dostarczając szczegółowych informacji zwrotnych na temat problemów z dostarczaniem wiadomości e-mail, TLS-RPT pomaga właścicielom domen zachować integralność i poufność ich komunikacji. W tym kompleksowym przewodniku zbadamy, czym jest SMTP TLS Reporting, jak działa i dlaczego jest niezbędny dla strategii bezpieczeństwa poczty e-mail".

Kilka protokołów pomaga szyfrować kanały wiadomości SMTP, aby uniemożliwić cyberprzestępcom przechwytywanie komunikacji e-mail. Należą do nich STARTTLS, DANE i MTA-STS. Jednakże, gdy próby szyfrowania nie powiodą się podczas korzystania z tych protokołów, wiadomość e-mail może nie zostać dostarczona. TLS-RPT (zgodnie z opisem w RFC 8460) zapewnia mechanizm informacji zwrotnej do zgłaszania tych niepowodzeń dostarczalności.

Zdecydowanie zalecamy używanie TLS-RPT w połączeniu z MTA-STS . Zrozummy, jak te protokoły współpracują ze sobą, aby wzmocnić bezpieczeństwo poczty e-mail.

Co to jest TLS-RPT?

TLS-RPT (Transport Layer Security Reporting) to standard zgłaszania problemów z dostarczaniem wiadomości e-mail, gdy nie są one szyfrowane za pomocą TLS. Jego znaczenie w uwierzytelnianiu wiadomości e-mail idzie w parze z powodem włączenia szyfrowania TLS dla wiadomości e-mail. 

Szyfrowanie TLS zapewnia bezpieczne dostarczanie każdej wysłanej wiadomości e-mail. W przypadku, gdy połączenie nie jest bezpieczne, wiele wiadomości e-mail może nie zostać dostarczonych. TLS-RPT umożliwia właścicielom domen monitorowanie dostarczania wiadomości e-mail i awarii połączeń. Raporty mogą zawierać informacje na temat: 

• Problemy z obsługą zasad MTA-STS 
• Przyczyna i typ niepowodzenia dostawy
• Adres IP agentów transferu poczty wysyłających i odbierających wiadomości e-mail
• Całkowita liczba udanych i nieudanych sesji połączeń TLS 

Zapewnia to widoczność kanałów e-mail i możliwość szybszego przeciwdziałania wyzwaniom związanym z dostarczalnością.

Uprość raportowanie SMTP TLS dzięki PowerDMARC!

Jak działa raportowanie TLS?

W komunikacji e-mail SMTP szyfrowanie TLS jest "oportunistyczne". Oznacza to, że jeśli nie można wynegocjować szyfrowanego kanału, wiadomość e-mail jest nadal wysyłana w formacie niezaszyfrowanym (zwykły tekst). W rzeczywistości, prawie 4 dekady temu, protokoły poczty elektronicznej SMTP nie obsługiwały szyfrowania TLS. Musiało ono zostać wprowadzone później w postaci polecenia STARTTLS. 

Polecenie STARTTLS jest wydawane tylko w komunikacji SMTP, jeśli obie strony obsługują szyfrowanie TLS. W przeciwnym razie wiadomość e-mail zostanie wysłana w postaci zwykłego tekstu. 

Aby pozbyć się oportunistycznego szyfrowania w SMTP, wprowadzono MTA-STS (RFC 8461). Protokół MTA-STS zapewnia szyfrowanie wiadomości e-mail przed ich dostarczeniem. Serwer poczty e-mail lub Mail Transfer Agent (MTA) negocjuje z serwerem odbierającym, aby sprawdzić, czy obsługuje on polecenie STARTTLS. Jeśli tak, wiadomość e-mail jest szyfrowana za pomocą TLS i dostarczana. W przeciwnym razie dostarczenie nie powiedzie się.

Wyjaśnienie krok po kroku, jak działa TLS-RPT

1. Zrozumienie procesu uzgadniania TLS

Uścisk dłoni Transport Layer Security (TLS handshake) to proces ustanawiania bezpiecznego połączenia między dwoma komunikującymi się agentami transferu poczty (MTA). Proces ten obejmuje następujące kroki: 

• MTA wysyłający wiadomości e-mail wysyła wiadomość "Client Hello" do MTA odbierającego. Wiadomość ta zawiera przydatne parametry, takie jak wersje TLS i zestawy szyfrów. 
• MTA odbierający wiadomości e-mail odbiera tę wiadomość i odpowiada wiadomością "Server Hello". Zawiera ona wybraną wersję TLS i zestaw szyfrów. 
• Po zainicjowaniu uzgadniania TLS, odbierający MTA wysyła swój certyfikat SSL/TLS, który jest wydawany przez zaufany urząd certyfikacji (CA). Certyfikat ten zawiera klucz publiczny.
• Oba komunikujące się MTA bezpiecznie wymieniają swoje klucze kryptograficzne i nawiązują połączenie szyfrowane TLS. Zapewnia to bezpieczną komunikację e-mail między obiema stronami. 

2. Nieudane scenariusze uzgadniania TLS 

Uściski TLS mogą zakończyć się niepowodzeniem z różnych powodów: 

• Błędy certyfikacji: Wygasłe certyfikaty lub certyfikaty wydane przez niezaufane urzędy certyfikacji mogą prowadzić do błędów uzgadniania TLS.
• Niezgodności wersji: Jeśli występuje niezgodność między wersjami TLS obsługiwanymi przez wysyłające i odbierające MTA, może to prowadzić do niepowodzenia uzgadniania.
• Awarie STARTTLS: Jeśli polecenie STARTTLS nie zostanie poprawnie zaimplementowane, może to ponownie doprowadzić do niepowodzenia szyfrowania TLS.
• Egzekwowanie MTA-STS: W przypadku, gdy odbiorca wiadomości e-mail ustawił tryb polityki MTA-STS na "wymuszanie", nieudany handshake TLS może prowadzić do odrzucenia wiadomości.

3. Generowanie i dostarczanie raportów

Za każdym razem, gdy wystąpią błędy szyfrowania TLS, serwer wysyłający generuje raport TLS-RPT i wysyła go do właściciela domeny w celu dalszej oceny i rozwiązywania problemów. 

Treść raportu

Szczegóły serwera wysyłającego: Adres IP i nazwa domeny nadawcy.

Szczegóły serwera odbierającego: Informacje o domenie odbiorcy i serwerze poczty e-mail.

Opis błędu: Typ i szczegóły błędu (np. błąd certyfikatu, niezgodność protokołu).

Czas porażki: Znacznik czasu wystąpienia błędu.

Tryb zasad: Określa, czy domena jest w trybie "testowania" czy "wymuszania".

Dostarczanie raportów

Te raporty TLS są wysyłane w formacie JSON na adres e-mail określony w rekordzie TLS-RPT DNS TXT właściciela domeny. 

Rola szyfrowania oportunistycznego w SMTP

SMTP tradycyjnie wykorzystuje szyfrowanie oportunistyczne. Oznacza to, że próbuje użyć TLS, ale powraca do niezaszyfrowanego dostarczania, jeśli odbierający MTA nie obsługuje TLS.

Szyfrowanie oportunistyczne ma jednak jedno poważne ograniczenie. W tym typie szyfrowania, który nie ustanawia żadnych ograniczeń, wiadomości e-mail mogą być wysyłane w postaci zwykłego tekstu lub czystego tekstu (w niezaszyfrowanym formacie), jeśli szyfrowanie TLS nie powiedzie się. Takie niezaszyfrowane wiadomości są podatne na przechwycenie.

Jak MTA-STS i TLS-RPT współpracują ze sobą?

Mail Transfer Agent Strict Transport Security (MTA-STS) i TLS-RPT są uzupełniającymi się protokołami w ekosystemie uwierzytelniania wiadomości e-mail. Podczas gdy MTA-STS zapewnia, że wysyłający MTA musi używać TLS do dostarczania i odrzucać wiadomości e-mail, jeśli szyfrowanie nie powiedzie się,

TLS-RPT umożliwia właścicielom domen monitorowanie nieudanych uzgodnień TLS i rozwiązywanie problemów. Wdrożone razem mogą zapobiegać przechwytywaniu wiadomości w tranzycie i minimalizować problemy z dostarczalnością wiadomości e-mail. 

Związek między DANE i TLS-RPT

DNS-based Authentication of Named Entities (DANE) to protokół, który umożliwia właścicielom domen określenie certyfikatów TLS zweryfikowanych za pomocą DNSSEC w celu zapobiegania atakom typu man-in-the-middle. Podczas gdy TLS-RPT monitoruje awarie TLS, DANE zapewnia, że używane są tylko zaufane certyfikaty. W ten sposób DANE aktywnie zapobiega atakom polegającym na obniżaniu poziomu TLS i fałszowaniu certyfikatów, utrzymując w ten sposób integralność komunikacji e-mail. 

Dlaczego potrzebujesz raportowania SMTP TLS?

Właściciele domen muszą być informowani o problemach z dostarczaniem wiadomości e-mail z powodu awarii szyfrowania TLS dla wiadomości e-mail wysyłanych z domeny obsługującej MTA-STS. Raportowanie TLS umożliwia to poprzez dostarczanie tych informacji. 

• Bezpieczeństwo poczty e-mail: Podkreślenie zagrożeń związanych z niezaszyfrowaną komunikacją e-mail (np. przechwytywanie, ataki typu man-in-the-middle).
• Zgodność: Wspomnij, w jaki sposób TLS-RPT pomaga organizacjom spełniać wymogi regulacyjne dotyczące ochrony danych.
• Dostarczalność: Wyjaśnij, w jaki sposób TLS-RPT poprawia dostarczalność wiadomości e-mail poprzez identyfikację i rozwiązywanie problemów z szyfrowaniem.

Kroki konfiguracji TLS-RPT

Możesz włączyć raportowanie TLS dla swojej domeny, tworząc rekord TXT dla TLS-RPT i publikując go w DNS. Rekord ten musi być opublikowany w subdomenie smtp.tls.yourdomain.com

Krok 1: Wygenerowanie rekordu TLS-RPT (przy użyciu generatora rekordów TLS-RPT)

Możesz zarejestrować się w PowerDMARC za darmo i skorzystać z naszego generatora rekordów TLS-RPT, aby utworzyć swój rekord.

Krok 2: Wprowadź swój adres e-mail do raportowania

Wprowadź adres e-mail, na który chcesz otrzymywać raporty SMTP TLS.

Krok 3: Opublikowanie rekordu TLS w systemie DNS

Możesz skontaktować się z rejestratorem domeny, aby utworzyć nowy rekord TXT dla TLS-RPT. Jeśli zarządzasz własnym DNS, edytuj ustawienia DNS, aby uwzględnić rekord.

Składnia i przykład rekordu TLS-RPT

Składnia: v=TLSRPTv1; rua=mailto:[email protected];

Rozbijmy 2 składniki dostarczonego rekordu raportowania TLS:

1. v=TLSRPTv1: Ten znacznik określa wersję używanego protokołu TLS-RPT. W tym przypadku, "TLSRPTv1" oznacza pierwszą wersję protokołu.
2. rua=mailto:[email protected]: rua oznacza "Reporting URI(s) for Aggregate Data". Ten znacznik określa, gdzie serwer pocztowy odbiorcy powinien wysyłać zagregowane raporty TLS.

Można skonfigurować więcej niż jedno miejsce docelowe do odbierania raportów. W przypadku wielu miejsc docelowych należy oddzielić każdy wpis przecinkiem (,). Możesz użyć "mailto:", aby określić adres e-mail dla tego kroku lub poinstruować MTA, aby przesyłał raporty za pośrednictwem POST do adresów URL punktów końcowych, używając "https:" w polu rua=. Jeśli używasz "https:" , upewnij się, że pole definiuje adres URL do serwera WWW obsługującego protokół HTTPS z ważnym certyfikatem. Zarówno "mailto:", jak i "https:" mogą być również używane w jednym rekordzie, oddzielone przecinkiem. 

Przykład: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

Uwaga: W praktyce należy zastąpić "yourdomain.com" rzeczywistą nazwą domeny, w której chcesz otrzymywać te raporty.

Zrozumienie raportów TLS-RPT JSON

Struktura raportu TLS-RPT JSON

Raporty TLS są wysyłane w formacie JSON. Poniżej znajduje się przykład tego, jak może wyglądać raport JSON TLS:

{

  "organization-name": "Organization Inc.",

  “date-range”: {

    "start-datetime": “2020-10-22T00:00:00Z”,

    "end-datetime": “2020-10-22T23:59:59Z”

  },

  "contact-info": "[email protected]",

  "report-id": “2020-10-22T00:00:00Z_domain.com”,

  "policies": [

    {

      “policy”: {

        "typ polityki": "sts",

        "policy-string": [

          "version: STSv1",

          "tryb: testowanie",

          "mx: mx.domain.com",

          "mx: mx2.domain.com",

          "mx: mx3.domain.com",

          "max_age: 604800"

        ],

        "policy-domain": "domain.com"

      },

      “summary”: {

        "total-successful-session-count": 15,

        "total-failure-session-count": 0

      }

Kluczowe pola i ich znaczenie

Oto podział głównych pól w tym raporcie JSON TLS:

Format raportu TLS-RPT JSON i interpretacja danych

Metadane raportu

{

  "organization-name": "Sending MTA Organization",

  “date-range”: {

    "start-datetime": “2025-02-25T00:00:00Z”,

    "end-datetime": “2025-02-25T23:59:59Z”

  },

  "report-id": “unique-report-id-12345”

}

Ta sekcja raportu JSON zawiera podstawowe informacje, takie jak nazwa organizacji nadawcy wiadomości e-mail, data i godzina rozpoczęcia, data i godzina zakończenia oraz unikalny identyfikator wygenerowanego raportu TLS.

Szczegóły polityki

“policy”: {

  "typ polityki": "sts",

  "policy-string": "mode: enforce; mx: mail.example.com; max_age: 604800;"

}

W tej sekcji opisano zaimplementowany tryb polityki MTA-STS, który w tym przypadku jest trybem wymuszania, ale można go również ustawić na tryb testowania. 

Szczegóły awarii

"failure-details": [

  {

    "result-type": "certificate-expired",

    "sending-mta": "smtp.example.org",

    "receiving-mta": "mail.example.com",

    "failure-reason": "TLS handshake nie powiódł się z powodu wygasłego certyfikatu"

  }

]

Ta sekcja jest najważniejszą częścią raportu TLS, zawierającą szczegółowe uzasadnienie szyfrowania i potencjalnych błędów dostarczania. W tym przypadku przykład wskazuje, że wygasły certyfikat jest przyczyną niepowodzenia uzgadniania TLS. Odgrywa to znaczącą rolę w wykrywaniu błędów podczas nieudanych uzgodnień TLS i promuje szybkie rozwiązywanie problemów w bezpiecznej komunikacji TLS. 

Przyczyny niepowodzenia szyfrowania TLS i rozwiązywanie problemów

Przyczyn niepowodzenia szyfrowania TLS może być kilka. Poza brakiem wsparcia dla szyfrowania po obu stronach, bardziej złowrogie powody, takie jak atak SMTP downgrade, mogą prowadzić do niepowodzenia połączenia TLS. Ale właściciele domen chcieliby wiedzieć o nieudanej dostawie. Raportowanie TLS (TLS-RPT) jest protokołem, który powiadamia użytkownika. W przypadku niepowodzenia dostawy otrzymasz raport TLS w formacie pliku JSON na adres e-mail zdefiniowany w rekordzie TLS-RPT. Poniżej podano kilka typowych przyczyn niepowodzeń szyfrowania i wskazówki dotyczące rozwiązywania problemów:

1. Kwestie związane z certyfikatami

certificate_expired

Certyfikat przedstawiony przez zdalny serwer przekroczył datę wygaśnięcia. To czyni go niewiarygodnym do szyfrowania. W takim przypadku należy odnowić certyfikat.

certificate_not_valid_yet

Certyfikat przedstawiony przez zdalny serwer nie jest jeszcze ważny. Może to być spowodowane nieprawidłowym czasem serwera lub przedwczesnym użyciem certyfikatu. W takim przypadku najlepiej skontaktować się z dostawcą certyfikatu.

certificate_revoked

Certyfikat przedstawiony przez zdalny serwer został odwołany przez urząd certyfikacji z powodu obaw o bezpieczeństwo. W takim przypadku najlepiej skontaktować się z dostawcą certyfikatu.

no_valid_signature

Łańcuch certyfikatów przedstawiony przez zdalny serwer nie jest zaufany przez serwer pocztowy nadawcy lub klienta, co wskazuje na potencjalne zagrożenie bezpieczeństwa. W takim przypadku najlepiej skontaktować się z dostawcą certyfikatu.

unsupported_certificate

Certyfikat przedstawiony przez zdalny serwer wykorzystuje algorytmy szyfrowania lub długości kluczy, które nie są obsługiwane przez serwer pocztowy nadawcy, uniemożliwiając bezpieczne połączenie. W takim przypadku najlepiej skontaktować się z dostawcą certyfikatu.

2. Niezgodność nazwy hosta i tożsamości

hostname_mismatch

Nazwa hosta określona w certyfikacie serwera nie jest zgodna z nazwą hosta serwera, z którym próbuje się połączyć serwer pocztowy nadawcy. Wskazuje to na możliwy atak typu man-in-the-middle lub problem z konfiguracją.

Możesz sprawdzić rekordy MX w pliku zasad MTA-STS, aby upewnić się, że są one zgodne z rekordem MX dla domeny.

3. Uścisk dłoni i kwestie związane z protokołem

handshake_failure

Wystąpił błąd podczas początkowego procesu uzgadniania TLS między serwerem pocztowym nadawcy a serwerem pocztowym odbiorcy, uniemożliwiając ustanowienie bezpiecznego kanału. Należy dwukrotnie sprawdzić, czy połączenie SMTP STARTTLS zostało nawiązane. Może być kilka przyczyn przyczyniających się do niepowodzeń szyfrowania, takich jak brak wsparcia dla STARTTLS lub atak TLS downgrade.

4. Kwestie polityki MTA-STS

mta_sts_policy_not_found

Ten błąd występuje, gdy serwer pocztowy nadawcy nie może znaleźć polityki MTA-STS dla domeny odbiorcy. Przejrzyj plik zasad MTA-STS. Powinieneś sprawdzić swój rekord MTA-STS, aby upewnić się, że został opublikowany poprawnie.

mta_sts_policy_invalid

Ten błąd występuje, gdy polityka MTA-STS znaleziona w DNS dla domeny odbiorcy jest nieprawidłowa, zawiera błędy lub nie jest zgodna ze specyfikacją MTA-STS. Przejrzyj plik zasad MTA-STS. Określ odpowiedni tryb polityki MTA-STS. Może to być Brak, Wymuszanie lub Testowanie. Instruuje to serwery wysyłające, jak obsługiwać wiadomości e-mail, które przechodzą błędy walidacji polityki MTA-STS. 

mta_sts_policy_fetch_error

Ten błąd występuje, gdy serwer pocztowy nadawcy napotyka błąd podczas próby pobrania polityki MTA-STS z rekordów DNS domeny odbiorcy. Należy zweryfikować rekordy MTA-STS w DNS, aby upewnić się, że składnia rekordów jest poprawna.

mta_sts_connection_failure

Ten błąd występuje, gdy serwer pocztowy nadawcy próbuje nawiązać bezpieczne połączenie za pomocą MTA-STS, ale kończy się niepowodzeniem z powodów takich jak niezaufane certyfikaty, nieobsługiwane zestawy szyfrów lub inne problemy z TLS. Należy sprawdzić ważność certyfikatu i upewnić się, że certyfikat jest aktualny z najnowszym standardem TLS.

mta_sts_invalid_hostname

Ten błąd występuje, gdy nazwa hosta serwera pocztowego odbiorcy, określona w polityce MTA-STS, nie jest zgodna z rzeczywistą nazwą hosta serwera. Należy sprawdzić rekordy MX w pliku zasad MTA-STS, aby upewnić się, że są one zgodne z rekordem MX dla domeny.

Najlepsze praktyki dotyczące implementacji TLS-RPT

Regularne monitorowanie raportów TLS

Raporty TLS powinny być regularnie monitorowane, aby nie przegapić niedostarczonych wiadomości. Można to zrobić ręcznie monitorując skrzynkę pocztową pod kątem raportów JSON lub korzystając z narzędzia do analizy raportów, takiego jak PowerTLS-RPT.

Upewnij się, że polityka MTA-STS jest prawidłowo skonfigurowana

Aby zapewnić prawidłową implementację TLS-RPT, polityka MTA-STS powinna być skonfigurowana poprawnie i bez błędów składni. Możesz sprawdzić swój rekord za pomocą naszego MTA-STS checker dla tego kroku.

Szybkie reagowanie na awarie szyfrowania

Po wykryciu błędów szyfrowania opisanych w raporcie TLS, ważne jest, aby szybko podjąć działania w celu uniknięcia problemów z dostarczalnością wiadomości e-mail w przyszłości. 

Używanie bezpiecznych wersji protokołu TLS

Korzystanie wyłącznie z najnowszych i obsługiwanych wersji protokołu TLS jest niezbędne do uniknięcia niepożądanych błędów szyfrowania. 

Uproszczone raportowanie SMTP TLS z PowerDMARC

Raportowanie SMTP TLS w PowerDMARC ma na celu poprawę bezpieczeństwa przy jednoczesnym ułatwieniu życia dzięki hostowanej usłudze.

Przetłumaczone raporty TLS

Złożone raporty TLS-RPT JSON są konwertowane na uproszczone informacje, które można przejrzeć w kilka sekund lub przeczytać szczegółowo. 

Problemy z autowykrywaniem

Platforma PowerDMARC wskazuje i podkreśla napotkany problem, dzięki czemu można go rozwiązać bez marnowania czasu.

Nie ma jednej rzeczy, która podoba mi się w platformie PowerDMARC, mają łatwy w użyciu i zrozumiały układ z czymś, co nazwałbym pełnymi funkcjami pozwalającymi na hostowaną kontrolę DMARC, SPF flatteningmożliwość łatwego rozszerzenia SPF w celu sprawdzenia specyfiki rekordu, a nawet pełne wsparcie dla MTA-STS i TLS-RPT!

Dylan B (Właściciel firmy)

Często zadawane pytania dotyczące zabezpieczeń warstwy transportowej

1. Co oznacza skrót TLS?

TLS to skrót od Transport Layer Security. 

2. Kto wydaje certyfikaty TLS? 

Urzędy certyfikacji (CA) mogą wydawać certyfikaty TLS. Proces wydawania certyfikatu obejmuje weryfikację tożsamości posiadacza certyfikatu. Po pomyślnej identyfikacji wydawany jest certyfikat. 

3. Dlaczego potrzebuję certyfikatu TLS?

Certyfikaty TLS odgrywają kluczową rolę w zabezpieczaniu komunikacji przez Internet. Pomagają szyfrować poufnych informacji wymieniane między komunikującymi się serwerami internetowymi. Niektóre z jego najczęstszych zastosowań obejmują zabezpieczanie komunikacji e-mail i HTTPS.

4. Jaki jest obecny standard TLS?

TLS 1.3 jest najnowszą wersją Transport Layer Security. TLS-RPT może być zaimplementowany przy użyciu dowolnej wersji TLS. Może to obejmować starsze wersje protokołu lub przyszłe wersje. Wersja jest zwykle określana na podstawie kryteriów, takich jak możliwości komunikujących się serwerów. 

Dodatkowe zasoby

1. Generator rekordów TLS-RPT 
2. Narzędzie do sprawdzania rekordów TLS-RPT
3. MTA-STS 
4. DMARC

• O
• Latest Posts

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC

Yunes jest liderem zespołu operacyjnego w PowerDMARC z wiedzą ekspercką w zakresie uwierzytelniania i bezpieczeństwa poczty elektronicznej. Yunes jest certyfikowanym przez Microsoft Azure Administrator Associate z certyfikatami CompTIA A+ i wieloma innymi.

Najnowsze posty autorstwa Yunes Tarada (zobacz wszystkie)

• 550 Adres nadawcy narusza zasady dotyczące wielkości liter w nazwach użytkowników: przyczyny i rozwiązania – 11 lutego 2026 r.
• Przewodnik krok po kroku dotyczący konfiguracji SPF, DKIM i DMARC dla Wix – 26 stycznia 2026 r.
• Jak naprawić błąd „Odwrotny DNS nie pasuje do banera SMTP” - 22 stycznia 2026 r.