DKIM nie działa po zmianie narzędzi poczty: przewodnik migracji CNAME i selektorów (2026)

Opublikowano 2026-07-08

Dane z 2026-06-29 · metodologia v7. Zagregowane dane ze spisu 261 milionów ocenionych domen. Zobacz jak oceniamy.

DKIM psuje się po zmianie narzędzi z dwóch mechanicznych powodów: Twój panel DNS zniekształcił cele CNAME nowego narzędzia — zazwyczaj dołączając własną strefę — lub selektory starego narzędzia zostały usunięte przed odpłynięciem jego poczty. Tylko 3,87% domen — 10 092 481 — wypełnia triadę SPF+DKIM+DMARC, zgodnie ze spisem Defaults.Exposed obejmującym 261 086 232 ocenionych domen.

Kolejność naprawy: przeskanuj domenę, a następnie sprawdź przechowywany cel każdego nowego CNAME przy użyciu dig — cel kończący się Twoją własną nazwą domeny to poszlaka. Napraw rekordy na autorytatywnych serwerach nazw, potwierdź, że nowe narzędzie podpisuje i przechodzi zanim przepuścisz przez nie prawdziwą pocztę, i zachowaj selektory starego narzędzia opublikowane, dopóki jego ruch odpłynie.

Dlaczego DKIM zepsuło się po zmianie narzędzi?

Nic w samym DKIM się nie zmieniło — Twoje selektory tak. Stare narzędzie podpisywało swoimi selektorami; nowe podpisuje innymi, zwykle delegowanymi przez dwa lub trzy rekordy CNAME dodane podczas wdrożenia. Cztery pułapki odpowiadają za niemal każdy błąd DKIM po migracji:

Twój panel DNS dołączył Twoją strefę do celu CNAME. Wiele paneli traktuje każdą wklejoną nazwę hosta jako względną i po cichu przechowuje target.provider.com.yourdomain.com zamiast target.provider.com. Rekord istnieje, panel pokazuje zielony znacznik i nie rozwiązuje się do niczego.
Zamieszanie z końcową kropką. Niektóre panele wymagają końcowej kropki (target.provider.com.) żeby oznaczać „absolutna — zatrzymaj dołączanie strefy”; inne odrzucają kropkę jako nieprawidłową i same obsługują absolutność. Ta sama wklejona wartość jest poprawna w jednym panelu i zniekształcona w następnym.
Selektory starego narzędzia zostały usunięte w dniu przełączenia. Poczta, którą stare narzędzie już podpisało, siedzi w kolejkach ponowień i ścieżkach przekazywania przez dni; usunięcie jego selektorów — lub zamknięcie starego konta, co niszczy delegowane CNAME — retroaktywnie psuje tę pocztę.
Weryfikowałeś na złych serwerach nazw. Jeśli migracja obejmowała zmianę serwerów nazw, naprawione rekordy mogą istnieć w jednym zestawie NS, podczas gdy odbiorcy nadal odpytują drugi.

Tylko 51,84% z 261 milionów domen w spisie ma możliwy do odkrycia klucz DKIM w czasie skanowania (dane z 2026-06-29).

Ta sama migracja zazwyczaj pozostawia też debris SPF — 1 013 416 domen, mniej więcej 1 na 138 spośród próbujących SPF, ma dwa rekordy v=spf1, klasyczny znak że zmiana dostawcy dodała rekord zamiast go scalić. Ta strona ruchu ma własny przewodnik: SPF przestało działać po zmianie dostawcy poczty.

Jak rozpoznać zniekształcony rekord CNAME?

