DNS, Email & Deliverability

Miért kerülnek az e-mailjei spambe akkor is, ha az SPF, DKIM és DMARC sikeres

A hitelesítés azt bizonyítja, hogy jogosult küldeni. Azt nem bizonyítja, hogy a címzettek akarják is a levelet.

The Wux Webtools Team The Wux Webtools Team 14 min olvasás AI-támogatott, ember által ellenőrzött
Illustration of authenticated email messages being evaluated by reputation filters before reaching inbox or spam folders.
Tartalomjegyzék
  1. A sikeres hitelesítés a rajtvonal, nem a célvonal
  2. Mit bizonyít valójában az SPF, a DKIM és a DMARC
  3. A legnagyobb ok: a reputáció
  4. Lehet, hogy a lista a probléma
  5. A sikeres DMARC még mindig jelenthet gyenge igazodást
  6. A tartalom továbbra is számít, csak nem a régi módon
  7. A küldési minták gyanúsnak tűnhetnek
  8. A leiratkozás kezelése ma már kézbesíthetőségi funkció
  9. Az infrastruktúrája zajos lehet
  10. Hogyan diagnosztizálja a problémát kapkodás nélkül
  11. Józan kézbesíthetőségi ellenőrzőlista

A sikeres hitelesítés a rajtvonal, nem a célvonal

Frusztráló, amikor megteszi a felelős lépést — helyesen konfigurálja az SPF-et, a DKIM-et és a DMARC-ot —, az e-mailjei mégis spambe kerülnek.

A zavar általában abból fakad, hogy a hitelesítést kézbesíthetőségi garanciának tekintjük. Nem az. Az SPF, DKIM és DMARC egy szűkebb kérdésre ad választ: jogosult-e ez a szerver e domain nevében küldeni, és a látható feladó összhangban van-e a hitelesített identitással?

Ez fontos. Hitelesítés nélkül a modern postafiók-szolgáltatók joggal nem bíznak Önben. De miután ezeken az ellenőrzéseken átment, a Gmailnek, az Outlooknak, a Yahoo-nak és a vállalati szűrőknek még el kell dönteniük, hogy az üzenet kívánt, biztonságos és releváns-e. Ez a döntés a feladó reputációjától, a címzettek viselkedésétől, a tartalomtól, az infrastruktúrától, a panaszoktól, a lista minőségétől és a küldési mintáktól függ.

Ha felfrissítené, hogy ezek a rekordok valójában mit csinálnak, kezdje a fejlesztőknek szóló útmutatónkkal: MX, SPF, DKIM és DMARC. Ez a cikk abból indul ki, hogy ezek a rekordok sikeresek, és a következő rétegre fókuszál: miért szűrődnek mégis a levelek.

Mit bizonyít valójában az SPF, a DKIM és a DMARC

Az SPF azt ellenőrzi, hogy a küldő levelezőszerver engedélyezett-e a return-path-ben szereplő domain által. A DKIM azt ellenőrzi, hogy az üzenetet kriptográfiailag aláírta-e egy domain, és hogy az üzenet aláírt részei nem módosultak-e. A DMARC azt ellenőrzi, hogy az SPF vagy a DKIM úgy megy-e át, hogy összhangban van a látható From domainnel.

Ez a kombináció segít megállítani a hamisítást. Azt viszont nem mondja ki, hogy:

  • a feladónak jó a reputációja;
  • a címzettek kérték az üzenetet;
  • a tartalom hasznos;
  • a linkek biztonságosak;
  • a küldési volumen normális;
  • a domain előélete tiszta;
  • az üzenet nem egy alacsony minőségű kampány része.

Gondoljon a hitelesítésre úgy, mint egy útlevélre. Igazolja a személyazonosságot. A határellenőrzés ettől még megkérdezheti, hová tart, mit visz magával, és okozott-e korábban problémát.

A legnagyobb ok: a reputáció

A postafiók-szolgáltatók folyamatosan pontozzák a feladókat. Érthető okokból nem teszik közzé a teljes pontozási modellt, de a főbb jelek jól ismertek.

