Egy cég DMARC-szabályzatának olvasása tíz másodperc alatt (és amit nem árul el)

Egyetlen DNS-lekérdezés megmutatja, hogy egy cég mit kért a világ levelezőszervereitől abban az esetben, ha hamisított leveleket küldtek a nevében. A rekord nyilvános, a parancs pedig egyetlen sor: dig +short TXT _dmarc.example.com. Az eredmény egy rövid beállítási karakterlánc, és benne van egy utasítás — p=none, p=quarantine vagy p=reject — amely a doméntulajdonos preferenciáját fejezi ki abban az esetben, ha az a domén használatával küldött üzenet nem felel meg a hitelesítésnek.

A jelenlegi specifikáció, az RFC 9989, amely 2026 májusában jelent meg IETF Standards Track dokumentumként, az idősebb RFC 7489-et váltotta fel. Szinte szűkszavúan definiálja a három értéket:

• p=none — „A doméntulajdonos nem fejez ki preferenciát."
• p=quarantine — „A doméntulajdonos gyanúsnak tartja az ilyen levelet. Lehetséges, hogy a levél valódi, de a hitelesítési hiba jelentős aggodalmat vet fel."
• p=reject — „A doméntulajdonos úgy tekint az ilyen hitelesítési hibákra, mint egyértelmű jelzésre, hogy a doménnév használata nem érvényes."

Olvassa el ezeket a szavakat újra, mert gyengébbek, mint ahogy a DMARC legtöbb magyarázata elismeri. A szabályzat egy preferencia, amelyet a küldő tesz közzé a fogadók megfontolására. Nem egy olyan utasítás, amelyet a fogadó köteles végrehajtani. Az RFC 9989 ezt egy mondatban mondja ki: „Az üzenet végső kezelése mindig a helyi szabályzat kérdése, és a levelezőszerver-fogadó belátásában áll." Ugyanez a rész mindkét következményt megemlíti — a fogadók „tetszés szerint elutasíthatnak vagy karanténba helyezhetnek egy üzenetet, még akkor is, ha az megfelel a DMARC-hitelesítésnek," és „nem szabad elutasítaniuk az üzeneteket csupán azért, mert az „reject" közzétett szabályzatát követik," pontosan azért, hogy a DMARC által nem leírható módon küldött legitim levelek és levelezési listák ne kerüljenek megsemmisítésre.

Mit árul el valójában a p=none? Kevesebbet, mint ahogy általában vádolnak. A specifikáció saját terminusában ez Monitoring Mode: a doméntulajdonos összesítő jelentéseket gyűjt és „nem fejez ki kezelési preferenciát a DMARC-hitelesítésben megbukó üzenetekre vonatkozóan," miközben a DMARC-ot telepítő fogadó „továbbra is" validálhatja a domén használatát. Mit nem csinál: nem kapcsol ki semmit a vevő oldalán. Az Ön szolgáltatójának levélszűrése, reputációs pontozása, URL-ellenőrzése és melléklet-elemzése független mechanizmus, amely függetlenül fut attól, hogy a küldő mit tett közzé. A hamisított üzenet, amely egy p=none doménhez érkezik, nem lesz előléptetve az inbox-ba a rekord miatt; egyszerűen átadásra kerül a fogadónak nyilatkozott preferencia nélkül, és a fogadó dönt.

A félreértés másik oldala az ellenkező irányba fut. A DMARC nem olvassa az adathalászat e-mail veszélyes részét. Saját specifikációja felsorolja, hogy mi van szándékosan a hatályon kívül, és a „content analysis" ebben a szóban szerepel. Azt is kijelenti, hogy a DMARC „nem foglalkozik vizuálisan hasonló doménnevek vagy az RFC5322.From emberolvasható megjelenítési nevének visszaélésével" — a két trükk, amely a legtöbb márkahamisítási levelet hordozza. És egy sikeres validálás értékéről: „egy DMARC-sikeres validálás önmagában nem garantálja, hogy az üzenet a címzett inbox-jába való kézbesítése biztonságos vagy kívánatos lenne." Egy megfelelően hitelesített üzenet egy eldobható doménből tisztán megfelel a DMARC-nak. A DMARC azt válaszolja meg, hogy ki volt jogosult a From: headerben szereplő domén használatára. Semmi más.

