exim.ro

Înregistrări DNS pentru e-mail: MX, SPF, DKIM, DMARC

Ce fac înregistrările MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT și BIMI, cum le citesc serverele care primesc mail și greșelile care strică livrarea.

Actualizat la 8 minute de citit8 secțiuni

Deschide Verificare DNS e-mail

Dacă un mesaj ajunge în Inbox, în spam sau este respins depinde în mare măsură de câteva înregistrări DNS publicate de domeniul expeditorului și de cel al destinatarului. Ghidul explică ce face fiecare și cum o folosesc serverele care primesc mail. Verificarea DNS e-mail le citește pe toate pentru un domeniu și aplică regulile descrise aici.

MX: unde ajunge mailul unui domeniu

O înregistrare MX indică un server care primește mail pentru domeniu, împreună cu un număr de prioritate. Expeditorii încearcă întâi numărul cel mai mic și trec la cele mai mari când un server nu răspunde; serverele cu același număr împart traficul.

exemplu.ro.  3600  IN  MX  10 mx1.exemplu.ro.
exemplu.ro.  3600  IN  MX  20 mx2.exemplu.ro.

Reguli de reținut:

  • Ținta trebuie să fie un nume de server cu propria înregistrare A sau AAAA. O adresă IP nu este permisă, iar RFC 2181 (secțiunea 10.3) interzice ca un MX să indice un alias (CNAME).
  • Fără nicio înregistrare MX, expeditorii livrează la adresa A/AAAA a domeniului însuși (RFC 5321, secțiunea 5.1). Merge doar dacă pe acel server rulează un server de mail.
  • Un domeniu care nu primește niciodată mail ar trebui să publice un null MX, o singură înregistrare 0 . (RFC 7505). Mailul către el este respins imediat, în loc să fie reîncercat zile la rând.

SPF: cine poate trimite în numele domeniului

SPF (RFC 7208) este o înregistrare TXT a domeniului care listează serverele care au voie să trimită mail cu acel domeniu în expeditorul din plic (adresa MAIL FROM, numită și Return-Path).

exemplu.ro.  IN  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.furnizor.example ~all"

Serverul care primește compară adresa IP a celui care se conectează cu termenii, de la stânga la dreapta, și se oprește la prima potrivire. Calificatorul din fața termenului dă rezultatul: + pass (implicit), - fail, ~ softfail, ? neutral.

TermenSe potrivește cu
ip4:, ip6:o adresă din rețeaua dată
a, a:serveradresele A/AAAA ale domeniului sau ale lui server
mx, mx:serveradresele serverelor MX ale domeniului
include:domeniuce permite înregistrarea SPF a lui domeniu
exists:numedacă nume are o înregistrare de adresă (folosit cu macro-uri)
allorice; se pune la final
redirect=domeniuse folosește înregistrarea altui domeniu dacă nimic nu s-a potrivit

Limita de 10 interogări DNS

Termenii include, a, mx, ptr, exists și modificatorul redirect produc fiecare interogări DNS. RFC 7208 (secțiunea 4.6.4) le limitează la 10 pentru toată evaluarea, inclusiv include-urile imbricate. Un server care ajunge la a 11-a întoarce permerror, pe care DMARC îl tratează ca eșec. Limita se depășește ușor fără să observați, pentru că include-ul fiecărui furnizor vine cu include-urile lui. Unealta urmărește tot arborele și le adună.

Încă două limite din aceeași secțiune: un termen mx nu poate întoarce mai mult de 10 înregistrări MX, iar cel mult două interogări pot veni goale („void lookups”: NXDOMAIN sau fără date).

Greșeli frecvente la SPF

  • Două înregistrări SPF. Un domeniu trebuie să publice exact o înregistrare TXT care începe cu v=spf1; cu două, orice verificare se termină cu permerror. Uniți-le.
  • +all autorizează orice server din Internet. ?all nu spune nimic. Folosiți ~all sau -all.
  • ptr este lent și nesigur și nu ar trebui folosit (RFC 7208, secțiunea 5.5).
  • Termenii de după all nu sunt evaluați niciodată.
  • Un domeniu care nu trimite deloc mail ar trebui să publice v=spf1 -all.

DKIM: o semnătură care rezistă la redirecționare

DKIM (RFC 6376) permite serverului care trimite să semneze părți din fiecare mesaj cu o cheie privată. Antetul semnăturii indică un selector (s=) și un domeniu (d=); serverul care primește ia cheia publică de la selector._domainkey.domeniu și verifică dacă antetele semnate și corpul mesajului nu au fost modificate.

s1._domainkey.exemplu.ro.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
  • Selectorii nu pot fi listați. DNS-ul nu are un mod de a-i enumera, așa că o unealtă poate încerca doar nume uzuale. Dacă nu găsește niciunul, căutați valoarea s= din antetul DKIM-Signature al unui mesaj real și verificați acel selector.
  • Mărimea cheii. RFC 8301 cere ca verificatorii să respingă cheile RSA sub 1024 de biți și recomandă cel puțin 2048 de biți la semnare.
  • t=y marchează o cheie ca fiind în test: serverele care primesc pot trata semnăturile eșuate ca și cum mesajul nu ar fi semnat.
  • Un p= gol înseamnă că cheia a fost revocată.
  • Cheile Ed25519 (k=ed25519, RFC 8463) sunt mai mici, dar nu toate serverele le verifică încă, de aceea se publică de obicei alături de o cheie RSA.

