Administratorii de severe de e-mail private pentru business se confrunta adesea cu foarte multe probleme si provocari. De la valurile de SPAM care trebuie blocate prin filtre specifice, securitatea corespondentei in serverul local de e-mail si serverele la distanta, configurarea si monitorizarea serviciilor SMTP, POP, IMAP, plus multe si multe alte detalii de configurare SPF, DKIM si DMARC pentru a respecta bunele practici de expediere securizata a mesajelor e-mail.
Multe probleme de expediere mesaje e-mail sau receptionare catre / de la ati provideri, apar din cauza configurarii incorecte a zonei DNS, ce tine de serviciul de e-mail.
Pentru ca de pe un nume de domeniu sa poata fi trimise e-mail-uri, acesta trebuie sa fie hostat pe un server de e-mail configurat corespunzator, iar numele de domeniu sa aibe zonele DNS pentru SPF, MX, DMARC SI DKIM setate corect in managerul DNS TXT al domeniului.
In articolul de azi ne vom opri asupra unei probleme destul de des intalnite pe serverele de e-mail private pentru business. Imposibilitatea de a trimite mesaje e-mail catre conturi de Gmail, Yahoo! sau iCloud.
Cuprins
Mesajele expediate catre @Gmail.com sunt respinse automat. “Mail delivery failed: returning message to sender”
Am intalnit recent o problema pe un domeniu de e-mail al unei companii, de pe care se expediaza regulat mesaje e-mail catre alte companii si catre persoane fizice, unele dintre acestea avand adrese @gmail.com. Toate mesajele expediate catre conturile de Gmail reveneau imediat la expeditor. “Mail delivery failed: returning message to sender”.
Mesajul de eroare returnat in serverul de e-mail pe EXIM arata in felul urmator:
1nSeUV-0005zz-De ** reciver@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtpIn acest scenariu nu este ceva foarte grav, cum ar fi includerea numelui de domeniu expeditor sau IP expeditor intr-o lista de SPAM globala sau o eroare majora de configuratie a serviciilor de e-mail pe sevrer (EXIM).
Chiar daca multi cand vad acest mesaj se duc cu gandul imediat la SPAM sau o la eroare de configurare SMTP, problema este generata de zona DNS TXT a domeniului. De cele mai multe ori, DKIM nu exista configurat in zona DNS sau nu este trecut corect in managerul DNS al domeniul. Des intalnita aceasta problema la cei care folosesc CloudFlare ca DNS Manager si uita sa treaca DNS TXT: mail._domainkey (DKIM), DMARC si SPF.
Asa cum ne spune si in mesajul de respingere de la Gmail, autenticitatea si autentificarea domeniul expeditor, a esuat. “This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks.”. Asta inseamna ca domeniul nu are configurate DNS TXT pentru a asigura credibilitate pentru serverul de e-mail destinatar. Gmail, in scenariul nostru.
Atunci cand adaugam un domeniu web cu serviciu de e-mail activ pe cPanel sau VestaCP, se creeaza automat si fisierele din zona DNS a domeniului respeciv. Zona DNS care contine inclusiv configuratia serviciului de e-mail: MX, SPF, DKIM, DMARC.
In situatia in care alegem ca domeniul sa fie pe manager DNS CloudFlare, zona DNS din contul de hosting al domeniului respectiv, trebuie copiata in CloudFlare, pentru ca domeniul de e-mail sa functioneze corect. Asta a fost problema in scenariul de mai sus. Intr-un manager DNS tert, nu exista inscrierea DKIM, desi ea exista pe managerul DNS al serverului local.
Ce este DKIM si de ce sunt rejectate e-mail-urile daca nu avem acesta caracteristica pe un domeniu de e-mail?
DomainKeys Identified Mail (DKIM) este o solutie standard de autentificare a unui domeniu e-mail, care adauga o semnatura digitala fiecarui mesaj expediat. Serverele de destinatie pot verifica prin DKIM daca mesajul vine de pe domeniul de drept al expeditorului si nu de pe un alt domeniu care foloseste ca masca identitatea expeditorului. Pe intelesul tuturor, daca aveti domeniul abcdqwerty.com fara DKIM, pot fi expediate mesaje e-mail de pe alte servere, folosind numele dvs. de domeniu. Este daca vreti un furt de identitate, care in termeni tehnici se numeste email spoofing.
O tehnica des intalnita atunci cand sunt expediate mesaje e-mail de phishing si spam.
Tot prin intermediul DKIM se poate asigura ca, continutul mesajului nu a fost modificat dupa ce a fost trimis de expeditor.
Avand DKIM setat corect pe severul gazda al sistemului de e-mail si in zona DNS, se elimina mult si posibilitatea ca mesajele dvs. sa ajunga in SPAM la destinatar sau sa nu ajunga deloc.
Un exemplu de DKIM este:
mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"Desigur, valoarea DKIM obtinuta prin algoritmul de cripatre RSA este unica pentru fiecare nume de domeniu si poate fi regenerata de pe serverul gazda al serviciului de e-mail.
Avand DKIM instalat si setat corect in DNS TXT manager, este foarte posibil sa rezolve problema mesajelor returnate catre conturile de Gmail. Cel putin pentru eroarea “Mail delivery failed”:
“SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked.”
Ca o scurta recapitulare, DKIM adauga o semnatura digitala fiecarui mesaj trimis, ceea ce permite serverelor de destinatie sa verifice autenticitate expeditorului. Daca mesajul a venit de la compania dvs. si nu a fost folosita adresa de o terta parte, cu scopul de a se folosi de identitatea dvs.
Gmail (Google) poate respinge automat toate mesajele care vin de pe domenii care nu au o astfel de semantura digitala DKIM.
Ce este SPF si de ce este important pentru expedierea in siguranta a mesajelor e-mail?
La fel ca si DKIM, si SPF are scopul de a preveni mesajele phishing si email spoofing. In acest fel mesajele expediate nu vor mai fi marcate ca spam.
Sender Policy Framework (SPF) este o metoda standard de autentificare a domeniului de pe care sunt expediate mesajele. Intrarile SPF sunt setate in managerul DNS TXT al domeniului dvs. iar in aceasta intrare va fi specificat numele de domeniu, IP-ul sau domeniile care au dreptul sa expedieze mesaje in e-mail folosind numele de domeniu al dvs. sau al organizatiei.
Un domeniu fara SPF poate permite spammerilor sa trimita mesaje de e-mail de pe alte servere, folosind ca masca numele dvs. de domeniu. In acest fel se pot raspandi informatii false sau se pot solicita date sensibile in numele organizatiei dvs.
Desigur, mesajele pot fi trimise in continuare in numele dvs. de pe alte servere, insa acestea vor fi marcate ca spam sau vor fi respinse, daca acel server sau nume de domeniu nu este specificat in intrarea SPF TXT a domeniului dvs.
O valoare SPF in DNS manager arata de forma:
@ : "v=spf1 a mx ip4:x.x.x.x ?all"Unde “ip4” reprezinta IPv4 al serverului dvs. de e-mail.
Cum setam SPF pentru mai multe domenii?
Daca dorim sa autorizam si alte domenii care sa trimita mesaje e-mail in numele domeniului nostru, le vom specifica cu valoarea “include” in SPF TXT:
v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~allAsta inseamna ca de pe numele domeniul nostru de e-mail se pot expedia mesaje e-mail si de pe example1.com si example2.com.
Este un record foarte util daca avem de exemplu un magazin online pe adresa “example1.com“, dar dorim ca mesajele din magazinul online catre clienti sa plece de pe adresa de domeniu a companiei, aceasta fiind “example.com“. In SPF TXT pentru “example.com”, ca fi nevoie sa specificam alaturi de IP si “include:example1.com”. Astfel ca de pe aceasta sa poata fi expediate mesaje in numele organizatiei.
Cum setam SPF pentru IPv4 si IPv6?
Avem un server de mail atat cu IPv4 cat si cu IPv6, este foarte important ca in SPF TXT sa fie specificate ambele IP-uri.
v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~allIn continuare, dupa “ip” poate fi folosita directiva “include” pentru a adauga domenii autorizate pentru expediere.
Ce inseamna “~all“, “-all” si “+all” ale SPF?
Asa cum am spus mai sus, providerii (ISP) pot primi in continuare mesaje e-mail in numele organizatiei dvs. chiar daca aceste sunt trimise de pe un domeniu sau IP care nu este specificat in politica SPF. Eticheta “all” spune serverelor de destinatie cum sa trateze aceste mesaje venite de pe alte domenii care nu sunt autorizate si trimit mesaje in numele dvs. sau al organizatiei.
~all : Daca mesajul este primit de la un domeniu care nu este listat in SPF TXT, mesajele vor fi accepate pe serverul de destinatie, insa ele vor fi marcate ca spam sau ca fiind suspecte. Se vor supune filtrelor anti-spam de bune practici ale providerului destinatar.
-all : Este cel mai strict tag adaugat unei intrari SPF. Daca domeniul nu este listat, mesajul va fi marcat ca neautorizat si va fi respins de provider. Acesta nu va fi livrat nici macar in spam.
+all : Foarte rar folosit si deloc recomandat, acest tag permite altora sa trimita mesaje de e-mail in numele dvs. sau al organizatiei. Cei mai multi provideri resping automat toate mesajele e-mail care vin de pe domenii cu SPF TXT “+all“. Tocmai pentru ca nu se poate verifica autencititatea expeditorului, decat in urma unei verificari de “email header”.
Rezumat: Ce inseamna Sender Policy Framework (SPF)?
Autorizeaza prin intermediul zonei DNS TXT / SPF, IP-uri si nume de domenii care pot expedia mesaje e-mail de pe domeniul dvs. sau al companiei. Totodata aplica consecintele care se aplica pentru mesajele care sunt trimise de pe domenii neautorizate.
Ce inseamna DMARC si de ce este important pentru server de e-mail?
DMARC (Domain-based Message Authentication Reporting and Conformance) este strans legat de standardele de politici SPF si DKIM.
DMARC este un sistem de validare conceput pentru a proteja numele de domeniu e-mail al dvs. sau al companiei, de practici precum email spoofing si phishing scams.
Folosind standardele de control SPF (Sender Policy Framework) si DKIM (Domain Keys Identified Mail), DMARC adauga o caracteristica foarte importanta. Raportarea.
Cand un proprietar de domeniu publica DMARC in zona DNS TXT, va obtine informatii despre cine trimite mesaje de e-mail in numele lui sau al companiei care detine domeniul protejat cu SPF si DKIM. Totodata providerii destinatari ai mesajelor vor sti daca si cum aceste politici de bune practici sunt monitorizate de proprietarul domeniului expeditor.
O intregistrare DMARC in DNS TXT poate fi de forma:
V=DMARC1; rua=mailto:report-id@rep.example.com; ruf=mailto:account-email@for.example.com; p=none; sp=none; fo=0;In DMARC se pot pot pune mai multe conditii de raportare a incidentelor cat si adresele de e-mail pe care sa ajunga analizele si rapoartele. Este indicat sa folositi adrese de e-mail dedicate pentru DMARC deoarece volumul de mesaje primite poate fi semnificativ.
Etichetele DMARC pot fi setate in functie de politica impusa de dvs. sau de organizatie:
v – versiunea protocolului DMARC existent. p – aplica aceasta politica atunci cand nu se poate verificarea DMARC pentru mesajele e-mail. Poate avea valorea: “none“, “quarantine” sau “reject“. Se utilizeaza “none” pentru a obtine rapoarte despre fluxul mesajelor si starea acesora.rua – Este o lista de URL-uri pe care ISP-urile pot trimite feedback in format XML. Daca adaugam aici adresa de e-mail, link-ul va fi de forma: “rua=mailto:feedback@example.com” .ruf – Lista de URL-uri pe care ISP-urile pot trimite rapoarte despre incidente si infractiuni cibernetice facute in numele organizatiei dvs. Adresa va fi de forma: “ruf=mailto:account-email@for.example.com“. rf – Formatul de raportare a infractiunilor cibernetice. Poate fi de forma “afrf” sau “iodef“. pct – Indica furnizorului de internet / ISP sa aplice politica DMARC numai pentru un anumit procent de mesaje esuate. De exemplu, putem avea: “pct=50%” sau politicile “quarantine” si “reject“. Niciodata nu va fi acceptat “none“. adkim – Specifica “Alignment Mode” pentru semnaturile digitale DKIM. Asta inseamna ca se verifica potrivirea semnaturii digitale a unei intrari DKIM cu domeniul. adkim poate avea valorile: r (Relaxed) sau s (Strict). aspf – In acelasi mod ca si in cazul adkim se specifica “Alignment Mode” pentru SPF si suporta aceleasi valori. r (Relaxed) sau s (Strict). sp – Aceasta politica se aplica pentru a permite subdomeniilor derivate din domeniul organizatiei, sa foloseasca valoarea DMARC a domeniului. Se evita astfel folosirea de politici separate pentru fiecare domeniul in parte. Este practic un “wildcard” pentru toate subdomeniile. ri – Prin aceasta valoare se seteaza intervalul la care se vor primi rapoarte XML pentru DMARC. De cele mai multe ori, raportarea este de preferat sa se faca zilnic. fo – Optiuni pentru rapoarte de frauda. “Forensic options“. Acestea pot avea valorile “0” pentru a raporta incidentele atunci cand esueaza atat verificarea SPF cat si DKIM, sau valoarea “1” pentru scenariul in care SPF sau DKIM nu exista sau nu trec verificarea.
Asadar, pentru a fi siguri ca mesajele de e-mail ale dvs. sau ale companiei ajung la destinatari in Inbox, este necesar sa tineti cont de aceste trei standarde de “bune practici pentru expediere mesaje e-mail“. DKIM, SPF si DMARC. Toate aceste trei standarde tin de DNS TXT si pot fi administrate din managerul DNS al domeniului.
1 thought on “Cum configuram zona DNS TXT pentru SPF, DKIM si DMARC si cum evitam ca mesajele e-mail business sa fie respinse de Gmail – Mail delivery failed”