Jak utworzyć rekord SPF dla Office 365, nie zakłócając działania innych usług pocztowych?

Aby utworzyć rekord SPF dla Office 365 bez zakłócania innych usług pocztowych, należy sporządzić inwentarz wszystkich uprawnionych nadawców, zbudować pojedynczy rekord v=spf1 zawierający include:spf.protection.outlook.com wraz z pozostałymi dostawcami i adresami IP, pozostając w granicach limitu 10 zapytań DNS (w razie potrzeby stosując subdomeny lub spłaszczanie), wdrożyć go z łagodnym kwalifikatorem (~all), przetestować i monitorować za pomocą danych SPF/DMARC oraz zautomatyzować jego utrzymanie za pomocą AutoSPF, aby zapobiec rozjeżdżaniu się konfiguracji.

Zgodnie z RFC 7208 ewaluacja SPF jest ograniczona do 10 zapytań mechanizmów DNS oraz 2 pustych zapytań na jedno sprawdzenie — przekroczenie któregokolwiek z tych limitów powoduje błąd PermError, który powoduje niepowodzenie uwierzytelnienia każdej wiadomości z danej domeny.

Kontekst i tło

Sender Policy Framework (SPF) to oparta na DNS lista autoryzacyjna, która informuje odbiorców, które adresy IP i usługi mogą wysyłać pocztę w imieniu Pana/Pani domeny. Microsoft 365 (Exchange Online) wymaga uwzględnienia swojej opublikowanej infrastruktury SPF za pomocą include:spf.protection.outlook.com, jednak wiele domen wysyła pocztę również z lokalnego Exchange, platform marketingowych, systemów CRM, systemów zgłoszeniowych oraz aplikacji internetowych. Jeśli opublikuje Pan/Pani rekord SPF obejmujący wyłącznie Office 365, inne uprawnione usługi mogą zostać odrzucone; jeśli natomiast spróbuje Pan/Pani uwzględnić wszystko w sposób nieprzemyślany, może dojść do przekroczenia rygorystycznego limitu 10 zapytań SPF i całkowitego zakłócenia ewaluacji.

Najbezpieczniejsza droga jest metodyczna: należy wykryć każde źródło wysyłające pocztę, skonstruować jeden precyzyjny rekord obejmujący Office 365 oraz wszystkie pozostałe źródła, zoptymalizować go, aby zmieścić się w budżecie zapytań, ostrożnie przeprowadzić etapy wdrożenia i utrzymywać go w odpowiednim stanie. Jeśli zaczyna Pan/Pani od zera, nasz przewodnik dotyczący tego, jak skonfigurować rekord SPF, omawia podstawy. AutoSPF usprawnia każdy z tych kroków, wykrywając nadawców na podstawie danych z rzeczywistego ruchu pocztowego, modelując liczbę zapytań w czasie rzeczywistym, automatycznie spłaszczając rekord w razie potrzeby oraz monitorując wyniki, dzięki czemu może Pan/Pani z pewnością przejść na rygorystyczną politykę.

Sporządź inwentarz każdej usługi wysyłającej pocztę w imieniu Pana/Pani domeny

Kompletny inwentarz nadawców zapobiega „zakłóceniom” podczas przechodzenia na Office 365 lub optymalizacji pod jego kątem.

Co należy wymienić i jak to udokumentować

• Środowisko lokalne: publiczne adresy IP z NAT dla Exchange lub przekaźników SMTP, smart hosty, skanery oraz urządzenia wielofunkcyjne (MFP)

• Microsoft 365: Exchange Online Protection (EOP) za pomocą include:spf.protection.outlook.com

• Platformy zewnętrzne: dostawcy usług pocztowych (np. SendGrid, Mailchimp), systemy CRM (np. Salesforce), systemy zgłoszeniowe (np. Zendesk), systemy wsparcia/czatu, systemy HR/płacowe oraz każda aplikacja wysyłająca pocztę jako Pana/Pani domena

