DMARC bevezetése: a none-tól a reject-ig

Modul 4: Kézbesíthetőség: SPF, DKIM és DMARC a gyakorlatban · Olvasási idő: 12 perc

Tanulási cél: E lecke után el tudja magyarázni, hogyan működik az igazodás (alignment), hogyan tervezhető meg egy DMARC-bevezetés szakaszokban p=none-tól p=reject-ig, hogyan válassza ki a megfelelő címkéket (rua, sp, np, t), és hogyan kezelje az átirányítással és levelezőlistákkal kapcsolatos ismert buktatókat.

Kulcsfogalmak: DMARC (RFC 9989), Author Domain (a Forrás mezőben szereplő domain), igazodás (alignment), relaxed és strict (adkim, aspf), szervezeti domain (organizational domain), DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (tesztmód), elavult címkék: pct, rf, ri, levelezőlisták, Forrás mező átírása, ARC

Mit ellenőriz pontosan a DMARC

A DMARC minden beérkező levélnél egyetlen kérdésre ad választ: sikeres-e az SPF vagy a DKIM egy olyan domainre, amely igazodik a Forrás mezőben szereplő címhez? A szabvány a Forrás mezőben szereplő domaint Author Domain-nak nevezi. A rekord alapjait a DNS-tanfolyam 4.5. leckéje tárgyalja. 2026 májusában jelent meg a felülvizsgált szabvány: az RFC 9989, az összegző jelentésekhez az RFC 9990, a hibajelentésekhez pedig az RFC 9991. A meglévő, v=DMARC1 kezdetű rekordok továbbra is érvényesek maradnak.

Igazodás a gyakorlatban

Az, hogy egy domain "hozzá tartozik" egy másikhoz, az igazodás (alignment) fogalommal írható le. Ennek két szintje van:

• relaxed (alapértelmezett): a domainek azonos szervezeti domainnel rendelkeznek. A nieuws.example.com és az example.com igazodik egymáshoz; az example.com és az example.net azonban nem.
• strict (adkim=s vagy aspf=s): a domaineknek pontosan meg kell egyezniük.

SPF esetén a DMARC a Return-Path domainjét hasonlítja össze a Forrás mező domainjével. DKIM esetén egy érvényes aláírás d= domainjét. Néhány példa egy Forrás: info@example.com fejléccel rendelkező levélre:

Hagyja tehát az adkim és az aspf értékét relaxed beállításon, kivéve, ha jó oka van rá, hogy ezt megváltoztassa.

Honnan tudja a fogadó fél, hogy mi a szervezeti domain? Korábban a Public Suffix List alapján, amely olyan domaineket sorol fel, mint a .nl, a .co.uk és a github.io. Az RFC 9989 ezt egy DNS tree walk eljárással váltja fel: a fogadó fél az adott domain és a felette álló domainek _dmarc rekordjait keresi meg. Egy átlagos felhasználó számára ez semmit nem változtat; ez csak akkor érzékelhető, ha aldomaineken is beállít rekordokat.

A bevezetés négy szakasza

A cél a p=reject beállítás elérése: ekkor a fogadó szerverek elutasítják azokat a leveleket, amelyek az Ön nevében próbálnak levelet küldeni, ez pedig a legjobb védelem a hamis számlák és az Ön nevében elkövetett adathalászat ellen. Aki azonban úgy állítja be rögtön a reject értéket, hogy nem ismeri az összes küldőjét, az akár a saját számláit is elutasíthatja. Ezért javasoljuk a következő sorrendet (e tanfolyam ajánlott útvonalaként):

0. szakasz: felkészülés

• Készítsen leltárt az összes küldőjéről (4.2. lecke).
• Győződjön meg róla, hogy minden küldő rendelkezik igazodó SPF-fel vagy DKIM-mel; lehetőleg DKIM-mel, mert az túléli az átirányítást.
• Hozzon létre egy külön címet a jelentésekhez, például dmarc@example.com, vagy használjon egy jelentésszolgáltatást. Hamarosan napi több jelentést is kaphat.

1. szakasz: mérés p=none beállítással

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

A p=none beállítás önmagában semmit nem tesz a levéllel. A fogadó felek minden levelet a szokásos módon kézbesítenek, de naponta küldenek Önnek egy összegző jelentést (aggregate report) minden olyan szerverről, amely az Ön domainje nevében küldött levelet, valamint arról, hogy sikeres volt-e az SPF, a DKIM és a DMARC. Ezzel egyúttal megfelel a Gmail, a Yahoo és a Microsoft tömeges küldőkre vonatkozó minimumkövetelményének is (5.3. lecke).

Hagyja ezt a beállítást legalább két-négy hétig érvényben, és hosszabb ideig, ha vannak olyan szolgáltatásai, amelyek csak ritkán küldenek levelet (egy éves emlékeztető, egy negyedéves számla). Olvassa el a jelentéseket (4.5. lecke), és javítson ki minden olyan saját forrást, amely nem felel meg.

2. szakasz: p=quarantine

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Az a levél, amely nem felel meg a DMARC-ellenőrzésnek, a fogadó félnél a levélszemét mappába kerül. Ha mégis elfelejt egy forrást, az adott levél nem vész el, de nehezebben megtalálható lesz. Ha óvatosan szeretne eljárni, adja hozzá először a t=y címkét (tesztmód): a fogadó felek ekkor egy fokozattal enyhébb szabályt alkalmaznak (quarantine esetén tehát none-t), de a jelentésekben látni fogja, mi történne egyébként. Ez az RFC 9989-ben a régi pct= címke helyettesítője.

Nézze át ismét néhány hétig a jelentéseket.