A domain reputációja és az IP reputációja egyaránt számít. Egy új domain tökéletes DKIM-mel is kockázatosnak tűnhet. Egy régi domain, amely évekig csak számlákat küldött, majd hirtelen 80 000 promóciós e-mailt kezd küldeni, szintén kockázatosnak látszik. Egy megosztott küldő IP, amelynek visszaélő szomszédai vannak, árthat, bár a nagy e-mail-szolgáltatók sokat dolgoznak ennek kezelésén.

A reputációt befolyásolja:

  • spambejelentések;
  • végleges visszapattanások;
  • régi vagy elhagyott címekre küldés;
  • hirtelen volumennövekedések;
  • alacsony megnyitási arány vagy figyelmen kívül hagyott üzenetek;
  • olvasás nélkül törölt üzenetek;
  • gyanús vagy frissen regisztrált domainekre mutató linkek;
  • korábbi adathalászati vagy malware-incidensek;
  • következetlen küldői identitás.

A kellemetlen igazság: a reputáció lassan épül fel, és gyorsan elvész. A hitelesítés alkalmassá teszi Önt a bizalomra. Önmagában nem teremt bizalmat.

Lehet, hogy a lista a probléma

Sok spam mappás probléma valójában listaminőségi probléma, amely DNS-problémának álcázza magát.

Ha egy listát lekapartak, megvásároltak, egy régi CRM-ből örököltek, rendezvényes szkennelésekből állítottak össze, vagy homályos hozzájárulás alapján építettek, általában rosszul fog teljesíteni. Még ha az első kampány nem is vált ki nyilvánvaló panaszokat, a postafiók-szolgáltatók látják a mintát: sok címzett nem reagál, néhányan spamként jelölik, és egyes címek visszapattannak.

A jó listák eredete unalmas. Az emberek szándékosan iratkoztak fel. Tudták, mire iratkoznak fel. Az első e-mail elég hamar megérkezett ahhoz, hogy emlékezzenek rá. A leiratkozás egyszerű.

Figyeljen ezekre a listával kapcsolatos figyelmeztető jelekre:

  • magas visszapattanási arány, különösen az első küldésnél;
  • sok szerepköralapú fiók, például info@, sales@ és admin@;
  • évekkel ezelőtt gyűjtött, de ritkán megkeresett címek;
  • olyan országokból vagy iparágakból származó feliratkozók, amelyeket nem szolgál ki;
  • szokatlanul alacsony kattintási vagy válaszadási arány;
  • a szolgáltatói küszöbértékeket meghaladó spambejelentések.

B2B csapatoknál a kapcsolatfelvételi űrlapok is megmérgezhetik az e-mail-folyamatokat. Ha az űrlapok lehetővé teszik az automatizált visszaélést, a domainje kéretlen értesítéseket, hamis érdeklődéseket vagy backscattert kezdhet küldeni. Erről a kockázatról írtunk itt: miért a kapcsolatfelvételi űrlap a legnagyobb spamkockázata. Az űrlapspam nem csak kellemetlenség; reputációs problémává válhat.

A sikeres DMARC még mindig jelenthet gyenge igazodást

Egy üzenet „átmehet DMARC-on”, miközben működésileg továbbra is rendezetlen.

Például a látható From cím lehet [email protected], a DKIM sikeres lehet a mailer.example.net domainre, az SPF pedig átmehet egy, az e-mail-szolgáltatója által kezelt bounce domainnel. Az igazodási beállításoktól és a szolgáltatói konfigurációtól függően ez technikailag elfogadható lehet. Egy tiszta beállítás azonban általában az Ön domainjével vagy egy egyértelműen kapcsolódó aldomainnel ír alá.

Ellenőrizze:

  • DKIM d= domain: egyezik vagy igazodik a From domainjéhez?
  • return-path domain: az Öné vagy a szolgáltatójáé?
  • DMARC policy: még évekkel később is p=none értéken áll?
  • aldomain policy: a feledésbe merült aldomainek védtelenek?
  • továbbítási viselkedés: a továbbított üzenetek megtörik az SPF-et, de DKIM révén túlélnek?

