De ce e-mailul pe care l-ai trimis mai departe către tine a ajuns în spam

Configurezi o trimitere automată de la contul tău vechi la cel nou, și o parte din mesaje vor dispărea tăcut în spam — nu pentru că furnizorul tău e stricat, ci pentru că trimiterea mai departe rescrie cine trimite mesajul fără să rescrie dovada criptografică. SPF verifică serverul greșit, verdictul DMARC se schimbă la fail, și un e-mail legitim pe care ți l-ai trimis ție însuți ajunge în carantină. Remedia are un nume: ARC, definit în RFC 8617 din 2019.

De ce trimiterea mai departe face ca mailul meu să eșueze SPF?

Pentru că SPF verifică ultimul server care a relayat mesajul, iar trimiterea mai departe schimbă serverul. SPF — Sender Policy Framework — este o înregistrare DNS care listează care adrese IP sunt autorizate să trimită mail pentru un domeniu. Când bank.com ți trimite o chitanță, serverul receptor verifică: a venit asta de la o adresă IP autorizată de bank.com? Da. Pass.

Acum trimite mai departe acea chitanță de pe Gmail la noua ta adresă. Serverele Google o transmit mai departe. Serverul receptor final rulează verificarea SPF și întreabă: este Google autorizat să trimită pentru bank.com? Nu, nu este. SPF eșuează. Documentația proprie a Google pentru Workspace o explică clar — mesajele trimise mai departe eșuează SPF pentru că serverul care trimite mai departe nu se află în înregistrarea SPF a domeniului original. Nimic nu a fost falsificat. Verificarea se uită pur și simplu la hop-ul greșit.

Deci de ce trimit asta în spam?

DMARC. Doar SPF eșuând era cândva supraviețuibil; DMARC l-a transformat într-un verdict. DMARC leagă SPF și DKIM împreună și spune receptorilor ce să facă când ambele eșuează: nimic, carantină sau reject. Până în 2024, expeditorii mari nu aveau de ales — Google și Yahoo au început să ceară DMARC pentru oricine trimite mai mult de 5.000 de mesaje pe zi utilizatorilor lor.

DKIM, celălalt pilon, este o semnătură coapă în mesaj. În teorie, supraviețuiește trimiterii mai departe, pentru că semnează conținutul, nu ruta. În practică, orice atinge mesajul o rupe. O listă de difuzare care anexează un footer „ești abonat, dezabonează-te aici", un server care rescrie linia Subject, chiar și o schimbare în modul cum se împachetează o linie — semnătura nu se mai potrivește, și DKIM eșuează și el. Acum ambii piloni sunt căzuți, DMARC spune fail, și chitanța ta proprie e în folderul de junk.

Ce este ARC și chiar repară asta?

ARC — Authenticated Received Chain, RFC 8617 — permite unui forwarder cinstit să garanteze că mailul a trecut autentificarea înainte de a-l atinge. Serverul care trimite mai departe îmbuibatoasele mesajul cu o înregistrare sigilată spunând „când a ajuns asta la mine, SPF și DKIM erau valide — ai încredere în cuvântul meu pentru piciorul pe care nu-l poți verifica." Receptorul final, dacă are încredere în acel forwarder, poate înlătura verdictul DMARC fail și livra mesajul.

Capcanul e în „dacă are încredere." ARC nu e o parolă; e un sistem de reputație. Un receptor cântărește dacă sigilul ARC provine de la un operator cunoscut, bine-comportat. Google atât timbrează headere ARC cât și le recunoaște de la expeditori cărora le are încredere, de aceea o trimitere mai departe Gmail-la-Gmail supraviețuiește de obicei, în timp ce o trimitere mai departe printr-un relay de la o universitate veche nu face asta.

Dacă rulezi singur trimiterea mai departe, două mișcări concrete ajută. Folosește Server-Side Redirect / rescrierea în stil SRS dacă furnizorul tău o oferă, care rescrie expeditorul envelopei ca SPF să verifice împotriva forwarder-ului tău în loc de domeniul original. Și preferă trimiterea mai departe între furnizori care ambii suportă ARC. Dacă consolidezi conturi și vrei ca destinația să se ocupe pur și simplu de neînțelegerile de autentificare pentru tine, asta e exact felul de plumbing pentru care o platformă de email AI e construită să absoarbă.

Când ar trebui să nu mai învinovățesc furnizorul?

Când modelul e „doar mailul trimis mai departe eșuează," furnizorul ți face treaba corect — protocolul e problema. Iată semnul: deschide headerele mesajului lipsă și caută linia Authentication-Results. Dacă vezi spf=fail alături de o IP de trimitere care aparține unui forwarder mai degrabă decât expeditorului original, asta e SPF verificând hop-ul greșit. Dacă dkim=fail apare pe mail care a trecut printr-o listă sau un relay care editează mesaje, asta e o semnătură stricată, nu o falsificare.

Adevărul inconfortabil e că autentificarea e-mailului a fost lipită, strat peste strat, peste două decenii unui sistem care nu a presupus niciodată că cineva ar mințit. SPF a venit în 2006, DKIM în 2007, DMARC în 2015, ARC în 2019 — fiecare plătând o gaură pe care o deschisese cea precedentă. Trimiterea mai departe e cusătura unde toți patru se freacă unul de altul, și inboxul tău e locul unde simți fricțiunea.

@@END@@