Tudásbázis
Küldje el ügyfelei értesítéseit a saját domainjéről, a saját e-mail-fiókjából: melyik szolgáltatót válassza, az SPF-, DKIM- és return-path-rekordok, amelyekre mindegyiknek szüksége van, miért ragaszkodunk ahhoz, hogy a tesztüzenet ténylegesen megérkezzen, és mi történik, ha egy szolgáltató meghibásodik.
Minden értesítés, amelyet ügyfelei kapnak — számlák, jelszó-visszaállítások, hibajegy-válaszok, projektfrissítések —, egy levelezőszolgáltatáson keresztül megy ki. Alapértelmezés szerint ez a szolgáltatás a miénk, a Feladó mezőben a Zinn Digital® szerepel, és a költségeket mi álljuk.
Amennyiben Ön ügynökségi vagy viszonteladói díjcsomaggal rendelkezik, lehetősége van helyette a saját levelezőszolgáltatását csatlakoztatni. Ügyfelei ekkor az Ön domainjét látják a Feladó mezőben, a válaszok Önhöz érkeznek vissza, a levelek pedig az Ön fiókjából, az Ön szolgáltatóján keresztül mennek ki.
A beállítást az irányítópulton az E-mail-küldés menüpontban végezheti el.
Bármelyik megfelelő. Válassza azt, amelyiknél már rendelkezik fiókkal.
| Szolgáltató | Legjobb választás, ha | Útmutató |
|---|---|---|
| Mailgun | API-t és nagyvonalú küldési korlátokat szeretne | A Mailgun beállítása |
| SendGrid | Már használja marketinglevelekhez | A SendGrid beállítása |
| Postmark | Kizárólag tranzakciós levelekhez, a legjobb kézbesíthetőséggel | A Postmark beállítása |
| Amazon SES | Már használja az AWS szolgáltatást, és a legalacsonyabb árat keresi | Az Amazon SES beállítása |
| Resend | A legegyszerűbb beállítást szeretné | A Resend beállítása |
| Saját SMTP-kiszolgáló | Saját levelezési infrastruktúrát üzemeltet | Az SMTP beállítása |
Amennyiben nincs preferenciája és meglévő fiókja sem, tranzakciós levelekhez mi a Postmark megoldását választanánk: nem hajlandó marketingleveleket továbbítani, és pontosan ezért olyan kiválóak a kézbesítési mutatói.
Bármelyik szolgáltatót is választja, ugyanaz a három DNS-rekord dönti el, hogy a levelei megérkeznek-e, vagy a spamben kötnek ki. A pontos értékeket a szolgáltatója generálja le; Önnek pedig hozzá kell adnia őket a domainjéhez.
SPF — egy TXT rekord a domainjén, amely felsorolja, ki jogosult az Ön nevében levelet küldeni. Ha már rendelkezik ilyennel, módosítsa azt; ne adjon hozzá egy másodikat. Egy két SPF rekorddal rendelkező domain esetében az SPF-ellenőrzés teljesen sikertelen lesz, ami rosszabb annál, mintha egy sem lenne.
DKIM — egy nyilvános kulcsot tartalmazó TXT vagy CNAME rekord, amelynek segítségével a fogadó szerverek ellenőrizhetik, hogy az üzenet valóban az Ön szolgáltatójától érkezett-e, és nem módosították-e. Ez a rekord végzi a legtöbb munkát, és ennek kell egyeznie ahhoz, hogy a DMARC-ellenőrzés sikeres legyen.
Return-path (bounce) domain — általában egy CNAME rekord. Ez állítja be azt a láthatatlan borítékcímet, amelyet a szolgáltatója a visszapattant levelek gyűjtésére használ. Enélkül a visszapattanó levelek olyan helyre kerülnek, amelyre nincs rálátása, a domain hírneve pedig anélkül romlik, hogy Ön tudna róla.
DMARC — egy TXT rekord a _dmarc.yourdomain.com címen, amely utasítja a fogadó szervereket, mi a teendő, ha az SPF és a DKIM nincs összhangban a Feladó mezővel. Kezdjen a p=none értékkel, amíg ellenőrzi, hogy minden átmegy-e a teszten, majd állítsa át p=quarantine, végül p=reject értékre.
⚠️ A DNS-módosítások nem lépnek életbe azonnal. Várjon akár egy órát is, mielőtt arra következtetne, hogy valami nem működik.
A leveleket a mail.yourdomain.com vagy notifications.yourdomain.com címről küldje, ne közvetlenül a yourdomain.com címről.
Ennek oka a hírnév megőrzése. Az üzleti levelezése a fő domainjét használja. Ha egy tömeges levélküldés során hiba történik, egy külön küldési aldomain megakadályozza a kár kiterjedését — munkatársai továbbra is tudnak e-mailezni az ügyfelekkel, miközben Ön elhárítja a problémát. Emellett lehetővé teszi, hogy anélkül állítsa be a küldéshez szükséges DNS-rekordokat, hogy hozzá kellene nyúlnia a saját postaládái működéséhez szükséges rekordokhoz.
A Küldés erről a domainről mezőbe továbbra is egy domaint kell megadnia, nem egy e-mail-címet. A @ előtti rész üzenetenként kerül kiválasztásra: a bizonylatok a billing@, a jelszó-visszaállítások a no-reply@, a hibajegy-válaszok pedig a support@ címről mennek ki.
A levelei csak ezt követően kezdenek el az Ön nevében kimenni.
⭐ A teszthez használjon egy másik domainen lévő postaládát — egy Gmail- vagy Outlook-cím ideális erre. Egy olyan üzenet, amely soha nem hagyja el a saját szerverét, sokkal kevesebbet bizonyít, mint egy olyan, amely átkelt az interneten, és átjutott valaki más spamszűrőjén.
Mert egy olyan szolgáltató, amely átvesz egy üzenetet, majd csendben eldobja azt, megtévesztésig hasonlít egy megfelelően működőre. Egy vadonatúj Amazon SES-fiók tesztkörnyezetben (sandbox) működik, így átveszi az üzenetet, de nem kézbesíti sehova. Egy olyan Mailgun-domain, amelynek a DNS-rekordjai még nem terjedtek el, pontosan ugyanígy viselkedik. Csakúgy, mint egy olyan SMTP-relay, amely 250-es választ küld, majd eldobja a levelet.
Ha a hitelesítési adat elfogadásának pillanatában átállítanánk a küldést, először abból értesülne a problémáról, hogy ügyfelei semmit sem kapnak meg — és napokkal később egy ügyféltől tudná meg. A kód a bizonyíték arra, hogy az üzenet elhagyta a szolgáltatóját, és célba is ért.
Értesítéseit sikertelenként rögzítjük, a rendszer újrapróbálkozik, az E-mail-küldés képernyő pedig pirosra vált, megjelenítve a szolgáltatója saját hibaüzenetét.
⛔ Ilyenkor sem küldjük ki őket a saját domainünkről. Ez szándékos döntés. Egy csendes biztonsági tartalékmegoldás azt eredményezné, hogy a hibás levelezőfiók éppen eléggé működőképes marad ahhoz, hogy senki ne javítsa meg — miközben a költségeket észrevétlenül mi álljuk. Így a hiba látható marad, a javítása az Ön feladata, és ez az egyetlen módja annak, hogy valóban elhárításra kerüljön.
Amíg a hiba nincs elhárítva, ügyfelei nem kapják meg ezeket az értesítéseket. Minden üzenet továbbra is elérhető az irányítópultjuk postaládájában, és semmi sem vész el — de az itt megjelenő piros sávot kezelje sürgős ügyként.
Semmi sem fog elromlani. Az értesítések továbbra is a mi domainünkről mennek ki, Zinn Digital® név alatt, a költségeket pedig továbbra is mi álljuk. Ügyfelei egyszerűen a mi nevünket látják majd az Öné helyett.
Kattintson a Leválasztás gombra. A tárolt hitelesítési adata törlődik, az értesítések pedig a következő üzenettől kezdve visszatérnek a mi domainünkre. Bármikor újra csatlakozhat.
Amit a tárhelyszolgáltatásról, a SEO-ról és a webhelyek nagy léptékű működtetéséről írtunk.
Hogyan alakítja a tárhely az indexelést és a linkértéket 2026-ban: az oldalak indexben tartása, a korosodott domainek ellenőrzése a tartalomépítés előtt, linképítés keresőmotoros lábnyom nélkül, és őszinte áttekintés arról, hogy az infrastruktúra mit tehet és mit nem tehet meg a SEO-ért.
Bejegyzés elolvasása →Gyakorlati ellenőrzőlista a gyors és biztonságos WordPress-hez: kiszolgálószintű gyorsítótárazás, webhelyenkénti objektum-gyorsítótár, a maroknyi futtatásra érdemes bővítmény, a technológiai verem naprakészen tartása és a WooCommerce-oldalak, amelyeket soha nem szabad gyorsítótárazni.
Bejegyzés elolvasása →Mi különbözteti meg valójában a jó menedzselt tárhelyet egy olcsó, vezérlőpulttal ellátott doboztól — migrációk, biztonsági mentések, elszigetelés, valódi gyorsítótárazás és őszinte skálázhatóság — és hogyan ítélheti meg, mielőtt elkötelezné magát.
Bejegyzés elolvasása →A támogatás minden csomag része, az ügyfélszolgálat a nap 24 órájában rendelkezésre áll, és a 58 támogatott nyelvünk bármelyikén írhat nekünk – mi a ön nyelvén válaszolunk.
Kapcsolatfelvétel az ügyfélszolgálattal → Összes cikk →