W przeciwieństwie do SPF, który dopuszcza tylko jeden rekord TXT na domenę, DKIM został stworzony tak, aby pomieścić tyle kluczy, ilu masz nadawców. Każda usługa, przez którą wysyłasz pocztę, publikuje własny klucz publiczny pod własnym selektorem, czyli krótką etykietą znajdującą się w dedykowanej subdomenie _domainkey.twojadomena.com. Oznacza to, że Google Workspace, SendGrid, Mailchimp i dowolny dostawca poczty transakcyjnej mogą jednocześnie podpisywać Twoją pocztę własnym kluczem, bez żadnego konfliktu, o ile żadne dwie z tych usług nie używają tej samej nazwy selektora.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Jeśli kiedykolwiek obawiałeś się, że dodanie drugiego dostawcy poczty "zepsuje" pierwszego tak, jak drugi wpis include potrafi zepsuć SPF, to DKIM całkowicie eliminuje ten problem. Celem projektowym selektorów jest właśnie to: wiele niezależnych kluczy, jedna domena, weryfikowanych osobno przez każdego odbiorcę.
Dlaczego DKIM dopuszcza wiele rekordów, a SPF tylko jeden
SPF jest publikowany jako pojedynczy rekord TXT w korzeniu domeny, a RFC 7208 mówi, że domena nie może mieć więcej niż jednego rekordu SPF. To ograniczenie do jednego rekordu sprawia, że SPF z wieloma dostawcami staje się uciążliwy i że limit 10 zapytań DNS tak szybko daje o sobie znać. Każdego nadawcę trzeba spłaszczyć do jednej linii.
DKIM działa odwrotnie. Klucz DKIM nie jest publikowany w korzeniu. Znajduje się on pod adresem selektor._domainkey.twojadomena.com, a selektor jest wybierany przez usługę podpisującą. Ponieważ każdy dostawca używa innej subdomeny, ich rekordy nigdy się nie zderzają. Odbiorca nie zgaduje, którego klucza użyć. Podpis w nagłówku wiadomości niesie ze sobą znacznik d= (domena) oraz znacznik s= (selektor), a odbiorca odpytuje dokładnie ten jeden rekord.
Oto podstawowa idea, którą warto sobie przyswoić: to wiadomość mówi odbiorcy, który klucz pobrać. Dziesięć różnych usług może w ciągu miesiąca podpisywać ten sam strumień wiadomości, a każda weryfikuje się względem własnego opublikowanego klucza, niezależnie. Pełne omówienie relacji między tymi trzema protokołami znajdziesz w artykule SPF, DKIM i DMARC wyjaśnione.
Jak naprawdę wygląda rekord DNS DKIM
Opublikowany klucz DKIM to rekord TXT (a czasem CNAME). Typowy surowy rekord klucza wygląda tak:
google._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
Znacznik p= zawiera klucz publiczny. Odbiorca łączy go z podpisem wykonanym kluczem prywatnym, dołączonym do wiadomości, aby potwierdzić, że poczta nie została zmieniona i naprawdę pochodzi od autoryzowanego podmiotu podpisującego dla tej domeny.
Jedyna twarda zasada: nigdy dwa klucze pod tym samym selektorem
Istnieje dokładnie jeden sposób na zepsucie wielu rekordów DKIM, i jest to: opublikowanie dwóch różnych kluczy publicznych pod tą samą nazwą selektora. DNS bez oporu zwróci oba ciągi TXT, odbiorca nie będzie w stanie stwierdzić, który jest wiążący, a weryfikacja stanie się zawodna. Jeden selektor odpowiada dokładnie jednemu kluczowi.
W praktyce prawie nigdy nie trafiasz na to przypadkiem, ponieważ dostawcy używają różnych nazw selektorów. Trafiasz na to, gdy rotujesz klucz i wklejasz nową wartość do istniejącego rekordu zamiast użyć świeżego selektora, albo gdy dwa wewnętrzne zespoły wybierają jako selektor default. Utrzymuj selektory unikalne dla każdego klucza i każdej usługi, a problem znika.
Konwencje selektorów według dostawcy
Większość usług albo podaje Ci dokładny selektor do opublikowania, albo daje rekordy CNAME wskazujące z powrotem na ich infrastrukturę. Oto, czego używają najczęściej spotykani nadawcy.
Google Workspace
Google używa selektora, który wybierasz podczas konfiguracji, a domyślnie sugeruje google. Twój rekord znajduje się więc pod adresem google._domainkey.twojadomena.com. Google publikuje wartość klucza, którą wklejasz jako rekord TXT w konsoli administracyjnej w sekcji Aplikacje, Google Workspace, Gmail, Uwierzytelnij pocztę. Możesz wybrać inną nazwę selektora, jeśli prowadzisz więcej niż jeden strumień podpisywany przez Google, ale google jest standardem.
SendGrid
SendGrid używa dwóch rotujących selektorów CNAME, zazwyczaj s1._domainkey i s2._domainkey, które wskazują na klucze hostowane przez SendGrid (na przykład s1.domainkey.uXXXXXX.wlYYY.sendgrid.net). Ponieważ są to rekordy CNAME, SendGrid kontroluje klucz bazowy i może go rotować bez ponownego dotykania Twojego DNS. Publikujesz oba.
Mailchimp
Mailchimp używa selektora k1 (publikowanego jako k1._domainkey.twojadomena.com jako CNAME do dkim.mcsv.net). Niektóre starsze konfiguracje odwołują się do k2 i k3 jako slotów rotacji. Mailchimp podaje dokładny cel rekordu CNAME na ekranie uwierzytelniania domeny.
Microsoft 365
Microsoft 365 publikuje dwa selektory CNAME, selector1._domainkey i selector2._domainkey, wskazujące na selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com oraz odpowiednik dla selector2. Konstrukcja z dwoma selektorami istnieje właśnie po to, aby Microsoft mógł między nimi rotować. Jeśli wysyłasz przez 365, przeczytaj również DMARC dla Microsoft 365.
Amazon SES
SES używa trzech rekordów CNAME o długich, opartych na tokenach nazwach selektorów, które generuje dla Ciebie (Easy DKIM), a każdy z nich wskazuje na dkim.amazonses.com. Nie wybierasz tych nazw, kopiujesz je dokładnie.
Postmark, Mailgun i inne
Postmark często używa selektora w rodzaju 20YYMMDD (selektor ze znacznikiem daty) lub pm._domainkey. Mailgun używa selektorów takich jak mx._domainkey albo wariantu k1 dla każdej domeny wysyłkowej. Gdy dostawca podaje Ci konkretny host i cel, traktuj te ciągi dosłownie. Nie normalizuj ich ani nie "porządkuj".
Praktyczny wniosek: skończysz z kilkoma rekordami _domainkey obok siebie, jedną rodziną na dostawcę, i dokładnie tak to powinno wyglądać.
Rotacja kluczy dla poszczególnych usług bez przestojów
Rotacja to moment, w którym wiele selektorów pokazuje swoją wartość. Ponieważ każda usługa ma własny selektor, możesz rotować klucz jednego dostawcy bez dotykania żadnego innego strumienia. Bezpieczny wzorzec to opublikowanie nowego selektora, pozwolenie dostawcy zacząć nim podpisywać, potwierdzenie, że poczta się weryfikuje, a następnie wycofanie starego selektora, gdy żadna wiadomość w drodze już się do niego nie odwołuje.
Dlatego właśnie dostawcy tacy jak SendGrid, Microsoft 365 i SES dostarczają dwa lub trzy selektory od pierwszego dnia. Przygotowują kolejny klucz z wyprzedzeniem, dzięki czemu rotacja jest przełączeniem, a nie gorączkowym pośpiechem. Pełny harmonogram i uzasadnienie okresów ważności kluczy znajdziesz w artykule harmonogram rotacji kluczy DKIM.
Dostawcy oparci na CNAME jeszcze bardziej to ułatwiają. Ponieważ rekord po Twojej stronie wskazuje na host, który oni kontrolują, rotują faktyczny klucz po swojej stronie, a Twój DNS nigdy się nie zmienia. To główny powód, dla którego tak wiele usług przeszło z surowych kluczy TXT na delegowane rekordy CNAME.
Weryfikacja, że każdy strumień podpisuje poprawnie
Publikacja rekordów to połowa pracy. Druga połowa to potwierdzenie, że każdy strumień faktycznie podpisuje i że podpis jest wyrównany z Twoją domeną na potrzeby DMARC. Wyślij prawdziwą wiadomość przez każdego dostawcę i sprawdź nagłówek Authentication-Results. Chcesz zobaczyć dkim=pass z wartością d=, która pasuje do Twojej domeny, a nie do współdzielonej domeny dostawcy. Jeśli d= pokazuje domenę dostawcy zamiast Twojej, podpis przejdzie DKIM, ale nie przejdzie wyrównania DMARC, co niweczy cały sens.
Aby samodzielnie odczytać te nagłówki, skorzystaj z przewodnika po nagłówku wyników uwierzytelniania. Jeśli DKIM przechodzi, ale DMARC nadal nie, winowajcą jest prawie zawsze wyrównanie, omówione w artykule naprawianie wyrównania DKIM.
Rekord DMARC spina to wszystko w całość, mówiąc odbiorcom, co robić, gdy strumień nie jest uwierzytelniony:
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
Gdy każdy dostawca podpisuje pod własnym selektorem i jest wyrównany z Twoją domeną, możesz przełączyć DMARC na p=reject z pewnością, że legalna poczta od wszystkich z nich nadal płynie.
Najczęściej zadawane pytania
Czy mogę mieć wiele rekordów DKIM w tej samej domenie?
Tak. DKIM jest do tego zaprojektowany. Każdy rekord znajduje się pod unikalnym selektorem pod adresem selektor._domainkey.twojadomena.com, więc możesz opublikować jeden klucz na każdą usługę wysyłkową bez żadnego konfliktu. Jedyna zasada jest taka, że dwa różne klucze nigdy nie mogą dzielić tej samej nazwy selektora.
Skąd odbiorca wie, którego klucza DKIM użyć?
Nagłówek DKIM-Signature wiadomości niesie ze sobą domenę (d=) i selektor (s=), którymi została podpisana. Odbiorca buduje zapytanie DNS z tych dwóch wartości i pobiera dokładnie ten jeden klucz publiczny, więc nigdy nie ma niejednoznaczności, nawet przy kilkunastu opublikowanych selektorach.
Jakie są selektory DKIM dla Google, SendGrid i Mailchimp?
Google Workspace domyślnie używa selektora google. SendGrid używa s1 i s2 jako rekordów CNAME. Mailchimp używa k1 (z k2/k3 widywanymi w niektórych konfiguracjach) jako CNAME do dkim.mcsv.net. Zawsze kopiuj dokładny host, który pokazuje Ci dostawca, zamiast zakładać.
Czy wiele kluczy DKIM spowalnia dostarczanie poczty?
Nie. Odbiorca pobiera tylko pojedynczy klucz wskazany w podpisie, który weryfikuje, a nie wszystkie. Opublikowanie dziesięciu selektorów dodaje dziesięć rekordów DNS, ale nic nie kosztuje w chwili weryfikacji, w przeciwieństwie do SPF, gdzie każdy dodatkowy nadawca liczy się do limitu 10 zapytań.