Kézbesítési ajánlások és kulcsforgatás
Feladó címe, SPF és DMARC, mellékletek korlátai, ingyenes SMTP-fiókok és Google/Microsoft kockázatai, valamint az API-kulcsok időnkénti cseréje.
Ezek az ajánlások a levelek megbízható kézbesítését segítik.
Érvényes feladói cím használata
Szekció neve “Érvényes feladói cím használata”Ellenőrizd a használt integrációnál megadott Feladó e-mail-címe mezőt. A címnek olyannak kell lennie, amelyet az integráció engedélyez feladóként. Ez általában a webhelyed domainjét használó cím. Ha nem vagy biztos benne, nézd meg az integráció leírását, vagy kérdezd a szolgáltató támogatását.
Gravity Forms értesítésnél a Gravity Forms hibaelhárítási leírásában is van erről megjegyzés.
SPF- és DMARC-rekordok beállítása
Szekció neve “SPF- és DMARC-rekordok beállítása”Az SPF- és DMARC-rekordok azt segítik, hogy a fogadó levelezőkiszolgálók ellenőrizni tudják a feladó hitelességét. Ezeket a domained DNS-beállításaiban kell megadnod, a domainregisztrátornál vagy a DNS-kezelő felületen.
Ha a rekordok hiányoznak vagy rosszul vannak beállítva, a levél kéretlennek minősülhet, vagy el is utasíthatják. A DMARC-rekord nem kötelező: bár elterjedt, nem minden levelezőkiszolgáló használja. Ha a szolgáltatód felajánlja a DMARC beállítását, érdemes élni vele.
- Egyéni SMTP integrációnál, ha a tárhelyed SMTP-kiszolgálóját használod, és a domained DNS-ét is ugyanaz a tárhely kezeli, lehet, hogy már van érvényes SPF-rekordod. Ha nem vagy biztos, kérdezd a tárhely támogatását.
- Külső SMTP- vagy API-integrációnál a szolgáltató részletes útmutatót és támogatást ad a rekordok beállításához. A DNS-rekordok beállításához a tárhelyed is segíthet.
A gyakori szolgáltatóknál (Brevo, Google, Mailgun, Microsoft 365, Postmark, SendGrid) a szolgáltató súgójában külön leírás van az SPF- és DMARC-beállításról.
A mellékletek szabályai
Szekció neve “A mellékletek szabályai”Az e-mail régebbi, mint az internet, és eredetileg néhány ezer kilobájtos postafiókokra tervezték. Egy ma kicsinek számító melléklet (például egy 20 MB-os fotó) nem volt része az eredeti szabványnak.
A levelezőkiszolgálók ezen a téren keveset változtak. Sok kiszolgáló és levelezőszolgáltató még mindig korlátozza a mellékletek számát, a mellékletek összméretét, az egyes fájlok legnagyobb méretét, sőt a fájltípust is.
A korlátozásokat a küldő kiszolgáló (az aktív integrációd) alkalmazza, ingyenes és fizetős szolgáltatásnál is. Ha a fizetős integráció nagyvonalú is, a levélre a szolgáltatói korlátok vonatkoznak. Az sem biztos, hogy a címzett szolgáltatója (Gmail, Yahoo!, Outlook 365 vagy céges levelezőkiszolgáló) fogadja a mellékletet, és akkor a levél nem érkezik meg.
Néhány gyakori integráció korlátja:
| Szolgáltató | Korlát |
|---|---|
| Mailgun | A levél legfeljebb 25 MB lehet a mellékletekkel együtt. |
| Postmark | A levél törzse legfeljebb 5 MB, mellékletekkel együtt legfeljebb 10 MB. |
| SendGrid | A levél legfeljebb 30 MB lehet a mellékletekkel együtt, de a mellékletek ne legyenek összesen 10 MB-nál nagyobbak. |
Ne használj ingyenes e-mail-fiókok SMTP-kiszolgálóját
Szekció neve “Ne használj ingyenes e-mail-fiókok SMTP-kiszolgálóját”Több ismert cég nyújt ingyenes e-mail-fiókot SMTP-támogatással, a legnépszerűbb a Google Gmail. Ezek az SMTP-kiszolgálók nem weboldalról való küldésre készültek, hanem személyes használatra, például a postafiók beállítására a telefonon vagy az asztali levelezőprogramban.
A szolgáltatók ezért több korlátozást is alkalmaznak. Egyiket dokumentálják, másikat figyelmeztetés nélkül érvényesítik. A leggyakoribb korlátozások:
- adott idő alatt küldhető levelek számának korlátja,
- a feladó címének megkötése a fiók saját címére,
- az egy levélben megadható címzettek számának korlátja.
Ezek csak példák, minden szolgáltató a sajátját alkalmazza. Ha mégis ingyenes fiók SMTP-kiszolgálóját használod, kérdezd meg a szolgáltatót a korlátairól. A korlátozások miatt nem ajánlott használni őket.
Google és Microsoft integrációk kockázatai
Szekció neve “Google és Microsoft integrációk kockázatai”A Google / Gmail és a Microsoft 365 / Outlook integráció általános fiókszolgáltatást használ, nem kifejezetten levélkézbesítésre épülő szolgáltatást (mint a Postmark vagy a Mailgun). A fiók csatlakoztatásakor nemcsak az SMTP-t, hanem a fiókhoz tartozó teljes szolgáltatáscsomagot elérhetővé teszed. Ezért ezek a cégek szigorúbb, folyamatosan változó biztonsági szabályokat alkalmaznak, ami hatással lehet a küldésre.
A leggyakoribb eset: a Gravity SMTP-n kívül történő művelet miatt a Google vagy a Microsoft fiók újra-hitelesítést kér. Amíg ezt nem veszed észre és nem végzed el, az integráció nem küld leveleket.
Újra-hitelesítést gyakran okoznak:
- a csatlakoztatott fiók jelszavának megváltoztatása,
- a kétlépcsős azonosítás (2FA) bekapcsolása a kezdeti csatlakoztatás után.
Ezek a Gravity SMTP-n kívül végzett műveletek megszakíthatják a kapcsolatot, és az integráció addig nem működik, amíg ki nem javítod.
Ha van választásod, a kifejezetten tranzakciós levelekre készült szolgáltató a jobb választás. Ilyenek például a Postmark, a Mailgun és a SendGrid. Stabilabbak, céltudatosabb útmutatót és könnyebben elérhető, a levélkézbesítési hibákban jártas támogatást adnak, a kézbesítésre vannak optimalizálva, és általában részletes naplót és statisztikát (kézbesítési állapot, megnyitások, visszapattanások) is nyújtanak. A Google és a Microsoft ezeket nem adja.
| Tulajdonság | Google / Gmail, Microsoft / Outlook 365 | Dedikált tranzakciós szolgáltató |
|---|---|---|
| Újra-hitelesítés szükséges lehet | Igen | Nem |
| Tranzakciós levelekre optimalizált | Nem | Igen |
| Jobb kézbesíthetőség | Nem | Igen |
Mikor jó mégis a Google vagy a Microsoft?
Szekció neve “Mikor jó mégis a Google vagy a Microsoft?”- Kis forgalmú webhelyeknél, ahol a levelek személyes vagy egyszerű célúak.
- Kis jelentőségű feladatoknál, ahol egy váratlan kapcsolatmegszakadás miatti levélvesztés nem kritikus.
- Ha a szervezet szabályzata szerint a saját levelezőkiszolgálót kell használni.
- Tesztelésre vagy a beállítás ellenőrzésére az indulás előtt.
A zavarok csökkentése
Szekció neve “A zavarok csökkentése”Ha mégis a Google vagy a Microsoft integrációt használod:
- Ha elérhető, használj alkalmazásjelszót a rendes jelszó helyett, így ritkábban lesz szükség újra-hitelesítésre.
- Állíts be riasztást, hogy értesülj, ha a hitelesítés meghiúsul, és gyorsan léphess.
- Időnként nézd meg az integráció beállításait, hogy még csatlakoztatva van-e.
API-kulcsok időnkénti cseréje
Szekció neve “API-kulcsok időnkénti cseréje”A levélszolgáltatók API-kulcsainak és hitelesítő adatainak rendszeres cseréje ajánlott biztonsági gyakorlat. A folyamat minden szolgáltatónál hasonló, az OAuth-kapcsolatoknál van néhány eltérés.
- Hozz létre új kulcsot a szolgáltatónál. Lépj be a levélszolgáltatód felületére, és készíts új API-kulcsot vagy ügyféltitkot (Client Secret). A régit még ne vond vissza. A szolgáltatónkénti lépéseket a szolgáltatók fejezetei írják le.
- Frissítsd a hitelesítő adatokat a Gravity SMTP-ben. Nyisd meg az SMTP → Beállítások → Integrációk oldalt, kattints az integrációra, cseréld le a régi kulcsot az újra, és mentsd. OAuth-kapcsolatnál (Google / Gmail, Microsoft 365 / Outlook, Zoho Mail) szakítsd meg a meglévő kapcsolatot, majd csatlakozz újra az új ügyféltitokkal.
- Tesztelj. Az SMTP → Eszközök → Teszt küldése eszközzel ellenőrizd, hogy minden működik.
- Vond vissza a régi kulcsot. Térj vissza a szolgáltató felületére, és vond vissza vagy töröld a régi kulcsot vagy ügyféltitkot.
Az OAuth-kapcsolatoknál az ügyfélazonosítót (Client ID) nem kell újragenerálni, mert az nyilvános adat.
Készült: