Jak skonfigurować SPF, DKIM i DMARC w Cloudflare

Jeśli próbujesz nauczyć się, jak skonfigurować SPF, DKIM i DMARC w Cloudflare, zacznij od jednej prostej prawdy: Cloudflare przechowuje rekordy DNS, ale twój dostawca poczty dostarcza wartości. To brzmi mało. To nie jest małe.

Cloudflare to miejsce, w którym znajdują się rekordy, co oznacza, że będziesz edytować wpisy TXT lub CNAME w jego panelu DNS. Rzeczywisty ciąg dołączenia SPF, selektor DKIM, klucz publiczny i polityka DMARC pochodzą z usługi, która wysyła twoją pocztę, niezależnie od tego, czy jest to Google Workspace, Microsoft 365, SendGrid, Mailgun, czy inna platforma. Bez tych wartości zgadujesz.

1. Potwierdź, co Cloudflare może, a czego nie może zrobić w zakresie uwierzytelniania poczty elektronicznej

Cloudflare nie wymyśla wartości SPF, DKIM ani DMARC. Tylko je publikuje. Jeśli twój dostawca mówi, aby dodać rekord TXT dla SPF, Cloudflare może go hostować. Jeśli dostawca daje ci selektor DKIM i cel CNAME, Cloudflare może to również hostować. Ale nie może zdecydować, które serwery mogą wysyłać pocztę w twoim imieniu.

To ma znaczenie, ponieważ ludzie często otwierają Cloudflare jako pierwsze i szukają magicznego przycisku. Nie ma takiego. Musisz mieć dokładną treść rekordu od swojego nadawcy, zanim dotkniesz DNS, w przeciwnym razie ryzykujesz opublikowanie rekordu, który przechodzi kontrolę w panelu, ale nie działa w prawdziwej skrzynce pocztowej.

2. Zbierz wartości DNS z platformy wysyłającej e-maile

Zanim cokolwiek edytujesz, zbierz trzy rzeczy z dokumentacji dostawcy. Po pierwsze, zbierz mechanizmy dołączenia SPF i wszelkie adresy IP, które usługa chce mieć w twoim rekordzie SPF. Po drugie, zbierz nazwy selektorów DKIM i dane klucza publicznego, lub cele CNAME, jeśli dostawca używa DKIM opartych na CNAME. Po trzecie, zbierz ciąg polityki DMARC, w tym politykę, od której planujesz zacząć, oraz wszelkie tagi raportowania.

Zapisz wartości w jednym miejscu. Użyj dokładnych nazw selektorów. Jeśli twój dostawca daje ci dwa selektory, nie zmieniaj ich nazw, ponieważ wyglądają niechlujnie. Jeśli dokumentacja mówi, że rekord powinien być `_spf.example.net`, trzymaj się tego. Małe błędy w formatowaniu powodują długie popołudnia.

Jest tu przydatny nawyk: uchwyć nazwę nadawcy, nazwę hosta, typ rekordu i ciąg docelowy w jednej tabeli, zanim zalogujesz się do Cloudflare. To przyspiesza fazę edytowania i zapobiega powszechnemu błędowi wklejania właściwej wartości do niewłaściwego pola nazwy.

3. Dodaj rekord SPF w DNS Cloudflare

W Cloudflare otwórz DNS i utwórz lub edytuj rekord TXT w korzeniu domeny, jeśli twój dostawca wysyła pocztę z samej domeny. Niektóre usługi używają zamiast tego subdomeny, takiej jak `mail.example.com`, więc użyj nazwy hosta, którą określa twój dostawca, a nie tej, którą zakładasz. Jeden hostname. Jeden rekord.

Rekord SPF powinien zazwyczaj istnieć tylko raz dla jednej nazwy hosta. To jest punkt, który ludzie pomijają. Jeśli już masz rekord SPF TXT, nie twórz drugiego rekordu SPF TXT obok niego. Połącz autoryzowanych nadawców w jeden ciąg, aby serwer odbierający widział jedną politykę, a nie dwie konkurujące odpowiedzi.

Typowa wartość SPF zawiera mechanizmy takie jak `include:` lub `ip4:`. Jeśli Twoja usługa doda drugiego nadawcę później, zaktualizuj istniejący rekord zamiast dodawać nowy. Duplikat rekordu SPF może spowodować błąd permerror, co oznacza, że systemy odbierające mogą traktować sprawdzenie jako nieudane, nawet jeśli poszczególne części wyglądają poprawnie.

Użyj nazwy rekordu, którą podaje Twój dostawca. Dla głównej domeny, Cloudflare często pokazuje `@` jako pole nazwy. Dla subdomeny wprowadź dokładnie tę etykietę. Nie dodawaj cudzysłowów wokół wartości, chyba że Twój dostawca wyraźnie Ci to zaleci. Cloudflare przechowuje tekst jako zwykłą treść DNS.

