E-mail-hitelesítés: SPF, DKIM, DMARC

Márkavédelem

Hitelesítés nélkül a domained szabad préda. A leggyakoribb eset a számlacsalás: az ügyfeled kap egy levelet a te címedről, más bankszámlaszámmal. A kár pénzben és bizalomban is mérhető, a helyreállítás hónapokig tart.

Kézbesíthetőség

A nagy szolgáltatók a hitelesítést szűrési jelként használják. Hiányos beállítással a rendelésvisszaigazolás, a jelszó-emlékeztető és a hírlevél is gyakrabban kerül spam mappába. Webshopnál ez közvetlen bevételkiesés.

Szabályozói nyomás

A Google és a Yahoo 2024 februárja óta a napi 5000 fölött küldő feladóktól megköveteli a DMARC-rekordot. A küszöb alatt is érdemes megcsinálni, mert a szűrés egyre szigorodik.

Technikai higiénia

A hitelesítés nem SEO-tényező, a rangsorolást nem befolyásolja. A weboldal biztonsági képét viszont igen: egy auditban a hiányzó DMARC ugyanabba a kategóriába esik, mint a hiányzó biztonsági fejlécek. A riportokban ezt látjuk a leggyakrabban együtt.

Minden domainre vonatkozik, ami e-mailt küld vagy fogad. Céges levelezés, webshop rendszerlevelei, hírlevélküldő, CRM-értesítések: mind érintett.

Külön figyelj erre:

• Webshopok, ahol a tranzakciós levél üzletkritikus.
• Több küldő rendszert használó cégek (levelezés + hírlevél + számlázó).
• Aldomainek: ha hirlevel.pelda.hu címről küldesz, a szervezeti domain DMARC-jában az sp= tag dönt róla.

Nem alkalmazható:

• Staging és fejlesztői címek, ahol nincs valódi levelezés. Ilyenkor a vizsgálat nem értelmezhető, és nem ellenőrizhető állapotot kapsz.
• Parkoltatott domain, amiről soha nem megy levél. Ott viszont érdemes egy v=spf1 -all és p=reject páros, hogy senki ne tudjon a nevében küldeni.

Hatókör szerint ez környezeti-hosztingszintű feladat. A fejlesztőd a weboldal kódjában nem tudja megjavítani, a DNS-kezelőben viszont öt perc alatt igen.

Lépések

1. Nyisd meg a terminált, és kérdezd le a TXT rekordokat dig vagy nslookup paranccsal (lásd a technikai példát).
2. Az SPF-et a domain gyökerén keresd: dig TXT pelda.hu. A v=spf1 kezdetű sor az.
3. A DMARC külön aldomainen van: dig TXT _dmarc.pelda.hu. A v=DMARC1 kezdetű sort keresed.
4. A DKIM-hez ismerned kell a selectort. Ezt a küldő rendszer dokumentációja adja meg (Google Workspace: google, Microsoft 365: selector1). A lekérdezés: dig TXT selector._domainkey.pelda.hu.
5. Ha nincs terminálod, küldj egy levelet magadnak. Gmailben a ... menüben az Eredeti megjelenítése pontnál látod az SPF, DKIM és DMARC eredményét egymás alatt.

Jó jel

• Pontosan egy SPF rekord, -all vagy ~all zárással.
• Létező DMARC rekord, p=quarantine vagy p=reject szabállyal.
• A DKIM aláírás pass értékkel jön vissza a fejlécben.
• Az SPF DNS-lekérdezéseinek száma 10 alatt van.

Rossz jel

• Nincs SPF, vagy kettő is van (ilyenkor mindkettő érvénytelen).
• Az SPF +all-ra végződik: ez bárkinek engedélyt ad.
• Nincs DMARC, vagy évek óta p=none állapotban áll.
• Aldomainről küldesz, de a szervezeti DMARC-ban nincs sp= tag.

Mit néz ebből a riport

Az audit a domain DNS-ében az SPF- és a DMARC-rekordot kérdezi le, és a záró mechanizmust, illetve a szabályzatot értékeli. A DKIM-et nem vizsgálja, mert ahhoz ismerni kellene a selectort. A szabály hatása közepes, a hatóköre környezet és hoszting. Staging címen a vizsgálat nem alkalmazható.

