Defaults.Exposed › Jelentések

DMARC vs. SPF: Mi a különbség, és melyikre van szükséged? (2026)

Közzétéve 2026-07-25 · frissítve2026-07-30

Adatok: 2026-08-16 · metodológia v8. Aggregált cenzusadatok 276 millió osztályozott domain alapján. A “kikényszerítés” quarantine vagy reject DMARC-házirendet jelent. Lásd: hogyan osztályozunk.

Része a DMARC-pillérnek — DMARC-elterjedtség, érettség és ranglisták, a teljes cenzuson mérve.

Mindkettőre szükséged van — először SPF, aztán DMARC —, mert különböző kérdésekre válaszolnak. Az SPF egy lista: mely szerverek küldhetnek e-mailt a domainem nevében? A DMARC egy házirend: mit tegyenek a fogadók egy hitelesítésen megbukó üzenettel — és hogyan tudom meg, hogy ez megtörtént? Egyik sem helyettesíti a másikat. Az SPF DMARC nélkül hamisíthatóan hagyja a látható “Feladó” címedet; a DMARC-nak SPF (vagy DKIM) nélkül nincs mit kikényszerítenie. A cenzus megmutatja, milyen gyakran keverik össze a kettőt: 2026-08-16 állapot szerint a 276 millió osztályozott domain 51.24%-a publikál SPF-et, de csak 11.83% kényszeríti ki a DMARC-ot — több tízmillió vállalkozásnyi szakadék, akik megtették az első lépést, és azt hiszik, készen vannak.

Mit csinál valójában az SPF

Az SPF (Sender Policy Framework) egyetlen DNS TXT-rekord, amely felsorolja a domained nevében levelet küldeni jogosult szervereket — a postafiók-szolgáltatódat, a hírlevélküldő eszközödet, a CRM-edet. Amikor egy levelezőszerver olyan üzenetet kap, amely állítása szerint tőled jön, ellenőrzi, hogy az üzenetet kézbesítő szerver rajta van-e a listádon.

Két részlet fontos itt, mert ezek határozzák meg az SPF korlátait:

• Az SPF a technikai feladót ellenőrzi, nem a láthatót. Az SPF által validált cím a boríték (envelope) feladó (a “Return-Path” — a cím, ahová a visszapattanások mennek). Sosem nézi azt a “Feladó” sort, amelyet egy ember a postafiókjában olvas. Ez a két cím teljesen eltérhet, és a legtöbb csalásnál el is tér.
• Az SPF nem mondja meg, mi történjen bukás esetén. A rekord egy minősítővel zárul (-all vagy ~all), amely javasolja, hogyan kezeljék a fogadók a listán nem szereplő feladókat, de nincs kötelező érvényű utasítás és nincs visszajelzés feléd. Az SPF-fel rendelkező domainek közül csak 39.2% használja egyáltalán a szigorú -all-t; 55.9% a ~all-t használja, amelyet a legtöbb fogadó úgyis kézbesít.

Az SPF szükséges alapinfrastruktúra. Önmagában nem védelem — ezt az adatok nyersen alátámasztják: az összes domain 30.9%-a publikál SPF-et, de egyáltalán nincs DMARC-ja (a hamis biztonságérzet szakadéka, megmérve).

Mit csinál valójában a DMARC

A DMARC (Domain-based Message Authentication, Reporting and Conformance) az SPF-re és a DKIM-re épül, és hozzáadja azt a három dolgot, ami azokból hiányzik:

1. Védi a címet, amelyet az emberek látnak. A DMARC igazítást (alignment) követel: az SPF-en vagy DKIM-en átment domainnek egyeznie kell a látható “Feladó” fejlécben szereplő domainnel. Ez zárja be az SPF által nyitva hagyott rést — a támadó többé nem mehet át az SPF-en a saját infrastruktúráján, miközben a te nevedet mutatja.
2. Megmondja a fogadóknak, mit tegyenek bukás esetén. A DMARC-rekordod egy házirendet publikál: p=none (kézbesítsd úgyis, csak jelentsd), p=quarantine (spam mappa) vagy p=reject (utasítsd el). Ez az a kikényszerítési réteg, amely az SPF-ből mindig is hiányzott.
3. Visszajelez neked. A fogadók aggregált jelentéseket küldenek, amelyek megmutatják, ki küld a domained nevében — jogosan és jogtalanul. Ez az egyetlen ilyen szabvány, amelynek visszacsatolási hurka van, és ezáltal tudod biztonságosan szorosabbra húzni a többit.

