EAGLE SOLUTIONS
Un instrument de verificare a domeniilor a pus un semn galben lângă domeniul meu: „DMARC: Policy set to p=none – messages are logged but not blocked.” O propoziție despre care nu e evident, la prima vedere, dacă merită atenție.
Merită. Pe românește înseamnă: dacă cineva scrie clienților mei folosind adresa mea, serverul destinatarului observă că e falsă – și o livrează oricum.
Remedierea e o singură linie în DNS. Tocmai de aceea e periculoasă: cine schimbă doar acea linie are șanse mari să-și amuțească mesajele propriului formular de contact. Era să pățesc exact asta.
Trei înregistrări, trei propoziții
Autentificarea e-mailului stă pe trei înregistrări DNS, fiecare răspunzând la altceva:
- SPF – ce servere au voie să trimită e-mailuri în numele domeniului tău.
- DKIM – o semnătură digitală pe mesajul propriu-zis, din care se vede că nu a fost modificat pe drum și că vine într-adevăr de la tine.
- DMARC – ce să se întâmple dacă primele două nu se potrivesc și cine primește rapoarte despre asta.
DMARC are trei trepte: `p=none` (înregistrează, dar livrează), `p=quarantine` (la spam) și `p=reject` (nici să nu fie preluat). Pe majoritatea domeniilor pe care le văd este `p=none` – sau nimic.
Nu e un risc teoretic. Un e-mail falsificat de pe adresa ta către clientul tău – ofertă, factură, „ne-am schimbat contul bancar” – arată exact ca al tău. Paguba o suferă clientul, dar numele tău rămâne pe ea.
Capcana: și propriul tău site e un „expeditor străin”
Înainte să schimb ceva, am verificat ce trimite de fapt e-mailuri în numele meu. S-a dovedit că veriga cea mai slabă era propriul meu WordPress.
WordPress folosește implicit funcția de trimitere a serverului, iar expeditorul e o adresă de forma `wordpress@domeniultau.ro`. Acest e-mail nu minte pe nimeni, doar că nu se potrivește nici cu SPF, nici cu DKIM. Cu `p=none` asta poate trece ani de zile, pentru că efectul e exact cât promite `none`: niciunul.
Dacă însă treci la `p=reject` din această stare, de atunci:
- notificarea formularului de contact nu mai ajunge la tine,
- confirmarea automată către vizitator nu mai ajunge,
- e-mailul de resetare a parolei dispare,
- și totul se întâmplă în tăcere: fără eroare, fără folder de spam, pur și simplu nu sosește.
Asta e cea mai frecventă greșeală din domeniu. Activarea DMARC durează tehnic două minute. Să afli ce trimite în numele tău – asta e munca.
Măsoară, nu ghici
Folosesc două instrumente gratuite, ambele arată aceleași trei lucruri (SPF, DKIM, DMARC), doar cu detalii diferite:
- mail-tester.com – primești o adresă de unică folosință, trimiți un e-mail și primești o notă pe zece. Rapid, dar are o limită zilnică.
- learndmarc.com – același lucru, dar te plimbă pas cu pas prin toată verificarea și îți arată și alinierea. Fără limită.
Detaliul cel mai important, greșit de cei mai mulți: trimite e-mailul de test de acolo de unde pleacă și în realitate. Dacă trimiți din programul tău de e-mail, testezi dacă e în regulă căsuța ta – și probabil este. Site-ul tău trimite însă pe cu totul alt drum. La mine exact acolo era diferența.
Ce trebuie urmărit: SPF și DKIM nu doar să fie „pass”, ci să se și alinieze cu domeniul expeditorului vizibil. DMARC nu se decide după cum că există vreo semnătură pe mesaj, ci după faptul că aceasta aparține domeniului tău.
Remedierea: și site-ul să trimită dintr-o căsuță „adevărată”
Soluția nu e magie: WordPress să nu folosească expeditorul anonim al serverului, ci să trimită prin SMTP autentificat, dintr-o căsuță poștală reală – la mine adresa `hello@`. Astfel expeditorul aparține domeniului acoperit de SPF și DKIM.
La un lucru trebuie însă atenție, altfel iese mai rău decât era. Pe notificarea formularului, expeditorul era până acum adresa vizitatorului – de aceea puteai apăsa pur și simplu „Răspunde”. Dacă schimbi expeditorul cu adresa ta și nu faci nimic altceva, „Răspunde” îți trimite ție însuți.
Soluția corectă: expeditorul să fie căsuța ta (de aici autentificarea), iar adresa vizitatorului să ajungă în antetul Reply-To. Astfel, în exterior totul e regulamentar, iar pentru tine răspunsul funcționează ca înainte.
Ce am greșit – și ce a arătat doar o verificare a antetelor
Am scris codul, am trimis e-mailul de test și rezultatul a fost 10/10: SPF, DKIM, DMARC, toate verzi. Se putea opri acolo.
Nu m-am oprit, pentru că nu am privit doar nota, ci și antetul mesajului – iar Reply-To lipsea. Era greșeala propriului meu cod: schimbam expeditorul într-un punct care rulează înainte să pot salva adresa vizitatorului. Până să setez Reply-To, adresa originală nu mai exista.
Nota ar fi rămas impecabilă. În practică însă, la fiecare solicitare ar fi trebuit să copiez manual adresa din textul mesajului. După o săptămână e enervant, după o lună e sursă de erori.
Asta e cea mai seacă, dar și cea mai importantă propoziție a articolului: scorul total nu e verificare. Uită-te și la antetele reale ale mesajului – expeditor, Return-Path, Reply-To -, fiindcă autentificarea poate fi impecabilă chiar dacă e-mailul e prost în folosirea zilnică.
Rezultatul
Același traseu, înainte și după remediere:
- Înainte: expeditor `wordpress@…`, SPF nealiniat, DKIM inexistent, DMARC `p=none` – adică oricine putea scrie în numele meu, iar serverul destinatarului livra oricum.
- După: expeditorul e căsuța mea reală, SPF ✓ și aliniat, DKIM ✓ (semnătură pe 2048 de biți) și aliniat, DMARC ✓ chiar și cu cea mai strictă regulă `p=reject` – iar adresa vizitatorului stă în Reply-To, deci răspunsul e neschimbat.
Rapoartele DMARC le-am direcționat către un serviciu gratuit care trimite săptămânal un rezumat lizibil despre cine a încercat să trimită în numele domeniului meu. În loc de XML brut, propoziții omenești, un e-mail pe săptămână.
La ce să fii atent după
Odată activat DMARC, regula rămâne valabilă: orice serviciu nou care trimite cu adresa ta trebuie mai întâi adăugat în SPF și configurat cu DKIM. Program de facturare, newsletter, CRM, sistem de rezervări, helpdesk – oricare. Altfel mesajele lor dispar în tăcere.
Nu e un argument împotriva înăspririi. Înseamnă doar că trimiterea de e-mailuri face parte din sistem la fel ca domeniul sau găzduirea – nu merge de la sine, trebuie întreținută.
Cui îi trebuie asta
Oricui are un domeniu propriu și un formular de contact. Concret, e urgent dacă:
- trimiți facturi sau oferte pe e-mail,
- clienții tăi pot primi de la tine instrucțiuni financiare,
- ai magazin online și pleacă confirmări de comandă,
- sau pur și simplu contează ca mesajele tale să nu ajungă la spam.
Verificarea durează cinci minute și e gratuită: trimite un e-mail de test de pe site-ul tău către unul dintre instrumentele de mai sus și uită-te la cele trei rânduri. Dacă vreunul e roșu, ai ce face.
Dacă nu vrei să intri în detalii, vezi pachetele lunare de mentenanță – verificarea și întreținerea autentificării e-mailului fac parte din ele. Dacă ai doar o întrebare punctuală, scrie-mi liniștit.
Despre același mod de gândire e vorba și când am rulat trei audituri SEO pe propriul site: și acolo esențialul era că semnalul și realitatea nu sunt același lucru – trebuie măsurat.