4. Opublikuj rekordy DKIM TXT lub CNAME w Cloudflare

DKIM to miejsce, w którym selektor ma znaczenie. Dostawca może dać ci rekord TXT, taki jak `selector1._domainkey` z długim kluczem publicznym, lub może dać rekord CNAME, który wskazuje na inną nazwę hosta. Cloudflare obsługuje oba, ale typ musi odpowiadać temu, co mówi dostawca. Wartość TXT w polu CNAME nie pomoże ci.

Wiele usług używa dwóch selektorów. To normalne. Google Workspace często używa dwóch kluczy podczas rotacji, a inni dostawcy robią coś podobnego, aby jeden klucz mógł być zastąpiony bez przerywania dostarczania. Jeśli nadawca podaje ci `s1` i `s2`, opublikuj oba rekordy. Jeśli drugi nadawca używa innej rodziny selektorów, trzymaj te rekordy oddzielnie. Nazwy mogą wyglądać powtarzalnie; rekordy nie są redundantne.

Wprowadź nazwę hosta DKIM dokładnie tak, jak podano. Jeśli dostawca mówi, aby utworzyć `selector1._domainkey.example.com`, użyj tej pełnej etykiety w Cloudflare. Jeśli dostawca podaje cel CNAME, wklej miejsce docelowe dokładnie tak, jak napisano. Cloudflare nie potrzebuje tłumaczenia. Potrzebuje dokładności.

Dla zespołów śledzących DKIM SPF DMARC konfigurację dla transakcyjnych, ta sama zasada ma zastosowanie, nawet gdy wolumen maili jest mały: selektor w DNS musi odpowiadać selektorowi w nagłówku wiadomości. Jeśli się różnią, DKIM zawodzi. Bez dramatu, po prostu porażka.

5. Utwórz rekord DMARC na _dmarc

DMARC należy umieścić na `_dmarc.yourdomain.com`. W Cloudflare utwórz rekord TXT o tej dokładnej nazwie. Wartość zaczyna się od `v=DMARC1`, a następnie dodaje twoją politykę i opcjonalne tagi. Typową polityką początkową jest `p=none`, ponieważ pozwala ci zbierać raporty, zanim zablokujesz cokolwiek. To najmniej agresywny punkt wyjścia.

Jeśli twoja organizacja jest gotowa na otrzymywanie raportów, dodaj tag `rua` z adresem do raportów zbiorczych i, jeśli to konieczne, tag `ruf` dla raportów kryminalistycznych. Użyj adresu, który ktoś faktycznie monitoruje. Martwa skrzynka pocztowa to nie strategia. To pułapka.

Jedna praktyczna zasada pomaga tutaj: zacznij od polityki DMARC, która odpowiada twojej obecnej tolerancji na fałszywe pozytywy, a następnie zaostrz ją później, gdy wiesz, że legalni nadawcy są zgodni. Jeśli posuniesz się za szybko, możesz zablokować faktury, powiadomienia lub resetowanie haseł. To zostanie natychmiast zauważone.

Cloudflare przechowa rekord DMARC TXT jak każdy inny wpis tekstowy, ale szczegóły mają znaczenie. Nazwa rekordu musi być `_dmarc`, nie `dmarc`, nie `_dmarc1`, i nie główną domeną. Ciąg polityki musi odpowiadać składni, której oczekuje twój dostawca. Jeśli twoja platforma pocztowa sugeruje tagi takie jak `sp`, `adkim` lub `aspf`, dodawaj je tylko wtedy, gdy rozumiesz ich wpływ.

6. Sprawdź ustawienia DNS specyficzne dla Cloudflare, które mogą blokować walidację

Cloudflare ma jedno ustawienie, które powoduje więcej zamieszania, niż powinno: proxy. Rekordy uwierzytelniania e-maili nie powinny być proxy. SPF, DKIM i DMARC znajdują się w DNS, a nie za pomarańczową chmurką. Jeśli przypadkowo proxy'ujesz nazwę hosta związaną z pocztą, mieszasz zasady ruchu internetowego z rekordami DNS e-maili.

Nazwy rekordów to kolejny powszechny punkt awarii. Selektor DKIM, który powinien być `selector1._domainkey`, może być wpisany jako `selector1._domainkey.` z przypadkową kropką lub jako `selector1 domainkey` z przestrzenią skopiowaną z strony dostawcy. Cloudflare akceptuje wiele wpisów DNS, ale systemy odbierające są mniej wyrozumiałe niż interfejs.

Starsze rekordy mogą również zakłócać. Jeśli stary rekord SPF TXT pozostaje obok nowego, lub jeśli przestarzały rekord DKIM CNAME nadal wskazuje na wycofaną usługę, walidacja może nie powieść się w sposób, który wydaje się losowy. Usuń martwy wpis dopiero po potwierdzeniu, że nie jest już potrzebny. To utrzymuje aktywnego nadawcę w nienaruszonym stanie.

