Czym jest selektor DKIM i jak nim zarządzać w przypadku wielu dostawców usług e-mailowych?

Czym jest selektor DKIM?

Selektor DKIM to krótki ciąg znaków umieszczony w nagłówku wiadomości e-mail podpisanej za pomocą DKIM, który wskazuje serwerowi pocztowemu odbiorcy, gdzie w systemie DNS znajduje się odpowiadający mu klucz publiczny. Jest on zdefiniowany w tagu `s=` nagłówka DKIM-Signature.

Każdy podpis DKIM zawiera wartość selektora. Selektor w połączeniu z domeną podpisującą z tagu `d=` tworzy ścieżkę zapytania DNS, która wskazuje konkretny rekord TXT zawierający klucz publiczny używany do weryfikacji podpisu.

Oto jak wygląda ten selektor w nagłówku wiadomości e-mail:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
bh=abc123…=; b=xyz789…=

W tym przykładzie `selector1` jest selektorem DKIM. Serwer odbierający wyśle zapytanie do adresu `selector1._domainkey.example.com`, aby pobrać klucz publiczny.

Organizacje często korzystają jednocześnie z wielu kluczy podpisujących, w zależności od swoich potrzeb związanych z obsługą poczty elektronicznej. Każdy klucz ma swój własny selektor, dzięki czemu oba mogą współistnieć w ramach tej samej domeny bez żadnych konfliktów.

Selektory umożliwiają również rotację kluczy bez przestojów. Można opublikować nowy klucz pod nowym selektorem, podczas gdy stary selektor pozostaje aktywny, a następnie przełączyć się na nowy klucz po zakończeniu propagacji.

Jak działają selektory DKIM?

Gdy serwer pocztowy odbierający otrzymuje wiadomość e-mail podpisaną za pomocą DKIM, odczytuje selektor (`s=`) i domenę (`d=`) z nagłówka wiadomości, wysyła zapytanie do serwera DNS pod adresem `{selector}._domainkey.{domain}`, pobiera klucz publiczny z uzyskanego rekordu TXT i wykorzystuje ten klucz do weryfikacji podpisu kryptograficznego wiadomości.

Oto instrukcja krok po kroku:

Krok 1: Serwer wysyłający podpisuje wiadomość e-mail

Zanim wiadomość e-mail opuści serwer pocztowy nadawcy (lub dostawcę usług e-mailowych), serwer ten wykorzystuje swój klucz prywatny do wygenerowania podpisu kryptograficznego obejmującego określone pola nagłówka oraz treść wiadomości. Podpis ten, wraz z wartością selektora i domeną podpisującą, jest dołączany do wiadomości e-mail jako nagłówek `DKIM-Signature`.

Krok 2: Serwer odbierający wyodrębnia selektor i domenę

Gdy wiadomość e-mail trafia do skrzynki odbiorczej, serwer odbiorczy analizuje nagłówek `DKIM-Signature` i pobiera dwie wartości:

1. Selektor z `s=` 
2. Domena zaczynająca się od `d=`.

Krok 3: Serwer odbierający wysyła zapytanie do serwera DNS

The server constructs a DNS query by combining the selector, the fixed string `_domainkey`, and the domain: {selector}._domainkey.{domain} → TXT record

Na przykład, jeśli `s=google`, a `d=example.com`, zapytanie DNS będzie wyglądało następująco: google._domainkey.example.com

Krok 4: Serwer DNS zwraca klucz publiczny

Rekord TXT pod tym adresem DNS zawiera klucz publiczny oraz powiązane parametry:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAO…

Krok 5: Serwer odbierający weryfikuje podpis

Serwer wykorzystuje klucz publiczny do weryfikacji podpisu kryptograficznego w nagłówku wiadomości e-mail. 

1. Jeśli podpis się zgadza, test DKIM zakończy się powodzeniem. 
2. Jeśli brakuje klucza, rekord jest nieprawidłowy.
3. Jeśli podpis nie jest zgodny, weryfikacja DKIM kończy się niepowodzeniem.