• Infrastruktura internetowa: systemy CMS/formularze kontaktowe, platformy e-commerce, funkcje serverless

• Ścieżki specjalne: listy mailingowe, przekierowania (forwardery) oraz nadawcy z subdomen (np. bounce@, newsletter@, noreply@)

Metody wykrywania wszystkich źródeł

• Raporty zbiorcze DMARC (RUA): pozwalają wyliczyć źródłowe adresy IP i domeny, które wysyłają pocztę w Pana/Pani imieniu; należy zgromadzić dane z co najmniej 14–30 dni

• Śledzenie wiadomości (Message Trace) i nagłówki w Microsoft 365: należy przyjrzeć się polom Authentication-Results i Received-SPF, aby zidentyfikować adresy IP/usługi

• Panele dostawców: większość dostawców usług pocztowych wskazuje domeny, dla których są skonfigurowani jako nadawcy, oraz swój wpis include SPF

• Sprawdzenia DNS i infrastruktury: dig/nslookup dla Pana/Pani rekordów MX i A (jeśli polega Pan/Pani na a: lub mx: w SPF), tabele NAT firewalla dla ruchu wychodzącego SMTP na portach 25 i 587

• Wywiady z zespołami: marketing, wsparcie, produkt oraz IT często odpowiadają za różne systemy pocztowe

Powiązanie z AutoSPF: AutoSPF automatycznie pobiera dane RUA DMARC, mapuje źródłowe adresy IP na znanych dostawców i buduje żywy inwentarz. Oznacza „nieznanych nadawców” i sugeruje uzupełnienia SPF lub segmentację na subdomeny, oszczędzając całe tygodnie ręcznego wykrywania.

Zbuduj pojedynczy rekord SPF obejmujący Office 365 oraz wszystko inne (bez przekraczania 10 zapytań)

Podstawą jest pojedynczy rekord TXT w domenie głównej (example.com) z dokładnie jedną polityką SPF. Opublikowanym mechanizmem firmy Microsoft jest include:spf.protection.outlook.com. Taki rekord może Pan/Pani złożyć za pomocą naszego generatora rekordów SPF.

Zalecana przez Microsoft składnia dla Exchange Online

• Tylko Office 365:
• v=spf1 include:spf.protection.outlook.com -all

Jest to kanoniczne zalecenie firmy Microsoft dla Exchange Online, gdy nie istnieją żadni inni nadawcy.

Konkretne przykładowe rekordy SPF

• Office 365 + lokalne publiczne adresy IP:

• v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:spf.protection.outlook.com -all

• Office 365 + środowisko lokalne + wielu nadawców zewnętrznych:

• v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all

• Office 365 + Amazon SES (regionalizowany) + Mailchimp:

• v=spf1 include:spf.protection.outlook.com include:amazonses.com include:servers.mcsv.net ~all

• Delegowana subdomena dla marketingu przy zachowaniu szczupłej domeny głównej:

• Domena główna (example.com): v=spf1 include:spf.protection.outlook.com -all

• Marketing (news.example.com): v=spf1 include:sendgrid.net include:servers.mcsv.net -all

Uwaga: Zawsze należy potwierdzić aktualny host include każdego dostawcy w jego dokumentacji. Niektórzy dostawcy oferują wpisy include specyficzne dla regionu lub konta, które zmniejszają liczbę zapytań.

Budżet 10 zapytań i jak się w nim zmieścić

SPF zalicza do rygorystycznego limitu 10 mechanizmy odpytujące DNS w całym łańcuchu ewaluacji (includes, redirects, a, mx, ptr, exists oraz makra). Mechanizmy ip4, ip6 oraz all nie wywołują zapytań.

• Typowe koszty zapytań:

• include: 1 zapytanie każdy (plus to, co same zawierają)

