SPF walidacja SPF jest ważna dla lepszego współczynnika dostarczalności wiadomości e-mail oraz dla ochrony Twojej domeny przed phishingiem i spamem atakami typu phishing i spam. Jednak ustawienia SPF są skomplikowane i można popełnić błąd podczas ich konfiguracji. Naprawianie i unikanie tych powszechnych błędów zapewnia, że nie ma fałszywych pozytywów i DMARC i zgodność z DMARC właściwie dla Twojej domeny wysyłającej wiadomości.
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 konfiguracji 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.
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 w podwójnych cudzysłowach ("-"), ale nigdy nie powinny one być częścią rzeczywistej zawartości rekordu DNS. Cudzysłowy służą jedynie do 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 support@powerdmarc.com.
- Jak znaleźć najlepszego dostawcę rozwiązań DMARC dla swojej firmy? - 25 kwietnia 2024 r.
- PowerDMARC i Zendata nawiązują partnerstwo w celu zwiększenia bezpieczeństwa domeny - 25 kwietnia 2024 r.
- PowerDMARC współpracuje z CNS w celu rozwoju praktyk bezpieczeństwa poczty elektronicznej na Bliskim Wschodzie - 24 kwietnia 2024 r.