Bounce-uri și complaint-uri tratate automat, în secunde

Cum trimitem

Toate identitățile SES ale Syncron au configurat un Configuration Set care publică evenimentele Bounce, Complaint, Delivery și Reject într-un topic SNS dedicat. Un worker dedicat consumă topic-ul, parsează payload-ul JSON și actualizează în baza de date starea fiecărui mesaj, fiecărei adrese și, agregat, starea fiecărei identități. Latența mediană între eventul SES și reacția platformei este sub 3 secunde.

• Hard bounce (bounceType=Permanent) — adresa este adăugată instant pe lista de supresie a merchant-ului și pe lista globală de hard bounce-uri. Următoarele trimiteri către acea adresă sunt blocate înainte de a ajunge la SES, ceea ce ne ferește de recidive.
• Soft bounce (bounceType=Transient) — re-încercăm de maximum 3 ori, cu pauze de 1h, 4h și 24h. Dacă toate eșuează, adresa este mutată pe supresie permanentă.
• Complaint (complaintFeedbackType=abuse sau similar) — adresa este suprimată permanent, indiferent de merchant. O adresă care s-a plâns o dată nu mai primește niciodată email prin Syncron, nici tranzacțional, nici marketing.
• Reject — mesaj respins de SES însuși (de regulă conținut suspectat de malware). Loggăm și avertizăm merchant-ul.

Conformitate

Pragurile noastre operaționale sunt aliniate cu cele impuse de AWS pentru menținerea accesului la SES production:

• Rata maximă acceptată de bounce: 5% (pragul AWS „under review”). Alarma internă pornește la 3%.
• Rata maximă acceptată de complaint: 0.1% (pragul AWS „under review”). Alarma internă pornește la 0.05%.
• Procesarea cererilor de unsubscribe / opt-out: sub 60 de secunde — mult sub limita CAN-SPAM de 10 zile.
• Procesarea FBL primite de la Gmail, Yahoo, Outlook (via SES): instant, fără cale de bypass manual.
• Reținem datele de bounce și complaint 13 luni pentru audit GDPR și AWS, apoi le anonimizăm.

Garanții operaționale

Când rata de bounce a unei identități depășește 5% într-o fereastră de 24h, sau rata de complaint depășește 0.1%, platforma pune automat trimiterea acelui merchant în pauză și deschide un ticket intern. Nu așteptăm ca AWS să trimită notificare de „under review” — acționăm preventiv. Merchant-ul este notificat pe email și în consolă, primește lista cu cauzele cele mai frecvente (ex. „45% din bounce-uri vin din import-ul CSV din 14 mai”) și un ghid concret de remediere. Trimiterea se reactivează doar după ce listele problematice sunt curățate și verificate. Această mecanică este motivul pentru care reputația domeniilor noastre rămâne în limite sănătoase chiar și când onboardăm zeci de merchanți noi în paralel.