Selektor łączy nagłówek wiadomości e-mail z rekordem DNS , ponieważ bez rekordu DNS serwer odbiorczy nie miałby możliwości zlokalizowania właściwego klucza publicznego, zwłaszcza gdy domena publikuje wiele kluczy DKIM dla różnych usług.

Składnia i format selektora DKIM 

Selektory DKIM muszą być zgodne z określonymi regułami składniowymi zdefiniowanymi w RFC 6376.

Dopuszczalne znaki:

• Znaki alfanumeryczne (a–z, A–Z, 0–9)
• Myślniki (-)
• Kropki (.) w selektorach typu subdomeny

Ograniczenia:

• W procesie rozpoznawania adresów DNS wielkość liter w selektorach nie ma znaczenia, choć standardowo stosuje się małe litery.
• W RFC 6376 nie określono maksymalnej długości, ale obowiązują praktyczne ograniczenia systemu DNS. W większości implementacji długość selektorów nie przekracza 63 znaków (maksymalna długość etykiety DNS).
• Selektory nie mogą zaczynać się ani kończyć łącznikiem.
• Kropki w selektorach tworzą hierarchie subdomen w zapytaniu DNS. Na przykład `2024.jan._domainkey.example.com` jest prawidłową ścieżką zapytania, jeśli selektorem jest `2024.jan`.

Format rekordu TXT DNS w ścieżce selektora zawiera następujące tagi:

Uwaga: Klucze RSA o długości 2048 bitów generują ciągi klucza publicznego, które przekraczają limit 255 znaków dla pojedynczego ciągu TXT w DNS. System DNS radzi sobie z tym poprzez wieloczęściowe rekordy TXT, w których wartość jest podzielona na wiele ciągów w cudzysłowie, które program rozpoznający łączy zgodnie z RFC 6376. Jednak nie wszystkie interfejsy zarządzania DNS obsługują to efektywnie, co jest częstą przyczyną niepowodzeń DKIM

Jak znaleźć selektor DKIM 

Istnieją cztery sprawdzone metody pozwalające ustalić, jakie selektory DKIM są używane dla danej domeny. Każda z nich ma inne zalety w zależności od tego, czy zarządzasz domeną, masz dostęp do nagłówków wiadomości e-mail, czy też przeprowadzasz audyt z zewnątrz.

Metoda 1: Sprawdź nagłówki wiadomości e-mail

Najprostszym sposobem jest sprawdzenie nagłówków wiadomości e-mail. Otwórz wiadomość wysłaną z danej domeny i wyświetl pełne nagłówki wiadomości.

• W Gmailu: Otwórz wiadomość → kliknij menu z trzema kropkami → „Pokaż oryginał”.
• W programie Outlook: Otwórz wiadomość → Plik → Właściwości → „Nagłówki internetowe”.
• W programie Apple Mail: Widok → Wiadomość → Wszystkie nagłówki.

Znajdź nagłówek `DKIM-Signature` i zlokalizuj znacznik `s=`. Ta wartość to selektor.

Jeśli wiadomość e-mail przeszła przez wiele usług podpisywania, może pojawić się więcej niż jeden nagłówek `DKIM-Signature`, z których każdy będzie miał inny selektor.

Metoda 2: Skorzystaj z narzędzia do sprawdzania DKIM

Jeśli znasz nazwę selektora, możesz bezpośrednio sprawdzić rekord DKIM pod adresem selector._domainkey.example.com. Wyszukiwanie rekordów DKIM w PowerDMARC, MXToolbox lub narzędzia DNS z wiersza poleceń, takie jak dig i nslookup, mogą zwrócićrekord TXT opublikowany dla tego selektora.

Korzystanie z dig:

bash

dig TXT selector1._domainkey.example.com +short

 

Korzystanie z nslookup:

bash

nslookup -q=TXT selector1._domainkey.example.com

Ta metoda wymaga, abyś znał już nazwę selektora lub wypróbował popularne wartości domyślne.

Funkcja sprawdzania DKIM w PowerDMARC może również automatycznie wykrywać selektory dla wielu domen, weryfikować składnię DKIM, identyfikować brakujące lub nieprawidłowe rekordy oraz pomagać w rozwiązywaniu typowych problemów związanych z konfiguracją DKIM. 