Nie ufaj panelowi — zapytaj DNS, co faktycznie przechowuje. Odpytaj cel CNAME dla każdego selektora, który dał Ci nowy narzędzie. Przykład ilustracyjny, naśladujący selektor delegowany w stylu SendGrid (kształt celu Twojego dostawcy będzie inny):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Dostawca prosił o s1.domainkey.u1234567.wl123.sendgrid.net — ale przechowywany cel kończy się na .yourdomain.com. Panel dołączył strefę; ta nazwa nie rozwiązuje się do niczego, więc odbiorcy nie znajdują klucza. Wersja prawidłowa:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Pojedyncza końcowa kropka w wyniku dig jest normalna — oznacza w pełni kwalifikowaną nazwę.) Jeśli cel jest prawidłowy, śledź go o jeden skok: dig TXT s1._domainkey.yourdomain.com +short powinien zwrócić klucz dostawcy. Pusta odpowiedź przy prawidłowym CNAME oznacza, że problem leży po stronie dostawcy delegacji — ukończ jego krok weryfikacji lub patrz DKIM „no key for signature” dla diagnozy na poziomie selektora.

Plan działania dla migracji: przed, w trakcie i po

Błąd zazwyczaj nie tkwi w rekordach — tkwi w kolejności. Migracje DKIM idą źle przy przełączeniu, bo weryfikacja odbywa się po zmianie, gdy prawdziwa poczta już nie przechodzi.

Faza	Co zrobić	Brama przed przejściem dalej
Przed przełączeniem	Dodaj CNAME DKIM nowego narzędzia (i rekordy domeny bounce), a następnie udowodnij je: sprawdź `dig` każdy przechowywany cel CNAME z zewnątrz sieci, ukończ własny krok weryfikacji narzędzia i wyślij test przez nowe narzędzie do skrzynki, którą kontrolujesz	Wiadomość testowa pokazuje `dkim=pass` z `d=` = Twoja domena — nigdy nie przepuszczaj prawdziwej poczty przez niezweryfikowane narzędzie
Dzień przełączenia	Przenieś prawdziwy ruch do nowego narzędzia. Nie dotykaj niczego należącego do starego narzędzia: zostaw jego selektory, CNAME i konto aktywne	Poczta nowego narzędzia przechodzi u prawdziwych odbiorców; stare narzędzie nadal przechodzi dla wszystkiego, co przez nie przepływa
Po odpływie	Obserwuj raporty zbiorcze DMARC, aż selektory starego narzędzia przestaną się pojawiać (kolejki ponowień i przekazywania działają przez dni — poczekaj tydzień lub więcej), następnie wycofaj jego rekordy i konto	Stare selektory nieobecne w raportach przez ≥ 7 dni przed usunięciem

Pogrubiony wiersz to miejsce, gdzie migracje są ratowane lub tracone: każde sprawdzenie w nim można wykonać na dni przed przełączeniem, bez żadnego ryzyka dla aktywnej poczty. Mechanika wycofywania selektorów — w tym dlaczego ponowna publikacja z pustym p= jest lepsza niż usunięcie — jest opisana w planie działania rotacji; ta tabela dotyczy sekwencjonowania samej zmiany narzędzia.

Jak naprawić DKIM po przełączeniu?

Uruchom bezpłatne skanowanie na defaults.exposed przed dotykaniem DNS. Odczytuje Twoje aktywne rekordy i pokazuje, co faktycznie widzą odbiorcy — w tym cele CNAME z dołączoną strefą i selektory, które się nie rozwiązują.
Wylistuj rekordy DKIM oczekiwane przez nowe narzędzie. Z jego konsoli administracyjnej — dla dostawców skrzynki, przewodniki konfiguracji Google Workspace i Microsoft 365 pokazują gdzie; narzędzia do newsletterów i CRM wymieniają swoje CNAME w sekcji uwierzytelniania domeny (patrz wiadomości Mailchimp/Brevo/Klaviyo nie przechodzą DMARC).
Sprawdź przechowaną wartość każdego rekordu przez dig CNAME <name> +short i porównaj znak po znaku z tym, o co prosiło narzędzie. Cel kończący się Twoją własną domeną = dołączona strefa; wpisz ponownie, a jeśli panel nadal dołącza, dodaj końcową kropkę (lub ją usuń, jeśli panel odrzuca kropki).
Weryfikuj na autorytatywnych serwerach nazw. dig +short NS yourdomain.com, a następnie powtórz sprawdzenia CNAME @<ten serwer nazw>. Jeśli migracja zmieniła serwery nazw, sprawdź oba zestawy — odbiorcy mogą nadal odpytywać stary, dopóki delegacja się nie przepropaguje.
Ponów weryfikację narzędzia i wyślij wiadomość testową. Nagłówek Authentication-Results powinien pokazywać dkim=pass z d= równym Twojej domenie — zaliczenie na domyślnej domenie narzędzia nie wyrównuje się dla DMARC.
Zostaw selektory starego narzędzia opublikowane, dopóki jego poczta odpłynie, a następnie celowo je wycofaj. Następnie ponów skanowanie i zajmij się wszystkim innym oznaczonym na stronie naprawy DKIM.

