Najczęstsze błędy, których należy unikać przy konfiguracji ustawień SPF

SPF walidacja jest ważna dla lepszego wskaźnika dostarczalności wiadomości e-mail i ochrony domeny przed phishingiem i spamem atakami. Jednak ustawienia SPF są skomplikowane i można się pomylić podczas ich konfigurowania. Naprawa i unikanie tych typowych błędów zapewnia brak fałszywych alarmów i DMARC są prawidłowo zgodne z domeną wysyłającą wiadomości e-mail.

7 typowych błędów, których należy unikać przy konfiguracji ustawień SPF

Niektóre mechanizmy DNS są używane do określania adresów IP systemów uprawnionych do wysyłania wiadomości e-mail z adresem ścieżki zwrotnej. Jednak ich nieprawidłowe użycie powoduje błędy, takie jak przekroczenie rozmiaru rekordu SPF, więcej niż 10 wyszukiwań DNS, więcej niż 2 nierozwiązane wyszukiwania DNS itp.

Wymieniliśmy typowe błędy SPF, aby pomóc Ci ich uniknąć podczas konfigurowania ustawień SPF.

Błąd 1: Wiele rekordów SPF

Powinien być jeden wpis SPF na domenę, w przeciwnym razie serwery odbierające będą odrzucały oba wpisy. Usuń wpisy SPF, które nie są obecnie używane, na przykład - przestarzałe usługi z aktywnymi wpisami SPF.

Możesz rozwiązać ten błąd ustawienia SPF, łącząc dwa lub więcej rekordów w jeden. Załóżmy, że domena użytkownika ma rekord SPF i zawiera wpis Elastic Email SPF, ale nie przechodzi weryfikacji. Możliwym powodem tego jest posiadanie 2 rekordów obecnych w domenie. 

v=spf1 a mx include:_sampledomain1.com include:_spf.elasticemail.com ~all

v=spf1 a mx include:_sampledomain2.com ~all

Możesz to rozwiązać, łącząc je w jeden rekord, taki jak:

v=spf1 a mx include:_sampledomain1.com include:_sampledomain2.com include:_spf.elasticemail.com ~all

Błąd 2: Zbyt wiele wyszukiwań DNS

Istnieje limit 10 wyszukiwań "include", co oznacza, że nie możesz wygenerować więcej niż 10 odwołań do innych domen. Każde wystąpienie parametrów "include", "a", "mx", "ptr", "exists" i "redirect" generuje lookup. Ponadto, jeśli domena, do której odwołuje się parametrinclude' zawiera inny parametr, zostanie on również zaliczony do limitu 10 lookupów. Tak więc, przekroczenie limitu lookupów jest jednym z najczęstszych błędów, które zdarzają się podczas konfigurowania ustawień SPF.

Możesz to naprawić usuwając 'zawiera' i odniesienia do nieaktywnych domen.

Uprość bezpieczeństwo z PowerDMARC!

Błąd 3: Permisywność wszystkie Mechanizm

Rekord SPF jest interpretowany od lewej do prawej strony, a znakwszystkie' będzie pasował do mechanizmu 'all nadawców, którzy nie pasowali do poprzednich mechanizmów. Sugeruje się, aby umieścić mechanizm 'all' na końcu swojego rekordu SPF i używać go z prefiksem ~ (softfail) lub - (fail). Gdy nie jest ustawiony żaden prefiks, domyślnie używany jest + (pass).

Błąd 4: Użycie ptr Mechanizm

SPF 'ptr' mechanizm służy do odwrotnego DNS lookup, który zwraca nazwę hosta do odpowiadającego mu adresu IP. Ta informacja jest pomocna szczególnie dla marek B2B. Jednak mechanizm ten ma problemy z niezawodnością i powoduje obciążenie serwerów reverse DNS oraz podłączonych do nich systemów pocztowych.

Dlatego też RFC7208 odradza używanieptr' mechanizmu. W większości przypadków można go zastąpić mechanizmem 'a' mechanizmem.

Błąd 5: Użycie mx Mechanizm

