Aby skonfigurować uwierzytelnianie poczty w AWS Route 53, tworzysz w swojej strefie hostowanej trzy typy rekordów: rekord TXT dla SPF w korzeniu strefy, rekordy CNAME dla DKIM (Amazon SES publikuje je za Ciebie, gdy domena jest hostowana w Route 53) oraz rekord TXT dla DMARC w subdomenie _dmarc. Route 53 korzysta z kreatora Create Record, w którym nazwa rekordu, typ i wartość trafiają do osobnych pól, a reguły dotyczące cudzysłowów w wartościach TXT są bardziej rygorystyczne niż u większości dostawców DNS.
Ten przewodnik omawia dokładne pola, dwa błędy z cudzysłowami, które psują rekordy TXT w Route 53, oraz powód, dla którego warto zacząć DMARC od p=none, zanim przejdziesz do egzekwowania polityki.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Zanim zaczniesz: wiedz, co publikujesz
SPF, DKIM i DMARC to trzy odrębne rekordy DNS, które wykonują trzy różne zadania. SPF wskazuje, które serwery mogą wysyłać pocztę z użyciem Twojej domeny w kopercie. DKIM dodaje podpis kryptograficzny, który przetrwa drogę do skrzynki odbiorczej. DMARC mówi odbiorcom, co zrobić z wiadomością, która nie przejdzie obu weryfikacji, a co równie ważne, włącza raportowanie pokazujące, kto wysyła pocztę w Twoim imieniu. Jeśli najpierw chcesz zbudować pełny model mentalny, przeczytaj SPF, DKIM i DMARC wyjaśnione.
Będziesz potrzebować dostępu do konsoli Route 53 oraz wartości wysyłkowych od swojego dostawcy poczty. Jeśli wysyłasz przez Amazon SES, większość tego procesu przebiega niemal automatycznie. Jeśli wysyłasz przez Google Workspace, Microsoft 365 lub ESP taki jak SendGrid albo Mailchimp, wklejasz wartości, które ci dostawcy Ci podają.
Krok 1: Dodaj rekord SPF (TXT w korzeniu strefy)
W konsoli Route 53 otwórz Hosted zones, kliknij swoją domenę, a następnie Create record.
- Record name: pozostaw to pole puste. Pusta nazwa w Route 53 oznacza apex strefy, czyli Twoją domenę główną. Nie wpisuj tu
@. Route 53 nie używa notacji@, a jej wpisanie tworzy dosłowną subdomenę@, która nic nie robi. - Record type: TXT
- Value: Twój łańcuch SPF, ujęty w podwójny cudzysłów.
Minimalny rekord SPF dla domeny, która wysyła wyłącznie przez Amazon SES, wygląda tak:
"v=spf1 include:amazonses.com -all"
Jeśli wysyłasz przez więcej niż jednego dostawcę, dodaj każdy include w tej samej linii. Na przykład SES plus Google Workspace:
"v=spf1 include:amazonses.com include:_spf.google.com -all"
W Route 53 liczą się dwie reguły. Po pierwsze, cała wartość musi znajdować się wewnątrz podwójnych cudzysłowów, ponieważ Route 53 przechowuje surową wartość TXT i nie dodaje cudzysłowów za Ciebie. Po drugie, publikujesz dokładnie jeden rekord SPF na domenę. Dwa osobne rekordy v=spf1 to trwały błąd (PermError) i odbiorcy potraktują SPF jako zepsuty. Jeśli masz już rekord SPF, edytuj go i dodaj nowy include, zamiast tworzyć drugi rekord.
Pilnuj liczby zapytań DNS. SPF dopuszcza maksymalnie 10 mechanizmów odpytujących DNS, a każdy include może wywołać ich kilka. Jeśli spiętrzysz wielu dostawców, możesz przekroczyć limit, co również powoduje PermError. Zajrzyj do jak naprawić zbyt wiele zapytań DNS w SPF, jeśli zbliżasz się do progu.
Użyj -all (twarde odrzucenie), gdy masz pewność, że każdy legalny nadawca jest wymieniony. Jeśli wciąż odkrywasz nadawców, ~all (miękkie odrzucenie) jest bezpieczniejszym rozwiązaniem tymczasowym. Unikaj +all, które upoważnia cały internet do wysyłania w Twoim imieniu i jest omówione w dlaczego +all jest niebezpieczne.
Krok 2: Dodaj DKIM (SES automatycznie publikuje rekordy CNAME w Twojej strefie)
DKIM to moment, w którym hosting w Route 53 się opłaca. Gdy strefa Twojej domeny jest hostowana w Route 53 i zweryfikujesz tożsamość tej domeny w Amazon SES, SES zaproponuje opublikowanie rekordów DKIM za Ciebie. Przy Easy DKIM SES generuje trzy rekordy CNAME wskazujące na klucze zarządzane przez SES, a jeśli zatwierdzisz zapis, trafiają one do Twojej strefy hostowanej automatycznie. Niczego nie wpisujesz ręcznie.
Te trzy rekordy mają następujący wzorzec, po jednym na selektor:
selector1._domainkey.example.com CNAME selector1.dkim.amazonses.com
Kilka rzeczy, które warto wiedzieć:
- DKIM w SES używa rekordów CNAME, a nie TXT. CNAME wskazuje na klucz hostowany przez SES, dzięki czemu SES może go rotować bez Twojej ingerencji w DNS. Jeśli chcesz poznać uzasadnienie delegacji przez CNAME zamiast surowego klucza TXT, przeczytaj DKIM: rekord CNAME kontra TXT.
- Pozostaw te trzy rekordy CNAME na stałe. Ich usunięcie psuje DKIM, a z czasem psuje wyrównanie (alignment) dla DMARC.
- Jeśli SES nie opublikuje ich automatycznie (na przykład gdy zweryfikowałeś tożsamość przed delegacją strefy albo korzystasz z BYODKIM), skopiuj trzy pary nazwa/wartość rekordów CNAME z konsoli SES do Route 53 ręcznie, używając Create record i typu CNAME.
Inni dostawcy zachowują się inaczej. Google Workspace i Microsoft 365 dają Ci pojedynczy rekord TXT w selektorze takim jak google._domainkey albo rekord CNAME, który dodajesz w ten sam sposób. Ogólną konfigurację DKIM u różnych dostawców opisuje jak skonfigurować DKIM.
Krok 3: Dodaj rekord DMARC (TXT w _dmarc)
DMARC mieszka pod stałą subdomeną: _dmarc. W Route 53 ponownie kliknij Create record.
- Record name:
_dmarc - Record type: TXT
- Value: Twoja polityka DMARC w cudzysłowach.
Zacznij tutaj, wyłącznie od monitorowania:
"v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Polityka p=none mówi odbiorcom, aby na razie niczego nie egzekwowali, ale znacznik rua prosi ich o wysyłanie raportów zbiorczych na wskazaną skrzynkę. To właśnie z tych raportów dowiadujesz się, które źródła wysyłają w imieniu Twojej domeny i czy przechodzą wyrównanie SPF oraz DKIM. Nie pomijaj tego etapu. Opublikowanie p=reject pierwszego dnia, zanim zobaczysz raporty, to najszybszy sposób, aby po cichu zablokować własne faktury, system zgłoszeń albo platformę marketingową.
Gdy raporty potwierdzą, że każde legalne źródło uwierzytelnia się i jest wyrównane, zaostrz politykę do p=quarantine, a następnie p=reject. Etapową ścieżkę opisuje jak przejść z DMARC none do reject, a różnicę między trzema politykami wyjaśnia polityka DMARC: none, quarantine czy reject.
Pole record name to najczęstszy błąd DMARC w Route 53. Jeśli pozostawisz je puste, opublikujesz DMARC w korzeniu, gdzie żaden odbiorca go nie szuka. Musi to być _dmarc. Po jego wpisaniu Route 53 pokaże pełną nazwę jako _dmarc.example.com, co jest poprawne.
Krok 4: Zweryfikuj, zanim zaufasz
Propagacja w Route 53 jest zwykle szybka, często poniżej minuty wewnątrz resolwerów AWS, choć publiczne resolwery mogą opóźniać się o czas TTL rekordu. Odczekaj kilka minut, a następnie potwierdź, że wszystkie trzy rekordy rozwiązują się i są poprawnie parsowane. Przepuść swoją domenę przez narzędzie SPFWise na górze tej strony. Odczyta ono Twoje aktualne rekordy SPF, DKIM i DMARC, wskaże błędy w cudzysłowach, policzy zapytania SPF, sprawdzi wyrównanie DKIM i zwróci ocenę wraz z konkretnymi poprawkami.
Wyślij jedną prawdziwą wiadomość testową do zewnętrznej skrzynki, którą kontrolujesz, i otwórz surowe nagłówki. Chcesz zobaczyć spf=pass, dkim=pass oraz dmarc=pass. Odczytywanie tych linii omawia jak czytać nagłówek Authentication-Results. Jeśli SPF przechodzi, ale DKIM zawodzi, albo odwrotnie, to zwykle problem z wyrównaniem, a nie zepsuty rekord, i dlaczego DKIM może zawieść, gdy SPF przechodzi prowadzi przez ten przypadek.
Najczęściej zadawane pytania
Czy w Route 53 używam @ dla domeny głównej?
Nie. Route 53 nie używa notacji @. Aby opublikować rekord w apeksie strefy (Twojej domenie głównej), pozostaw pole Record name puste. Wpisanie @ tworzy bezużyteczną subdomenę @, a Twój rekord SPF nie zostanie znaleziony.
Czy Route 53 dodaje cudzysłowy do rekordów TXT automatycznie?
Nie. Musisz sam ująć całą wartość TXT w podwójne cudzysłowy, na przykład "v=spf1 include:amazonses.com -all". Route 53 przechowuje wartość dosłownie. Brakujący cudzysłów to najczęstszy powód, dla którego rekord SPF lub DMARC w Route 53 nie daje się sparsować.
Jak Amazon SES publikuje DKIM w Route 53?
Gdy strefa Twojej domeny jest hostowana w Route 53 i zweryfikujesz domenę w SES za pomocą Easy DKIM, SES zaproponuje zapisanie trzech rekordów CNAME bezpośrednio w Twojej strefie hostowanej. Zatwierdź to, a rekordy CNAME dla DKIM pojawią się automatycznie. Pozostaw je na miejscu, ponieważ SES rotuje leżące pod nimi klucze bez żadnej dalszej pracy z Twojej strony w DNS. Pełny przewodnik po SES znajdziesz w konfiguracja SPF, DKIM i DMARC w Amazon SES.
Czy powinienem zacząć DMARC od p=reject w Route 53?
Nie. Zacznij od p=none z adresem rua, aby otrzymywać raporty zbiorcze bez blokowania jakiejkolwiek poczty. Gdy raporty potwierdzą, że każdy legalny nadawca uwierzytelnia się i jest wyrównany, przejdź do p=quarantine, a następnie p=reject.