Ne találgass a DNS-ednél: fejlesztőbarát körút az MX, SPF, DKIM és DMARC világában

Miért számítanak most az e-mailes DNS-rekordok

Az e-mail-hitelesítés korábban opcionális volt. 2026-ban már alapkövetelmény. A Gmail és az Outlook egyaránt megköveteli az SPF-et és a DKIM-et a tömeges feladóktól, a DMARC pedig gyorsan kötelezővé válik minden olyan domain számára, amely tranzakciós e-maileket küld. Ha a DNS-rekordjaid hibásak, az e-mailjeid nem érkeznek meg — nincs visszapattanás, nincs figyelmeztetés, csak csend.

A probléma az, hogy ezek a rekordok úgy vannak dokumentálva, mint az RFC-k, nem úgy, mint az eszközök. A legtöbb fejlesztő bemásolja az e-mail-szolgáltató beállítási útmutatójában szereplő példákat, és reménykedik a legjobbakban. Ez addig működik, amíg hibát kell keresni, hozzá kell adni egy második küldőszolgáltatást, vagy el kell magyarázni egy ügyfélnek, miért landolnak a kapcsolatfelvételi űrlap e-mailjei a spamben.

Ez az útmutató az MX, SPF, DKIM és DMARC rekordokon abban a sorrendben megy végig, ahogyan ténylegesen találkozni fogsz velük: elég részlettel a helyes konfiguráláshoz, és elég kontextussal a hibakereséshez, amikor valami elromlik.

MX rekordok: hová menjen a bejövő e-mail

Az MX rekordok mondják meg az internetnek, mely levelezőszerverek fogadnak e-mailt a domainedhez. A négy közül ezek a legegyszerűbbek, de ezeket is nagyon könnyű félrekonfigurálni.

Egy MX rekord két részből áll: egy prioritási számból és egy hostname-ből. Az alacsonyabb prioritási számokat próbálják először. Ha Google Workspace-et használsz, az MX rekordjaid például így nézhetnek ki:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

A záró pontok számítanak — azt jelzik, hogy a hostname teljesen minősített. A legtöbb DNS-szolgáltató automatikusan hozzáadja őket, de nem mindegyik.

Gyakori hibák: MX rekordot A rekordra irányítani hostname helyett, minden prioritást ugyanarra a számra állítani (ami kiüti a tartalékok értelmét), vagy elfelejteni eltávolítani a régi MX rekordokat szolgáltatóváltáskor. Az elavult MX rekordok nem csak ártalmatlanul ott ülnek — levélhurkokat okozhatnak, vagy két postafiók között megoszthatják a kézbesítést.

Ha saját kapcsolatfelvételi űrlapot futtatsz, és harmadik féltől származó szolgáltatások nélkül szeretnéd elkerülni a spamet, hasznos kiindulópont megérteni, hogyan válnak az űrlapok spamvektorokká.

SPF: mely szerverek küldhetnek a nevedben

Az SPF (Sender Policy Framework) egy TXT rekord, amely felsorolja azokat az IP-címeket és domaineket, amelyek jogosultak e-mailt küldeni a domained nevében. Ez az első ellenőrzés, amelyet a legtöbb levelezőszerver elvégez, amikor olyan üzenetet kap, amely azt állítja, hogy tőled érkezik.

Egy alap SPF rekord így néz ki:

v=spf1 include:_spf.google.com ~all

Lebontva:

• v=spf1 deklarálja az SPF verzióját
• include:_spf.google.com a Google SPF rekordjára delegál
• ~all soft fail — utasítsd el a nem listázott forrásokból érkező levelet, de ne légy túl szigorú

Használhatsz ip4: vagy ip6: mechanizmust is konkrét címek engedélyezésére, illetve a és mx mechanizmust a domained A és MX rekordjaira való hivatkozáshoz. A végén lévő all mechanizmus szabályozza, mi történjen az olyan forrásokból érkező levelekkel, amelyeket nem soroltál fel: a -all hard fail (elutasítás), a ~all soft fail (gyanúsként jelölés), a ?all semleges (nincs állásfoglalás), a +all pedig szabad pálya mindenkinek (ne használd).

