Nespėliokite dėl savo DNS: kūrėjams draugiška MX, SPF, DKIM ir DMARC apžvalga

Kodėl el. pašto DNS įrašai dabar svarbūs

El. pašto autentifikavimas anksčiau buvo pasirenkamas. 2026 m. tai jau bazinis reikalavimas. Gmail ir Outlook masinių siuntėjų atveju taiko SPF ir DKIM, o DMARC sparčiai tampa privalomas kiekvienam domenui, kuris siunčia transakcinius el. laiškus. Jei jūsų DNS įrašai neteisingi, jūsų laiškai nepasiekia gavėjų — nėra nei atmetimo pranešimo, nei įspėjimo, tik tyla.

Problema ta, kad šie įrašai dokumentuojami kaip RFC, o ne kaip įrankiai. Dauguma kūrėjų nukopijuoja pavyzdžius iš savo el. pašto teikėjo sąrankos vadovo ir tikisi geriausio. Tai veikia tol, kol prireikia šalinti triktis, pridėti antrą siuntimo paslaugą arba paaiškinti klientui, kodėl jų kontaktų formos laiškai patenka į šlamštą.

Šiame vadove MX, SPF, DKIM ir DMARC aptariami tokia tvarka, kokia su jais iš tikrųjų susidursite, pateikiant pakankamai detalių, kad juos teisingai sukonfigūruotumėte, ir pakankamai konteksto, kad galėtumėte derinti, kai kas nors sugenda.

MX įrašai: kur keliauja gaunami laiškai

MX įrašai internetui nurodo, kurie pašto serveriai priima el. laiškus jūsų domenui. Jie yra paprasčiausi iš keturių, bet kartu ir lengviausiai neteisingai sukonfigūruojami.

MX įrašą sudaro dvi dalys: prioriteto numeris ir serverio vardas. Mažesni prioriteto numeriai bandomi pirmiausia. Jei naudojate Google Workspace, jūsų MX įrašai gali atrodyti taip:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Galiniai taškai svarbūs — jie nurodo, kad serverio vardas yra visiškai kvalifikuotas. Dauguma DNS teikėjų juos prideda automatiškai, bet ne visi.

Dažnos klaidos: MX įrašai nukreipiami į A įrašą, o ne į serverio vardą; visiems prioritetams nustatomas tas pats skaičius (taip prarandama atsarginių serverių prasmė); arba migruojant pas kitą teikėją pamirštama pašalinti senus MX įrašus. Pasenę MX įrašai nėra tiesiog nekenksmingai likę — jie gali sukelti pašto kilpas arba padalyti pristatymą tarp dviejų pašto dėžučių.

Jei naudojate savo kontaktų formą ir norite išvengti šlamšto nepasikliaudami trečiųjų šalių paslaugomis, naudinga pradžia yra suprasti, kaip formos tampa šlamšto vektoriais.

SPF: kuriems serveriams leidžiama siųsti jūsų vardu

SPF (Sender Policy Framework) yra TXT įrašas, kuriame išvardijami IP adresai ir domenai, įgalioti siųsti el. laiškus jūsų domeno vardu. Tai pirmasis patikrinimas, kurį dauguma pašto serverių atlieka gavę žinutę, teigiančią, kad ji yra nuo jūsų.

Bazinis SPF įrašas atrodo taip:

v=spf1 include:_spf.google.com ~all

Išskaidžius:

• v=spf1 deklaruoja SPF versiją
• include:_spf.google.com deleguoja Google SPF įrašui
• ~all yra švelnus nepavykimas — atmesti laiškus iš nenurodytų šaltinių, bet nebūti pernelyg griežtiems

Taip pat galite naudoti ip4: arba ip6:, kad įtrauktumėte konkrečius adresus į leidžiamųjų sąrašą, arba a ir mx, kad nurodytumėte savo domeno A ir MX įrašus. Pabaigoje esantis all mechanizmas valdo, kas nutinka laiškams iš šaltinių, kurių nenurodėte: -all yra griežtas nepavykimas (atmesti), ~all yra švelnus nepavykimas (pažymėti kaip įtartiną), ?all yra neutralu (be nuomonės), o +all yra visiškas leidimas visiems (nenaudokite to).

