Rekord TXT w DNS to typ wpisu DNS, który przechowuje dowolny tekst przypisany do nazwy Twojej domeny. Każdy może go publicznie odpytać i właśnie dlatego wykorzystuje go uwierzytelnianie poczty: Twoje polityki SPF, DKIM i DMARC są publikowane jako rekordy TXT, aby odbierające serwery pocztowe mogły je odczytać i zdecydować, czy zaufać Twojej poczcie. Jeśli kiedykolwiek usłyszałeś polecenie "dodaj rekord TXT" w swoim DNS, niemal na pewno chodziło o jeden z tych trzech.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Pierwotnym przeznaczeniem rekordów TXT były ogólne notatki i informacje czytelne dla człowieka. W praktyce przejęły je odczytywane maszynowo polityki poczty. Gdy Gmail, Outlook lub Yahoo odbierają wiadomość podającą się za pochodzącą z Twojej domeny, sprawdzają konkretne rekordy TXT, aby ją zweryfikować. Wystarczy jeden błędny znak w tekście, a uwierzytelnianie zawiedzie, dlatego warto dokładnie zrozumieć, co te rekordy zawierają i jak działają poszczególne pola.
Czym właściwie jest rekord TXT
Rekord TXT to jeden z wielu typów rekordów DNS, obok A, MX, CNAME i NS. O ile rekord A mapuje nazwę na adres IPv4, a rekord MX wskazuje serwer pocztowy, o tyle rekord TXT po prostu przechowuje ciąg tekstu. Sam DNS nie wymusza żadnego stałego formatu. Znaczenie wynika z konwencji, na którą zgadzają się zarówno publikujący, jak i odczytujący.
To uwierzytelnianie poczty definiuje te konwencje. Tekst SPF zaczyna się od v=spf1. Tekst DMARC zaczyna się od v=DMARC1. Tekst DKIM zawiera klucz publiczny w postaci v=DKIM1; k=rsa; p=.... Odbierający serwer wie, który rekord pobrać i jak rozłożyć ciąg na części po jego otrzymaniu. Na tym polega cała sztuczka: rekordy TXT są uniwersalnym pojemnikiem, a standardy poczty wlewają do nich konkretny, ustrukturyzowany ciąg.
Każdy tworzony przez Ciebie rekord TXT ma trzy części, które ustawisz u swojego dostawcy DNS: host (nazywany też nazwą), wartość (sam tekst) oraz TTL. Ustaw te trzy poprawnie, a rekord zadziała.
Wyjaśnienie hosta, wartości i TTL
Host (lub nazwa) mówi, do której domeny lub subdomeny należy rekord. Dla głównego rekordu SPF wpisujesz @, co większość paneli DNS tłumaczy na samą domenę, na przykład example.com. Dla DMARC wpisujesz _dmarc, co staje się _dmarc.example.com. Dla DKIM wpisujesz coś w rodzaju selector1._domainkey, co staje się selector1._domainkey.example.com. Host to częste źródło błędów. Jeśli przypadkiem wpiszesz _dmarc.example.com do panelu, który już sam dokleja Twoją domenę, otrzymasz _dmarc.example.com.example.com, a rekord będzie niewidoczny dla odbiorców poczty.
Wartość to tekstowy ciąg w cudzysłowie. To właśnie polityka SPF, DKIM lub DMARC. Spacje i wielkość liter wewnątrz wartości mają znaczenie dla niektórych znaczników, a dla innych nie, więc kopiuj wartości dokładnie tak, jak podaje je Twój dostawca.
TTL (time to live) określa, przez ile sekund resolvery mogą przechowywać rekord w pamięci podręcznej, zanim sprawdzą go ponownie. Częstą wartością domyślną jest 3600 sekund (jedna godzina). Niższy TTL, na przykład 300, oznacza, że zmiany rozchodzą się szybciej, ale generuje nieco większy ruch DNS. Kiedy aktywnie edytujesz rekordy, krótszy TTL jest wygodny. Gdy wszystko się ustabilizuje, dłuższy TTL jest w porządku.
Trzy rekordy poczty, które mieszkają w TXT
Oto opisany przykład każdego z nich, na przykładzie domeny example.com.
SPF wymienia, które serwery mają prawo wysyłać pocztę w imieniu Twojej domeny. Host @, wartość:
v=spf1 include:_spf.google.com include:sendgrid.net -all
Czyta się to tak: SPF w wersji 1, autoryzuj Google Workspace i SendGrid do wysyłania oraz odrzucaj (-all) całą resztę. Na domenę musi przypadać dokładnie jeden rekord TXT SPF. Dwa rekordy SPF to twardy błąd. Pełny przewodnik znajdziesz w jak skonfigurować SPF.
DKIM publikuje klucz publiczny, aby odbiorcy mogli zweryfikować kryptograficzny podpis Twojej poczty. Host selector1._domainkey, wartość:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...
Wartość p= to długi klucz publiczny w base64, często ponad 255 znaków, co za chwilę okaże się istotne. Selektor (selector1) pozwala uruchomić więcej niż jeden klucz naraz. Zobacz jak skonfigurować DKIM.
DMARC mówi odbiorcom, co robić, gdy SPF i DKIM zawiodą, oraz gdzie wysyłać raporty. Host _dmarc, wartość:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s
To publikuje politykę odrzucania z rygorystycznym dopasowaniem i adresem do raportów zbiorczych. Zacznij od jak skonfigurować DMARC, jeśli budujesz to od zera. Jeśli chcesz poznać koncepcyjną różnicę między całą trójką, przeczytaj SPF, DKIM i DMARC wyjaśnione.
Limit 255 znaków i pułapka wielu ciągów
To najczęstszy powód, dla którego technicznie poprawny rekord i tak zawodzi, dlatego warto tu zwolnić.
Pojedynczy ciąg znaków wewnątrz rekordu TXT nie może przekroczyć 255 znaków. To ograniczenie samego formatu DNS na poziomie protokołu, zdefiniowane w RFC 1035, a nie reguła wymyślona przez Twojego dostawcę. Krótkie rekordy, takie jak SPF i DMARC, są od tego limitu bardzo daleko. Klucze DKIM, zwłaszcza 2048-bitowe klucze RSA, rutynowo przekraczają 255 znaków.
Standardowe rozwiązanie, opisane w RFC 7208 dla SPF i stosowane tak samo dla DKIM, polega na podzieleniu wartości na wiele ciągów w cudzysłowach wewnątrz jednego rekordu. Zamiast jednego ciągu o długości 400 znaków publikujesz:
"v=DKIM1; k=rsa; p=MIGfMA0GCS...firstpart" "secondpart...IDAQAB"
Gdy resolver odczytuje rekord TXT z wieloma ciągami, skleja je z powrotem bez separatora i bez dodawanych spacji. Dzięki temu dwa powyższe fragmenty ponownie stają się jednym ciągłym kluczem. Dwie rzeczy najczęściej zawodzą ludzi w tym miejscu. Po pierwsze, niektóre panele DNS wymagają, byś sam wpisał cudzysłowy, a inne dodają je automatycznie, co może dać podwojone cudzysłowy. Po drugie, jeśli w miejscu podziału wkradnie się spacja, sklejony klucz jest uszkodzony i DKIM zawodzi z błędem skrótu treści lub podpisu. Większość zarządzanych dostawców DNS i dostawców poczty obsługuje teraz podział za Ciebie, gdy wkleisz długi klucz, więc lepiej wklej całą wartość do jednego rekordu i pozwól panelowi podzielić ją na fragmenty, zamiast dzielić ręcznie.
Jeśli już dzielisz ręcznie, podziel klucz na dowolnej granicy znaku, a nie na granicy logicznej, i nigdy nie wstawiaj białych znaków między cudzysłowem zamykającym a otwierającym.
Jak odczytać i zweryfikować swoje aktywne rekordy
Ponieważ rekordy TXT są publiczne, możesz sprawdzić czyjekolwiek. W wierszu poleceń dig txt example.com zwraca SPF i wszelkie inne główne rekordy TXT, dig txt _dmarc.example.com zwraca politykę DMARC, a dig txt selector1._domainkey.example.com zwraca klucz DKIM. Wynik pokazuje każdy ciąg w cudzysłowie, dzięki czemu od razu widać, czy długi klucz DKIM został podzielony na wiele ciągów.
Szybszą drogą jest wklejenie swojej domeny do narzędzia sprawdzającego na górze tej strony. Pobiera ono Twoje aktywne rekordy TXT SPF, DKIM i DMARC, składa z powrotem podzielone ciągi, sprawdza składnię względem odpowiednich RFC i sygnalizuje problemy, takie jak brakujący rekord DMARC, dwa rekordy SPF czy uszkodzony klucz. Jeśli wciąż ustalasz, czego potrzebujesz, jakie rekordy DNS są potrzebne do poczty przedstawia pełny zestaw.
Najczęściej zadawane pytania
Czy SPF to rekord TXT, czy własny typ rekordu?
SPF jest publikowany jako rekord TXT. Kiedyś istniał dedykowany typ rekordu SPF (typ 99), ale RFC 7208 wycofał go w 2014 roku. Współczesne serwery odbierające patrzą wyłącznie na rekord TXT, więc publikuj swoją politykę v=spf1 jako TXT i nie twórz rekordu typu SPF.
Czy mogę mieć więcej niż jeden rekord TXT na tej samej domenie?
Tak, domena może przechowywać wiele rekordów TXT naraz, na przykład rekord SPF oraz ciąg weryfikacyjny domeny od Google lub Microsoft. Ważny wyjątek dotyczy SPF: możesz mieć tylko jeden rekord TXT zaczynający się od v=spf1. Wiele rekordów SPF powoduje trwały błąd i psuje uwierzytelnianie dla wszystkich wysyłających z tej domeny.
Dlaczego mój rekord DKIM zawodzi, choć wartość wygląda poprawnie?
Niemal zawsze z powodu podziału na 255 znaków. Klucz DKIM 2048-bitowy jest dłuższy, niż zmieści jeden ciąg, więc musi być przechowywany jako wiele ciągów w cudzysłowach, które resolver skleja z powrotem. Jeśli między ciągami prześlizgnęła się spacja albo rekord został ucięty przy wklejaniu, sklejony klucz jest błędny i podpis się nie zweryfikuje, mimo że wartość na pierwszy rzut oka wygląda dobrze.
Jakiego TTL użyć dla pocztowych rekordów TXT?
TTL wynoszący 3600 sekund (jedna godzina) to rozsądna wartość domyślna, gdy rekordy są już stabilne. Obniż go do 300 sekund, gdy aktywnie edytujesz, aby zmiany wchodziły w życie szybko, a potem podnieś z powrotem. TTL wpływa tylko na szybkość buforowania, a nie na to, czy rekord jest poprawny, więc sam w sobie nigdy nie będzie przyczyną niepowodzenia uwierzytelniania.