A szigorú igazodás nem kötelező minden feladónál, de az identitásnak koherensnek kell lennie. Ha az emberek és a szűrők egyaránt egymáshoz nem kapcsolódó domainek kusza halmazát látják, a bizalom sérül.

A tartalom továbbra is számít, csak nem a régi módon

Volt idő, amikor a kézbesíthetőségi tanácsok olyan szavak körül forogtak, mint az „ingyenes”, a „garancia” vagy a „cselekedjen most”. Ez a tanács ma már túl leegyszerűsítő. A modern szűrők az üzenet kontextusát, a feladó előéletét, a linkek reputációját, a HTML-struktúrát, a felhasználói viselkedést és sok más jelet vizsgálnak.

A tartalom ennek ellenére árthat.

Gyakori problémák:

  • linkrövidítők, amelyek eltakarják a célállomást;
  • nem egyező linkdomainek;
  • kizárólag képekből álló e-mailek kevés valódi szöveggel;
  • nehéz követési burkolók minden linken;
  • hibás HTML vagy rosszul formázott MIME-részek;
  • olyan mellékletek, amelyekre a címzettek nem számítottak;
  • megtévesztő tárgysorok;
  • túlzott személyre szabás, amely gépileg generáltnak tűnik;
  • jogi láblécszöveg, amely nem illik a küldő szervezethez.

Egy jó teszt: az e-mail akkor is értelmes lenne, ha minden kép blokkolva lenne, és a követési paramétereket eltávolítanánk? Ha nem, az üzenet törékeny.

Vizsgálja meg az üzenet tényleges forrását is. Az e-mail-fejlécek nem azonosak a HTTP-fejlécekkel, de a hozzáállás hasonló: ne találgasson, nézze meg a nyers kommunikációt. A redirectek és HTTP-fejlécek éles környezetben történő hibakereséséhez készült kis eszköztárunk a webhez íródott, de ugyanez a fegyelem érvényes az e-mailre is: ellenőrizze, mit küldtek el, mit írtak alá, és hová oldódnak fel a linkek.

A küldési minták gyanúsnak tűnhetnek

A postafiók-szolgáltatók számára fontos az időbeli viselkedés. Egy kis cég, amely havonta 500 e-mailt küld, majd hirtelen 50 000-et küld egy délután alatt, figyelmet fog kelteni, még akkor is, ha minden üzenet hitelesített.

Ezért fontos a bemelegítés. A bemelegítés nem varázslat. Egyszerűen azt jelenti, hogy a volument fokozatosan növeli, először azoknak küldve, akik a legnagyobb valószínűséggel reagálnak. Ha ezek a címzettek megnyitják, kattintanak, válaszolnak, vagy más módon kívántként kezelik a levelet, a reputációja nagyobb eséllyel növekszik biztonságosan.

Rossz küldési minták:

  • nagy volumennövekedések;
  • rendszertelen „kiküld és eltűnik” ütemezések;
  • küldés először a legkevésbé aktív címzetteknek;
  • régi listák újraaktiválása gondos kivezetési szabály nélkül;
  • tranzakciós és marketing levelek keverése ugyanazon a domainen tervezés nélkül;
  • e-mail-szolgáltató és volumen egyidejű megváltoztatása.

Sok csapatnál a megoldás a szegmentálás. A fontos leveleket stabil domainről vagy aldomainről küldje. A marketingkísérleteket tartsa külön. Ne engedje, hogy egy kockázatos kampány kárt tegyen a jelszó-visszaállításokban, számlákban vagy fiókértesítésekben.

A leiratkozás kezelése ma már kézbesíthetőségi funkció

A postafiók-szolgáltatók egyre inkább elvárják a tömeges feladóktól, hogy megkönnyítsék a leiratkozást. Ez látható leiratkozási linkeket, és sok tömeges feladó esetében egykattintásos leiratkozási fejléceket jelent.

A leiratkozási link elrejtése önsorsrontó. Ha az emberek nem tudnak leiratkozni, spamként fogják megjelölni az üzenetet. Egy spambejelentés sokkal erősebb negatív jel, mint egy leiratkozás.