Metoda 3: Sprawdź konsolę administracyjną usługi ESP

Większość dostawców usług poczty elektronicznej udostępnia selektor DKIM i klucz publiczny w swoich ustawieniach uwierzytelniania. Na przykład:

• Google Workspace: Konsola administracyjna → Aplikacje → Google Workspace → Gmail → Uwierzytelnij adres e-mail
• Microsoft 365: Portal Defender → Zasady i reguły → Zasady dotyczące zagrożeń → Uwierzytelnianie poczty e-mail → DKIM
• Mailchimp: Strona internetowa → Domeny → Uwierzytelnianie → Ustawienia DKIM

Metoda 4: Raporty zbiorcze DMARC

To najskuteczniejsza metoda na wykrycie wszystkich selektorów, które aktywnie podpisują wiadomości e-mail w imieniu Twojej domeny, w tym tych, o których być może nie wiesz.

Zestawione raporty DMARC (raporty RUA) zawierają wyniki uwierzytelniania DKIM dla każdej wiadomości otrzymanej przez zgłaszające serwery pocztowe. Każdy wynik zawiera użyty selektor, domenę podpisującą oraz status pozytywny/negatywny.

Jeśli Twoja organizacja korzysta z wielu dostawców usług e-mailowych (ESP) lub jeśli w Twoim imieniu logują się usługi stron trzecich, raporty DMARC ujawnią selektory, których nie udałoby się wykryć wyłącznie poprzez analizę nagłówków. Jest to szczególnie przydatne w wykrywaniu nieoficjalnych usług pocztowych, które zostały kiedyś autoryzowane, ale nigdy nie zostały wycofane z użytku.

Analizator DMARC firmy PowerDMARC analizator DMARC automatycznie analizuje te zbiorcze raporty i wyświetla wszystkie aktywne selektory DKIM dla każdej domeny na jednym pulpicie nawigacyjnym, eliminując konieczność ręcznego wyodrębniania i porównywania danych XML z wielu źródeł raportowania.

Note: There is no DNS wildcard or enumeration method to discover all selectors under `_domainkey.{domain}`. DNS does not support listing all subrecords of a zone from the outside. You cannot brute-force all possible selectors. The four methods above are the practical options.

5. Domyślne selektory DKIM w ESP: Tabela odniesień 2026 

Jednym z najczęstszych zadań związanych z zarządzaniem DKIM jest ustalenie, który selektor należy do danej usługi pocztowej. W poniższej tabeli przedstawiono domyślne selektory DKIM stosowane przez 14 największych dostawców usług e-mailowych na początku 2026 roku.

Ważne: Dostawcy usług e-mailowych mogą w dowolnym momencie zmienić domyślne selektory, a niektóre platformy przypisują selektory specyficzne dla konta lub losowe. Zawsze należy zweryfikować selektor wyświetlany w konsoli administracyjnej własnego dostawcy usług e-mailowych, porównując go z niniejszą tabelą.

Jeśli Twoja domena wysyła wiadomości e-mail za pośrednictwem trzech lub czterech z tych platform jednocześnie, w Twoim systemie DNS będą znajdowały się trzy lub cztery aktywne selektory DKIM, a każdy z nich wymaga osobnego monitorowania, weryfikacji i rotacji. 

Zarządzanie wieloma selektorami DKIM w różnych dostawcach usług e-mailowych staje się trudne w przypadku dużych skal, zwłaszcza gdy każda platforma ma inne harmonogramy rotacji, formaty selektorów i wymagania dotyczące DNS. 

Usługa PowerDMARC Hosted DKIM pomaga scentralizować zarządzanie selektorami za pomocą jednego pulpitu nawigacyjnego, ułatwiając dodawanie, rotację, weryfikację i monitorowanie selektorów DKIM bez konieczności wielokrotnego ręcznego modyfikowania rekordów DNS.

Rozpocznij bezpłatny okres próbny

Zasady nazewnictwa i najlepsze praktyki