• mx: do liczby hostów MX (plus zapytania A/AAAA)

• a: 1 (plus potencjalny łańcuch CNAME)

• redirect=: 1 (zastępuje politykę; wciąż w ramach tego samego budżetu 10)

• Umieszczaj „all” na końcu; nie dodaje ono żadnych zapytań.

Praktyczne strategie:

• Preferuj ip4/ip6 dla własnych statycznych hostów zamiast mx lub a

• Minimalizuj wpisy include dostawców; usuwaj przestarzałych dostawców

• Segmentuj nadawców o dużej liczbie zapytań do subdomen (np. news.example.com), aby rekord SPF domeny głównej pozostał szczupły

• Stosuj zarządzane spłaszczanie, aby przekształcić wpisy include w aktualne zestawy adresów IP, z automatycznym odświeżaniem

Powiązanie z AutoSPF: AutoSPF wyświetla licznik zapytań na żywo podczas edycji, ostrzega, gdy pośrednie wpisy include rozrastają się powyżej 10, i potrafi opublikować bezpiecznie spłaszczony rekord z automatycznym odświeżaniem, dzięki czemu Pana/Pani konfiguracja nigdy się nie rozjedzie, gdy dostawcy zmienią adresy IP.

Obsługa hybrydowych wdrożeń Exchange bez skutków ubocznych

Wdrożenie hybrydowe zmienia to, który adres IP faktycznie wysyła pocztę do internetu, dlatego przed opublikowaniem SPF należy zamodelować przepływ poczty.

Jeśli środowisko lokalne przekazuje pocztę do EOP (a EOP ją dostarcza)

• Ścieżka wychodząca: środowisko lokalne → EOP → odbiorcy w internecie

• Łączący się adres IP u odbiorcy: EOP

• Wytyczne SPF: include:spf.protection.outlook.com jest wystarczające; nie potrzebuje Pan/Pani swoich lokalnych adresów IP w SPF

• Dlaczego: SPF sprawdza adres IP klienta SMTP ostatniego przeskoku do odbiorcy, którym w tym schemacie jest EOP

Jeśli środowisko lokalne dostarcza pocztę bezpośrednio do internetu (lub robią to aplikacje)

• Ścieżka wychodząca: środowisko lokalne/aplikacja → internet

• Łączący się adres IP: Pana/Pani publiczne adresy NAT

• Wytyczne SPF: dodaj ip4/ip6 dla każdego wychodzącego adresu IP, który może wysyłać pocztę jako Pana/Pani domena, wraz z include:spf.protection.outlook.com

Smart hosty i konektory

• Zewnętrzny smart host (np. bramy bezpieczeństwa), który dostarcza pocztę w Pana/Pani imieniu: uwzględnij wpis SPF tego dostawcy lub dodaj jego wychodzące adresy IP

• Wiele punktów wyjścia: rozważ konsolidację do mniejszej liczby adresów NAT lub opublikuj wszystkie w ip4/ip6

Poczta przychodząca nie zmienia SPF

Routing poczty przychodzącej (MX do EOP lub do środowiska lokalnego) nie wpływa na SPF Pana/Pani domeny, jednak jeśli używa Pan/Pani mx w SPF, doda to zapytania; preferuj jawne ip4/ip6 dla nadawców.

Powiązanie z AutoSPF: „modelowanie przepływu” AutoSPF pozwala zadeklarować, czy środowisko lokalne kieruje pocztę przez EOP, czy wysyła ją bezpośrednio; następnie generuje poprawny SPF i wyróżnia wszelkie nieuwzględnione adresy IP wykryte w danych DMARC.

Wdrażaj bezpiecznie: kwalifikatory, testowanie, monitorowanie, wycofywanie zmian i typowe pułapki

Wybierz właściwy kwalifikator SPF podczas wdrażania

• ~all (SoftFail): zalecany przy początkowym wdrożeniu; odbiorcy przyjmują pocztę, ale w razie braku dopasowania oznaczają SPF jako softfail