Użyj 'mx' z nazwami domen, a nie nazwami serwerów pocztowych. Podając mx:mailserver.sample.com jest uważane za niepoprawne, chyba że faktycznie wymagasz walidacji SPF, aby sprawdzić wszystkie hosty akceptujące pocztę dla domeny 'mailserver.sample.com'. W większości przypadków nie będzie takich hostów, ponieważ "mailserver.sample.com" jest sam w sobie hostem, a nie domeną.

Nie natkniesz się na to jako na błąd składni, ale nie będzie to po prostu pasować do niczego.

Poprawny sposób sprawdzania poprawności rekordu MX dla 'sample.com' to mx:sample.com. Gdy musisz określić nazwę hosta lub adres IP określonego serwera pocztowego, a:mailserver.sample.com lub ip4:x.x.x.x powinno być użyte

Błąd 6: Tworzenie rekordu SPF bez odpowiedniego badania

Dotyczy to w szczególności dostawców usług internetowych. Nie twórz rekordów z połowicznymi informacjami o domenie, jej właścicielu i marce, do której należy. Zbadaj z jakiego serwera pocztowego korzystają, w przeciwnym razie możesz skończyć blokując ich ścieżkę dostarczania poczty wychodzącej z ich biurowego serwera pocztowego.

Błąd 7: Literówki

Unikaj popełniania typowych błędów podczas konfiguracji ustawień SPF poprzez podwójne sprawdzenie rekordu SPF pod kątem literówek. Możesz wpisać "inlcude" zamiast "include". Może to spowodować, że cały rekord będzie nieważny.

Błąd 8: Nie publikowanie rekordów SPF dla nazw HELO używanych przez Twoje serwery pocztowe

Verifying HELO or EHLO names is encouraged by the SPF RFC. HELO or its developed version EHLO is used when Mail from is <> despite the recipient’s failure in doing 100% HELO checking.

Opublikowanie protokołu HELO obejmuje wygenerowanie rekordu SPF odpowiadającego HELO FQDN używanemu przez Twój serwer pocztowy. Na przykład: mailserver.sample1.com

Generalnie powinna to być zupełnie odrębna reguła SPF od tej, która sprawdza adres From w Twojej domenie powiązanej z "sample1.com".

Błąd 9: Zawartość rekordu TXT nie jest wyświetlana z podwójnymi cudzysłowami

Zawartość rekordu DNS TXT jest zawsze ujęta w podwójne cudzysłowy ("-"), ale nigdy nie powinny one być częścią rzeczywistej zawartości rekordu DNS. Te cudzysłowy służą jedynie do celów wyświetlania, ponieważ pomagają oddzielić początek i koniec zawartości rekordu TXT.

Rekord SPF powinien zaczynać się od v=spf1 ale jeśli zaczyna się od "v=spf1to nie zostanie w ogóle rozpoznany.

Nadal problem?

Każda zmiana ustawień SPF wymaga pewnego czasu na propagację w Internecie. Może to potrwać nawet do 72 godzin. Jeśli jednak nadal masz jakieś problemy, skorzystaj z naszego darmowego SPF record checker lub skontaktuj się z naszym zespołem ekspertów pod adresem [email protected].

• O
• Latest Posts

Ahona Rudra

Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC

Ahona jest Marketing Managerem w PowerDMARC, z ponad 5-letnim doświadczeniem w pisaniu na tematy związane z cyberbezpieczeństwem, specjalizującym się w bezpieczeństwie domen i poczty elektronicznej. Ahona posiada dyplom ukończenia studiów podyplomowych w zakresie dziennikarstwa i komunikacji, umacniając swoją karierę w sektorze bezpieczeństwa od 2019 roku.

Latest posts by Ahona Rudra (zobacz wszystkie)

• Microsoft wzmacnia zasady dotyczące nadawców wiadomości e-mail: Kluczowe aktualizacje, których nie można przegapić - 3 kwietnia 2025 r.
• Konfiguracja DKIM: Przewodnik krok po kroku dotyczący konfiguracji DKIM dla bezpieczeństwa poczty e-mail (2025) - 31 marca 2025 r.
• PowerDMARC uznany za lidera sieci dla DMARC w G2 Spring Reports 2025 - 26 marca 2025 r.