Defaults.Exposed › Naprawy › Guides

SPF przestało działać po zmianie dostawcy poczty — naprawa po migracji (2026)

Opublikowano 2026-07-08

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

SPF zwykle zrywa się po zmianie dostawcy poczty, bo rekord nowego dostawcy został dodany obok starego. Dwa rekordy v=spf1 to błąd trwały — SPF całkowicie traci ważność. 1 013 416 domen — mniej więcej jedna na 138 spośród tych, które próbują używać SPF — jest w tym stanie, zgodnie ze spisem Defaults.Exposed obejmującym 261 milionów domen. Scal je w jeden.

Naprawa zajmuje około dziesięciu minut: przeskanuj domenę, aby zobaczyć dokładnie, co zostawiła migracja, wylistuj każdy rekord SPF na autorytatywnych serwerach nazw, scal je w jeden rekord zawierający tylko nowego dostawcę i zweryfikuj za pomocą dig. Ten przewodnik opisuje każdy krok, a także sprawdzenia DKIM i serwerów nazw, o których większość migracji zapomina.

Dlaczego SPF zepsuło się zaraz po migracji?

Ponieważ przewodnik konfiguracji nowego dostawcy powiedział „dodaj ten rekord TXT” — i tak zrobiłeś, obok starego. To jest jedyna rzecz, której standard SPF nie pozwala. RFC 7208 (§3.2, wynik błędu określony w §4.5) zezwala na dokładnie jeden rekord v=spf1 na domenę; odbiorca, który znajdzie dwa lub więcej, musi zwrócić PermError, a nie zgadywać, który jest autorytatywny. PermError oznacza, że SPF jest nieważny: nie stary rekord, nie nowy, żadnego SPF w ogóle.

I to nie koniec. DMARC traktuje PermError jako błąd w nodze SPF, więc Twoja poczta teraz zależy wyłącznie od DKIM. Jeśli DKIM nowego dostawcy też nie jest jeszcze skonfigurowany — co jest powszechne w połowie migracji — wysyłasz bez uwierzytelnienia dokładnie w chwili, gdy zmieniłeś infrastrukturę, a to jest moment, gdy odbiorcy przyglądają Ci się najuważniej.

To jest kopiuj-wklej, który unieważnia ochronę przy zmianie dostawców, i nie jest rzadki: 1 013 416 domen publikuje teraz dwa lub więcej rekordów SPF — mniej więcej jedna na 138 z 139 milionów domen próbujących używać SPF, zgodnie ze spisem Defaults.Exposed obejmującym 261 milionów domen (dane z 2026-06-29). Pełne liczby dotyczące pułapki dwóch rekordów mają własny raport; ta strona zawiera proceduralne rozwiązanie.

Co zostawiła migracja?

Pięć pozostałości powoduje niemal każde niepowodzenie SPF po migracji. Sprawdzaj je w tej kolejności:

Jak to naprawić? Lista kontrolna po migracji

1. Najpierw uruchom bezpłatne skanowanie na defaults.exposed. Odczytuje Twój aktywny DNS i mówi, czy masz wiele rekordów SPF, brakujący include lub lukę DKIM — zdiagnozuj przed dotknięciem czegokolwiek.

2. Wylistuj każdy rekord SPF na autorytatywnych serwerach nazw. dig +short NS yourdomain.com, a następnie dig +short TXT yourdomain.com @<nameserver> dla jednego z nich. Policz ciągi zaczynające się od v=spf1. Jedyna bezpieczna liczba to 1.

3. Scal do jednego rekordu. Jeden rekord, zaczynający się od v=spf1, zawierający include nowego dostawcy i każdego innego nadawcy, którego nadal używasz (narzędzie do fakturowania, CRM, platforma newslettera), jeden końcowy -all lub ~all. Przykład — stary Google Workspace, nowy Microsoft 365, w połowie odpływu:

   Before:  "v=spf1 include:_spf.google.com ~all"
            "v=spf1 include:spf.protection.outlook.com -all"
   
   After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
   Later:   "v=spf1 include:spf.protection.outlook.com -all"
   

   Wartości dostawców i specyfika paneli DNS są w przewodnikach konfiguracji dla Google Workspace i Microsoft 365.

4. Usuń dodatkowe rekordy. Scalenie bez usunięcia nic nie naprawia — PermError wynika z liczby.

5. Zachowaj include starego dostawcy tylko dopóki stary system nadal wysyła — zaplanowane raporty, stary konektor CRM, zapomniana skrzynka. Gdy odpływ się zakończy, usuń go: przestarzały include pozostawia starą infrastrukturę z uprawnieniami do wysyłania jako Ty, a każdy include kosztuje wyszukiwania DNS wliczane do twardego limitu 10 dla SPF — co najmniej 797 263 domen unieważniło SPF przekraczając ten limit (spis, 2026-06-29).