Selektory DKIM mogą nosić niemal dowolne nazwy, o ile są zgodne z regułami składniowymi. Bez spójnej konwencji nazewniczej zarządzanie selektorami szybko staje się uciążliwe w miarę dodawania nowych usług i rotacji kluczy.

Zalecane wzorce nazewnictwa

Systematyczne podejście do nazewnictwa znacznie ułatwia określenie odpowiedzialności, śledzenie zmian, rozwiązywanie problemów związanych z awariami oraz zapobieganie późniejszym niejasnościom operacyjnym. 

Wzór 1: ESP + data

Przykłady:

• google-2026q1
• sendgrid-202601
• hubspot-IV kwartał 2025 r.

Jest to wzorzec najbardziej przydatny w praktyce. Już na pierwszy rzut oka można sprawdzić, która usługa jest właścicielem klucza oraz kiedy ostatnio został on zmieniony. Podczas audytu można od razu zaznaczyć każdy selektor, którego data jest starsza niż 12 miesięcy.

Schemat 2: Funkcja obsługi + sekwencja

Przykłady:

• marketing-01
• transakcyjny-01
• korporacyjne-01

Przydatne, gdy ta sama domena jest obsługiwana przez wielu dostawców usług pocztowych (ESP) i chcesz uporządkować selektory według strumienia poczty, a nie według dostawcy.

Wzorzec 3: Ustawienia domyślne ESP (bez niestandardowych nazw)

Wiele dostawców usług ESP nie pozwala na nadawanie własnych nazw selektorom. Google Workspace zawsze używa nazwy `google`. Microsoft 365 stosuje nazwy `selector1` i `selector2`. W takich przypadkach należy korzystać z tego, co oferuje platforma, a mapowanie śledzić zewnętrznie.

Praktyki związane z nazewnictwem, których należy unikać

Niewłaściwie skonstruowane lub zbyt ogólne nazwy mogą powodować niejasności podczas audytów, rozwiązywania problemów i rotacji kluczy, zwłaszcza w środowiskach z wieloma dostawcami usług poczty elektronicznej (ESP) i dużą liczbą aktywnych selektorów. Należy unikać następujących praktyk związanych z nazewnictwem: 

• Nazwy ogólne bez kontekstu: `key1`, `test`, `dkim` nie dostarczają żadnych informacji o ESP ani stanie rotacji.
• Selektory zawierające poufne informacje: Nie umieszczaj w nazwach selektorów szczegółów dotyczących wewnętrznej infrastruktury, nazw hostów serwerów ani identyfikatorów pracowników. Nazwy selektorów są publicznie widoczne za pośrednictwem DNS.
• Zbyt długie selektory: Chociaż technicznie dozwolone jest użycie selektorów o długości do 63 znaków, selektory dłuższe niż 30 znaków niepotrzebnie komplikują rekordy DNS i polecenia wyszukiwania.

Konfiguracja obejmująca jedną domenę i jednego dostawcę usług poczty elektronicznej (ESP) jest prosta. Wystarczy wygenerować parę kluczy, opublikować klucz publiczny pod selektorem dostawcy ESP i gotowe. Wyzwania operacyjne pojawiają się, gdy ta sama domena wysyła wiadomości e-mail za pośrednictwem wielu platform.

Praktyczne ramy zarządzania

Poniższy pięcioetapowy cykl życia stanowi ustrukturyzowane podejście do zarządzania selektorami:

Etap 1: Inwentaryzacja

Zarejestruj wszystkie aktywne selektor DKIM dla każdej domeny, którą zarządzasz, uwzględniając dostawcę usług e-mailowych (ESP), długość klucza, datę opublikowania oraz osobę lub zespół odpowiedzialny. Raporty zbiorcze DMARC to najszybszy sposób na stworzenie tego spisu, ponieważ ujawniają one każdy selektor obecnie podpisujący pocztę dla Twojej domeny, w tym te, których nikt nie pamięta, że zostały skonfigurowane.

Etap 2: Weryfikacja