Jeśli pracujesz również nad ustawieniem uwierzytelniania e-mail dla e-maili transakcyjnych, to jest moment, aby sprawdzić każdego hosta wysyłającego wymienionego przez dostawcę. Zapomniana subdomena może spowodować, że wiadomość wsparcia przejdzie, podczas gdy wiadomość potwierdzająca nie, a takie rozdzielone zachowanie jest trudne do zauważenia, dopóki klient nie zgłosi reklamacji.

7. Zweryfikuj propagację i uwierzytelnianie poczty z DNS zarządzanym przez Cloudflare

Po zapisaniu rekordów, poczekaj na propagację DNS. Dokładny czas zależy od twojego TTL i pamięci podręcznej resolvera przed tobą, więc nie zakładaj, że rekord jest widoczny wszędzie w momencie, gdy Cloudflare mówi, że został zapisany. Sprawdź zewnętrznie za pomocą narzędzia do wyszukiwania DNS i potwierdź, że każda nazwa rekordu zwraca oczekiwaną wartość.

Następnie wyślij prawdziwą wiadomość testową z usługi, która korzysta z rekordów. Nie testuj z losowej skrzynki odbiorczej, która omija twój normalny przepływ poczty. Otwórz nagłówki wiadomości w odbierającej skrzynce pocztowej i szukaj SPF pass, DKIM pass i DMARC alignment pass. Wiadomość może nadal trafić do spamu z innych powodów, ale wynik uwierzytelnienia powinien powiedzieć ci, czy strona DNS jest poprawna.

Jedno szybkie sprawdzenie wystarczy na pierwszy raz, ale drugie sprawdzenie z innej skrzynki pocztowej daje lepszy sygnał. Test Gmail i test Microsoft 365 mogą zachowywać się różnie, jeśli jeden resolver widzi stary rekord przez chwilę, podczas gdy inny widzi nowy. To nie jest rzadkie. To się zdarza.

Jeśli dostarczalność jest częścią tego samego projektu, połącz tę pracę z najlepszymi praktykami dostarczalności e-mail. Uwierzytelnienie to nie cała historia, ale to część, która pozwala odbiorcom zdecydować, czy twoja domena mówi sama za siebie.

8. Zaktualizuj rekordy, gdy twój dostawca poczty się zmienia

Ustawienia poczty się zmieniają. Dostawca rotuje klucze DKIM, dodawana jest platforma marketingowa lub usługa transakcyjna jest przenoszona po migracji. Gdy to się zdarzy, zaktualizuj rekordy DNS w Cloudflare przed przełączeniem ruchu, a nie po. Taka kolejność oszczędza ci dzień z uszkodzonymi podpisami.

Rotacja DKIM jest zazwyczaj najczystszą zmianą. Dostawca daje ci nowy selektor i klucz, publikujesz go w Cloudflare i czekasz, aż nowy selektor zostanie zweryfikowany, zanim wycofasz stary. Utrzymuj oba aktywne podczas przejścia, jeśli dostawca to wspiera. Dwa selektory są łatwiejsze niż jedna awaria.

Zmiany SPF są nieco bardziej delikatne, ponieważ rekord musi pozostać poniżej limitów rozmiaru TXT DNS i wyszukiwania ustalonych przez standard SPF. Jeśli nowy nadawca dołącza do stosu, dodaj jego mechanizm include do istniejącego rekordu SPF zamiast dodawać kolejny rekord obok niego. Jeśli jesteś blisko limitu wyszukiwania, zredukuj zbędne includes tam, gdzie to możliwe, i potwierdź aktualne wytyczne dostawcy.

Dla zespołów, które korzystają z wielu usług, zarządzanie jest łatwiejsze, jeśli jedna osoba odpowiada za listę autoryzowanych nadawców. Lista ta powinna zawierać nazwę usługi, nazwę hosta, selektor DKIM oraz datę ostatniej zmiany. Prosta tabela utrzymuje edycje Cloudflare w spójności, a spójność jest ważniejsza niż pomysłowość.

Jeśli obsługa odbić i zmiany nadawcy są częścią tego samego projektu skrzynki pocztowej, ta sama dyscyplina pomaga w najlepszych praktykach obsługi odbić e-mailowych. Migracja dostawcy może zmienić zarówno uwierzytelnianie, jak i zachowanie błędów w tym samym dniu, a żadna ze stron nie powinna być zgadywana.

Cloudflare upraszcza część publikacyjną, ale rekordy wciąż wymagają dyscypliny. Jeden nadawca. Jeden rekord SPF. Każdy selektor DKIM we właściwym miejscu. Jeden rekord DMARC w `_dmarc`. Jeśli utrzymasz te cztery punkty w porządku, reszta to głównie cierpliwość, kilka sprawdzeń nagłówków i chęć aktualizacji DNS przed nadejściem kolejnej zmiany platformy.