A csapda: a DMARC csak quarantine vagy reject szinten véd. Egy p=none-on parkoló rekord figyel, és semmi mást nem tesz — a p=none nem védelem. 2026-08-16 állapot szerint a domainek 74.20%-ának nincs DMARC-rekordja, 13.96% csak megfigyelő módban áll, és mindössze 11.83% kényszerít ki.

SPF vs. DMARC, egymás mellett

Az egysoros összefoglaló: az SPF egy útvonalat hitelesít; a DMARC egy identitást véd. A fogadók az SPF-et egy jelzésként mérlegelik a sok közül. A kikényszerített DMARC egy döntés.

Miért bukik el az SPF önmagában

Három strukturális ok, nem implementációs hiba:

A Feladó-fejléc rése. Az SPF sosem vizsgálja a “Feladó” sort. Egy csaló a scammer-domain.com infrastruktúrájáról küld, a látható Feladó mezőben a te cégeddel: az SPF az ő boríték-domainjét ellenőrzi az ő SPF-rekordja alapján, simán átmegy, és a hamisítvány hitelesnek tűnve landol. Ezt csak a DMARC igazítási követelménye kapja el — ezért marad rutinszerű az e-mail-hamisítás a csak-SPF-es domainek ellen, és ezért személyesíthető meg továbbra is az osztályozott domainek 88.17%-a.

Továbbítás. Amikor valaki automatikusan továbbítja a leveledet (egy régi cím egy újra, egy terjesztési alias), a továbbító szerver kézbesíti azt — és az a szerver nincs az SPF-rekordodban, így az SPF teljesen jogos levélen bukik el. Ez nem hibás konfiguráció; a továbbítás így működik. A DKIM-aláírások túlélik a továbbítást, ezért a DMARC (amely igazított SPF vagy igazított DKIM esetén is átmegy) kezeli ezt, a nyers SPF pedig nem. Részletek: a továbbítás elrontja az SPF-et.

Nincs következmény, nincs visszajelzés. Még egy tökéletes, -all-lal záruló SPF-rekord is azon múlik, hogy minden fogadó a cselekvést választja-e, és semmit sem mond arról, mit küldenek a nevedben. A DMARC ezt kifejezett utasítássá és jelentéssé alakítja.

Milyen sorrendben telepíts

A sorrend azért számít, mert a DMARC azt fogyasztja, amit az SPF és a DKIM előállít. Telepíts fentről lefelé:

1. Először SPF. Publikálj egy TXT-rekordot minden jogos feladóval, a végén ~all-lal, amíg ellenőrzöl, -all-lal, amikor kész vagy. SPF javítása.
2. Másodikként DKIM. Kapcsold be az aláírást a levelezőszolgáltatódnál — ez tartja épen a hitelesítést továbbítás közben is. DKIM javítása.
3. DMARC p=none szinten, jelentéssel. Publikáld: v=DMARC1; p=none; rua=mailto:..., és ténylegesen olvasd is a jelentéseket — meglepően sok domain publikál vakon DMARC-ot, jelentési cím nélkül. Szolgáltatói lépések: Google Workspace · Microsoft 365.
4. Húzd szorosabbra quarantine-ra, majd reject-re, amint a jelentések azt mutatják, hogy a jogos leveleid átmennek. Ez a lépés a védelem; minden előtte lévő csak előkészület. A biztonságos felfelé vezető út.

Az előreugrás mindkét irányban bajt okoz. A DMARC az SPF/DKIM előtt a saját jogos leveleidet karanténozza. Az SPF-és-kész — a leggyakoribb végállapot, az összes domain 30.9%-a — nyitva hagyja a látható Feladó címet. A domaineknek csak 2.79%-a teljesíti az összes lépést.