3. szakasz: p=reject

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Az a levél, amely nem felel meg a DMARC-ellenőrzésnek, elutasításra kerül. A feladó bounce-üzenetet kap, a Microsoftnál például a 5.7.509 kóddal, a Gmailnél pedig a DMARC-szabályra való hivatkozással (6. modul). Figyelje továbbra is a jelentéseket: mindig felbukkanhatnak új szolgáltatások.

Mikor lehet gyorsabban haladni?

Ha minden levele egyetlen szolgáltatón keresztül megy, amely az Ön nevében kezeli az SPF-et és a DKIM-et, és más semmi nem küld levelet az Ön domainje nevében? Ebben az esetben azonnal beállítható a szigorú szabály. Egyes tárhelyszolgáltatók ezért alapértelmezésben p=reject beállítást alkalmaznak. Ha utólag mégis hírlevélküldő szolgáltatást vagy könyvelőprogramot kezd használni, állítsa vissza ideiglenesen p=none értékre egy jelentési címmel, amíg az adott szolgáltatás megfelelően be nem áll.

A többi címke

Egy másik domainen található jelentési cím (például egy jelentésszolgáltatásé) csak akkor működik, ha az adott domain engedélyt ad erre egy olyan rekorddal, mint a example.com._report._dmarc.rapportdienst.example. Ezt a szolgáltatás általában maga intézi (RFC 9990, 4. fejezet).

Buktatók

Levelezőlisták

Egy klasszikus levelezőlista az Ön levelét a lista minden tagjának továbbküldi, a saját szerveréről, és gyakran hozzáfűz egy [lista] jelölést a tárgyhoz vagy egy lábjegyzetet a szöveghez. Ekkor az SPF (eltérő szerver) és a DKIM (megváltozott levél) is sikertelen lesz. p=reject esetén a fogadó felek elutasítják az Ön levelét a listán. A modern listakezelő szoftverek ezt úgy oldják meg, hogy átírják a Forrás mezőt a lista címére ("Jan via Leden"), vagy úgy, hogy a levelet változatlanul küldik tovább. Ha olyan listát használ, amely ezt nem teszi meg, ezt a jelentéseiben fogja visszaköszönni látni.

Átirányítás

Lásd a 3.3. leckét: az SPF megszakad, a DKIM viszont többnyire túléli. A fogadó fél az ARC segítségével dönthet úgy, hogy megbízik egy ismert átirányítóban. A jelentésekben ezt úgy ismeri fel, hogy egy ismeretlen szerverről érkező levélnél a DKIM pass, az SPF viszont fail; ez önmagában nem ok arra, hogy enyhítsen a szabályán.

Két rekord vagy egy elgépelés

Két DMARC-rekord a _dmarc néven érvénytelenné teszi a szabályt, és egy elgépelés a p= értékben is (a p=rejected nem létezik). Minden módosítás után ellenőrizze.

A gyakorlatban: így néz ki egy kezelőfelületen

A WebOké tárhelycsomagjainál alapértelmezésben a v=DMARC1;p=reject beállítás van érvényben, jelentési cím nélkül. Ez biztonságos, ha minden levele ezeken a szervereken megy keresztül. Ha más szolgáltatásokon keresztül is küld leveleket, állítsa p=none értékre egy rua címmel, és haladjon végig a szakaszokon. A DirectAdminben ezt a DNS adminisztráció menüpontban, a _dmarc rekord melletti ceruza ikonnal teheti meg (a Domain irányelv típusa és az Összegző e-mail (RUA) mezőkben); a Fiókom felületen a DNS fülön található DMARC-segéddel. Más szolgáltatóknál egy TXT-rekordot hoz létre _dmarc néven, és saját maga írja be a szöveget; az eredmény ugyanaz.

Összefoglalás

• A DMARC akkor sikeres, ha az SPF vagy a DKIM sikeres egy olyan domainre, amely igazodik a Forrás mező domainjéhez; a relaxed igazodás elfogadja az aldomaineket is.
• Bevezetés: leltár készítése, p=none beállítás rua-val és a jelentések olvasása, p=quarantine (esetleg t=y-nal), majd p=reject.
• Használja a np=reject beállítást a nem létező aldomainekhez, amint a fő szabály szigorú. A pct, az rf és az ri elavultak.
• A levelezőlisták és az átirányítás várható hibákat okoznak; a DKIM és az ARC ezek egy részét kezelni tudja.
• Pontosan egy rekord legyen a _dmarc néven, elgépelés nélkül.

Kvíz

Feladat

Z4.4 feladat: A domén DMARC-rekordjának ellenőrzése és a következő lépés kiválasztása. Adja meg a saját domainjét (vagy az internet.nl domaint). Adja meg a DMARC-rekordot úgy, ahogy megtalálta, a p= értékét, és hogy szerepel-e benne rua cím. Ezután válassza ki, hogy ön szerint a bevezetés mely szakasza legyen a következő lépés, és indokolja meg miért. A program élőben lekéri a rekordot, ellenőrzi a szintaxist az RFC 9989 alapján (egyetlen rekord, érvényes p, ismert címkék, elavult címkék figyelmeztetésként), és az Ön válaszait is megjeleníti mellette.

További olvasnivaló

Az ezekben a cikkekben leírt lépések a WebOké kezelőfelületeire vonatkoznak; más szolgáltatóknál ez hasonló módon működik.

• Ingyenes DNS-tanfolyam 4.5: DMARC: mit kell tenniük a címzetteknek a hamis levelekkel
• DirectAdmin útmutató 5.9: DMARC beállítása
• Mi az a DMARC? Magyarázat közérthetően
• DMARC-rekord létrehozása a DirectAdminben
• RFC 9989 (DMARC), különösen a 4.7. szakasz (címkék) és a C. melléklet (az RFC 7489 óta történt változások)