Przewodnik konfiguracji rekordu SPF w GoDaddy na rok 2026

Masz już rekord w GoDaddy, ostatnia kampania została wysłana, a Gmail nadal traktuje połowę Twoich wiadomości tak, jakby pochodziły od nieznajomego. Potem ktoś dodaje CRM, narzędzie do newsletterów i platformę transakcyjną, a cała konfiguracja zaczyna przypominać plątaninę luźnych kabli. To zazwyczaj moment, w którym rekord SPF w GoDaddy przestaje być tylko formalnością, a staje się fundamentem Twojej dostarczalności.

Bolesne jest to, że błędy SPF rzadko dają o sobie znać w jasny sposób. Dodawany jest nadawca, edytowany jest DNS, a kilka tygodni później zespół zauważa trafianie do spamu, błędy uwierzytelniania lub sytuację, w której jedna platforma działa, a druga znika z listy. Jeśli brzmi to znajomo, masz do czynienia z zarządzaniem DNS, strukturą rekordu i sufitem 10 zapytań, a nie tylko z “problemami z pocztą”.

Dlaczego Twój rekord SPF w GoDaddy ma większe znaczenie, niż myślisz

SPF jest prosty w koncepcji, ale brutalny w praktyce. Serwer odbiorczy sprawdza opublikowaną politykę domeny w DNS, a następnie pyta, czy serwer wysyłający ma uprawnienia do wysyłki w imieniu tej domeny. Jeśli odpowiedź się nie zgadza, wiadomość może zostać potraktowana jako nieautoryzowana, nawet jeśli nadawca jest uczciwy.

Dlatego zepsuty rekord SPF w GoDaddy szkodzi bardziej, niż wielu sądzi. Zarówno Microsoft 365, jak i Google Workspace polegają na sygnałach uwierzytelniania, które dostawcy skrzynek oceniają w tle, więc brakujący lub błędnie sformułowany rekord SPF może wpłynąć na dostarczalność do skrzynki odbiorczej, zanim ktokolwiek zauważy widoczną awarię. Różnica między hardfail a softfail ma tutaj znaczenie, ponieważ końcowy kwalifikator mówi odbiorcom, czy nieautoryzowana poczta powinna zostać odrzucona całkowicie, czy potraktowana z podejrzeniem.

Element, który pomija większość zespołów

SPF nie mówi tylko: “czy ta domena jest Twoja”. Mówi: “czy ten nadawca znajduje się na zatwierdzonej liście opublikowanej w DNS”. To tutaj zaczyna mieć znaczenie wyrównanie SPF (SPF alignment), ponieważ DMARC sprawdza później, czy widoczna domena nadawcy (From) zgadza się z uwierzytelnionym źródłem.

Praktyczna zasada: jeśli nadawca został dodany do stosu technologicznego po utworzeniu pierwotnego rekordu SPF, ten nadawca prawdopodobnie stał się problemem, chyba że rekord DNS również został zaktualizowany.

Własne wytyczne GoDaddy odzwierciedlają nowoczesne podejście, w którym SPF jest publikowany jako rekord TXT, a nie jako osobny typ rekordu SPF, a proces pracy koncentruje się na edycji DNS wewnątrz portfolio domen. Ta konfiguracja brzmi zwyczajnie, ale właśnie dlatego SPF psuje się tak często. Rekord łatwo dodać raz i łatwo o nim zapomnieć po zatwierdzeniu kolejnego narzędzia.

Dodawanie pierwszego rekordu SPF w DNS GoDaddy

Zacznij w Portfolio domen, otwórz DNS i dodaj rekord jako TXT. Własna pomoc GoDaddy pokazuje tę ścieżkę dla konfiguracji SPF, z polityką SPF wprowadzoną w polu Wartość (Value) i hostem ustawionym na główny (root), gdy polityka dotyczy całej domeny, podczas gdy TTL pozostaje na Domyślny (Default) w udokumentowanym przykładzie dla powiązanych rekordów pocztowych Pomoc GoDaddy dotycząca rekordu SPF Pola rekordów DNS GoDaddy dla uwierzytelniania poczty.

