Brevo SMTP: beállítás, konfiguráció és hibaelhárítási útmutató

A Brevo SMTP leveszi az alkalmazásod kimenő leveleit a webtárhely helyi levelezőügynökéről, és olyan infrastruktúrára helyezi, amely minden üzenetet hitelesít, naplóz és jelent. A beállítás kicsi: egy hosztnév, egy port, két hitelesítési adat. Elrontani szintén kicsi dolog, és a hibamódok csendesek. Ez az útmutató lefedi a beállításokat, a hitelesítési modellt, azt a DNS-munkát, amitől a kézbesítés egyáltalán megtörténik, és azokat a hibákat, amelyekbe belefutsz, ha bármelyik darab rosszul áll. Ha még szolgáltatót választasz, a tágabb SMTP e-mail szolgáltatás útmutató előbb a piacot hasonlítja össze.

Mi az a Brevo SMTP

A Brevo a Brevo SMTP-t a saját SMTP-továbbító szolgáltatásaként írja le. Az alkalmazásod, a webhelyed vagy a levelezőszervered átad egy üzenetet a továbbítónak egy hitelesített kapcsolaton, a Brevo pedig felel az útválasztásért, az újrapróbálkozásokért, a reputációért és a jelentésekért. A továbbított levelek statisztikái a kampánystatisztikák mellett jelennek meg, és egy kemény visszapattanás automatikusan tiltólistára teszi az adott kapcsolatot.

A továbbítót tranzakciós üzenetekre építették: jelszó-visszaállításokra, nyugtákra, rendelés-visszaigazolásokra, fiókértesítésekre. Ha még nem éles a határ ezek és a marketinglevelek között, azt, hogy mi a tranzakciós e-mail, külön írás fedi le.

SMTP vagy a REST API

Mindkét út ugyanahhoz a platformhoz vezet. A gyakorlati felosztás:

Egy kemény korlát: a Brevo fejlesztői dokumentációja kimondja, hogy az SMTP-továbbító nem támogatja a kötegelt küldést, és a kötegelt műveleteket az API-végpontokhoz irányítja.

Az SMTP-hitelesítési adataid létrehozása

A Brevo SMTP-hitelesítése két olyan értéket használ, amelyet könnyű összekeverni a már meglévő hitelesítési adataiddal.

Keresd meg az SMTP-bejelentkezésedet

Az SMTP-bejelentkezésed nem a Brevo-fiókod e-mail-címe. Ez egy külön azonosító, amely a Settings, SMTP and API oldal Login mezőjében látható, [email protected] formátumban.

Ebből két szabály következik, mindkettő a Brevo hibaelhárítási dokumentációjából. Ne írd az smtp-relay.brevo.com címet a felhasználónév mezőbe: az a továbbító hosztja, nem a bejelentkezésed. És ne írd az SMTP-bejelentkezésedet a From fejlécbe, mert az téged hitelesít, nem pedig egy feladót azonosít.

Generálj SMTP-kulcsot

A jelszó egy SMTP-kulcs, nem a fiókjelszavad és nem egy API-kulcs.

1. Nyisd le a fiók legördülő menüjét, és válaszd a Settings, majd az SMTP and API pontot.
2. Az SMTP fülön kattints a Generate a new SMTP key gombra.
3. Nevezd el a kulcsot arról az integrációról, amelyik használni fogja.
4. Válaszd ki a változatot. A Standard az ajánlott 64 karakteres kulcs, a Short egy 15 karakteres kulcs azoknak a klienseknek, amelyek nem bírják a hosszú jelszavakat.
5. Állíts be lejáratot 7 nap és 1 év között, vagy válaszd a lejárat nélkülit.
6. Kattints a Generate gombra, majd azonnal másold ki a teljes kulcsot.

A teljes kulcs egyszer jelenik meg, utána az oldal csak az utolsó néhány jegyét mutatja. Ha elveszíted, generálj újat, és frissítsd a konfigurációdat.

Kapcsolati beállítások

Az értékek, amelyeket bármelyik kliensbe vagy könyvtárba be kell írnod:

Portválasztás

