Bounce, complaint a suppression list: co to je a proč chrání vaši doménu

„Zákazník říká, že mu nechodí e-maily, ale u vás je u jeho adresy napsáno suppressed. Odblokujte ho." Tenhle dotaz dostává každá e-mailová služba a odpověď na něj je složitější než „ano". Tenhle článek vysvětluje, co se děje, když e-mail nedojde, proč se některé adresy automaticky blokují, a proč je to ve vašem zájmu, i když to na první pohled vypadá jako překážka.

Co se děje po odeslání

Když relay předá e-mail cílovému serveru (Seznam, Gmail, Microsoft, firemní Exchange), server odpoví kódem. Zjednodušeně:

• 2xx: přijato. U nás stav delivered. Znamená to, že server e-mail převzal; do které složky ho zařadil, nikdo zvenku nezjistí.
• 4xx: dočasně odmítnuto. Stav deferred. Zkoušíme to znovu s rostoucím odstupem až 24 hodin.
• 5xx: trvale odmítnuto. Stav bounced.

Bounce tedy není „e-mail se ztratil", ale konkrétní odpověď cílového serveru, kterou u nás vidíte v poli reason i s původním textem.

Hard bounce vs. soft bounce

Hard bounce je trvalá chyba: adresa neexistuje (550 5.1.1 User unknown), doména nemá poštovní server, nebo server odmítá vaši doménu úplně. Další pokusy nepomohou. Nejčastější příčina v e-shopu je překlep při objednávce: jan.novak@gmial.com.

Soft bounce je dočasná chyba: plná schránka, přetížený server, greylisting (server první pokus odmítne a čeká, jestli to zkusíte znovu, což spam roboti nedělají). U nás je to stav deferred a řešíme ho opakováním. Pokud ani po 24 hodinách neprojde, skončí jako bounced s důvodem.

Rozdíl je důležitý pro to, co se stane dál.

Complaint: když si příjemce stěžuje

Příjemce klikne na „Označit jako spam". Jeho poskytovatel to zaznamená a u některých (Microsoft, Yahoo, Seznam) pošle odesílateli zprávu přes tzv. feedback loop: „uživatel X si stěžoval na e-mail Y". U nás to vidíte jako stav complained. Gmail individuální stížnosti neposílá; nabízí jen souhrnnou míru stížností v Postmaster Tools.

U transakčních e-mailů by stížnosti měly být výjimečné. Když se objevují, bývá příčina jedna z těchto:

• do potvrzení objednávky je přibalená reklama,
• e-maily chodí příliš často (pět notifikací k jedné zásilce),
• uživatel nepozná odesílatele (jiná značka, cizí doména „via"),
• adresu zadal někdo jiný (dárek, překlep, nebo zneužití formuláře).

Proč na tom poskytovatelům záleží

Gmail, Seznam a Microsoft hodnotí reputaci odesílající domény a IP adresy podle chování. Dva signály jsou nejsilnější:

1. Míra bounce. Kdo posílá na hodně neexistujících adres, buď má nakoupený seznam, nebo zastaralou databázi; obojí je znak spamera. Za bezpečnou hranici se obvykle považuje do 2 % hard bounce; nad 5 % se už reputace zhoršuje rychle.
2. Míra stížností. Gmail v požadavcích na odesílatele uvádí, že míra spamu v Postmaster Tools má zůstat pod 0,3 %, ideálně pod 0,1 %. Nad 0,3 % začnou e-maily končit ve spamu plošně, včetně těch transakčních.

A tady je zásadní věc: reputace je na doménu. Pokud váš newsletter vyrobí stížnosti, trpí tím i potvrzení objednávek ze stejné domény. Proto doporučujeme marketing a transakční provoz oddělit alespoň na subdomény.

Suppression list: pojistka, která funguje automaticky

Blokovaný seznam (suppression list) je seznam adres u vašeho účtu, na které služba odmítne odeslat, i když jí to aplikace přikáže. Dostanou se na něj:

• adresy po hard bounce,
• adresy, jejichž majitel si stěžoval,
• adresy, které se odhlásily (relevantní u e-mailů s odhlašovacím odkazem).

Pokus o odeslání na takovou adresu skončí stavem suppressed, neúčtuje se a dostanete o něm webhook jako o každé jiné změně stavu. Z pohledu reputace je to ta nejlepší věc, která se mohla stát: e-mail, který by skončil jako další bounce nebo další stížnost, vůbec neopustil vaši doménu.

Proč je to automatické a ne volitelné: protože aplikace to samy nedělají. E-shop ukládá adresu k objednávce a posílá na ni při každé změně stavu, bez ohledu na to, že první potvrzení se vrátilo. Bez blokovaného seznamu by stejný překlep vygeneroval pět bounce za jednu objednávku.

„Odblokujte mi zákazníka"

Vraťme se k dotazu z úvodu. Než adresu odblokujete, zjistěte, proč na seznamu je:

• Hard bounce kvůli překlepu: odblokování nepomůže, adresa neexistuje. Opravte ji v objednávce a pošlete na správnou.
• Hard bounce kvůli dočasnému problému, který server hlásil jako trvalý (stává se u firemních serverů po migraci): odblokování dává smysl, pokud zákazník potvrdí, že schránka funguje.
• Stížnost: odblokování je riziko. Příjemce řekl, že e-maily nechce; další zpráva je další stížnost. Výjimkou je, když si stížnost sám omylem vyrobil a výslovně o e-maily žádá.

U nás odebrání adresy zatím řešíme přes podporu (napíšete nám adresu a důvod), samoobslužnou správu seznamu v dashboardu připravujeme. Záměrně nechceme tlačítko „odblokovat vše", protože by bylo první, co by někdo v pátek odpoledne zmáčkl.

Co dělat ve své aplikaci

1. Zpracovávejte webhook bounced. Označte adresu u zákazníka jako neplatnou a při dalším přihlášení ho požádejte o opravu. Pokud máte telefon, pošlete SMS s důležitou informací (expedice, platba).
2. Validujte adresu při zadání. Ne regulárním výrazem na „správný formát", ale kontrolou, že doména má MX záznam, a varováním u typických překlepů (gmial.com, seznam.cu). Ušetříte většinu hard bounce dřív, než vzniknou.
3. Neposílejte transakční e-maily z newsletterové domény a naopak.
4. Sledujte míry. Bounce nad 2 % a stížnosti nad 0,1 % jsou důvod zjistit proč, ne čekat, až se to projeví.
5. Při migraci z jiné služby si vyexportujte její blokovaný seznam a importujte ho; jinak první týden pošlete na všechny mrtvé adresy znovu. Postup je v checklistu k migraci.

Shrnutí

Blokovaný seznam není překážka, ale pojistka. Chrání doménu, ze které posíláte potvrzení objednávek, před následky překlepů, mrtvých adres a vlastních chyb. Jak stavy sledovat přes API a webhooky, najdete v přehledu API a SMTP.