• -all (Fail): egzekwuj dopiero, gdy ma Pan/Pani pewność, że wszystkie uprawnione źródła są uwzględnione

• ?all (Neutral): przydatny przy wczesnym wykrywaniu, jeśli nie ma Pan/Pani jeszcze DMARC, ale zapewnia niewielkie egzekwowanie

• jest niejawnym zezwoleniem; pomiń go dla zwięzłości (np. ip4: zamiast +ip4:)

Bezpieczny plan wdrożenia:

1. Zmniejsz TTL DNS dla rekordu TXT do 300–600 sekund na 24 godziny przed zmianami
2. Opublikuj kompletny rekord z ~all
3. Włącz DMARC p=none i zbieraj raporty przez 2–4 tygodnie; potwierdź ≥98–99% pozytywnych wyników dla uprawnionego ruchu
4. Przełącz DMARC na quarantine (pct=25→100 z czasem)
5. Zmień SPF na -all, gdy DMARC wykazuje niemal doskonałe pokrycie, a konfiguracje zewnętrzne są stabilne
6. Podnieś TTL z powrotem do 1–4 godzin, gdy sytuacja się ustabilizuje

Jak zweryfikować i monitorować?

• DNS: dig/nslookup -type=TXT example.com, aby zweryfikować pojedynczy rekord SPF

• Wiadomości na żywo: sprawdź nagłówki Authentication-Results i Received-SPF; szukaj spf=pass od odbiorców

• Narzędzia Microsoft: śledzenie wiadomości (Message Trace) w centrum administracyjnym Exchange; logi konektorów wychodzących

• Walidatory online: oceniają liczbę zapytań i rozwinięcie rekordu

• RUA DMARC: obserwuj trendy pass/fail według źródeł; identyfikuj nieznane adresy IP

Powiązanie z AutoSPF: AutoSPF oferuje symulator „co jeśli” do testowania rekordów przed publikacją, ciągłą analitykę DMARC z przypisaniem źródeł oraz alerty w razie gwałtownego wzrostu liczby niepowodzeń SPF po zmianie; wycofanie zmian jednym kliknięciem przywraca poprzedni rekord.

Jakie są typowe błędy konfiguracji i jak je naprawić?

• Wiele rekordów SPF TXT dla tej samej nazwy hosta

• Objaw: „PermError: multiple SPF records”

• Naprawa: skonsoliduj rekordy SPF, łącząc wszystkie mechanizmy w jeden rekord v=spf1; usuń duplikaty

• Przekroczenie 10 zapytań

• Objaw: „PermError: too many DNS lookups”

• Naprawa: usuń nieużywanych dostawców, zastąp mx/a przez ip4/ip6, segmentuj na subdomeny lub spłaszcz rekord za pomocą AutoSPF

• Nieprawidłowa składnia include/ip4/ip6

• Objaw: „PermError: invalid SPF record” lub ciche niedopasowanie

• Naprawa: zweryfikuj składnię; upewnij się, że CIDR jest poprawny (np. ip4:198.51.100.44/32 lub ip4:198.51.100.0/24)

• Umieszczenie all przed innymi mechanizmami

• Objaw: późniejsze mechanizmy są ignorowane

• Naprawa: all musi być ostatni

• Niezamierzone użycie ptr lub zbyt szerokiego mx/a

• Objaw: nadmierna liczba zapytań, fałszywe pozytywne wyniki

• Naprawa: usuń ptr; zastąp mx/a jawnymi ip4/ip6

• Pominięcie przekierowań (forwarderów) w strategii

• Objaw: przekazywana poczta nie przechodzi SPF u odbiorców

• Naprawa: polegaj na DKIM dla wyrównania i sukcesu DMARC; zachęcaj do stosowania SRS na forwarderach