Az őszinte határesetek

• A levelezőlisták mindkettőt elronthatják. A tárgyat átíró vagy láblécet hozzáadó listák érvénytelenítik a DKIM-aláírásokat és megbuktatják az SPF-et (a listaszerver küld). A modern listák kompenzálásképp átírják a Feladó fejlécet. Ha a közösséged levelezőlistákon él, számíts némi fájdalomra reject szinten — kezelhető, nem ok arra, hogy none-on maradj.
• Az SPF átmehet, miközben a DMARC megbukik. Sok küldőplatform a saját domainjét használja boríték-feladóként, így az SPF átmegy — a te Feladó-domaineddel nem igazítva. Az ilyen levélnek igazított DKIM kell (egyedi aláíró domain, amit a jó platformok támogatnak), hogy átmenjen a DMARC-on. Ha a DMARC-od megbukik, miközben az SPF és a DKIM átmegy, szinte mindig az igazítás az ok.
• Az SPF-nek 10 DNS-lekérdezéses korlátja van. Túl sok include: bejegyzés láncolása esetén a rekord állandó hibát ad vissza, és teljesen figyelmen kívül marad. Konszolidálj, mielőtt szorosabbra húzod a DMARC-ot, különben törött SPF tetejére kényszerítesz.
• A soha nem küldő domaineknek is kell mindkettő — a legszigorúbb változatban (v=spf1 -all és p=reject) —, különben a parkoltatott és nem használt domainjeid a legkönnyebben hamisíthatók.
• A DMARC nem az út vége. A pontosan egyező domainnel való megszemélyesítést állítja meg. A hasonló kinézetű domainek, a megjelenítettnév-trükkök és a feltört valódi postafiókok más problémák — valósak, de nem ok arra, hogy kihagyd az egyetlen támadási osztályt, amelyet három DNS-rekorddal le tudsz zárni.

Gyakran ismételt kérdések

Ugyanaz a DMARC, mint az SPF? Nem. Az SPF a jóváhagyott küldőszerverek listája, egy olyan cím alapján ellenőrizve, amelyet az olvasó sosem lát. A DMARC azt ellenőrzi, hogy aki hitelesített, egyezik-e a látható “Feladó” címmel, bukás esetén alkalmazza az általad választott házirendet, és jelent neked.

Kell DMARC, ha már van SPF-em? Igen. Az SPF önmagában nem védi a látható Feladó címet — a domainek 30.9%-ának van SPF-je és nincs DMARC-ja, és továbbra is hamisíthatók. Az SPF a DMARC előfeltétele, nem helyettesítője.

Használhatok DMARC-ot SPF nélkül? Technikailag igen, ha a DKIM a helyén van — a DMARC bármelyik igazított mechanizmussal átmegy. A gyakorlatban mindkettőt akarod alá: az SPF elkapja, amit a DKIM elvét, és fordítva (a továbbítás a klasszikus eset, ahol csak a DKIM éli túl).

Melyiket állítsam be először? SPF, aztán DKIM, aztán DMARC p=none szinten jelentéssel, aztán kikényszerítés. A DMARC-nak működnie kell az első kettőnek, mielőtt biztonságosan szorosabbra húzhatod.

Kerül bármelyik pénzbe? Nem — az SPF, a DKIM és a DMARC mind ingyenes DNS-rekord. A befektetés a gondosság és a sorrend, nem a költségvetés. (A DMARC-jelentések olvasása könnyebb egy ingyenes vagy fizetős jelentésnézővel, de maga a védelem semmibe sem kerül.)

Nézd meg, hol áll a domained

A legtöbb domainnek megvan a listája, de nincs meg a zárja. Ellenőrizd a tiédet ingyen és privát módon — együtt látod az SPF-, DKIM- és DMARC-állapotodat, és hogy melyik a következő lépés.

Ellenőrizd a domained → · SPF javítása → · DMARC javítása → · Hogyan osztályozunk → · Csak aggregált adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.