Dla każdego selektora w Twoim zasobie sprawdź w systemie DNS, czy klucz publiczny został opublikowany i ma prawidłowy format. Wyślij wiadomość testową za pośrednictwem każdego dostawcy usług e-mailowych i upewnij się, że weryfikacja DKIM przebiega pomyślnie. Sprawdź długości kluczy i zaznacz wszystkie selektory korzystające z klucza 1024-bitowego.

Etap 3: Ujednolicenie

Wprowadź konwencję nazewniczą i stosuj ją do wszystkich selektorów, za które odpowiadasz. W przypadku systemów ESP wykorzystujących stałe nazwy selektorów należy jasno udokumentować ich przyporządkowanie. Ustal harmonogram rotacji i wyznacz osoby odpowiedzialne.

Etap 4: Monitorowanie.

Wykorzystaj zbiorcze raporty DMARC do ciągłego monitorowania wskaźników powodzenia i niepowodzenia weryfikacji DKIM dla poszczególnych selektorów. Nagły wzrost wskaźnika niepowodzeń dla konkretnego selektora zazwyczaj wskazuje na zmianę w systemie DNS, wygaśnięcie klucza lub zmianę konfiguracji u dostawcy usług e-mailowych (ESP).

Etap 5: Wycofanie z eksploatacji

Po zaprzestaniu korzystania z usługi ESP należy unieważnić jej klucz DKIM poprzez opublikowanie pustej wartości `p=` w rekordzie DNS selektora. Nie należy po prostu usuwać rekordu DNS. Pusta wartość `p=` jednoznacznie informuje serwery odbiorcze, że klucz został unieważniony. Całkowite usunięcie rekordu powoduje niepowodzenie wyszukiwania w DNS, co jest niejednoznaczne i może być różnie interpretowane przez poszczególnych odbiorców.

PowerDMARC oferuje scentralizowany pulpit nawigacyjny, który mapuje wszystkie aktywne selektory DKIM we wszystkich domenach na koncie, pobierając dane jednocześnie z raportów zbiorczych DMARC i monitoringu DNS. Dla dostawców usług zarządzanych (MSP) obsługujących duże portfele klientów rozwiązuje to problem śledzenia opartego na arkuszach kalkulacyjnych, które staje się niemożliwe do opanowania przy kilkudziesięciu domenach.

Rotacja kluczy DKIM i strategia wyboru kluczy

Rotacja kluczy DKIM polega na wygenerowaniu nowej pary kluczy i opublikowaniu nowego klucza publicznego pod nowym (lub zaktualizowanym) selektorem, a następnie skonfigurowaniu usługi wysyłającej tak, aby podpisywała wiadomości nowym kluczem prywatnym.

Klucz prywatny DKIM, który pozostaje niezmieniony przez lata, stanowi coraz większe zagrożenie. Jeśli klucz zostanie ujawniony w wyniku włamania do serwera, ataku wewnętrznego lub luki w zabezpieczeniach systemu przechowywania kluczy, osoba atakująca może podpisywać wiadomości e-mail, które przejdą uwierzytelnianie DKIM w imieniu Twojej domeny. Regularna rotacja kluczy ogranicza czas trwania narażenia.

Jak zmienić klucze DKIM bez przestojów

Standardowy proces rotacji wykorzystuje kolejno dwa selektory:

1. Wygeneruj nową parę kluczy: Utwórz nową parę kluczy RSA (lub Ed25519) o długości 2048 bitów.
2. Opublikuj nowy klucz publiczny pod nowym selektorem: Na przykład, jeśli aktualny selektor to `google-2025q3`, opublikuj nowy klucz pod `google-2026q1`.
3. Poczekaj na propagację DNS: Poczekaj od 24 do 48 godzin, aż nowy rekord TXT zostanie propagowany na całym świecie. W przypadku usługi Microsoft 365 pełna propagacja może potrwać do 96 godzin.
4. Zaktualizuj konfigurację podpisywania: Skonfiguruj ESP lub serwer pocztowy tak, aby podpisywał wychodzące wiadomości przy użyciu nowego klucza prywatnego i nowego selektora.
5. Sprawdź: Wyślij wiadomości testowe i sprawdź, czy DKIM działa poprawnie z nowym selektorem.
6. Unieważnij stary klucz: Po upływie okresu przejściowego (zwykle od 7 do 14 dni, aby umożliwić dostarczenie wiadomości w trakcie przesyłania, podpisanych starym kluczem), opublikuj pustą wartość `p=` dla starego selektora.