Az SPF-nek két éles széle van. Először is, továbbításkor eltörik, mert a továbbító szerver nincs benne az SPF rekordodban. Másodszor, az SPF rekordokra tíz DNS-lekérdezéses korlát vonatkozik. Ha túl sok harmadik féltől származó szolgáltatást foglalsz bele, túlléped a korlátot, és az SPF leáll. A javítás az SPF rekord „kilapítása”: az include: direktívák cseréje a tényleges IP-tartományokra — ez viszont karbantartást igényel, amikor a szolgáltatók IP-címet változtatnak.

DKIM: kriptográfiai bizonyíték a feladó azonosságára

A DKIM (DomainKeys Identified Mail) digitális aláírást ad a kimenő e-mailedhez. A fogadó szerver az aláírást a DNS-edben közzétett nyilvános kulccsal ellenőrzi. Ha az aláírás érvényes, és az üzenetet nem módosították, a DKIM sikeres.

Az SPF-fel ellentétben a DKIM túléli a továbbítást, mert az aláírás az üzenettel együtt utazik. Rugalmasabb is — több DKIM kulcsod lehet különböző küldőszolgáltatásokhoz, mindegyik saját selectorral.

Egy DKIM DNS rekord így néz ki:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

A selector (default ebben a példában) tetszőleges — az e-mail-szolgáltatód választja ki. A p= érték a nyilvános kulcs, általában egy hosszú, base64-kódolt karakterlánc. Az e-mail-szolgáltatód generálja a privát kulcsot, és ezzel írja alá a kimenő üzeneteket.

A DKIM beállítását szinte mindig az e-mail-szolgáltatód kezeli. A te dolgod az, hogy kimásold az általuk adott TXT rekordot, és beilleszd a DNS-edbe. A trükkös rész az, hogy egyes DNS-szolgáltatók nem kezelik jól a hosszú TXT rekordokat — vagy levágják őket, vagy megkövetelik, hogy az értéket több idézőjeles karakterláncra bontsd.

A DKIM működésének ellenőrzéséhez küldj teszt e-mailt egy Gmail-címre, és nézd meg a fejléceket. Keresd a dkim=pass értéket az Authentication-Results fejlécben.

DMARC: házirend-kikényszerítés és jelentéskészítés

A DMARC (Domain-based Message Authentication, Reporting and Conformance) összeköti az SPF-et és a DKIM-et, és megmondja a fogadó szervereknek, mit tegyenek, ha a hitelesítés sikertelen. Emellett jelentéskészítést is engedélyez, így láthatod, ki küld e-mailt a domained nevében — a legitim feladókat és a hamisítókat egyaránt.

Egy minimális DMARC rekord így néz ki:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none azt jelenti, hogy csak monitorozás történik — a sikertelen üzeneteket ne utasítsák el és ne tegyék karanténba
• rua=mailto:[email protected] megadja, hová küldjék az összesített jelentéseket

Ha már biztos vagy benne, hogy az SPF és a DKIM működik, szigoríthatod a házirendet p=quarantine értékre (a sikertelen üzenetek menjenek spambe) vagy p=reject értékre (utasítsák el őket azonnal). Beállíthatsz aldomain-házirendet is az sp= mezővel, és megadhatod a pct= mezővel, hogy az üzenetek hány százalékára alkalmazzák a házirendet.

A DMARC jelentések XML-fájlok, amelyeket a nagy fogadók naponta küldenek. Nyersen bőbeszédűek és nehezen olvashatók, de pontosan megmutatják, mely üzenetek mentek át vagy buktak el a hitelesítésen, és miért. Ha legitim levelek elutasítását látod, a jelentések megmutatják, melyik SPF- vagy DKIM-ellenőrzés hibázik.

Egy buktató: a DMARC alignmentet követel. SPF esetén a Return-Path fejlécben lévő domainnek egyeznie kell a From fejlécben lévő domainnel (vagy annak aldomainjének kell lennie). DKIM esetén a DKIM aláírásban lévő d= domainnek kell egyeznie a From domainnel. Ha harmadik féltől származó küldőszolgáltatást használsz, támogatnia kell az egyedi return patheket vagy a saját domaineddel történő DKIM-aláírást, nem a sajátjával.