A Brevo az 587-est ajánlja alapértelmezettként. A 465-öst SMTP over SSL célra jelölték ki, később elavulttá nyilvánították, de továbbra is széles körben támogatott, és akkor helyes, ha az első parancs előtt titkosított kapcsolatra van szükséged. A 2525-ös nem IETF- vagy IANA-regisztrált port, de a legtöbb internetszolgáltató és felhőszolgáltató engedi, ami vészkijáratot csinál belőle, ha az 587-es blokkolva van.

A titkosítás mező szokta megzavarni az embereket. A Brevo azt mondja, hagyd üresen, hacsak nem 465-ön vagy. Ez nem azt jelenti, hogy a kapcsolat titkosítatlan: az 587-esen és a 2525-ösön a kiszolgáló hirdeti a STARTTLS képességet, és minden hozzáértő kliens frissít a hitelesítés előtt. Azt jelenti, hogy ne válaszd az „SSL” opciót, amikor az 587-esre csatlakozol, mert a port és a titkosítás eltérése helyes hitelesítési adatokkal is elbukik.

Teszteld a kapcsolatot, mielőtt bármilyen kódot írnál

Győződj meg róla, hogy a továbbító válaszol, és a TLS egyeztetése lefut, mielőtt az alkalmazáskódot kezdenéd hibakeresni.

openssl s_client -starttls smtp -crlf -connect smtp-relay.brevo.com:587

A sikeres kézfogás a kiszolgáló 250-es képességlistájával zárul, amelyben szerepelnie kell a STARTTLS sornak és egy AUTH sornak a PLAIN és LOGIN értékkel. Ha egyáltalán nincs banner, az hálózati gond, nem hitelesítési.

A küldődomained hitelesítése

Ezt a lépést szokták kihagyni, és ez dönti el, hogy megérkezik-e bármi. 2024. február 1. óta a domainhitelesítés kötelező a Gmail és a Yahoo feladói követelményei alatt, és a Brevo megjegyzi, hogy a Microsoft 2025. május 5-én hasonló szabványokat jelentett be. A hitelesítetlen levelet kiszűrik vagy elutasítják, függetlenül attól, melyik továbbító küldte.

A rekordok, amelyeket a Brevo kér

A Brevo automatikusan hozzá tudja adni ezeket, ha a Brevón belülről bejelentkezel a domainszolgáltatódhoz, vagy kézzel is bemásolhatod az értékeket a DNS-zónádba. Az, hogy melyik DKIM-formát kapod, a fióktól függ: a két CNAME-rekord alapértelmezetten 2048 bites kulcsot használ, az egyetlen TXT-forma 1024 biteset.

Miért nincs SPF-rekord

A Brevo GYIK-je egyértelmű: az SPF- és MX-rekordok nem szükségesek egy domain hitelesítéséhez, és csak dedikált IP beállításakor kapod meg őket. Megosztott infrastruktúrán a Brevo felügyeli a visszaútvonalat, így a DKIM és a tulajdonosi ellenőrzés viszi a hitelesítést. Ha olyan szolgáltatótól költözöl, amelyik SPF-include-ot követelt, ne találj ki egyet; egy fölösleges include csak a lekérdezési korlát kockázatát növeli.

A DMARC továbbra is számít, és a Brevo közzétesz egy működő kiindulórekordot:

v=DMARC1; p=none; rua=mailto:[email protected]

Kezdd p=none házirenddel, hogy összesítő jelentéseket kapj a kézbesítés kockáztatása nélkül, majd szigoríts quarantine és reject felé, ha már minden jogos forrás rendben van. Az e-mail-kézbesíthetőségi útmutatónk lefedi ezt a haladási sort.

Ellenőrizd a feladót

Minden From címnek ellenőrzött feladónak kell lennie, vagy hitelesített domainen kell ülnie. Egy új feladót az adott címre küldött 6 jegyű kóddal ellenőriztetsz, de a hitelesített domainen lévő feladók kihagyják ezt a lépést, és pontosan ezért hitelesítesz előbb. Az ingyenes levelezési domainek nem hitelesíthetők, így egy gmail.com vagy outlook.com végződésű From címet elutasítanak vagy kiszűrnek.