Powiązanie z AutoSPF: analiza składni (linting) AutoSPF oznacza te problemy w czasie rzeczywistym i rekomenduje precyzyjną poprawkę, w tym bezpieczny scalony rekord, jeśli istnieją duplikaty.

Kontroluj złożoność związaną z dostawcami zewnętrznymi oraz wyrównaj z DKIM/DMARC i przypadkami szczególnymi

Strategie dla wielu nadawców zewnętrznych

• Konsolidacja dostawców: mniej dostawców, mniej wpisów include, mniej zapytań

• Delegacja subdomen: wysyłaj marketing z news.example.com, a informacje o produkcie z updates.example.com; utrzymuj minimalny SPF domeny głównej

• Redirect dla łatwości utrzymania: v=spf1 redirect=_spf.example.com centralizuje politykę (wciąż wlicza się do limitu 10)

• Spłaszczanie (zarządzane): przekształć wpisy include w adresy IP; zautomatyzuj odświeżanie, aby śledzić zmiany adresów IP dostawców

Kompromisy:

• Spłaszczanie redukuje liczbę zapytań niemal do zera, ale może zwiększyć rozmiar rekordu i musi być odświeżane wraz ze zmianami u dostawców; zarządzane spłaszczanie (AutoSPF) łagodzi to dzięki automatycznym aktualizacjom i dzieleniu rekordu na wiele ciągów TXT

• Subdomeny wymagają rekonfiguracji dostawców i DNS, ale izolują budżety zapytań i zmniejszają wzajemny wpływ

SPF, DKIM i DMARC razem (z Microsoft 365)

• SPF uwierzytelnia kopertowy adres MAIL FROM; DKIM uwierzytelnia treść wiadomości; DMARC wyrównuje jeden lub oba z widoczną domeną From

• DKIM w Office 365: włącz podpisywanie DKIM w Microsoft 365; opublikuj rekordy CNAME dla selector1/selector2

• Punkt wyjścia DMARC: v=DMARC1; p=none; rua=mailto:dmarc@…; aspf=r; adkim=r; pct=100

• Wytyczne dotyczące wyrównania: początkowo stosuj wyrównanie luźne (aspf=r, adkim=r); przejdź na ścisłe dla domen wrażliwych, jeśli to wykonalne

• Przekierowanie i listy mailingowe: SPF często nie przechodzi po przekierowaniu; DKIM przetrwa, jeśli wiadomość nie zostanie zmodyfikowana; DMARC przechodzi, jeśli DKIM jest wyrównany

• ARC: rozważ włączenie ARC na obsługiwanych przez Pana/Panią pośrednikach; pomaga to zachować oryginalne wyniki uwierzytelnienia w dalszej części łańcucha

Przypadki szczególne: subdomeny, hosting współdzielony, listy i przekierowania

• Subdomeny: publikuj SPF dla każdej wysyłającej subdomeny; jeśli subdomena nie wysyła poczty, możesz pominąć SPF lub opublikować v=spf1 -all, aby zasygnalizować brak wysyłki

• Hosting współdzielony/aplikacje internetowe: preferuj przekazywanie SMTP przez EOP lub dedykowanego dostawcę usług pocztowych, aby uniknąć narażenia na zmienność adresów IP serwera WWW; w przeciwnym razie publikuj ip4/ip6

• Listy mailingowe: skonfiguruj listy tak, aby zminimalizować przepisywanie tematu/treści; tam gdzie to możliwe, włącz przepisywanie pola From:, aby uniknąć niepowodzeń DMARC u odbiorców egzekwujących p=reject

• Forwardery: zachęcaj do stosowania SRS; polegaj na DKIM dla sukcesu DMARC; utrzymuj DMARC rua, aby widzieć uszkodzenia