Pola, które mają znaczenie

Typ (Type) powinien być TXT, a nie SPF. Dokumentacja GoDaddy używa TXT, ponieważ jest to standardowy format publikacji dla SPF w nowoczesnym DNS, a ten wybór pozwala uniknąć niejednoznaczności u różnych walidatorów.

Nazwa (Name) powinna zazwyczaj wynosić @ dla polityki domeny głównej. Mówi to GoDaddy, że rekord należy do szczytu domeny, a nie do subdomeny. Wartość (Value) to miejsce, w którym znajduje się ciąg SPF, więc tam wklejasz samą politykę.

TTL może pozostać na Domyślny, jeśli postępujesz zgodnie z udokumentowaną konfiguracją GoDaddy, zwłaszcza gdy nie jesteś w trakcie rozwiązywania problemów. Dokładne nazwy pól łatwo przeoczyć, ale to one stanowią różnicę między rekordem, który znajduje się w głównym katalogu domeny, a takim, który znajduje się w bezużytecznym miejscu.

Prosty przykład poczty zarządzanej przez GoDaddy wygląda tak: v=spf1 include:secureserver.net -all, co jest formą, którą GoDaddy pokazuje dla hostingu poczty. Jeśli autoryzujesz tylko jedno źródło nadawcze, to jest to kształt, którego potrzebujesz: jeden rekord, jedna polityka, jedno miejsce.

Dla wariantu specyficznego dla Gmaila, ten przewodnik SPF dla użytkowników Gmaila pokazuje tę samą logikę “TXT przede wszystkim” w praktyce.

Jeśli wpiszesz typ rekordu inny niż TXT lub pozostawisz hosta pustego, gdy polityka musi znajdować się w głównym katalogu, rekord może istnieć w interfejsie użytkownika, ale nadal zawodzić na poziomie DNS.

W dalszej części procesu własny interfejs GoDaddy staje się mniej ważny niż autorytatywna strefa DNS, ale pierwszym zwycięstwem jest wprowadzenie rekordu w odpowiednim polu, z odpowiednim typem i u odpowiedniego hosta.

Składnia SPF dla używanych nadawców

Wiele organizacji nie korzysta z jednego nadawcy. Używają głównej skrzynki pocztowej, platformy marketingowej, CRM i systemu transakcyjnego. Rekord SPF jest pojedynczym oświadczeniem, które autoryzuje je wszystkie, więc faktycznym zadaniem jest wybranie odpowiednich mechanizmów i utrzymanie listy na tyle krótkiej, aby została zweryfikowana, zanim DNS GoDaddy zacznie działać na Twoją niekorzyść.

Gotowe do wklejenia ciągi SPF dla typowych stosów nadawców

Konfiguracja nadawcy	Wartość SPF	Wykorzystane zapytania
Google Workspace	v=spf1 include:_spf.google.com -all	Jedno include, potem końcowa weryfikacja polityki
Microsoft 365	v=spf1 include:spf.protection.outlook.com -all	Jedno include, potem końcowa weryfikacja polityki
Google Workspace plus narzędzie marketingowe	v=spf1 include:_spf.google.com include:servers.mcsv.net -all	Dwa include, plus wszelkie zagnieżdżone zapytania wewnątrz dołączonych rekordów
Microsoft 365 plus nadawca transakcyjny	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all	Dwa include, plus wszelkie zagnieżdżone zapytania wewnątrz dołączonych rekordów