Rotacja kluczy DKIM w środowiskach z wieloma dostawcami usług e-mailowych

Każdy moduł ESP posiada własny mechanizm obrotowy:

• Microsoft 365: zapewnia wbudowaną rotację selektorów pomiędzy `selector1` a `selector2`. Rotację można uruchomić za pośrednictwem portalu Defender.
• SendGrid: automatycznie przełącza się między `s1` a `s2`.
• Google Workspace: wymaga ręcznego wygenerowania klucza za pośrednictwem Konsoli administracyjnej.
• Większość platform marketingowych: wymagają ręcznej rotacji w ustawieniach uwierzytelniania domeny.

Rotacja wszystkich selektorów w tym samym dniu powoduje powstanie okresu podwyższonego ryzyka i utrudnia rozwiązywanie problemów w razie awarii. Należy rozłożyć rotacje na różne tygodnie lub miesiące.

Hostowana funkcja DKIM firmy PowerDMARC obsługuje generowanie kluczy, publikację w DNS oraz rotację selektorów dla wszystkich domen na Twoim koncie, z konfigurowalnymi harmonogramami rotacji dla poszczególnych domen i dostawców usług e-mailowych.

Rozpocznij bezpłatny okres próbny

Typowe błędy związane z selektorami DKIM i sposoby ich naprawiania 

Gdy weryfikacja DKIM kończy się niepowodzeniem, przyczyną jest prawie zawsze jeden z kilku błędów związanych z selektorami lub konfiguracją DNS. W poniższej tabeli przedstawiono najczęstsze awarie, ich objawy oraz sposoby ich usuwania.

Problem obcinania w algorytmie 2048-bitowym – szczegółowe omówienie

Gdy organizacje przechodzą z kluczy DKIM 1024-bitowych na 2048-bitowe (biorąc pod uwagę, że 1024-bitowy algorytm RSA jest uznawany za zbyt słaby do celów DKIM), długość klucza publicznego zakodowanego w formacie Base64 wzrasta mniej więcej dwukrotnie. Powstały ciąg znaków zazwyczaj przekracza 400 znaków.

W rekordach DNS typu TXT długość pojedynczego ciągu znaków w ramach danego rekordu jest ograniczona do 255 znaków. Rozwiązaniem, określonym w dokumencie RFC 6376, jest podzielenie wartości na kilka ciągów znaków w ramach jednego rekordu TXT. Serwery pocztowe odbierające wiadomości automatycznie łączą te ciągi.

Większość popularnych interfejsów do zarządzania DNS nie radzi sobie z tym zbyt sprawnie:

• Niektóre interfejsy bez ostrzeżenia skracają wartość do 255 znaków.
• Niektóre interfejsy całkowicie odrzucają wpis, wyświetlając niejasny komunikat o błędzie.
• W niektórych interfejsach administrator musi ręcznie podzielić ciąg znaków i ująć każdy fragment w cudzysłowy.

Jeśli opublikujesz klucz 2048-bitowy, a weryfikacja DKIM natychmiast zacznie kończyć się niepowodzeniem, sprawdź rzeczywistą odpowiedź DNS za pomocą polecenia `dig` lub `nslookup`. Porównaj zwróconą wartość `p=` z pełnym kluczem publicznym z Twojej pary kluczy. Jeśli zwrócona wartość jest krótsza, oznacza to, że Twój dostawca usług DNS ją skrócił.

Aby tego uniknąć: 