Győződjön meg róla, hogy:

  • a leiratkozási link bejelentkezés nélkül működik;
  • a kéréseket gyorsan teljesítik;
  • a List-Unsubscribe fejléc jelen van a tömeges leveleknél;
  • a preferenciaközpontok egyszerűek, nem labirintusok;
  • a leiratkozott felhasználókat a CRM-szinkronok nem adják hozzá újra.

Ez azon területek egyike, ahol a jogi megfelelés és a kézbesíthetőség ugyanabba az irányba mutat: tartsa tiszteletben a címzett döntését.

Az infrastruktúrája zajos lehet

Még jó DNS mellett is alááshatják a bizalmat az infrastruktúrahibák.

Ellenőrizze a küldő IP-k reverse DNS-ét. Győződjön meg róla, hogy a HELO/EHLO nevek értelmesek. Kerülje a kompromittált webszerverekről való küldést. Figyelje, hogy a domainje vagy IP-je megjelenik-e megbízható tiltólistákon. Tartsa működőképesen a TLS-t. Válassza szét a levélfolyamokat, ha a kockázati profiljuk eltér.

Legyen óvatos a harmadik fél feladókkal is. Minden platform, amelyet engedélyez az SPF rekordjában, minden közzétett DKIM selector és minden integráció, amely az Ön domainjeként tud küldeni, az e-mail-reputációs felület részévé válik. A régi eszközöket, elfeledett CRM-eket és elhagyott marketingplatformokat el kell távolítani.

Gyakorlati negyedéves áttekintés:

  1. Sorolja fel az összes szolgáltatást, amely jogosult e-mailt küldeni a domainje nevében.
  2. Erősítse meg, hogy házon belül ki felel az egyes szolgáltatásokért.
  3. Távolítsa el a nem használt SPF include-okat és DKIM kulcsokat.
  4. Nézze át a DMARC aggregate reportokat ismeretlen feladók után kutatva.
  5. Ellenőrizze a panasz-, visszapattanási és leiratkozási arányokat levélfolyamonként.

Ez nem látványos munka. De sok kézbesíthetőségi probléma éppen itt derül ki.

Hogyan diagnosztizálja a problémát kapkodás nélkül

Ne változtasson meg tíz dolgot egyszerre. Soha nem fogja tudni, mi segített.

Kezdjen egy friss üzenettel, amely spambe került, és menjen végig ezen a sorrenden:

  1. Erősítse meg a hitelesítést. Ellenőrizze az SPF, DKIM és DMARC eredményeket a received fejlécekben.
  2. Ellenőrizze az igazodást. Nézze meg, mely domainek mentek át, és igazodnak-e a látható From domainhez.
  3. Azonosítsa a levélfolyamot. Tranzakciós, életciklus-, értékesítési, hírlevél- vagy hideg megkeresés?
  4. Tekintse át a közönség minőségét. Hozzájáruló, nemrég aktív címzetteknek küldték?
  5. Vizsgálja meg a linkeket. A linkdomainek megbízhatóak, következetesek és várhatóak?
  6. Nézze meg az aktivitást. A címzettek megnyitják, kattintanak, válaszolnak vagy figyelmen kívül hagyják?
  7. Ellenőrizze a panaszokat és visszapattanásokat. Ezek gyakran többet mondanak, mint a megnyitási arányok.
  8. Hasonlítsa össze a szolgáltatókat. A probléma főleg Gmailnél, Outlooknál, vállalati szűrőknél jelentkezik, vagy mindenhol?
  9. Változtasson meg egy változót. Szegmentáljon, csökkentse a volument, tisztítsa a listát vagy módosítsa a tartalmat — majd mérjen.

Ha jelentős volument küld, használja a postafiók-szolgáltatók által kínált jelentéskészítő eszközöket, ahol elérhetők. Nem fednek fel minden részletet, de megmutathatják, hogy domainreputációs, IP-reputációs, hitelesítési vagy panaszarány-problémája van-e.

<!-- tool-cta:start -->