Często zadawane pytania

Czy potrzebuję końcowej kropki w CNAME DKIM czy nie? To całkowicie zależy od panelu. Kropka oznacza „absolutna nazwa — nie dołączaj strefy”; niektóre panele tego wymagają, niektóre dodają ją za Ciebie, niektóre odrzucają. Jedynym testem, który ma znaczenie, jest wynik dig CNAME <selector>._domainkey.yourdomain.com +short po zapisaniu: jeśli cel kończy się Twoją własną domeną, panel dołączył strefę i potrzebujesz kropki (lub innego formatu wejściowego).

Czy mogę usunąć rekordy DKIM starego narzędzia w dniu przełączenia? Nie. Poczta, którą stare narzędzie podpisało, nadal jest w kolejkach ponowień i ścieżkach przekazywania, a usunięcie klucza, na który wskazuje, retroaktywnie psuje te wiadomości. Trzymaj stare selektory aktywne, dopóki nie przestaną pojawiać się w Twoich raportach zbiorczych DMARC — tydzień lub więcej — i nie zamykaj starego konta przed tym.

Mój panel DNS i nowe narzędzie oba mówią „zweryfikowane”, ale odbiorcy nadal nie zaliczają DKIM. Jak to? Dwa częste przypadki: narzędzie zweryfikowało się względem zbuforowanego sprawdzenia, podczas gdy autorytatywne serwery nazw serwują coś innego (odpytaj je bezpośrednio przez dig @<ns>), albo DKIM przechodzi, ale na domyślnej domenie podpisywania narzędzia, a nie Twojej, więc DMARC nadal nie przechodzi wyrównania. Skanowanie odróżnia te dwa przypadki.

Czy rekordy DKIM obu narzędzi mogą współistnieć podczas nakładania się? Tak — i powinny. DKIM nie ma reguły pojedynczego rekordu: każdy selektor to własna nazwa DNS, więc rekordy obu narzędzi mieszkają obok siebie bez konfliktu, co sprawia, że reguła trzymania starych selektorów przez czas odpływu jest wolna do przestrzegania. (SPF jest odwrotne — dwa rekordy v=spf1 go unieważniają, dlatego przewodnik migracji SPF mówi o scalaniu.)

Wyślij właścicielowi raport

Jeśli przeprowadzasz tę migrację dla klienta lub pracodawcy, zamknij ją z dowodem. Gdy nowe narzędzie podpisuje i wyrównuje, ponów bezpłatne skanowanie i prześlij oceniony raport właścicielowi firmy: z datą, dowód w prostym języku, że zmiana pozostawiła domenę w pełni uwierzytelnioną. To artefakt, który będzie mu potrzebny przy przedłużeniu ubezpieczenia cybernetycznego i kolejnym kwestionariuszu bezpieczeństwa dostawcy — zamienia „migracja jest gotowa” z twierdzenia w dokument.

Sprawdź swój DKIM bezpłatnie

Sprawdź, czy selektory Twojego nowego narzędzia się rozwiązują — i co dokładnie naprawić — prywatnie i tylko dla właściciela.

Sprawdź swoją domenę → · SPF przestało działać po zmianie dostawcy → · Napraw DKIM → · Skonfiguruj DKIM w Google Workspace → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.