• Warto skorzystać z usług dostawcy DNS, który natywnie obsługuje długie rekordy TXT (Cloudflare, AWS Route 53 oraz większość korporacyjnych platform DNS radzą sobie z tym bez problemów).
• Należy stosować DKIM oparty na rekordach CNAME, w którym ścieżka DNS selektora wskazuje na rekord CNAME hostowany przez dostawcę usług e-mailowych (ESP). Dostawca usług e-mailowych zarządza rekordem TXT w swojej infrastrukturze, co pozwala całkowicie uniknąć tego problemu.
• Jeśli musisz korzystać z dostawcy, który wymaga ręcznego dzielenia, podziel klucz na ciągi znaków o długości nieprzekraczającej 250 znaków, z których każdy należy ująć w cudzysłowy, w ramach jednego rekordu TXT.

Selektory DKIM i zgodność z DMARC 

DKIM i DMARC to odrębne protokoły, ale ich wzajemne oddziaływanie często zaskakuje administratorów. Może się zdarzyć, że DKIM przejdzie pomyślnie, podczas gdy DMARC nadal zakończy się niepowodzeniem. Gdy tak się dzieje, przyczyną jest prawie zawsze niezgodność domen, związana z tym, jak domena podpisująca selektora odnosi się do domeny w nagłówku `From:`.

Jak działa synchronizacja DMARC z DKIM

Protokół DMARC wymaga, aby co najmniej jeden mechanizm uwierzytelniania (SPF lub DKIM) przeszedł pomyślnie test i był zgodny z domeną podaną w nagłówku `From:`.

Dla dopasowania DKIM , domena `d=` w nagłówku DKIM-Signature musi odpowiadać domenie w nagłówku `From:`. Sam selektor nie jest brany pod uwagę przy sprawdzaniu zgodności. Zgodność opiera się wyłącznie na domenie `d=`.

DMARC obsługuje dwa tryby synchronizacji:

Dwa scenariusze, w których DKIM przechodzi pomyślnie, ale DMARC kończy się niepowodzeniem

Jednym z najbardziej mylących wyników uwierzytelniania wiadomości e-mail jest sytuacja, w której DKIM przechodzi pomyślnie, a DMARC nadal kończy się niepowodzeniem. Zazwyczaj dzieje się tak, gdy sam podpis jest prawidłowy, ale domena podpisująca nie pokrywa się z widoczną domeną w polu „Od:”, używaną w wiadomości.

Scenariusz 1: Zewnętrzny dostawca usług e-mailowych (ESP) korzysta z własnej domeny

Niektóre dostawcy usług poczty elektronicznej (ESP), jeśli dla danej domeny nie skonfigurowano wyraźnie protokołu DKIM, podpisują wychodzące wiadomości, używając w polu `d=` własnej domeny. Na przykład wiadomość e-mail wysłana w imieniu adresu `[email protected]` może zawierać podpis DKIM z wartością `d=esp-provider.com`.

Weryfikacja DKIM przebiegła pomyślnie (podpis jest prawidłowy), ale weryfikacja DMARC zakończyła się niepowodzeniem, ponieważ adres `esp-provider.com` nie jest zgodny z adresem `example.com`.

Skonfiguruj podpisywanie DKIM w platformie ESP tak, aby w tagu `d=` wykorzystywano Twoją własną domenę. Zazwyczaj wymaga to dodania selektora DKIM platformy ESP jako rekordu DNS w Twojej domenie oraz włączenia opcji niestandardowego podpisywania DKIM w ustawieniach platformy ESP.

Scenariusz 2: Podpisywanie subdomen z ścisłym dostosowaniem do DMARC

Jeśli w polityce DMARC zastosowano ścisłe dopasowanie (`adkim=s`), a dostawca usług e-mailowych (ESP) podpisuje wiadomości przy użyciu `d=sub.example.com`, podczas gdy w polu `From:` widnieje adres `example.com`, test DMARC zakończy się niepowodzeniem, mimo że test DKIM zakończy się powodzeniem.

Należy albo przełączyć się na tryb luźnego dopasowania (`adkim=r`, co jest ustawieniem domyślnym), albo upewnić się, że domena `d=` w podpisie DKIM dokładnie odpowiada domenie `From:`.

Sprawdzanie spójności między różnymi dostawcami usług językowych

