Tovább a tartalomhoz

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.

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.

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.

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.

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.

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.

  1. 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.
  2. 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.
  3. Tesztelj. Az SMTP → Eszközök → Teszt küldése eszközzel ellenőrizd, hogy minden működik.
  4. 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:

Tiszteletben tartjuk a magánszférádat

Sütiket használunk a böngészési élmény javítására és a forgalom elemzésére. Az analitika csak akkor indul, ha engeded. Adatvédelmi irányelvek, Sütitájékoztató.

Sütibeállítások