Klucz DKIM jest zawsze publikowany jako rekord TXT. Gdy dostawca prosi Cię o dodanie rekordu CNAME przy selektorze, ten CNAME nie jest kluczem. To wskaźnik, który deleguje wyszukiwanie do rekordu utrzymywanego przez Twojego dostawcę poczty, więc właściwy rekord TXT nadal znajduje się na końcu łańcucha, na jego serwerach DNS. Użyj rekordu TXT, gdy chcesz samodzielnie posiadać klucz i nim zarządzać. Użyj CNAME, gdy chcesz, aby dostawca rotował klucze za Ciebie bez konieczności ponownego dotykania DNS.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Oba podejścia kończą się w tym samym miejscu: resolver podążający za selector._domainkey.yourdomain.com musi dotrzeć do rekordu TXT, który zawiera klucz publiczny DKIM. Jedyne pytanie brzmi: kto przechowuje ten rekord TXT i kto może go zmieniać.
Jeden fakt, który rozwiewa nieporozumienia
Weryfikacja DKIM, zdefiniowana w RFC 6376, polega na tym, że odbierający serwer pocztowy pobiera klucz publiczny z DNS. Ten klucz jest publikowany w rekordzie TXT pod bardzo konkretną nazwą: selektor, po nim dosłowna etykieta _domainkey, a następnie Twoja domena. Zatem dla selektora o nazwie s1 w domenie example.com nazwa rekordu to s1._domainkey.example.com.
Wartość w tym rekordzie TXT wygląda tak:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
Tag p= zawiera klucz publiczny zakodowany w base64. To właśnie tego potrzebuje odbiorca. Nigdy nie znajduje się on w rekordzie CNAME. CNAME w ogóle nie może przenosić wartości p=, ponieważ jedynym zadaniem CNAME jest powiedzieć: "ta nazwa jest aliasem dla tamtej nazwy, zajrzyj tam zamiast tutaj".
Gdy więc dostawca podaje Ci CNAME do dodania, mówi w istocie: skieruj swój selektor na naszą nazwę hosta, a my opublikujemy i będziemy utrzymywać rekord TXT po naszej stronie. Resolver odbiorcy podąża za Twoim CNAME, trafia na rekord dostawcy i odczytuje stamtąd klucz. Z punktu widzenia odbierającego serwera wynik jest identyczny. Różnica dotyczy wyłącznie kontroli i utrzymania.
TXT: klucz należy do Ciebie
Przy zwykłym rekordzie TXT wklejasz pełny klucz publiczny DKIM do własnej strefy DNS. Sam go wygenerowałeś (lub dostawca przekazał Ci gotową wartość) i teraz znajduje się on w rekordzie, który kontrolujesz.
To właściwy wybór, gdy:
- Prowadzisz własny serwer pocztowy lub MTA i generujesz własną parę kluczy.
- Dostawca daje Ci wartość TXT do wklejenia zamiast celu CNAME.
- Chcesz, aby klucz był widoczny i możliwy do audytu we własnym pliku strefy, bez zależności od DNS strony trzeciej w kwestii zawartości klucza.
- Zarządzasz ręcznie wieloma selektorami w jednej domenie i chcesz, aby każdy był jawnie określony.
Kosztem jest to, że odpowiadasz też za rotację. Gdy przychodzi czas na wymianę klucza, generujesz nową parę, publikujesz rekord TXT nowego selektora, przełączasz podpisywanie na nowy selektor, a później wycofujesz stary. Nic się nie rotuje, jeśli tego nie zrobisz. Jeśli wybierasz tę drogę, trzymaj się realnego harmonogramu, który omawiamy w rotacji kluczy DKIM.
CNAME: rotacją zarządza Twój dostawca
Przy delegacji CNAME dodajesz rekordy takie jak ten:
s1._domainkey.example.com. CNAME s1.dkim.provider.net.
Nigdy nie widzisz klucza. Dostawca publikuje właściwy rekord TXT pod s1.dkim.provider.net i utrzymuje go w aktualnym stanie. Gdy rotuje klucze, zmienia rekord TXT po swojej stronie, a Twój CNAME nadal wskazuje na ten sam alias, więc nowy klucz zostaje podchwycony bez żadnego działania z Twojej strony.
To właściwy wybór, gdy:
- Twój dostawca usług pocztowych (większość dużych nadawców, takich jak SendGrid, Amazon SES, Mailchimp, Klaviyo i podobni) podaje Ci cele CNAME podczas konfiguracji.
- Chcesz automatycznej rotacji kluczy bez zmiany w DNS za każdym razem.
- Wolisz nie przechowywać ani nie zarządzać materiałem klucza samodzielnie.
Większość zarządzanych dostawców domyślnie stosuje delegację CNAME właśnie dlatego, że pozwala im to rotować klucze według własnego harmonogramu, aby utrzymać podpisy w dobrej kondycji. Jeśli podążasz za instrukcją dostawcy, taką jak uwierzytelnianie domeny w SendGrid, wiersze CNAME, które masz dodać, to dokładnie ten wzorzec delegacji.
Zestawienie: co jest właściwe dla Ciebie
| Czynnik | Rekord TXT | Delegacja CNAME |
|---|---|---|
| Co publikujesz | Pełny klucz publiczny (p=...) | Alias do nazwy hosta dostawcy |
| Kto rotuje klucz | Ty, ręcznie | Twój dostawca, automatycznie |
| Gdzie znajduje się klucz | Twoja strefa DNS | Strefa DNS dostawcy |
| Najlepszy do | Poczty własnej, kluczy niestandardowych, pełnej kontroli audytu | Zarządzanych ESP, bezobsługowego utrzymania |
| Główne ryzyko | Zapomnienie o rotacji | Błędna konfiguracja dostawcy lub przerwany łańcuch |
| Zmiana przy wymianie klucza | Samodzielne dodanie nowego selektora TXT | Brak, dostawca to obsługuje |
Żadne z rozwiązań nie jest bezpieczniejsze pod względem kryptograficznym. Ten sam klucz RSA lub Ed25519 chroni pocztę w obu przypadkach. Kompromis dotyczy kontroli kontra wygody.
Pułapki rozwiązywania zagnieżdżonych rekordów CNAME
Najczęstsze awarie przy delegacji to problemy z łańcuchem, a nie z kluczem.
CNAME nie może istnieć obok innych rekordów
Dokładnie pod nazwą selector._domainkey.example.com możesz mieć CNAME albo TXT, nigdy oba naraz. Reguły DNS zabraniają współistnienia CNAME z jakimkolwiek innym typem rekordu pod tą samą nazwą. Jeśli dodasz CNAME dla delegacji i jednocześnie wkleisz klucz TXT przy tym samym selektorze, resolvery uznają strefę za uszkodzoną. Wybierz jedno na selektor.
Łańcuchy muszą faktycznie kończyć się rekordem TXT
Dostawcy czasami kierują swoją pierwszą nazwę hosta na drugą, więc resolver przechodzi z CNAME na CNAME, zanim dotrze do końcowego rekordu TXT. To jest dozwolone. Problem pojawia się, gdy któreś ogniwo pośrednie jest zepsute, wygasłe lub wskazuje na host, który nie publikuje już klucza. Każdy przeskok musi się rozwiązać, a ostatni musi być rekordem TXT z prawidłową wartością p=. Jeśli któreś ogniwo zwróci NXDOMAIN, cały łańcuch zawodzi, a DKIM jest traktowany tak, jakby klucza w ogóle nie było.
Uważaj na kropki końcowe i doklejane domeny
Gdy Twój panel DNS pyta o cel CNAME, niektóre panele automatycznie doklejają Twoją domenę. Jeśli celem ma być s1.dkim.provider.net, a panel po cichu robi z tego s1.dkim.provider.net.example.com, alias wskazuje w próżnię. Wpisz w pełni kwalifikowany cel dokładnie tak, jak podaje go dostawca, i potwierdź ostateczną zapisaną wartość.
Spłaszczanie CNAME w apeksie jest tu bez znaczenia
Selektory DKIM nigdy nie znajdują się w apeksie strefy, więc spłaszczanie, które niektórzy dostawcy DNS stosują wobec rekordów głównych, nie dotyczy nazw _domainkey. Nie potrzebujesz go i nie powinieneś włączać niczego, co przepisuje te rekordy.
Sprawdź, co faktycznie rozwiązuje się pod Twoim selektorem
Nie ufaj samemu panelowi dostawcy. Zweryfikuj to, co widzi odbiorca. Z terminala możesz prześledzić łańcuch:
dig +short s1._domainkey.example.com CNAME
dig +short s1._domainkey.example.com TXT
Pierwsze polecenie pokazuje, czy CNAME istnieje i na co wskazuje. Drugie podąża za łańcuchem i wypisuje końcową wartość TXT, która powinna zaczynać się od v=DKIM1 i zawierać klucz p=. Jeśli zapytanie o CNAME zwraca nazwę hosta, ale zapytanie o TXT nie zwraca nic, Twoja delegacja wskazuje na martwy cel i u odbiorców DKIM będzie zawodzić.
Uruchomienie naszego skanera wykonuje ten sam przebieg za Ciebie i ocenia wynik, dzięki czemu na pierwszy rzut oka widzisz, czy klucz, który się rozwiązuje, jest prawidłowy - a to szybsze niż czytanie surowego wyjścia dig. Jeśli klucz się rozwiązuje, ale poczta nadal nie przechodzi DKIM, problemem jest zwykle podpisywanie lub wyrównanie, a nie typ rekordu, co rozkładamy na czynniki w naprawie wyrównania DKIM.
Najczęściej zadawane pytania
Czy rekord DKIM to CNAME czy TXT?
Sam klucz jest zawsze rekordem TXT. CNAME to zawsze jedynie wskaźnik, który deleguje wyszukiwanie do Twojego dostawcy, publikującego prawdziwy rekord TXT po swojej stronie. Oba warianty są prawidłowe, ale klucz publiczny nigdy nie znajduje się wewnątrz CNAME.
Czy mogę później przełączyć się z CNAME na TXT?
Tak. Usuń CNAME przy tym selektorze, a następnie dodaj rekord TXT pod tą samą nazwą z pełną wartością v=DKIM1; k=rsa; p=.... Nie możesz zachować obu przy tym samym selektorze, więc usuń jeden przed dodaniem drugiego i poczekaj na propagację DNS, zanim zaczniesz na nim polegać.
Dlaczego mój dostawca daje mi tylko CNAME?
Ponieważ pozwala mu to rotować klucze za Ciebie bez ponownej edycji DNS. Zarządzani nadawcy wolą delegację, aby wymiana klucza po ich stronie była dla Ciebie niewidoczna, a Twoje podpisy pozostawały prawidłowe. To wygoda utrzymania, a nie wymóg bezpieczeństwa.
Skąd mam wiedzieć, który jest faktycznie aktywny?
Odpytaj selektor bezpośrednio. dig s1._domainkey.example.com CNAME pokazuje ewentualny alias, a dig s1._domainkey.example.com TXT pokazuje końcowy klucz, do którego rozwiązuje się łańcuch. Jeśli zapytanie o TXT zwraca wartość zaczynającą się od v=DKIM1, to jest klucz, którego użyją odbiorcy.