A javítás mindenhol a DNS-kezelőben történik, nem a CMS-ben. A CMS-ek alatt ezért azt írom le, honnan szerzed meg a küldő rendszer adatait.

WordPress

1. Nézd meg, mi küldi a leveleket: a szerver mail() függvénye vagy egy SMTP-plugin (WP Mail SMTP, FluentSMTP).
2. SMTP esetén a szolgáltató (SendGrid, Mailgun, Brevo) adja a kötelező SPF-include-ot és a DKIM CNAME-eket.
3. Vedd fel ezeket a DNS-kezelőben, majd told fel a DMARC-ot p=none szinten.
4. Két hét riportgyűjtés után lépj p=quarantine, majd p=reject szintre.

Shopify

1. A Settings > Notifications > Sender email pontban add meg a saját domained címét.
2. A Shopify ott kiírja a szükséges CNAME rekordokat (SPF és három DKIM bejegyzés).
3. Vedd fel őket a DNS-kezelőben, és várd meg a zöld Verified állapotot.
4. A DMARC-ot külön, kézzel kell felvenned a _dmarc aldomainre.

Unas

1. Az admin felületen a levélküldés beállításainál nézd meg, saját domainről megy-e a küldés.
2. Az Unas dokumentációjában megadott SPF-include értéket vedd fel a meglévő SPF rekordba, ne külön sorba.
3. Ha hírlevélküldőt is használsz, annak az include-ját is ugyanabba a sorba tedd.
4. DMARC rekordot a domain DNS-kezelőjében hozz létre.

Shoprenter

1. A rendszer a saját szervereiről küld, ezért a Shoprenter által dokumentált SPF-include kötelező.
2. Egyeztesd a támogatással a DKIM selectort, és vedd fel a publikus kulcsot.
3. A DMARC-ot itt is a domain gyökerén, _dmarc néven állítod be.

Egyedi fejlesztés

1. Listázd az összes küldő forrást: alkalmazásszerver, tranzakciós API, hírlevélküldő, számlázó, ügyfélszolgálati rendszer.
2. Mindegyikhez vedd fel az SPF-include-ot, és figyelj a 10-es lekérdezési limitre.
3. Kapcsold be a DKIM aláírást minden forrásnál, lehetőleg külön selectorral.
4. Indulj p=none szabállyal és rua= riportcímmel, majd szigoríts.
5. Aldomainről küldő rendszernél állítsd be az sp= taget is.

• Két SPF rekord egy domainen: az RFC szerint ilyenkor egyik sem érvényes, a hitelesítés azonnal bukik.
• +all vagy hiányzó záró mechanizmus: gyakorlatilag mindenkinek engedélyt ad a nevedben küldeni, tehát semmit nem véd.
• Örök p=none: a DMARC csak figyel, de nem tesz semmit, a hamisított levél így simán kézbesül.
• 10 fölötti SPF-lekérdezés: a fogadó permerror-t ad, és az egész SPF-ellenőrzés érvénytelen lesz.
• Hiányzó sp= tag: a szervezeti domain védve van, de az aldomainjeiről bárki küldhet.
• Új küldő rendszer bevezetése DNS-módosítás nélkül: a számlázó vagy a CRM levelei csendben spam mappába kerülnek.
• DKIM aláírás hírlevélküldőnél kihagyva: továbbküldésnél elbukik a hitelesítés, mert az SPF ott már nem segít.

Lekérdezés terminálból. Ez mindhárom rekordot megmutatja, ha léteznek:

dig +short TXT pelda.hu
dig +short TXT _dmarc.pelda.hu
dig +short TXT google._domainkey.pelda.hu

# Windowson:
nslookup -type=TXT _dmarc.pelda.hu

Egy működő beállítás DNS-rekordjai. A ~all soft fail, a -all hard fail; kezdésnek a ~all biztonságosabb:

; SPF a domain gyökerén, egyetlen sorban minden küldővel
pelda.hu.           IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

; DMARC szabályzat, aldomain-öröklés sp= taggel
_dmarc.pelda.hu.    IN TXT "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@pelda.hu; pct=100; adkim=r; aspf=r"

; DKIM publikus kulcs, a selector a küldő rendszertől függ
google._domainkey.pelda.hu. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

A rua= címre érkező XML-riportokból derül ki, mely rendszerek küldenek a nevedben. Ezt olvasd két hétig, mielőtt p=reject-re váltasz.