Cum se configurează înregistrările DKIM, SPF și DMARC pentru un server Zimbra

DKIM, SPF și DMARC rezolvă trei părți diferite ale autentificării e-mailurilor de ieșire, iar o implementare Zimbra fiabilă necesită ca acestea să funcționeze împreună. SPF le spune destinatarilor ce sisteme au permisiunea de a trimite cu domeniul plicului dvs. DKIM. DKIM adaugă o semnătură criptografică legată de un domeniu. DMARC verifică dacă o identitate SPF sau DKIM care trece se aliniază cu domeniul vizibil în antetul De la mesaj, apoi publică o politică de gestionare și raportare.

Un detaliu al standardelor actuale contează aici: începând cu octombrie 2026, specificația protocolului DMARC activ este RFC 9989 , publicată în mai 2026. Aceasta anulează vechiul RFC 7489 și modifică unele detalii de implementare, inclusiv transformarea vechii pctetichete în istoric și introducerea tetichetei de testare. Acest lucru este important dacă copiați un exemplu DMARC mai vechi dintr-un ghid Zimbra anterior sau un tutorial DNS.

Ce ai nevoie înainte de a schimba DNS-ul

Aveți nevoie de acces administrativ la shell la un MTA Zimbra, acces la zona DNS publică autoritară pentru domeniul dvs. de trimitere și o listă completă a fiecărui sistem care trimite în mod legitim e-mailuri folosind domeniul respectiv. Această listă poate include serverul dvs. Zimbra, un server de relay sau o gazdă inteligentă, platforme de marketing, sisteme de ticketing, aplicații cloud și orice serviciu de e-mail de recuperare în caz de dezastru.

O neînțelegere frecventă este aceea că publicarea înregistrărilor doar pentru gazda Zimbra este întotdeauna suficientă. Este suficientă doar atunci când Zimbra este cu adevărat singurul expeditor autorizat. SPF este evaluat în funcție de identitatea SMTP, iar DMARC poate expune expeditorii terți uitați odată ce aplicarea este activată. Acțiune: inventariați toate sursele de ieșire înainte de a publica o politică SPF sau DMARC restrictivă.

Pasul 1: Generați cheia DKIM în Zimbra

Zimbra include zmdkimkeyutilutilitarul pentru semnarea DKIM la nivel de domeniu. Documentația oficială a Zimbra recomandă rularea acestuia pe un server MTA. Pentru a adăuga date DKIM pentru un domeniu care nu le are deja, comutați la contul Zimbra și executați:

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

Comanda stochează datele DKIM în intrarea de domeniu LDAP a Zimbra și afișează selectorul și înregistrarea TXT publică pe care trebuie să le publicați. Documentația de semnare DKIM a Zimbra documentează, de asemenea, -qcum să interogați datele DKIM existente, -usă le actualizați și -rsă le eliminați.

Pentru instalările Zimbra moderne, rezultatul poate diferi în ceea ce privește valoarea exactă a selectorului față de exemplele pe care le vedeți online. Selectorul nu ar trebui să fie un cuvânt fix, cum ar fi defaultsau zimbra; utilizați exact selectorul pe care îl imprimă propriul server. Acțiune: copiați întreaga înregistrare a cheii publice din rezultatul comenzii, în loc să o reconstruiți manual.

Pasul 2: Publicați înregistrarea TXT DKIM

Verificatorii DKIM caută cheia publică în DNS sub un nume construit din selector și ._domainkey. Mecanismul este definit în RFC 6376 . În termeni practici ai furnizorilor DNS, înregistrarea arată de obicei astfel:

Indiferent dacă introduceți doar numele YOUR_SELECTOR._domainkeysau numele complet al YOUR_SELECTOR._domainkey.example.comzonei, depinde de panoul de control DNS. Unii furnizori adaugă automat numele zonei. Acțiune: previzualizați numele final al înregistrării complet calificate din furnizor înainte de salvare, pentru a nu crea accidental ...example.com.example.com.

Pasul 3: Creați o înregistrare TXT SPF pentru domeniul expeditor