Integrációs útmutatók

WordPress

A WordPress a wp_mail függvénynek adja át a kimenő levelet, az pedig azt hívja, amit a tárhely biztosít. A Brevón keresztüli irányításhoz bővítmény kell.

1. Az admin oldalsávban menj a Plugins, majd az Add New Plugin pontra.
2. Keress rá a Brevóra, telepítsd a „Newsletter, SMTP, Email marketing and Subscribe forms by Brevo” bővítményt, majd aktiváld.
3. Menj a Brevo, majd a Home pontra, és írd be a Brevo API key v3 értékedet az aktiválási mezőbe. Ez a lépés azért használ API-kulcsot, mert a bővítmény kapcsolatokat is szinkronizál. Kattints a Login gombra.
4. A Transactional emails alatt válaszd a Yes lehetőséget.
5. Válassz meglévő feladót, vagy hozz létre egyet. Minden WordPress-e-mail ezt a feladónevet és címet használja.
6. Adj meg egy címet, és kattints a Send email gombra egy teszt kiváltásához.

Két hiba gyakori. Az az üzenet, hogy a tranzakciós e-mailek nincsenek aktiválva, mert a Brevo SMTP-fiókod nem lett aktiválva, azt jelenti, hogy a Brevo ügyfélszolgálatának kell bekapcsolnia a platformot. Az az üzenet pedig, hogy az SMTP nem használható, mert a wp_mail függvényt egy másik folyamat már deklarálta, versengő SMTP-bővítményt jelez; egyesével kapcsold ki a többit.

Kiszolgálóoldali alkalmazás

A Brevo saját Node.js-példája a nodemailert és a fenti beállításokat használja:

const nodemailer = require("nodemailer");

const transporter = nodemailer.createTransport({
  host: "smtp-relay.brevo.com",
  port: 587,
  secure: false, // true a 465-höz, false a többi porthoz
  auth: {
    user: process.env.BREVO_SMTP_LOGIN, // [email protected]
    pass: process.env.BREVO_SMTP_KEY,
  },
});

async function sendOrderConfirmation() {
  const info = await transporter.sendMail({
    from: '"Acme Support" <[email protected]>',
    to: "[email protected]",
    subject: "Your order is confirmed",
    text: "Order 10482 is confirmed and ships within two business days.",
  });
  console.log("Message sent:", info.messageId);
}

sendOrderConfirmation().catch(console.error);

Figyeld meg a secure: false beállítást az 587-es porton. Ez a jelző az implicit TLS-t vezérli, nem azt, hogy a kapcsolat titkosított-e; a nodemailer továbbra is kiadja a STARTTLS parancsot. Csak a 465-höz állítsd true értékre.

A Python-megfelelő a szabványos könyvtárral:

import smtplib, ssl
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "Acme Support <[email protected]>"
msg["To"] = "[email protected]"
msg["Subject"] = "Your order is confirmed"
msg.set_content("Order 10482 is confirmed and ships within two business days.")

with smtplib.SMTP("smtp-relay.brevo.com", 587, timeout=20) as server:
    server.starttls(context=ssl.create_default_context())
    server.login(BREVO_SMTP_LOGIN, BREVO_SMTP_KEY)
    server.send_message(msg)

Mindkettő a környezetből olvassa a hitelesítési adatokat, és ez a következő szakasz témája.

Kulcsbiztonság és rotáció

A Brevo az SMTP-kulcsokat jelszóként kezeli. Az üzemeltetési szabályokat érdemes szó szerint követni.

• Integrációnként egy kulcs. Nevezz el minden kulcsot arról a rendszerről, amelyik használja, így egy szivárgás vagy egy leszerelés pontosan egy dolgot von vissza.
• Soha ne commitolj kulcsot. Környezeti változók, egy titokkezelő vagy a platformod konfigurációtára. Nem verziókezelés, nem egy követett .env fájl, nem egy képernyőkép.
• Rotálj állásidő nélkül. Generáld le a cserét, telepíts, igazold, hogy a küldés működik, majd töröld a régi kulcsot. A törlés visszafordíthatatlan, és egy még használatban lévő kulcs törlése azonnal leállítja a tranzakciós küldést.
• Törlés helyett inaktiválj, ha egy integrációt szüneteltetnél. A kulcsokat később újra lehet aktiválni.
• Számíts a lejáratra. A kulcsok 7 naptól 1 évig terjedő lejáratot hordozhatnak, és a Brevo 90 nap után lejáratja az inaktív kulcsokat.