SPF turi dvi aštrias briaunas. Pirma, jis sugenda, kai el. laiškas persiunčiamas, nes persiuntimo serverio nėra jūsų SPF įraše. Antra, SPF įrašams taikomas dešimties DNS užklausų limitas. Jei įtrauksite per daug trečiųjų šalių paslaugų, viršysite limitą ir SPF nustos veikti. Sprendimas — suplokštinti SPF įrašą: pakeisti include: direktyvas tikrais IP intervalais, bet tai reikalauja priežiūros, kai teikėjai keičia savo IP adresus.

DKIM: kriptografinis siuntėjo tapatybės įrodymas

DKIM (DomainKeys Identified Mail) prie jūsų siunčiamų el. laiškų prideda skaitmeninį parašą. Gaunantis serveris patikrina parašą pagal viešąjį raktą, paskelbtą jūsų DNS. Jei parašas galioja ir žinutė nebuvo pakeista, DKIM patikra praeina.

Skirtingai nei SPF, DKIM išlieka persiunčiant, nes parašas keliauja kartu su žinute. Jis taip pat lankstesnis — galite turėti kelis DKIM raktus skirtingoms siuntimo paslaugoms, kiekvieną su savo selektoriumi.

DKIM DNS įrašas atrodo taip:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selektorius (default šiame pavyzdyje) yra laisvai pasirenkamas — jį parenka jūsų el. pašto teikėjas. p= reikšmė yra viešasis raktas, paprastai ilga base64 koduota eilutė. Jūsų el. pašto teikėjas sugeneruoja privatųjį raktą ir naudoja jį siunčiamoms žinutėms pasirašyti.

DKIM sąranką beveik visada tvarko jūsų el. pašto teikėjas. Jūsų užduotis — nukopijuoti jų pateiktą TXT įrašą ir įklijuoti jį į savo DNS. Sudėtinga dalis ta, kad kai kurie DNS teikėjai blogai tvarko ilgus TXT įrašus — jie juos arba nukerpa, arba reikalauja padalyti reikšmę į kelias kabutėmis apgaubtas eilutes.

Norėdami patikrinti, ar DKIM veikia, išsiųskite bandomąjį laišką į Gmail adresą ir patikrinkite antraštes. Authentication-Results antraštėje ieškokite dkim=pass.

DMARC: politikos taikymas ir ataskaitos

DMARC (Domain-based Message Authentication, Reporting and Conformance) sujungia SPF ir DKIM ir nurodo gaunantiems serveriams, ką daryti, kai autentifikavimas nepavyksta. Jis taip pat įgalina ataskaitas, kad galėtumėte matyti, kas siunčia el. laiškus jūsų domeno vardu — tiek teisėtai, tiek apsimetant.

Minimalus DMARC įrašas atrodo taip:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none reiškia tik stebėjimą — neatmesti ir nekarantinuoti nepavykusių žinučių
• rua=mailto:[email protected] nurodo, kur siųsti suvestines ataskaitas

Kai įsitikinsite, kad SPF ir DKIM veikia, galite sugriežtinti politiką iki p=quarantine (siųsti nepavykusias žinutes į šlamštą) arba p=reject (atmesti jas iš karto). Taip pat galite nustatyti subdomenų politiką su sp= ir nurodyti procentą žinučių, kurioms taikyti politiką, naudodami pct=.

DMARC ataskaitos yra XML failai, kuriuos didieji gavėjai siunčia kasdien. Neapdorotos jos išsamios ir sunkiai skaitomos, bet tiksliai parodo, kurios žinutės autentifikavimą praėjo ar jo nepraėjo ir kodėl. Jei matote, kad teisėti laiškai atmetami, ataskaitos parodys, kuris SPF arba DKIM patikrinimas nepavyksta.

Vienas kabliukas: DMARC reikalauja sutapimo. SPF atveju domenas Return-Path antraštėje turi sutapti su domenu From antraštėje (arba būti subdomenas). DKIM atveju DKIM parašo d= domenas turi sutapti su From domenu. Jei naudojate trečiosios šalies siuntimo paslaugą, ji turi palaikyti pasirinktinius grąžinimo kelius arba DKIM pasirašymą jūsų domenu, o ne savo.

