Uwierzytelnianie domeny w SendGrid sprawia, że Twoje wiadomości przechodzą kontrole SPF i DKIM, ponieważ każe Ci opublikować trzy rekordy CNAME na delegowanej subdomenie w rodzaju em1234.yourdomain.com. SendGrid podpisuje każdą wiadomość kluczem DKIM, który jest wyrównany do Twojej domeny głównej, a ścieżkę Return-Path kieruje przez tę subdomenę, dzięki czemu SPF przechodzi właśnie tam, a nie na Twoim rekordzie głównym. Czego SendGrid nie robi, to nie tworzy rekordu DMARC - dlatego uwierzytelnianie jest gotowe tylko w połowie, dopóki sam go nie dodasz.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Ten przewodnik rozszyfrowuje model delegowanej subdomeny em1234, porównuje zabezpieczenia automatyczne (SendGrid zarządza rekordami ukrytymi za CNAME) z trybem ręcznym (samodzielnie wklejasz surowe rekordy TXT) oraz wyjaśnia, dlaczego delegowana subdomena pozostawia Twój główny rekord SPF nietknięty. Następnie krok po kroku pokazuje, jak dodać prawdziwą politykę DMARC i potwierdzić, że rekordy CNAME poprawnie się rozwiązują.
Co SendGrid faktycznie każe Ci opublikować
Gdy uruchamiasz uwierzytelnianie domeny w panelu SendGrid (Settings, a następnie Sender Authentication), generuje on niewielki zestaw rekordów CNAME. Przy domyślnie włączonych zabezpieczeniach automatycznych otrzymujesz coś zbliżonego do tego:
em1234.yourdomain.com CNAME u1234.wl.sendgrid.net
s1._domainkey.yourdomain.com CNAME s1.domainkey.u1234.wl.sendgrid.net
s2._domainkey.yourdomain.com CNAME s2.domainkey.u1234.wl.sendgrid.net
Numery są unikalne dla Twojego konta, więc traktuj 1234 jako symbol zastępczy i skopiuj dokładne wartości z własnej konsoli. Trzy rekordy pełnią trzy zadania. Rekord em1234 to markowa subdomena wysyłkowa, która staje się Twoją ścieżką Return-Path, czyli miejscem, w którym oceniany jest SPF. Dwa rekordy selektorów s1 i s2 odpowiadają za DKIM. SendGrid używa dwóch selektorów, aby móc rotować między nimi klucze podpisujące bez przerwy w działaniu.
Jeśli włączysz również Link Branding, otrzymasz jeszcze jeden lub dwa rekordy CNAME (często url1234 i 1234), które przepisują linki śledzące kliknięcia tak, aby wskazywały na Twoją domenę zamiast na sendgrid.net. To poprawa dostarczalności i zaufania, a nie wymóg uwierzytelniania, ale warto to zrobić przy tej samej okazji.
Dlaczego delegowana subdomena pozostawia główny rekord SPF w spokoju
To część, która myli osoby przyzwyczajone do innych dostawców wysyłki. Nie dodajesz include:sendgrid.net do rekordu SPF swojej domeny głównej. W ogóle nie ruszasz głównego rekordu SPF.
Oto mechanizm. Każda wiadomość wysyłana przez SendGrid używa nadawcy koperty (Return-Path, nazywanego też MAIL FROM) na subdomenie em1234.yourdomain.com, a nie na Twojej domenie głównej. SPF zawsze sprawdzany jest względem domeny nadawcy koperty, więc odbiorcy wyszukują SPF dla em1234.yourdomain.com. Ponieważ ta nazwa jest rekordem CNAME wskazującym na SendGrid, wyszukiwanie podąża dalej do własnego rekordu SPF firmy SendGrid, który wymienia jej adresy IP wysyłkowe i kończy się twardym lub miękkim odrzuceniem. SPF przechodzi na subdomenie, a Twój główny rekord v=spf1 w ogóle nie jest w to zaangażowany.
Ten projekt ma realną zaletę: utrzymuje zakresy IP firmy SendGrid poza Twoim głównym rekordem SPF, więc nie może on pchnąć Cię w stronę limitu dziesięciu wyszukiwań, który psuje tak wiele rekordów. Jeśli kiedykolwiek musiałeś naprawić rekord SPF z nadmiarem wyszukiwań DNS, docenisz, że model SendGrid całkowicie omija ten problem. Twój główny rekord SPF nadal reguluje pocztę wysyłaną z Twoich własnych serwerów i innych dostawców, a poczta z SendGrid uwierzytelnia się na własnej subdomenie.
Jak wyrównanie i tak przechodzi dla DMARC
DMARC nie chce jedynie, żeby SPF albo DKIM przeszły. Chce, żeby przynajmniej jedno z nich przeszło i było wyrównane z domeną w widocznym nagłówku From. SendGrid daje Ci dwie wyrównane ścieżki.
DKIM podpisuje się jako d=yourdomain.com (Twoja domena główna), więc DKIM wyrównuje się bezpośrednio. SPF uwierzytelnia się na em1234.yourdomain.com, która jest subdomeną Twojej domeny głównej, więc przy wyrównaniu złagodzonym (domyślnym dla DMARC) domeny organizacyjne pasują do siebie i SPF również się wyrównuje. Otrzymujesz zarówno przechodzący, wyrównany podpis DKIM, jak i przechodzący, wyrównany wynik SPF. Jeśli chcesz w pełni zrozumieć, jak te elementy współdziałają, zajrzyj do SPF, DKIM i DMARC wyjaśnione oraz do pogłębionej analizy naprawy wyrównania DKIM.
Zabezpieczenia automatyczne kontra tryb ręczny: co naprawdę się różni
Podczas konfiguracji SendGrid prezentuje przełącznik o nazwie Automated Security, który zmienia to, co publikujesz.
Zabezpieczenia automatyczne WŁĄCZONE (CNAME, domyślnie)
Publikujesz rekordy CNAME wskazujące na SendGrid. Właściwe klucze publiczne DKIM i wartości SPF znajdują się po stronie SendGrid, za tymi rekordami CNAME. Zaletą jest rotacja kluczy: SendGrid może wycofać stary klucz DKIM i uruchomić nowy na selektorze s1 lub s2 bez proszenia Cię o edycję DNS. Twoje rekordy nadal wskazują na ten sam cel CNAME, a wartość, na którą się rozwiązują, zmienia się w tle. Dla niemal wszystkich to właściwy wybór. To ten sam tok rozumowania, który stoi za preferowaniem DKIM jako CNAME zamiast rekordu TXT przy dostawcach hostowanych.
Zabezpieczenia automatyczne WYŁĄCZONE (ręczny TXT)
Zamiast tego publikujesz surowe rekordy TXT: rekord SPF w formacie TXT na subdomenie pocztowej oraz pojedynczy rekord TXT z kluczem publicznym DKIM, który należy w całości do Ciebie. Nic nie rozwiązuje się przez SendGrid, więc widzisz dokładne wartości. Kosztem jest to, że każda przyszła rotacja klucza DKIM staje się ręczną zmianą DNS, którą musisz wykonać, a jeśli SendGrid dokona rotacji według swojego harmonogramu, a Ty nie zaktualizujesz rekordu TXT, podpisy zaczną zawodzić. Wybierz tryb ręczny tylko wtedy, gdy Twój dostawca DNS nie potrafi utworzyć rekordów CNAME na tych nazwach hostów lub gdy polityka bezpieczeństwa zabrania delegowania zawartości rekordu stronie trzeciej.
Tak czy inaczej, wynikowe uwierzytelnianie jest równoważne, gdy zostanie poprawnie opublikowane. Różnica polega wyłącznie na tym, kto z czasem utrzymuje materiał klucza.
Dodaj rekord DMARC, którego SendGrid nie utworzy
SendGrid uwierzytelnia Twoją pocztę, ale nie publikuje polityki DMARC, a to właśnie DMARC faktycznie mówi odbiorcom, co zrobić z pocztą, która nie przejdzie kontroli. Bez niego nie masz żadnej polityki, żadnego raportowania ani żadnej ochrony przed podszywaniem się. Google i Yahoo wymagają teraz rekordu DMARC od nadawców masowych, więc jeśli wysyłasz duże wolumeny, nie jest to opcjonalne. Aktualne progi znajdziesz w wymaganiach nadawców Google i Yahoo.
Zacznij w trybie monitorowania, aby móc obserwować raporty, zanim zaczniesz cokolwiek egzekwować:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r"
p=none zbiera dane bez wpływu na dostarczanie. Adres rua odbiera codzienne raporty zbiorcze, dzięki czemu możesz potwierdzić, że poczta z SendGrid się wyrównuje, zanim zaostrzysz politykę. Znaczniki złagodzonego wyrównania (adkim=r, aspf=r) pasują do tego, jak wyrównuje się model subdomeny SendGrid, więc pozostaw je złagodzone. Gdy raporty pokażą, że SendGrid i Twoje inne prawidłowe źródła przechodzą kontrole, przejdź do p=quarantine, a następnie do p=reject. Pełną progresję opisano w jak skonfigurować DMARC oraz przejście DMARC od none do reject.
Potwierdź, że rekordy CNAME się rozwiązują, zanim zaczniesz wysyłać
Zmiany DNS oraz własna weryfikacja SendGrid mogą opóźniać się od kilku minut do całej doby, w zależności od TTL Twojego dostawcy. Nie ufaj samemu zielonemu znaczkowi. Przepuść swoją domenę przez skaner powyżej, aby potwierdzić, że selektory DKIM są aktywne, a DMARC jest obecny, i sprawdź rekordy CNAME z wiersza poleceń:
dig +short s1._domainkey.yourdomain.com CNAME
Poprawny wynik zwraca cel s1.domainkey.u1234.wl.sendgrid.net. Powtórz dla s2._domainkey oraz dla em1234. Częste tryby awarii: host DNS, który po cichu dokleja Twoją domenę do już w pełni kwalifikowanego celu (dając ...sendgrid.net.yourdomain.com), albo serwer proxy lub CDN, który spłaszcza lub ukrywa rekord CNAME. Jeśli narzędzie sprawdzające pokaże przechodzący DKIM i obecny DMARC, wyślij jedną wiadomość testową i przeczytaj nagłówek Authentication-Results, aby potwierdzić zarówno dkim=pass, jak i spf=pass z Twoją domeną główną w wyrównaniu.
Najczęściej zadawane pytania
Czy muszę dodać include:sendgrid.net do mojego rekordu SPF?
Nie. Przy standardowym uwierzytelnianiu domeny SendGrid używa ścieżki Return-Path na Twojej subdomenie em1234, a SPF jest oceniany właśnie tam, poprzez rekord CNAME. Twój główny rekord SPF pozostaje nietknięty, co również trzyma Cię z dala od limitu dziesięciu wyszukiwań. Dodaj include SendGrid tylko wtedy, gdy celowo skonfigurowałeś niestandardowe ustawienie, które wysyła z domeny koperty Twojej domeny głównej.
Jaka jest różnica między selektorami DKIM s1 i s2?
To dwa klucze podpisujące DKIM. SendGrid używa pary, aby móc rotować jeden klucz, podczas gdy drugi pozostaje aktywny, unikając okna, w którym poczta jest niepodpisana. Przy włączonych zabezpieczeniach automatycznych ta rotacja odbywa się za rekordami CNAME bez żadnej zmiany DNS po Twojej stronie. Oba selektory muszą się rozwiązywać, aby uwierzytelnianie pozostało sprawne.
Czy SendGrid konfiguruje DMARC za mnie?
Nie. SendGrid obsługuje SPF i DKIM za pośrednictwem rekordów CNAME, ale nigdy nie publikuje rekordu DMARC. Musisz sam dodać _dmarc.yourdomain.com. Zacznij od p=none, aby zebrać raporty, potwierdź, że poczta z SendGrid się wyrównuje, a następnie przejdź do quarantine i reject.
Czy powinienem używać zabezpieczeń automatycznych, czy trybu ręcznego?
Używaj zabezpieczeń automatycznych (opcja CNAME), chyba że Twój dostawca DNS nie potrafi utworzyć tych nazw hostów CNAME lub polityka zabrania delegowania wartości rekordów. Zabezpieczenia automatyczne pozwalają SendGrid rotować klucze DKIM bez edytowania przez Ciebie DNS. Tryb ręczny TXT daje Ci pełną własność materiału klucza, ale sprawia, że każda przyszła rotacja jest ręcznym zadaniem, o którym nie możesz zapomnieć.