SPF este publicat ca o înregistrare TXT DNS la domeniul a cărui autorizație de trimitere doriți să o descrieți. RFC 7208 necesită înregistrări TXT pentru SPF și precizează că mai multe înregistrări SPF cu același nume de proprietar produc o eroare permanentă. Cu alte cuvinte, nu creați o a doua v=spf1înregistrare TXT doar pentru că adăugați un alt serviciu de e-mail.

Dacă serverul dvs. Zimbra trimite direct de la o adresă IPv4 publică stabilă, un exemplu minim este:

v=spf1 ip4:203.0.113.10 -all

Dacă toate gazdele la care face referire înregistrările MX ale domeniului dvs. sunt expeditori legitimi de ieșire, ați putea utiliza mx; dacă un serviciu terț publică un domeniu de includere SPF, este posibil să aveți nevoie de un include:mecanism. Înregistrarea exactă este specifică implementării, deci nu există un singur șir SPF Zimbra universal corect.

O altă greșeală frecventă este presupunerea că ~alleste întotdeauna mai sigur decât -all. Adevărata întrebare este dacă inventarul expeditorilor autorizați este complet. Un strict -alleste rezonabil atunci când este. Acțiune: autorizați fiecare expeditor legitim dintr-o înregistrare SPF, verificați-o în producție, apoi alegeți allcalificatorul final pe baza acestor dovezi.

Păstrați SPF relativ simplu. RFC 7208 limitează mecanismele și modificatorii care declanșează căutări DNS la 10 în timpul evaluării; depășirea limitei poate duce la permerror. Acțiune: numărați includerile și alte mecanisme de extindere DNS înainte de a adăuga un alt furnizor.

Pasul 4: Publicați mai întâi DMARC în modul de monitorizare

Politica DMARC este publicată la _dmarc.example.com. O primă înregistrare precaută este:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=nonesolicită destinatarilor să nu modifice gestionarea pe baza politicii DMARC în timp ce colectați date. Adresa ruasolicită rapoarte agregate; formatul actual al raportului agregat este specificat de RFC 9990. Utilizați o cutie poștală sau un serviciu de raportare capabil să proceseze rapoarte DMARC în loc de o cutie poștală personală nesupravegheată.

Nu copiați orbește pct=10, pct=25, sau exemple similare de implementare din articole mai vechi. RFC 9989 marchează pctca istoric deoarece experiența operațională a arătat o aplicare inconsistentă. Standardul actual folosește [numele codului] t=ypentru testarea comportamentului atunci când este necesar. Acțiune: începeți cu p=noneși analizați rapoartele; nu vă bazați pe eșantionarea procentuală ca mecanism de siguranță.

Pasul 5: Verificați toate cele trei înregistrări în DNS-ul public

După ce furnizorul DNS a publicat înregistrările, interogați-le din afara serverului autoritativ sau de la un resolver care vede DNS public. De exemplu:

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

Pentru SPF, confirmați că există un singur răspuns TXT care începe cu v=spf1la numele proprietarului respectiv. Pentru DKIM, confirmați că selectorul se potrivește exact cu valoarea stocată în prezent de Zimbra. Pentru DMARC, confirmați că există o singură înregistrare de politică DMARC utilizabilă la numele așteptat.

Propagarea DNS este condiționată de furnizorul dvs., TTL și memoria cache a resolverului. O modificare care apare imediat pe un server de nume autorizat poate fi totuși stocată în memoria cache în altă parte. Acțiune: testați cu cel puțin un resolver public independent înainte de a da vina pe Zimbra pentru un răspuns vechi.

Pasul 6: Trimiteți un mesaj real și verificați alinierea autentificării

Trimiteți un mesaj din domeniul Zimbra către o cutie poștală de pe un alt furnizor și inspectați anteturile complete ale mesajelor. Un rezultat reușit ar trebui să arate în mod normal o semnătură DKIM și/sau un rezultat SPF acceptat, plus acceptarea DMARC, deoarece cel puțin o identitate autentificată se aliniază cu domeniul De la vizibil.

Aici devine vizibilă o altă concepție greșită: DMARC nu necesită ca atât SPF, cât și DKIM să fie acceptate. Necesită o identitate SPF aliniată care să fie acceptată sau o identitate DKIM aliniată care să fie acceptată. RFC 9989 definește alinierea relaxată ca implicită pentru ambele aspfși adkim, deși puteți solicita o aliniere strictă cu s. Acțiune: inspectați Authentication-Resultsși identificați exact ce mecanism furnizează acceptarea DMARC aliniată.