Ez az a pont, ahol a 2024-es tömeges küldő szabályokat rendszeresen félreértelmezik, beleértve a cikk első verzióját is. A Google küldő irányelvei megkövetelik, hogy a 5000 vagy több üzenetet naponta küldő feladók Gmail-fiókokra „állítsanak be DMARC e-mail hitelesítést a küldési doménhez," majd ugyanakkor azt mondják: „A DMARC érvénykényesítési szabályzat beállítható none értékre." A Yahoo saját Sender Hub-ja, amelyet külön kell olvasni, nem pedig automatikusan fel lehet tételezni, hogy másolja a Google-t, az követelményt így fogalmazza meg: „Tegyen közzé egy érvényes DMARC-szabályzatot, amely legalább p=none - a DMARC-nak meg kell felelnie," és egyáltalán nem tesz közzé numerikus mennyiségi küszöbértéket. Mindkét követelménykészlet 2024 februárjától lépett hatályba. Egyikük sem kényszerít senkit le a p=none-ról. Amit valójában kényszerítnek, az az a hitelesítés, amely összhangban van: a Google megköveteli, hogy „a feladó From: headerében szereplő domén legyen összhangban az SPF-doménnel vagy a DKIM-doménnel," és a Yahoo azt mondja, hogy a lazított összehangolás elfogadható. Az összehangolás, nem a szigor, az ajtó.

Ez hagyja a valós okot, hogy a doménnevek a monitorozásnál maradnak, és ez működési jellegű, nem pedig gyávagyság. A quarantine vagy reject értékre való áttérés azt jelenti, hogy először meg kell találni minden olyan szolgáltatást, amely leveleket küld az Ön nevében — bérszámfejtés, jegykiadás, marketing, egy nem dokumentált támogatási asztal — és hitelesíteni mindegyiket, hogy összehangban legyen. Maga a szabvány elismeri azokat a veszélyeket, amelyek lassúvá teszik ezt: a harmadik fél szerződött feladóit a DMARC nem vezeti be és nem zárja ki, az továbbítás és a levelezési listák az összehangolást megbonthatják a küldő hibája nélkül, és a specifikáció a fogadókat az RFC 7960-ra mutatja rá pontosan az ezekben a hibamódokban. Egy szervezet, amely p=none-t tesz közzé és olvassa a jelentéseit, a munka a specifikáció által leírt sorrendben végzi. Az, amely p=none-t tesz közzé és figyelmen kívül hagyja a jelentéseket, nem. Kívülről a rekord egyedül nem tudja megmondani, hogy a kettő közül melyiket nézed.

Nincs szükség terminálra az ellenőrzéshez. Ingyenes keresőeszközök — a dmarcian domain checker, az MXToolbox DMARC check — lekérdezik a rekordot és kinyomtatják a szabályzatot az Ön számára. Végezze el a banknál, a bérszámfejtési szolgáltatónál, a légitársaságnál, amellyel repülőzik. Csak olvassa el a választ annak, ami: a doméntulajdonos szándékainak nyilatkozata, egy input a sokféle között, amelyet az Ön levelezőszolgáltatója önmaga dönt, egy bizonyos típusú hamisítás tekintetében. Ez egy valóban hasznos dolog, amelyet tíz másodperc alatt el lehet olvasni. Nem az, hogy az a következő üzenet, amely azt állítja, hogy az adott márkáról származik, biztonságos-e.

Helyesbítés, 2026. október 20. A cikk egy korábbi verziója úgy leírta a p=none-t, mint amely hamisítványokat szállít az inbox-ba, és a p=reject-et mint az egyetlen beállítást, amely blokkolja az utánzott üzenetet, azt mondta, hogy a 2024-es Google és Yahoo tömeges küldő szabályai eltávolítják a feladókat a p=none-ról, és körülbelül egyharmad doménekben érvénykényesítésről szóló számadatot idéztek. A szabályzat leírásait az RFC 9989 alapján kijavítottuk; mind a Google, mind a Yahoo valójában elfogadja a p=none-t, amely fent idézett a saját dokumentációjából; és az érvénykényesítési számadatot eltávolítottuk, mert az alapjául szolgáló jelentés nem teszi közzé a mintáját vagy a nevezőjét. A cikk most azt is feltünteti, amit a DMARC nem vizsgál meg.