Hogyan auditáld a jelenlegi beállításodat

A legtöbb DNS-probléma láthatatlan, amíg gondot nem okoz. Így ellenőrizheted a rekordjaidat, mielőtt valami eltörik:

1. Kérdezd le az MX rekordjaidat: dig MX example.com adja vissza a levelezőszervereid hostname-jeit és prioritásait. Ellenőrizd, hogy egyeznek-e az e-mail-szolgáltatód dokumentációjával.

1. Ellenőrizd az SPF szintaxisát: dig TXT example.com, majd keresd meg a v=spf1 rekordot. Futtasd át egy SPF-validátoron, hogy elkapd a szintaktikai hibákat és a lekérdezési korlát megsértését.

1. Ellenőrizd a DKIM kulcsokat: Küldj teszt e-mailt, és vizsgáld meg a DKIM-Signature fejlécet. Nyerd ki a selectort és a domaint, majd kérdezd le: dig TXT selector._domainkey.example.com, hogy megerősítsd, létezik a nyilvános kulcs.

1. Validáld a DMARC házirendet: dig TXT _dmarc.example.com adja vissza a DMARC rekordodat. Győződj meg róla, hogy a rua= olyan címre mutat, amelyet tényleg figyelsz.

1. Teszteld végponttól végpontig: Használj olyan szolgáltatást, mint a mail-tester.com, vagy küldj egy Gmail-címre, és ellenőrizd a teljes fejléceket. Keresd az spf=pass, dkim=pass és dmarc=pass értékeket az Authentication-Results fejlécben.

Ha azt hibakeresed, miért nem érkeznek meg az e-mailek, a fejlécek a legjobb eszközeid. A legtöbb levelezőkliensben megtekinthetők a nyers fejlécek — Gmailben nyisd meg az üzenetet, kattints a három pontra, és válaszd az 'Eredeti megjelenítése' lehetőséget. Az Authentication-Results fejléc pontosan megmondja, melyik ellenőrzés bukott el, és miért.

Mikor használj aldomain-házirendeket

Ha több aldomainről küldesz e-mailt — például newsletter.example.com marketinghez és app.example.com tranzakciós levelekhez —, aldomainenkénti DMARC házirendeket állíthatsz be. Ez lehetővé teszi, hogy szigorú házirendeket kényszeríts ki az általad kontrollált aldomaineken, miközben a fő domaineden lazább szabályt tartasz.

A kompromisszum a komplexitás. Minden aldomainnek saját SPF, DKIM és DMARC rekordokra van szüksége, és nyomon kell követned, mely küldőszolgáltatások mely aldomainekre jogosultak. A legtöbb kis csapat számára egyetlen jól konfigurált domain egyszerűbb és ugyanilyen biztonságos.

Mi a teendő, ha a hitelesítés elromlik

A leggyakoribb hibatípus az, amikor új küldőszolgáltatást adnak hozzá a DNS frissítése nélkül. Ha új tranzakciós e-mail-szolgáltatót kezdesz használni, hozzá kell adnod az SPF include-jukat vagy IP-tartományukat, be kell állítanod a DKIM-aláírást a saját domaineddel, és ellenőrizned kell a DMARC alignmentet.

A második leggyakoribb probléma a továbbítás. Ha a felhasználók továbbítják az e-mailedet egy másik címre, az SPF sikertelen lesz, mert a továbbító szerver nincs benne az SPF rekordodban. A DKIM általában túléli a továbbítást, így amíg a DKIM sikeres, és a DMARC házirended engedi a részleges alignmentet, az üzenetnek továbbra is kézbesülnie kell. Ha azt látod, hogy a továbbított leveleket elutasítják, ellenőrizd a DMARC házirendedet — a p=reject szigorú alignmenttel eltöri a továbbítást.

A harmadik probléma a DNS-propagáció. A DNS-rekordok módosításainak terjedése órákig tarthat, és a különböző levelezőszerverek különböző ideig cache-elik a rekordokat. Ha épp most frissítettél egy rekordot, és még nem működik, várj néhány órát, majd teszteld újra. A propagációt ellenőrizheted például a whatsmydns.net eszközzel.

Fő tanulságok

• Az MX rekordok a bejövő leveleket irányítják; az SPF, DKIM és DMARC a kimenő leveleket hitelesítik. Különböző problémákat oldanak meg, és mind a négyre szükséged van.
• Az SPF továbbításkor eltörik, és tíz lekérdezéses korlátja van. A DKIM túléli a továbbítást, de szolgáltatásonkénti konfigurációt igényel. A DMARC összeköti őket, és jelentéskészítést tesz lehetővé.
• DMARC-ban kezdd p=none értékkel, figyeld a jelentéseket néhány hétig, majd szigoríts p=quarantine vagy p=reject értékre, amikor biztos vagy benne, hogy a legitim levelek átmennek.
• A DNS-hibák csendesek. Teszteld a konfigurációdat valódi e-maillel, és vizsgáld meg a fejléceket, hogy megerősítsd: az SPF, DKIM és DMARC sikeres.
• Ha a hitelesítés egy új küldőszolgáltatás hozzáadása után romlik el, ellenőrizd az SPF include-okat, a DKIM selectorokat és a DMARC alignmentet. A fejlécek megmondják, melyik ellenőrzés bukott el.

FAQ

Q: Lehet több SPF rekordom?

A: Nem. Több SPF rekord esetén mindegyiket figyelmen kívül hagyják. Ha több szolgáltatást kell engedélyezned, használj include: direktívákat egyetlen SPF rekordon belül, vagy sorold fel közvetlenül az IP-tartományokat. Figyelj a tíz lekérdezéses korlátra.

Q: Kell DMARC, ha csak napi néhány e-mailt küldök?

A: Igen. A DMARC nem a mennyiségről szól — hanem annak bizonyításáról, hogy az vagy, akinek mondod magad. Még a kis domainek is profitálnak a DMARC-ból, mert megakadályozza a hamisítást, és rálátást ad a kézbesítési problémákra. Kezdd p=none értékkel és egy jelentési címmel.

Q: Mi történik, ha a DKIM és az SPF is sikertelen, de az e-mail legitimnek tűnik?

A: A DMARC házirendedtől függ. Ha p=none, a levél figyelmeztetéssel kézbesül. Ha p=quarantine, spambe kerül. Ha p=reject, visszapattan. Ezért érdemes a DMARC jelentéseket figyelni, mielőtt szigorú házirendet kényszerítesz ki — lehetnek legitim feladóid, akikről nem tudtál.

Q: Használhatom ugyanazt a DKIM kulcsot több domainhez?

A: Technikailag igen, de ne tedd. Minden domainnek saját DKIM kulcspárral kell rendelkeznie. A kulcsok megosztása megnehezíti a rotációt, és növeli a károk hatókörét, ha egy privát kulcs kompromittálódik.

Q: Milyen gyakran rotáljam a DKIM kulcsokat?

A: Nincs univerzális szabály, de a legtöbb domainnél évente egyszer ésszerű. Ha azt gyanítod, hogy egy kulcs kompromittálódott, azonnal rotáld. Ügyelj arra, hogy az új nyilvános kulcsot közzétedd a DNS-ben, mielőtt az új privát kulccsal kezdesz aláírni, és a rotáció után hagyd a régi kulcsot a DNS-ben néhány napig a késve érkező levelek kezelésére.

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

💡 Próbálja ki ezt: Vizsgálja meg bármely domain közzétett házirendjét a DMARC Lookup segítségével, hogy lássa, hogyan illeszkednek egymáshoz a gyakorlatban az MX-, SPF- és DMARC-rekordok.

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

Források

• RFC 7208: Sender Policy Framework (SPF) — Az SPF specifikációja, beleértve a szintaktikai szabályokat és a tíz lekérdezéses korlátot.
• RFC 6376: DomainKeys Identified Mail (DKIM) — A DKIM specifikációja, az aláírás létrehozásának és ellenőrzésének leírásával.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — A DMARC specifikációja, beleértve a házirend-szintaxist és az összesített jelentések formátumát.
• Google Workspace: Prevent spoofing and spam — Gyakorlati útmutatás az SPF, DKIM és DMARC konfigurálásához Google Workspace domaineken.