Kaip audituoti dabartinę sąranką

Dauguma DNS problemų nematomos, kol nesukelia bėdos. Štai kaip patikrinti įrašus prieš kažkam sugendant:

1. Užklauskite MX įrašų: dig MX example.com turėtų grąžinti jūsų pašto serverių vardus ir prioritetus. Patikrinkite, ar jie atitinka jūsų el. pašto teikėjo dokumentaciją.

1. Patikrinkite SPF sintaksę: dig TXT example.com ir ieškokite v=spf1 įrašo. Perleiskite jį per SPF tikrintuvą, kad aptiktumėte sintaksės klaidas ir užklausų limito pažeidimus.

1. Patikrinkite DKIM raktus: išsiųskite bandomąjį laišką ir peržiūrėkite DKIM-Signature antraštę. Išskirkite selektorių ir domeną, tada užklauskite dig TXT selector._domainkey.example.com, kad patvirtintumėte, jog viešasis raktas egzistuoja.

1. Patvirtinkite DMARC politiką: dig TXT _dmarc.example.com turėtų grąžinti jūsų DMARC įrašą. Įsitikinkite, kad rua= nurodo adresą, kurį iš tikrųjų stebite.

1. Išbandykite nuo pradžios iki pabaigos: naudokite tokią paslaugą kaip mail-tester.com arba siųskite į Gmail adresą ir patikrinkite visas antraštes. Authentication-Results antraštėje ieškokite spf=pass, dkim=pass ir dmarc=pass.

Jei derinate, kodėl laiškai nepasiekia gavėjų, antraštės yra geriausias jūsų įrankis. Dauguma pašto klientų leidžia peržiūrėti neapdorotas antraštes — Gmail atidarykite žinutę, spustelėkite tris taškus ir pasirinkite „Show original“. Authentication-Results antraštė tiksliai parodys, kuris patikrinimas nepavyko ir kodėl.

Kada naudoti subdomenų politikas

Jei siunčiate el. laiškus iš kelių subdomenų — tarkime, newsletter.example.com rinkodarai ir app.example.com transakciniam paštui — galite nustatyti atskiras DMARC politikas kiekvienam subdomenui. Tai leidžia taikyti griežtas politikas subdomenams, kuriuos kontroliuojate, ir palikti laisvesnę politiką pagrindiniam domenui.

Kompromisas — sudėtingumas. Kiekvienam subdomenui reikia savo SPF, DKIM ir DMARC įrašų, taip pat turite sekti, kurios siuntimo paslaugos įgaliotos kuriems subdomenams. Daugumai mažų komandų vienas gerai sukonfigūruotas domenas yra paprastesnis ir toks pat saugus.

Ką daryti, kai autentifikavimas sugenda

Dažniausias gedimo scenarijus — naujos siuntimo paslaugos pridėjimas neatnaujinus DNS. Jei pradedate naudoti naują transakcinių el. laiškų teikėją, turite pridėti jų SPF include arba IP intervalą, sukonfigūruoti DKIM pasirašymą jūsų domenu ir patikrinti DMARC sutapimą.

Antra dažniausia problema — persiuntimas. Jei naudotojai persiunčia jūsų laiškus kitu adresu, SPF nepavyks, nes persiuntimo serverio nėra jūsų SPF įraše. DKIM paprastai išlieka persiunčiant, todėl jei DKIM praeina ir jūsų DMARC politika leidžia dalinį sutapimą, žinutė vis tiek turėtų būti pristatyta. Jei matote, kad persiųsti laiškai atmetami, patikrinkite DMARC politiką — p=reject su griežtu sutapimu sugadins persiuntimą.

Trečia problema — DNS išplitimas. DNS įrašų pakeitimams išplisti gali prireikti valandų, o skirtingi pašto serveriai įrašus talpykloje laiko skirtingą laiką. Jei ką tik atnaujinote įrašą ir jis neveikia, palaukite kelias valandas ir bandykite dar kartą. Išplitimą galite patikrinti naudodami tokį įrankį kaip whatsmydns.net.