💡 Próbálja ki ezt: Még ha az SPF át is megy, a hibás konfigurációk és a lekérdezési korlátok ronthatják a kézbesíthetőséget—ellenőrizze újra a rekordját az SPF Tester segítségével.

<!-- tool-cta:end -->

Józan kézbesíthetőségi ellenőrzőlista

Ha az e-mailje hitelesített, de mégis spambe kerül, először ezekre a javításokra fókuszáljon:

  • csak olyanoknak küldjön, akiknél egyértelmű hozzájárulás vagy erős meglévő kapcsolat áll fenn;
  • azonnal távolítsa el a végleges visszapattanásokat;
  • szűrje ki a tartósan inaktív címzetteket;
  • tegye a leiratkozást könnyebbé, mint a panaszkodást;
  • tartsa következetesen a From neveket és domaineket;
  • kerülje a hirtelen volumennövekedéseket;
  • ahol indokolt, válassza szét a tranzakciós és promóciós leveleket;
  • távolítsa el a nem használt harmadik fél feladókat a DNS-ből;
  • aláírja a leveleket igazodó DKIM domainnel;
  • figyelje a DMARC jelentéseket és a panaszzal kapcsolatos adatokat.

A minta egyszerű: legyen azonosítható, legyen várható, legyen kívánt és legyen következetes.

Az SPF, DKIM és DMARC azért szükséges, mert bizonyítják, hogy a levele nem triviálisan hamisított. De a beérkező levelek közé kerülés reputációs döntés. A postafiók-szolgáltatók nem csak azt kérdezik: „Ez tényleg Öntől jött?” Azt is kérdezik: „Úgy tűnik, a felhasználóink akarnak levelet kapni Öntől?”

Erre a második kérdésre nehezebb válaszolni, és nehezebb hamisítani. És ez dönti el, hogy a hitelesített levél eljut-e a beérkező levelek közé.

Gyakran ismételt kérdések

Kerülhet e-mail spambe akkor is, ha az SPF, DKIM és DMARC mind sikeres?
Igen. A hitelesítés csak azt bizonyítja, hogy az üzenet jogosult és igazodó. A postafiók-szolgáltatók továbbra is értékelik a reputációt, a címzettek aktivitását, a panaszokat, a tartalmat, a linkeket, az infrastruktúrát és a küldési viselkedést.
Javítja a beérkező levelek közé kerülést a p=reject DMARC policy?
Közvetlenül nem. Az erősebb DMARC policy megvédheti a domainjét a hamisítástól, és javíthatja a domain iránti bizalmat, de nem kapcsoló a beérkező levelek közé kerüléshez. A gyenge listaminőség vagy a sok panasz továbbra is spambe küldheti a hitelesített levelet.
Használjak külön domaint marketing e-mailekhez?
Gyakran inkább aldomaint használjon, ne teljesen független domaint. Például a marketing.example.com segíthet elkülöníteni a reputációt a kritikus tranzakciós levelektől, miközben a márkaidentitás egyértelmű marad. Kerülje a csak kampányokhoz létrehozott, eldobhatónak tűnő domaineket.
Fontosak még a spamet kiváltó szavak?
Kevésbé fontosak, mint sokan gondolják. A modern szűrés kontextuális. A megtévesztő tárgysorok, gyanús linkek, hibás HTML, kizárólag képekből álló e-mailek és gyenge aktivitás általában nagyobb problémát jelentenek, mint egy állítólag kockázatos szó.
Mit ellenőrizzek először, ha egy kampány spambe kerül?
Ellenőrizze a hitelesítést és az igazodást, majd nézze meg a panaszokat, a visszapattanási arányt, a lista forrását, a közelmúltbeli volumenváltozásokat és a linkdomaineket. Ha ezek nincsenek rendben, a tárgysor átírása nem fogja megoldani az alapvető problémát.

Források és további olvasmányok

  1. Google Workspace Admin Help: Email sender guidelines
  2. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
  3. M3AAWG Sender Best Common Practices
  4. Microsoft Learn: Email authentication in Microsoft 365
A szerzőről
The Wux Webtools Team

Utolsó frissítés:

Tovább olvasom