Ha a webshopos e-mailek spambe kerülnek vagy meg sem érkeznek, először azt kell tisztázni, hol hibásodik meg a folyamat. Más megoldást igényel, ha a webshop nem hoz létre értesítést, a levélküldő szolgáltatás elutasítja a kérést, vagy a fogadó postaláda a levélszemét közé sorolja a levelet.
A következő hibakeresési sorrenddel elkerülhető, hogy találomra telepíts SMTP-bővítményeket és átállítsd a DNS-rekordokat.
Először kövesd végig egyetlen rendelés üzenetét
Készíts saját próbavásárlást ellenőrzött tesztpostaládával. Jegyezd fel a rendelés azonosítóját, a küldési eseményt, az időpontot és a szolgáltató üzenetazonosítóját. Ezzel ugyanazt az e-mailt tudod követni a webshopban és a levélküldő rendszerben.
- Létrejött az értesítés? Nézd meg a WooCommerce vagy más webshopmotor rendelési státuszát és e-mail-beállításait.
- Átvette a küldő szolgáltató? Ellenőrizd a csatlakozást, hitelesítést és a kvótákat.
- Elfogadta a fogadó szerver? Olvasd el a visszapattanási vagy halasztási hibakódokat.
- Hova került a levél? Vizsgáld meg a spam mappát, a szűrőket és a továbbítási szabályokat.
- Minden címzettnél ugyanaz a hiba? Tesztelj több, saját kezelésű postaládával.
A szolgáltatói naplóban szereplő „kézbesítve” státusz gyakran csak a fogadó levelezőszerver átvételét jelenti. Nem bizonyítja, hogy a levél a beérkező mappában landolt vagy elolvasták.
Milyen szerepe van az SPF, DKIM és DMARC beállításoknak?
Az SPF a küldésre jogosult levelezőszerverek ellenőrzésében vesz részt. A DKIM digitális aláírást használ az üzenet hitelesítéséhez. A DMARC a látható feladói domain és a hitelesített domain összhangját vizsgálja, emellett feldolgozási szabályt és jelentési lehetőséget biztosít.
A Gmail hivatalos feladói útmutatója külön feltételeket szab az általános és a napi 5000-nél több Gmail-címzettet elérő küldésre. Érdemes mindhárom beállítást megfelelően konfigurálni, de önmagukban ezek sem garantálják, hogy egy levél a beérkező mappába jut.
Ha a webshop mellett számlázó és hírlevélküldő szolgáltatás is használja ugyanazt a domaint, az összes jogos feladót fel kell mérni. Ne másold át egy másik webhely SPF-beállítását, mert ezzel a saját leveleid egy részét is hibássá teheted.
Mitől lesz megbízható a küldés SMTP-vel vagy e-mail API-val?
Mindkettő működő megoldás lehet. A fontos kérdés, hogy a választott szolgáltatás ad-e részletes naplókat, hibakódokat, megfelelő kvótát és biztonságos újrapróbálási lehetőséget. Egy SMTP-plugin telepítése nem helyettesíti a domainhitelesítést, és nem javítja automatikusan a küldő hírnevét.
Átmeneti szerverhiba esetén indokolt lehet az újrapróbálás. Véglegesen hibás címnél viszont ugyanazt az üzenetet nem érdemes végtelenségig újraküldeni. A naplózásnál kerüld a szükségtelen vásárlói adatok és titkos azonosítók tárolását.
Rendelési üzenetek és hírlevelek ne keveredjenek
A vásárlás visszaigazolása, a szállítási tájékoztató és a marketingkampány külön üzleti célt szolgál. Technikailag is hasznos lehet elkülönített küldési folyamattal, sablonnal és forgalomkövetéssel kezelni őket. A marketingcélú kommunikációhoz szükséges hozzájárulás és leiratkozási folyamat nem vezethető le automatikusan egy rendelés tényéből.
A rendelési értesítések időérzékenyek. Érdemes úgy kialakítani a rendszert, hogy egy nagyszámú hírlevélküldés vagy átmeneti szolgáltatói hiba ne tartsa fel a vásárlói tájékoztatást.
Hol keresd a hibát, ha nem érkezik rendelés-visszaigazolás?
Érdemes különválasztani az üzenet létrehozását, elküldését és kézbesítését. Ha a WooCommerce-ben a rendelés megfelelő állapotba került, de nem indult el az értesítés, elsőként a webáruház e-mail-beállításait és a rendelési eseményt kell ellenőrizni. Ha a levélküldő szolgáltatás már átvette az üzenetet, a további kérdés az, hogy elfogadta-e a fogadó levelezőrendszer. Ha elutasította, az okot gyakran naplóban vagy hibakódban lehet megtalálni.
Az egyes próbarendeléseknél jegyezd fel az időpontot, a rendelés azonosítóját és a címzettet. Ez lehetővé teszi a webshop eseménynaplójának és a levelezőszolgáltatás naplójának összevetését. Ne kizárólag annyit figyelj, hogy „nem jött meg az e-mail”. Egy tartós hiba megoldásához tudni kell, pontosan hol szakadt meg az út. A vizsgálathoz saját, tesztelésre használt postaládákat válassz.
Hogyan állítsd be a feladó domaint?
Az SPF, a DKIM és a DMARC különböző, egymást kiegészítő feladatot látnak el. Az SPF azt segít ellenőrizni, mely szerverek küldhetnek levelet a domain nevében. A DKIM digitális aláírással támogatja az üzenet hitelességének ellenőrzését. A DMARC pedig a feladóként látható domain és a hitelesítési eredmények összhangjára vonatkozó szabályokat tesz lehetővé. Ezek fontosak a kézbesíthetőséghez, de a jó beállítás sem garantálja, hogy minden fogadó postaláda a beérkezett üzenetek közé sorolja a levelet.
Különösen gyakori hiba, hogy a webshop több rendszeren át küld: egyszer a tárhely levelezőjét használja, máskor egy külön e-mail-szolgáltatót. A szükséges DNS-rekordokat ilyenkor a ténylegesen használt szolgáltatásokhoz kell kialakítani. Az SPF-rekordok összevonására is figyelni kell; az ugyanazon domainhez közzétett több különálló SPF-rekord hibát okozhat. A részletes feladói követelményeket a Gmail hivatalos útmutatója ismerteti.
Miért más a vásárlói értesítés és a hírlevél?
A rendelés-visszaigazolás a vásárlás működéséhez kapcsolódó tranzakciós üzenet. A hírlevél ezzel szemben marketingkommunikáció, amelynek célja és hozzájárulási követelményei eltérhetnek. Üzemeltetési szempontból sem szerencsés a kettőt úgy összekeverni, hogy egy nagyobb kampány forgalma hátrányosan befolyásolja a rendelési értesítések küldését.
Gondolj arra, mi történik az ügyfélszolgálaton, ha a vásárló fizetett, de nem kapott visszaigazolást. Nemcsak a technikai hiba számít: a hiányzó üzenet bizalmatlanságot, többletmunkát és ismételt érdeklődéseket is okozhat. A kézbesítés ellenőrzése ezért legyen a webshop üzemeltetésének rendszeres része. Ha szolgáltatót váltasz, az új rendszert próbáld ki néhány tesztrendeléssel, mielőtt az összes vásárlói értesítést átirányítanád.
Miért fontos külön ellenőrizni a vásárlói és a belső értesítéseket?
Az ügyfélnek szánt rendelés-visszaigazolás és az üzlet munkatársának küldött újrendelés-értesítés nem ugyanazt a célt szolgálja. Előfordulhat, hogy az egyik levél létrejön, a másik nem, vagy eltérő címre és feladóval megy ki. A hibakeresés ezért ne álljon meg annál, hogy „a webshop küld e-mailt”. Külön próbarendeléssel ellenőrizd a vásárlói visszaigazolást, a belső jelzést, és ha van ilyen, a sikertelen fizetéshez kapcsolódó értesítést is.
Érdemes feljegyezni, pontosan mikor indult el a küldés, melyik címre és milyen tárggyal. Ha a szolgáltató naplója kézbesítési hibát jelez, azt másként kell kezelni, mint amikor a webshop egyáltalán nem kezdeményezte a levélküldést. Így a tárhely, a bővítmény és a külső levélküldő közötti felelősséget is gyorsabban el lehet különíteni.
Hogyan bizonyítsd, hogy megszűnt a hiba?
Tesztelj új rendelést, sikertelen fizetést, státuszváltást és szükség esetén újraküldést. Minden esetnél rögzítsd az elvárt címzettet, tárgyat és értesítésszámot. Nézd meg a ténylegesen megérkezett üzenetet is: helyesek-e a rendelési adatok és a hivatkozások?
Az e-mail-kézbesítési hiba javítása után végezz teljes próbavásárlást, és ellenőrizd a rendelés visszaigazolását, a számlázási értesítéseket és az esetleges sikertelen küldés kezelését. Ha a gond a webshop és a levélküldő szolgáltatás kapcsolatában van, érdemes átnézni a KovaBuild webshopfejlesztési és integrációs szolgáltatását is.
A cél nem az, hogy „küldjön levelet a webshop”, hanem hogy a fontos értesítések útja ellenőrizhető és hibakereshető legyen.