Te ciągi są przydatne, ponieważ pokazują wzorzec: jeden rekord, jedna polityka, jedno miejsce do kontrolowania w GoDaddy. Jeśli Twój stos zaczyna się od Google Workspace lub Microsoft 365, a następnie rozrasta się o pocztę marketingową i transakcyjną, rekord zazwyczaj przestaje dotyczyć składni, a zaczyna dotyczyć tego, ile zapytań DNS każdy dostawca zużywa w tle.

Co robią mechanizmy

include mówi, aby sprawdzić politykę SPF innej domeny i odziedziczyć jej autoryzację. Jest to koń pociągowy dla Google Workspace, Microsoft 365, Mailchimp, SendGrid i podobnych platform.

ip4 służy do stałych adresów wysyłkowych, co pomaga, gdy kontrolujesz źródłowy adres IP i nie chcesz polegać na łańcuchu polityk innego dostawcy. all na końcu ustala regułę dla wszystkiego, co nie zostało jeszcze autoryzowane, a kwalifikator decyduje, jak surowa ma być awaria.

Praktyczna zasada: używaj surowszego zakończenia, gdy lista nadawców jest stabilna, a łagodniejszego tylko wtedy, gdy nadal porządkujesz stos.

Przydatną perspektywą zewnętrzną na planowanie nadawców jest porada dla kampanii e-mailowych małych firm, ponieważ zespoły kampanijne często dodają narzędzia bez sprawdzania ich wpływu na DNS.

Częścią, która wywraca prawdziwe konfiguracje w GoDaddy, jest budżet zapytań. Każde dodatkowe include zużywa ten budżet, a rekord może wyglądać czysto, mimo że zawodzi, ponieważ łańcuch staje się zbyt głęboki. Buduj składnię wokół stosu, którego używasz, a nie tego, którego chciałbyś używać.

Łączenie wielu nadawców bez przekraczania limitu zapytań

Głównym trybem awarii rekordu SPF w GoDaddy nie jest składnia, lecz akumulacja. Domena zaczyna od jednego nadawcy, potem marketing dodaje kolejnego, potem sprzedaż dodaje CRM, potem operacje dodają platformę transakcyjną i nikt nie zauważa, że SPF próbuje teraz zweryfikować więcej systemów, niż pozwala na to standard.

Zasada jest bezwzględna i nie podlega negocjacjom. Nigdy nie publikuj więcej niż jednego rekordu SPF pod tą samą nazwą. Jeśli dla tej samej domeny istnieją dwa rekordy TXT SPF, odbiorcy mogą potraktować wynik jako nieprawidłowy lub niejednoznaczny, co oznacza, że rekord, który miał pomagać, może być tym, który psuje uwierzytelnianie.

Jak działa proces łączenia

Zacznij od wypisania każdego legalnego nadawcy. Następnie połącz je w jedną politykę TXT, używając instrukcji include, gdzie dostawca zarządza własną infrastrukturą wysyłkową. Jeśli masz już rekord w GoDaddy, edytuj go zamiast tworzyć drugą kopię.

Drugą pułapką jest zagnieżdżanie. Pojedyncze include może ukrywać kilka kolejnych zapytań wewnątrz własnej polityki SPF dostawcy i właśnie dlatego domeny mogą wyczerpać budżet szybciej, niż zespół się spodziewa. Wskazówki dotyczące GoDaddy ostrzegają użytkowników, aby pozostali poniżej limitu 10 zapytań mechanizmów DNS, a limit ten ma zastosowanie podczas oceny, a nie po fakcie Najlepsze praktyki konfiguracji SPF dla domen GoDaddy Wskazówki SPF na rok 2026 dla domen GoDaddy.

Czystszy model operacyjny

• Najpierw sprawdź każdego nadawcę: usuń stare narzędzia, które już nie wysyłają poczty, ponieważ nieaktualne include nadal zużywają budżet.
• Skonsoliduj w jedną politykę: trzymaj całą autoryzację w jednym rekordzie TXT pod poprawną nazwą.
• Zweryfikuj liczbę zapytań przed zapisaniem: rekord, który wygląda schludnie, nadal może zawieść, jeśli zagnieżdżone include wypchną go ponad sufit.