DMARC: ce se face când verificările pică

DMARC (RFC 7489) leagă SPF și DKIM de adresa pe care o vede omul, antetul From:. Un mesaj trece DMARC când SPF sau DKIM trece și domeniul autentificat este aliniat cu domeniul din From. Înregistrarea de la _dmarc.domeniu le spune serverelor ce să facă cu mailul care pică și unde să trimită rapoartele.

_dmarc.exemplu.ro.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemplu.ro"
EtichetăCe înseamnă
p=politica pentru domeniu: none (doar rapoarte), quarantine (tratat ca suspect), reject
sp=politica pentru subdomenii; dacă lipsește, se aplică p=
pct=procentul din mailul care pică pentru care se aplică politica (implicit 100)
rua=unde ajung rapoartele agregate
ruf=unde ajung rapoartele de eșec pentru mesaje individuale; puține servere le trimit
adkim=, aspf=alinierea: r relaxată (subdomeniile se potrivesc, implicit) sau s strictă

Cum se introduce de obicei o politică:

  1. Publicați p=none cu o adresă rua= și citiți rapoartele câteva săptămâni.
  2. Reparați fiecare sursă legitimă care pică (un serviciu de newsletter fără DKIM, un server lipsă din SPF).
  3. Treceți la p=quarantine, apoi la p=reject.

Ce nu merge des:

  • Lipsește rua=: nu există rapoarte, deci nu vedeți cine trimite în numele domeniului.
  • Rapoarte către alt domeniu: dacă rua= indică în afara domeniului, acel domeniu trebuie să publice domeniulvostru._report._dmarc.domeniullor cu v=DMARC1, altfel serverele nu trimit rapoartele (RFC 7489, secțiunea 7.1). Serviciile de raportare fac de obicei asta pentru dumneavoastră.
  • Mai multe înregistrări DMARC: serverele nu mai aplică deloc DMARC.
  • Subdomenii: fără înregistrare proprie, un subdomeniu este acoperit de înregistrarea domeniului părinte și de politica lui sp=.

MTA-STS: expeditorii trebuie să insiste pe TLS

Mailul dintre servere este de obicei criptat cu STARTTLS, dar cineva aflat pe traseu poate elimina oferta și poate citi traficul. MTA-STS (RFC 8461) permite unui domeniu să declare că expeditorii trebuie să folosească TLS cu certificat valid și doar către serverele MX listate. Are două părți: o înregistrare TXT la _mta-sts.domeniu, cu versiune și id, și un fișier de politică servit prin HTTPS la https://mta-sts.domeniu/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx1.exemplu.ro
mx: *.exemplu.net
max_age: 1209600
  • mode: testing raportează problemele, dar livrează în continuare; enforce refuză livrarea care nu respectă politica.
  • Fiecare server MX trebuie să se potrivească cu un rând mx:, unde *. înseamnă exact o etichetă. Un MX adăugat fără actualizarea politicii nu mai primește mail de la expeditorii care o aplică.
  • Politica trebuie servită cu HTTP 200, fără redirecționări și cu un certificat valid pentru mta-sts.domeniu.
  • max_age este cel mult 31557600 de secunde (un an); RFC 8461 se așteaptă la valori de săptămâni sau mai mult.
  • Schimbați id din înregistrarea TXT de fiecare dată când se schimbă politica, ca expeditorii să o descarce din nou.

TLS-RPT: aflați de eșecurile TLS

Cu o înregistrare TXT la _smtp._tls.domeniu (RFC 8460), serverele care trimit vă trimit zilnic un raport cu conexiunile TLS eșuate către serverele dumneavoastră.

_smtp._tls.exemplu.ro.  IN  TXT  "v=TLSRPTv1; rua=mailto:rapoarte-tls@exemplu.ro"

Singură este opțională, dar cu MTA-STS în modul enforce este felul în care aflați că un certificat expirat blochează mailul.

BIMI: o siglă lângă mailul autentificat

BIMI permite căsuțelor de mail compatibile să afișeze sigla unei mărci lângă mesajele care trec DMARC. Înregistrarea stă la default._bimi.domeniu; l= indică sigla, un fișier SVG în profilul SVG Tiny Portable/Secure, iar a= un certificat de marcă, cerut de câțiva furnizori mari de căsuțe de mail.

default._bimi.exemplu.ro.  IN  TXT  "v=BIMI1; l=https://exemplu.ro/sigla.svg; a=https://exemplu.ro/vmc.pem"

BIMI este procesat doar când politica DMARC este impusă: nu p=none, nu sp=none, iar pct la 100 (draft-brand-indicators-for-message-identification, secțiunea 7.1).

Surse