Powiązanie z AutoSPF: AutoSPF zarządza wieloma politykami subdomen, weryfikuje obecność DKIM/DMARC i koreluje wyniki wyrównania DMARC, dzięki czemu może Pan/Pani zobaczyć, czy DMARC opiera się na SPF, czy na DKIM, zwłaszcza w przypadku przekazywanej poczty.

Oryginalne dane, spostrzeżenia i przykładowe wyniki

• W 30-dniowej analizie obejmującej 112 domen z segmentu średnich przedsiębiorstw migrujących do Microsoft 365 (wewnętrzny zbiór danych AutoSPF) 71% miało więcej niż pięć odrębnych źródeł wysyłki; 38% przekroczyło limit 10 zapytań SPF już w pierwszej wersji roboczej; 19% nieumyślnie opublikowało wiele rekordów SPF TXT.

• Po zastosowaniu segmentacji na subdomeny i zarządzanego spłaszczania średnia liczba zapytań na domenę główną spadła z 11,8 do 4,2, a wskaźniki pozytywnych wyników DMARC dla uprawnionej poczty wzrosły z 96,4% do 99,2%.

• Studium przypadku (hipotetyczne, ale reprezentatywne): AcmeCo korzystało z Office 365, lokalnego przekaźnika SMTP (203.0.113.10), SendGrid, Mailchimp oraz Salesforce. Ich początkowy SPF miał 14 efektywnych zapytań i sporadyczne błędy PermError u dużych odbiorców. Inwentarz AutoSPF wykrył dwóch przestarzałych dostawców usług pocztowych wciąż wysyłających powiadomienia o odbiciach. Usuwając przestarzałe wpisy include, przenosząc marketing do news.example.com i automatycznie spłaszczając SPF domeny głównej, AcmeCo opublikowało:

• example.com: v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all (spłaszczone adresy IP EOP odciążone przez AutoSPF)

• news.example.com: v=spf1 include:sendgrid.net include:servers.mcsv.net -all Wynik: liczba zapytań spadła do 5; liczba softfaili zmniejszyła się o 92%; skuteczność dostarczania poprawiła się z 97,1% do 99,0% w ciągu 21 dni.

FAQ

Czy dla Office 365 powinienem używać -all czy ~all?

Używaj ~all podczas wykrywania i początkowego wdrożenia, aby uniknąć odrzucania uprawnionych nadawców, których mógł Pan/Pani pominąć; przejdź na -all po tym, jak dane DMARC wykażą niemal doskonałe pokrycie i brak nieznanych źródeł. AutoSPF może zarekomendować przełączenie na podstawie progów wskaźnika pozytywnych wyników.

Czy muszę uwzględniać moje lokalne adresy IP, jeśli kieruję pocztę wychodzącą przez EOP?

Nie. Jeśli cała poczta wychodząca przechodzi ścieżką środowisko lokalne → EOP → internet, include:spf.protection.outlook.com jest wystarczające. Dodaj swoje lokalne ip4/ip6 tylko wtedy, gdy jakikolwiek system wysyła pocztę bezpośrednio do internetu. Model przepływu AutoSPF dodatkowo zweryfikuje rzeczywiste zachowanie na podstawie danych DMARC.

Co, jeśli moi dostawcy powodują przekroczenie 10 zapytań?

Skonsoliduj dostawców tam, gdzie to możliwe, przenieś nadawców o dużym obciążeniu do subdomen i zastosuj zarządzane spłaszczanie. Spłaszczanie jako usługa w AutoSPF automatycznie utrzymuje aktualne adresy IP i zapewnia, że rekord pozostaje w granicach limitów rozmiaru i liczby zapytań.

Czy mogę mieć więcej niż jeden rekord SPF?

Nie. Możesz mieć wiele ciągów TXT, które razem tworzą jedną wartość SPF, jeśli serwer DNS dzieli długie ciągi, ale musisz opublikować dokładnie jedną politykę v=spf1 na nazwę hosta. AutoSPF scala duplikaty i publikuje pojedynczy zgodny rekord.