Pagrindinės išvados

• MX įrašai nukreipia gaunamą paštą; SPF, DKIM ir DMARC autentifikuoja siunčiamą paštą. Jie sprendžia skirtingas problemas, ir jums reikia visų keturių.
• SPF sugenda persiunčiant ir turi dešimties užklausų limitą. DKIM išlieka persiunčiant, bet reikalauja konfigūracijos kiekvienai paslaugai. DMARC juos sujungia ir įgalina ataskaitas.
• DMARC pradėkite nuo p=none, kelias savaites stebėkite ataskaitas, tada sugriežtinkite iki p=quarantine arba p=reject, kai būsite tikri, kad teisėtas paštas praeina.
• DNS klaidos tylios. Išbandykite konfigūraciją su tikrais el. laiškais ir peržiūrėkite antraštes, kad patvirtintumėte, jog SPF, DKIM ir DMARC praeina.
• Jei autentifikavimas sugenda pridėjus naują siuntimo paslaugą, patikrinkite SPF include, DKIM selektorius ir DMARC sutapimą. Antraštės parodys, kuris patikrinimas nepavyko.

DUK

Q: Ar galiu turėti kelis SPF įrašus?

A: Ne. Dėl kelių SPF įrašų visi jie bus ignoruojami. Jei reikia įgalioti kelias paslaugas, naudokite include: direktyvas viename SPF įraše arba IP intervalus nurodykite tiesiogiai. Stebėkite dešimties užklausų limitą.

Q: Ar man reikia DMARC, jei per dieną siunčiu tik kelis laiškus?

A: Taip. DMARC nėra apie apimtį — jis apie įrodymą, kad esate tie, kuo sakote esantys. Net maži domenai gauna naudos iš DMARC, nes jis apsaugo nuo apsimetimo ir suteikia matomumą apie pristatymo problemas. Pradėkite nuo p=none ir ataskaitų adreso.

Q: Kas nutinka, jei DKIM ir SPF abu nepavyksta, bet laiškas atrodo teisėtas?

A: Tai priklauso nuo jūsų DMARC politikos. Jei p=none, laiškas pristatomas su įspėjimu. Jei p=quarantine, jis patenka į šlamštą. Jei p=reject, jis atmetamas. Todėl prieš taikydami griežtą politiką turėtumėte stebėti DMARC ataskaitas — galite turėti teisėtų siuntėjų, apie kuriuos nežinojote.

Q: Ar galiu naudoti tą patį DKIM raktą keliems domenams?

A: Techniškai taip, bet nedarykite to. Kiekvienas domenas turėtų turėti savo DKIM raktų porą. Dalijimasis raktais apsunkina rotaciją ir padidina poveikio spindulį, jei privatusis raktas būtų kompromituotas.

Q: Kaip dažnai turėčiau rotuoti DKIM raktus?

A: Universalios taisyklės nėra, bet kartą per metus yra protinga daugumai domenų. Jei įtariate, kad raktas buvo kompromituotas, rotuokite nedelsdami. Prieš pradėdami pasirašinėti nauju privačiuoju raktu, būtinai paskelbkite naują viešąjį raktą DNS, o po rotacijos seną raktą DNS palikite kelioms dienoms, kad būtų aptarnauti vėluojantys laiškai.

<!-- tool-cta:start -->

💡 Išbandykite tai: Patikrinkite bet kurio domeno paskelbtą politiką naudodami DMARC Lookup, kad pamatytumėte, kaip MX, SPF ir DMARC įrašai praktiškai dera tarpusavyje.

<!-- tool-cta:end -->

Šaltiniai

• RFC 7208: Sender Policy Framework (SPF) — SPF specifikacija, įskaitant sintaksės taisykles ir dešimties užklausų limitą.
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM specifikacija, apimanti parašų generavimą ir tikrinimą.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC specifikacija, įskaitant politikos sintaksę ir suvestinių ataskaitų formatą.
• Google Workspace: Prevent spoofing and spam — Praktinės SPF, DKIM ir DMARC konfigūravimo gairės Google Workspace domenams.