Keményebb határhoz a Brevo blokkolni tudja az ismeretlen IP-címekről érkező kéréseket. Az engedélyezési lista közös az API- és az SMTP-kulcsok között, így bármit engedélyezel, az mindkettőre vonatkozik. Konténeres vagy felhős terhelésnél légy óvatos: a kimenő cím lehet egy NAT-átjáró a várt példány IP-je helyett, és ha ezt elrontod, 525 5.7.1 Unauthorized IP address elutasítást kapsz.

Azok a csapatok, amelyek a Brevót egy webáruház, egy CRM és egy ügyfélszolgálati rendszer mellett futtatják, végül több kulcsot, feladót és domaint kezelnek egyszerre. A Tajo egy helyen tartja ezt a konfigurációt négy irányítópult helyett.

Küldési korlátok és szabályozás

Az SMTP-küldés a csomagod e-mail-kreditjeiből merít. Az ingyenes csomagon ez napi 300 e-mail küldését jelenti; a korlát naponta nullázódik, és a fel nem használt küldések nem vihetők át. Ha eléred, a Brevo további legfeljebb 1000 e-mailt tart egy újrapróbálkozási sorban, és azon a soron túl semmit nem kézbesít. A fizetős csomagok megszüntetik a napi plafont, a Brevo árazási útmutató pedig lebontja a szinteket.

Ha a kreditek teljesen elfogynak, az SMTP-n beadott üzenetek szünetelnek és sorba állnak, nem pedig eltűnnek. A várólista a Transactional, majd a Real time, majd a Usage and plan alatt, az Email queue részben található.

A Brevo kemény sebességkorlátokat a REST API-ra tesz közzé, nem a továbbítóra. Az általános szinten a POST /v3/smtp/email másodpercenként 1000 kérést enged, és a korlát túllépése 429 Too Many Requests választ ad. Az API-út sebességkorlát-fejléceket is visszaad, amelyekhez igazíthatod a tempót, a továbbító viszont nem.

Visszapattanások és panaszok figyelése

A továbbított levél a Transactional alatt, a Statistics és a Logs oldalon látható. Az események, amelyekre reagálnod kell:

• Kemény visszapattanás. A cím érvénytelen, és a Brevo automatikusan tiltólistára teszi a kapcsolatot.
• Blokkolt. A címzett korábban panaszt tett, leiratkozott, kemény visszapattanást okozott, vagy kézzel lett blokkolva.
• Késleltetett és puha visszapattanás. A szolgáltató elfogadta a kapcsolatot, de késleltette vagy visszautasította az üzenetet. Az egy szolgáltatóval szembeni ismétlődő késleltetés reputációs problémát jelez, nem kódproblémát.

A naplók lekérdezgetése nem skálázódik. A Brevo támogat tranzakciós webhookokat, amelyek valós időben tolják a kézbesítési, visszapattanási, megnyitási és panaszeseményeket a végpontodra, és így tartod naprakészen a saját tiltási adataidat.

A figyelendő szám a spampanasz-arány. A Gmail, a Yahoo és a Microsoft 0,3% alatt tartást vár el a feladóktól, a Brevo pedig azt ajánlja, hogy a Gmail Postmaster Tools eszközzel figyeld. Egy áthágásból kilábalni sokkal tovább tart, mint elkerülni.

Hibaelhárítás

535 5.7.8 Authentication failed

A felhasználónevet vagy a jelszót nem sikerült ellenőrizni. Valószínűség szerint:

• A fiók e-mail-címét használtad az [email protected] formátumú SMTP-bejelentkezés helyett.
• Az smtp-relay.brevo.com került a felhasználónév mezőbe. A Brevo ezt nevezi meg az egyik leggyakoribb okként.
• API-kulcsot használtál SMTP-kulcs helyett.
• A kulcs záró szóközt vagy sortörést hordoz a másolás-beillesztésből.
• A titkosítási beállítás nem illik a porthoz.
• A kulcs egy biztonsági riasztás után érvénytelenné vált, ilyenkor generálj újat.

525 5.7.1 Unauthorized IP address

Az IP-blokkolás aktív, és a csatlakozó cím nincs engedélyezve. Add hozzá, és előbb ellenőrizd a valódi kimenő címedet, ha az alkalmazás NAT mögött vagy konténerplatformon fut.

Nincs válasz és nincs banner

Ha a TCP-kapcsolat felépül, de a kiszolgáló soha nem küldi el a 220-as üdvözlését, a hitelesítés el sem kezdődhet, és a hiba a hálózat te oldaladon van. A vállalati tűzfalak néha engedik a kapcsolatot, majd csendben eldobják az SMTP-forgalmat. Az AWS, az Azure és a Google Cloud új fiókokon alapértelmezetten korlátozza a kimenő SMTP-t. Kérd a korlátozás feloldását, vagy válts a 2525-ös portra.

450, a platform nincs aktiválva

A hiba azt mondja, hogy az SMTP-fiókod még nincs aktiválva, vagy hogy a küldőplatformod jelenleg le van tiltva. Új fiókon a tranzakciós küldéshez a Brevo ügyfélszolgálatától külön aktiválási lépés kell. Bejáratott fiókon ez általában felfüggesztést jelent, vagy azért, mert egy védtelen űrlapot botregisztrációk értek, vagy mert a fiók kompromittálódás jeleit mutatta.

A feladót elutasították

Három dolgot ellenőrizz: a domain hitelesítve van, a feladó ellenőrizve van, és a From fejléc nem az SMTP-bejelentkezésed.

A levelet elfogadják, de spambe kerül

Ebben a sorrendben dolgozz. Igazold, hogy a küldődomain hitelesített, és a DKIM aláír. Igazold, hogy a From domain a sajátod, nem egy ingyenes levelezőszolgáltatóé. Nézd meg a panaszarányodat a Postmaster Toolsban a 0,3%-os küszöbhöz képest. A tartalmat csak azután nézd, hogy ezek az ellenőrzések tiszták, mert szinte soha nem az az elsődleges ok.

Dedikált IP-címek

A dedikált IP csak nagy, egyenletes mennyiségnél segít. Be kell melegíteni, mielőtt érdemben küldenél rajta, és kell hozzá egy küldő aldomain, amely a fejlécekben mailed by és return path domainként jelenik meg. Ez az az egyetlen konfiguráció, ahol a Brevo SPF- és MX-rekordot is ad, az adott aldomainhez tartozó A, CNAME, DKIM és DMARC rekordok mellett.

Két részlet szokta megfogni az embereket. Egy kizárólag marketinge-mailre beállított dedikált IP sorba állítja a tranzakciós üzeneteidet küldés helyett, ezért állítsd át, vagy vegyél egy második IP-t. A tranzakciós és a marketingútvonal szétválasztása pedig legalább két IP-ből álló készletet és eltérő feladókat igényel, hogy a marketinglevelek gyenge elköteleződése ne húzhassa le a nyugtákat és a jelszó-visszaállításokat.

Elsőre jól csinálni

Hitelesítsd a domaint, hozz létre egy elnevezett SMTP-kulcsot, csatlakozz az smtp-relay.brevo.com címre az 587-esen, és küldj tesztet a valódi kódúton, ne egy irányítópulti gombbal. Szinte minden későbbi probléma három dolog egyikére vezethető vissza.

• Rossz hitelesítési adat a felhasználónév vagy a jelszó mezőben.
• Port- és titkosítási beállítás, amely nem egyezik egymással.
• Küldődomain, amelyet soha nem hitelesítettek.

Ha ezeket eltalálod, a továbbító eltűnik a háttérben, és pontosan ez az, amit egy tranzakciós infrastruktúrának tennie kell.