Mail Merge for Gmail pasuje do tej logiki idealnie. Wysyła przez uwierzytelnioną infrastrukturę Google, więc nie potrzebuje własnego osobnego include i nie dodaje się do budżetu SPF, gdy już autoryzujesz Google Workspace.

Powód, dla którego ma to tak duże znaczenie, jest prosty. Zespół może mieścić się w limicie przez miesiące, a potem jeden nowy dostawca wypycha rekord poza krawędź i SPF zaczyna zawodzić bez żadnego oczywistego błędu DNS w interfejsie GoDaddy.

Weryfikacja, czy Twój rekord faktycznie działa

Zapisanie rekordu w GoDaddy nie jest dowodem. Oznacza to jedynie, że zmiana została wprowadzona, a nie że autorytatywna strefa ją serwuje, że pamięci podręczne zostały zaktualizowane i że polityka analizuje się poprawnie.

Trzy sprawdzenia, trzy różne odpowiedzi

Pierwszym sprawdzeniem jest zapytanie DNS do aktywnej strefy. Zapytanie dig lub nslookup mówi Ci, co zwracają autorytatywne serwery nazw, co ma znaczenie, ponieważ interfejs GoDaddy może pokazać wartość przed zakończeniem propagacji i nie powie Ci, czy strefę posiada inny host DNS.

Drugim sprawdzeniem jest parser SPF, taki jak sprawdzanie SPF w MXToolbox. Tego rodzaju narzędzie jest przydatne, ponieważ odczytuje składnię i jednocześnie zlicza zapytania, co jest dokładnie miejscem, w którym pojawiają się zagnieżdżone include i łańcuchy przekraczające limit.

Trzecim sprawdzeniem jest dowód na poziomie wiadomości. Wyślij test do Gmaila, otwórz oryginalną wiadomość i sprawdź nagłówki. Linia Authentication-Results zazwyczaj pokaże, czy SPF przeszedł, czy nie dla domeny wysyłającej, co mówi Ci, jak dostawca skrzynki ocenił wiadomość, a nie tylko co mówi DNS.

Praktyczna zasada: jeśli DNS wygląda poprawnie, ale nagłówki nadal wykazują błąd, problem zazwyczaj leży na warstwie walidacji, a nie w interfejsie GoDaddy.

Istnieje również rzeczywistość propagacji, którą zespoły ignorują na własne ryzyko. Zachowanie TTL w GoDaddy jest zazwyczaj szybkie, ale zmiany DNS w przypadkach brzegowych mogą nadal wymagać czasu, aby ustabilizować się w różnych resolverach. Jeśli przenosisz rekordy między dostawcami, najpierw potwierdź autorytatywne serwery nazw, a następnie zweryfikuj względem rzeczywistej strefy, a nie panelu sterowania, którego akurat użyłeś. Do śledzenia wiadomości od początku do końca, ten przewodnik śledzenia wiadomości e-mail jest czystszym uzupełnieniem.

Od przejścia SPF do pełnego uwierzytelniania poczty

Przejście SPF daje poczucie bezpieczeństwa, ale nie rozwiązuje całego problemu. SPF autoryzuje tylko źródła wysyłkowe, nie podpisuje wiadomości i nie powstrzymuje wiadomości przed zmianą po opuszczeniu nadawcy. Dlatego sam SPF może nadal pozostawiać przypadki przekierowań i luki w podszywaniu się.

Gdzie pasują DKIM i DMARC

DKIM dodaje kryptograficzny podpis do samej wiadomości. W DNS zarządzanym przez GoDaddy zazwyczaj oznacza to rekord TXT pod hostem selektora, a Google Workspace powszechnie używa google._domainkey jako części tej konfiguracji.