Pasul 7: Treceți de la monitorizare la aplicare numai după ce rapoartele sunt clare

Odată ce datele DMARC arată că expeditorii legitimi se autentifică și se aliniază corect, puteți modifica politica la p=quarantinesau eventual p=reject. În standardul actual, none, quarantineși rejectexprimă evaluarea proprietarului domeniului privind utilizarea neautentificată, dar destinatarii își păstrează în continuare discreția privind gestionarea locală.

Nu tratați p=rejectca pe o optimizare a livrabilității. DMARC este în principal un control al autentificării și al abuzului de domeniu; nu face ca mesajele dorite să fie automat de încredere și nu garantează plasarea în inbox. Acțiune: faceți din aplicarea legii o decizie de securitate bazată pe o acoperire de autentificare aliniată, nu pe o promisiune a unor rate mai mari de livrare în inbox.

Pasul 8: Rotiți cheile DKIM fără a șterge imediat vechea înregistrare DNS

Pentru a actualiza datele DKIM pentru un domeniu, Zimbra documentează:

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

Comanda creează date DKIM actualizate și produce o nouă intrare DNS. Zimbra recomandă în mod specific păstrarea înregistrării TXT anterioare în DNS pentru o perioadă de timp, astfel încât mesajele semnate cu cheia anterioară să poată fi verificate în timp ce sunt în tranzit sau în coadă. Acțiune: publicați mai întâi noul selector, verificați-l și păstrați temporar selectorul anterior înainte de a-l elimina.

Referință rapidă: ce dovedește fiecare înregistrare

Verificări specifice Zimbra care merită făcute

Ghidul Zimbra privind protecția e-mailurilor menționează că DKIM trebuie generat per domeniu și publicat în DNS-ul public al fiecărui domeniu. De asemenea, documentează problemele de aliniere care pot apărea la anumite personaje sau comportamentul răspunsurilor automate în configurații mai vechi. Aceste detalii sunt situaționale, nu universale: dacă implementarea dvs. utilizează aliasuri, personaje, relee sau rescriere neobișnuită a envelopelor de la destinație, testați separat acele căi de mesaje.

Pentru o instalare Zimbra pe mai multe domenii, repetați configurarea DKIM și publicarea DNS pentru fiecare domeniu de trimitere. SPF și DMARC sunt, de asemenea, politici de domeniu; nu presupuneți că o înregistrare pe un domeniu găzduit acoperă automat un alt domeniu fără legătură. Acțiune: construiți o mică matrice de testare pentru fiecare domeniu și fiecare rută de ieșire înainte de a activa aplicarea strictă a DMARC.

Lista de verificare finală pentru validare

• Există exact o singură înregistrare SPF care începe cu v=spf1la fiecare domeniu de trimitere.
• Înregistrarea SPF include fiecare rută de ieșire autorizată și se încadrează în limitele de procesare DNS SPF.
• Zimbra semnează e-mailurile trimise cu selectorul stocat pentru domeniul respectiv.
• Cheia publică DKIM corespunzătoare este vizibilă în DNS-ul public sub selector._domainkey.
• Înregistrarea TXT DMARC este publicată la _dmarc.domainși folosește sintaxa curentă.
• Mesajele de test externe arată o trecere SPF sau DKIM aliniată și, prin urmare, o trecere DMARC.
• Rapoartele agregate sunt revizuite înainte de trecerea de la monitorizare la carantină sau respingere.
• Selectorii DKIM vechi sunt păstrați temporar în timpul rotației și eliminați numai după fereastra de tranziție.

Dacă aceste verificări sunt satisfăcătoare, serverul dvs. Zimbra nu publică doar trei înregistrări DNS; acesta prezintă un lanț de autentificare coerent pe care receptorii la distanță îl pot valida. Această distincție contează mai mult decât copierea oricărui șir de exemplificări dintr-un ghid, deoarece sursele SPF corecte, selectorul DKIM și momentul aplicării DMARC depind de modul în care propria dvs. e-mail părăsește efectiv organizația.