6. Skonfiguruj DKIM nowego dostawcy — i nie usuwaj jeszcze starych selektorów. Nowe selektory podpisują nową pocztę; stare selektory muszą pozostać opublikowane, dopóki każda wiadomość podpisana nimi zostanie dostarczona i ewentualne przekazania się ustabilizują. Pełny opis w DKIM przestało działać po zmianie narzędzi poczty.

7. Jeśli zmieniłeś też serwery nazw, sprawdź oba. Migracje DNS często idą w parze z migracjami poczty. Odpytaj stary i nowy zestaw NS bezpośrednio (dig TXT yourdomain.com @old-ns i @new-ns) — dopóki delegacja rejestratora całkowicie się nie przepropaguje, niektórzy odbiorcy nadal pytają stare serwery, więc naprawiony rekord musi istnieć w jakimkolwiek zestawie, który odpowiada.

8. Ponów skanowanie i potwierdź, że SPF pokazuje jeden ważny rekord z wynikiem pozytywnym.

Którą domenę SPF faktycznie sprawdza?

Odbiorcy oceniają SPF względem domeny Return-Path (RFC5321.MailFrom) — adresu bounce — a nie nagłówka From widocznego dla odbiorców. Po migracji ma to podwójne znaczenie: Twój nowy dostawca może używać własnej domeny bounce, dopóki nie skonfigurujesz niestandardowej, a SPF „przechodzący” na domenie, która nie jest Twoja, nie wyrówna się dla DMARC. Naprawą jest DKIM nowego dostawcy, podpisany Twoją domeną.

Migracja i rebranding jednocześnie?

Zmieniłeś też domenę oprócz dostawcy? Traktuj to jako dwie oddzielne prace. Nowa domena potrzebuje pełnego zestawu — SPF, DKIM, DMARC — od pierwszego dnia; skorzystaj z listy kontrolnej poczty dla nowej domeny. Stara domena pozostaje uwierzytelniona tak długo, jak przekazywanie lub ruch odpowiedzi przez nią przepływa, i zostaje wyraźnie zabezpieczona (nie po prostu porzucona), gdy jest zaparkowana. Stara domena z przestarzałym, na wpół zepsutym SPF to cel spoofingu noszący Twoje dawne imię.

Często zadawane pytania

Czy mogę mieć dwa rekordy SPF podczas migracji? Nie. Standard nie przewiduje okresu przejściowego — dwa rekordy v=spf1 to PermError od chwili pojawienia się drugiego, a 1 013 416 domen siedzi w tym stanie według spisu (2026-06-29). Bezpieczny podczas migracji wzorzec to jeden rekord niosący includes obu dostawców w czasie nakładania się.

Jak długo powinienem trzymać include starego dostawcy? Do momentu gdy nic nie wysyła przez starego dostawcę — zazwyczaj tyle, ile trwa okno nakładania się, od kilku dni do kilku tygodni. Obserwuj Return-Path wszystkiego, co nadal przychodzi przez stary system; gdy ten ruch ustanie, usuń include i sprawdź ponownie liczbę wyszukiwań.

Dlaczego narzędzie do sprawdzania nadal pokazuje mój stary rekord po naprawie? Buforowanie DNS honoruje TTL rekordu, a jeśli serwery nazw zmieniły się, niektóre resolvery nadal pytają stary zestaw. Sprawdź bezpośrednio na autorytatywnych serwerach nazw przy użyciu dig TXT yourdomain.com @<ns> — jeśli odpowiedź tam jest poprawna, naprawa jest gotowa, a pamięci podręczne się dogonią. Jeśli jest błędna w jednym zestawie NS, patrz „SPF record not found” — prawdziwe przyczyny.

Czy muszę zmieniać DMARC przy zmianie dostawcy? Zazwyczaj nie samego rekordu — podaje on Twoją skrzynkę raportową i politykę, a nie dostawcę. Ale Twoje wyniki DMARC zależą od SPF i DKIM, które właśnie migrowałeś: spodziewaj się spadku w raportach podczas przełączania i potwierdź, że obie nogi przechodzą przed zaostrzeniem polityki. Zacznij od naprawy SPF, jeśli skanowanie pokazuje, że noga SPF nadal nie przechodzi.

Wyślij właścicielowi raport

Jeśli wykonujesz tę migrację dla klienta, zakończ z dowodem. Ponów bezpłatne skanowanie gdy scalenie jest aktywne i prześlij oceniony raport właścicielowi firmy: SPF, DKIM i DMARC przechodzą u nowego dostawcy, w prostym języku, z datą. To artefakt, który złożą przy przedłużeniu ubezpieczenia cybernetycznego i kolejnym kwestionariuszu bezpieczeństwa dostawcy — dowód, że migracja pozostawiła domenę lepiej uwierzytelnioną niż na początku.

Sprawdź swoją domenę → · DKIM przestało działać po zmianie narzędzi poczty → · „SPF record not found” — prawdziwe przyczyny → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.