DMARC znajduje się na szczycie SPF i DKIM. Mówi systemom odbiorczym, co robić, gdy uwierzytelnianie zawiedzie i gdzie wysyłać raporty, zazwyczaj poprzez rekord TXT w _dmarc w domenie. Bez DMARC dostawcy skrzynek nie mają wspólnej polityki, której mogliby przestrzegać, gdy SPF lub DKIM się nie zgadzają.

Kluczowym wnioskiem jest to, że SPF to tylko jedna warstwa zaufania. Sfałszowana wiadomość może nadal wykorzystywać słabe wyrównanie, jeśli DKIM nie jest na miejscu, a przekierowana wiadomość może nadal zachowywać się inaczej niż oryginalna wysyłka, nawet gdy SPF był czysty u źródła.

Praktyczny stos jest prosty. SPF autoryzuje nadawcę, DKIM podpisuje wiadomość, a DMARC mówi odbiorcom, jak postępować, gdy te dwa elementy się nie zgadzają. Wcześniejsza sekcja dotycząca weryfikacji ma tutaj znaczenie, ponieważ nie chcesz zaostrzać polityki, zanim nie będziesz mieć pewności, że każdy legalny nadawca się uwierzytelnia.

Aby uzyskać głębszy wgląd w pełny stos, ten przewodnik uwierzytelniania poczty łączy SPF, DKIM i DMARC w jeden proces pracy.

Utrzymywanie czystości SPF podczas kampanii Mail Merge

Kampania Mail Merge szybko poddaje pracę nad DNS presji. Zespoły sprzedaży, rekrutacji lub wydarzeń mogą wysłać czystą sekwencję z Gmaila jednego dnia, a potem winić treść w następnym tygodniu, gdy odpowiedzi spadną, mimo że głębszym problemem był dryf uwierzytelniania.

Mail Merge for Gmail wysyła przez uwierzytelnioną infrastrukturę Google, więc nie tworzy osobnego nadawcy, który potrzebuje własnego include SPF. Większym ryzykiem jest to, że otaczający stos się zmienia, właściciel domeny dodaje kolejną platformę, a dostawcy skrzynek zaczynają oceniać historię wiadomości, która nie wygląda już na spójną.

Lista kontrolna przed kampanią, która naprawdę pomaga

• Potwierdź, że SPF przechodzi dla wysyłającego konta Google: przetestuj dokładnie tę skrzynkę, która wyśle kampanię, a nie losowy alias.
• Potwierdź, że DKIM jest włączony w panelu administratora Google Workspace: sam SPF jest zbyt kruchy dla przekierowanej lub ponownie opakowanej poczty.
• Potwierdź, że DMARC jest ustawiony przynajmniej na p=none z włączonym raportowaniem: to daje Ci wgląd, zanim zaostrzysz politykę.

Zielony wynik SPF sam w sobie nie oznacza, że kampania jest bezpieczna do uruchomienia. Oznacza jedynie, że nadawca pasował do aktualnej polityki DNS w tym momencie.

Najlepszym nawykiem jest traktowanie rekordu SPF jak hydrauliki. Sprawdź go przed kampanią, sprawdź go, gdy dodawany jest nowy nadawca, i sprawdź go ponownie, gdy platforma zmienia swoją ścieżkę wysyłkową. W ten sposób uchronisz rekord SPF w GoDaddy przed starzeniem się w problem z dostarczalnością.

---

Mail Merge for Gmail pomaga zespołom wysyłać spersonalizowane kampanie z Gmaila, utrzymując ścieżkę wysyłkową powiązaną z Google Workspace, co ułatwia uzasadnienie SPF, gdy stos domen staje się zatłoczony. Jeśli porządkujesz konfigurację DNS w GoDaddy przed kolejną rundą outreachu, odwiedź Mail Merge for Gmail i sprawdź, jak pasuje to do procesu pracy, który już zależy od utrzymania czystości SPF, DKIM i DMARC.