W środowiskach obsługujących wiele dostawców usług e-mail (ESP) każda platforma wysyłająca może podpisywać wiadomości przy użyciu różnych domen `d=`. Jeden dostawca może podpisywać wiadomości przy użyciu Twojej domeny głównej, inny – przy użyciu subdomeny, a trzeci może domyślnie korzystać z własnej domeny, dopóki nie skonfigurujesz niestandardowego podpisu.

Zestawione raporty DMARC zawierają domenę `d=` oraz wynik weryfikacji zgodności dla każdej wiadomości podpisanej za pomocą DKIM. Przejrzyj te raporty, aby zidentyfikować dostawców usług e-mailowych (ESP), którzy podpisują wiadomości przy użyciu niezgodnej domeny. Raporty DMARC serwisu PowerDMARC wskazują przypadki niezgodności w podziale na źródła wysyłki, co ułatwia określenie, które z dostawców usług e-mailowych wymagają ponownej konfiguracji.

Wniosek

Organizacje, które traktują zarządzanie selektorami jako stały element działalności operacyjnej, a nie jednorazowe zadanie konfiguracyjne, są tymi, które zapewniają stałą skuteczność dostarczania wiadomości, bezproblemowo przechodzą audyty i szybko reagują na incydenty.

Jeśli zarządzasz kilkoma domenami lub współpracujesz z wieloma dostawcami usług e-mailowych, warto zainwestować w scentralizowane zarządzanie widocznością selektorów DKIM.

PowerDMARC zapewnia taki scentralizowany wgląd, łącząc analizę zbiorczych raportów DMARC, monitorowanie DNS oraz zarządzanie hostowanym DKIM w jednym interfejsie zaprojektowanym właśnie z myślą o tego rodzaju złożoności operacyjnej.

Z łatwością zarządzaj selektorami DKIM w wielu dostawcach usług e-mailowych. Zarejestruj się na okres próbny , aby monitorować rekordy DKIM, poprawić zgodność z DMARC i chronić dostarczalność wiadomości e-mail.

Najczęściej zadawane pytania

Jak sprawdzić swój selektor DKIM?

Selektor DKIM można znaleźć, przeglądając pełne nagłówki wiadomości e-mail i lokalizując element DKIM-Signature . Wartość po s= jest selektorem. Na przykład w s=googleselektorem jest google.

Ile selektorów DKIM może mieć domena?

Nie ma żadnych ograniczeń technicznych dotyczących liczby selektorów DKIM, jakie może posiadać dana domena. Organizacje często stosują jednocześnie wiele selektorów dla różnych dostawców poczty elektronicznej, działów lub okresów rotacji kluczy.

Czy wiele dostawców usług e-mailowych może używać różnych selektorów DKIM w tej samej domenie?

Tak. Każdy dostawca usług poczty elektronicznej zazwyczaj korzysta z własnego selektora DKIM. Na przykład Google Workspace, SendGrid i Mailchimp mogą mieć oddzielne selektory w ramach tej samej domeny bez żadnych konfliktów.

Jaka jest różnica między selektorem DKIM a kluczem DKIM?

Selektor to etykieta służąca do lokalizowania rekordu DKIM w systemie DNS, natomiast klucz DKIM to rzeczywista para kluczy kryptograficznych (publiczny i prywatny) wykorzystywana do podpisywania i weryfikacji wiadomości e-mail.

Dlaczego DKIM przechodzi pomyślnie, a DMARC nadal kończy się niepowodzeniem?

Zazwyczaj wynika to z niepowodzenia w dopasowaniu DMARC. Podpis DKIM może zostać pomyślnie zweryfikowany, ale d= w podpisie DKIM nie jest zgodna z polem From: użytej w wiadomości e-mail.

Jak często należy zmieniać selektory i klucze DKIM?

Zgodnie z najlepszymi praktykami w zakresie bezpieczeństwa zaleca się wymianę kluczy DKIM co 6–12 miesięcy. Podczas wymiany zarówno stare, jak i nowe selektory powinny pozostać tymczasowo aktywne, aby uniknąć błędów weryfikacji w trakcie propagacji DNS.