DMARC beállítása: a p=reject nem lehet az első lépés

Aktívan levelező domainnél a DMARC beállítása a küldők felmérésével, az SPF és a DKIM ellenőrzésével, majd p=none házirendű DNS-rekorddal kezdődjön. A Google Workspace DMARC-útmutatója is ezt a megfigyelő házirendet ajánlja induláskor, és a hitelesítési eredmények alapján javasolja a későbbi szigorítást.

A p=none mellett érkező riportokból kiderülhet, hogy egy jogos számlázó, webáruház vagy hírlevélküldő levelei elbuknak-e a DMARC-vizsgálaton. A p=reject az elbukó üzenetek elutasítását kéri a fogadó rendszertől; ezért az aktív domainnél előbb a hibásan beállított küldőket kell rendezni.

Vegye számba a domain összes küldőjét

Írja össze azokat a rendszereket, amelyek a vállalkozás domainjével látható feladót használnak. A Google Workspace vagy a Microsoft 365 mellett ide tartozhat egy számlázó, ügyfélszolgálati rendszer, webáruház és kampányküldő is. A ritkán futó automatikus értesítéseket külön jegyezze fel, mert egy rövid megfigyelési időszakban nem feltétlenül jelennek meg.

Minden küldőnél rögzítse a címzett által látott From-címet, a technikai MAIL FROM domaint és a DKIM-aláírás d= domainjét. Küldjön próbaüzenetet külső postafiókba, majd az Authentication-Results fejlécben nézze meg az SPF-, DKIM- és DMARC-eredményt. Ellenőrzőpont: a szigorításhoz ne csak a fő levelezőrendszer, hanem minden ismert külső szolgáltatás hitelesítési útját is ismerje.

Az SPF- vagy DKIM-siker önmagában kevés

A DMARC sikeréhez legalább az egyik hitelesítési útvonalnak sikeresnek és a látható From-domainhez illeszkedőnek kell lennie. A Gmail küldői irányelvei a közvetlenül küldött leveleknél is a From-domain és az SPF- vagy DKIM-domain illeszkedését követelik meg. Előfordulhat tehát, hogy egy szolgáltató SPF-ellenőrzése a saját technikai domainjén sikeres, miközben az Ön domainjével küldött levél DMARC-eredménye sikertelen.

Külső küldőnél olyan DKIM-aláírást kérjen, amely a saját domainjéhez illeszkedik, vagy állíttasson be hozzá illeszkedő technikai küldődomaint. Ha az egyik megfelelő út már működik, a DMARC sikeres lehet; a másik út beállítása további tartalékot adhat. A próbaüzenet fejlécében a spf=pass vagy dkim=pass érték mellett az smtp.mailfrom=, illetve a header.d= domaint is vesse össze a header.from= domainnel.

Az első rekordban hagyja meg az alapértelmezett, megengedő illeszkedést. A szigorú aspf=s vagy adkim=s pontos domainazonosságot vár el, így egy jogos aldomainnel küldött üzenet illeszkedése is megváltozhat. Ellenőrzőpont: minden fontos küldőtől legyen olyan próbaüzenet, amelynél a sikeres SPF vagy DKIM a From-domainhez is illeszkedik.

Megfigyelő rekord és működő riportcím

Az alábbi minta feltételezi, hogy a ceg.example helyére a saját domainje kerül, és a [email protected] cím már fogad levelet. A rekordot a domain DNS-kezelőjénél hozza létre, akkor is, ha a postafiókokat Google Workspace vagy Microsoft 365 szolgáltatja.

• Rekordtípus: TXT
• Gazdanév: _dmarc.ceg.example
• TXT-érték: v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

Egyes DNS-felületek automatikusan hozzáfűzik a domain nevét a gazdanévhez; ilyenkor csak _dmarc értéket kell beírni. Mentés után a nyilvánosan lekérdezhető _dmarc.ceg.example TXT-rekordot ellenőrizze. Ha már van DMARC-rekord ezen a néven, azt módosítsa, és ne hozzon létre mellé egy második házirendet.

A rua=mailto: mező az összesített jelentések címét adja meg. Erre külön postafiók vagy jelentésfeldolgozó célszerű, mert több fogadótól géppel feldolgozható üzenetek érkezhetnek. A mintában a pct=100 p=none mellett nem jelent blokkolást: a DMARC-házirend nem kér karantént vagy elutasítást, bár a fogadó más szűrői továbbra is befolyásolhatják a kézbesítést.

A riport döntse el, mikor szigoríthat

Az összesített jelentésekben a küldő IP-címét, az üzenetek számát és az SPF-, illetve DKIM-eredményt vesse össze a küldőleltárral. Egy ismeretlen forrás lehet kihagyott üzleti szolgáltatás vagy illetéktelen küldő; egyetlen dmarc=fail eredményből ez még nem dönthető el. Az ismert, hibázó küldőnél előbb javítsa a hitelesítést vagy az illeszkedést, majd küldjön új próbaüzenetet.

A Microsoft 365 DMARC-útmutatója a p=none utáni karantént, majd az elutasítást írja le, és a pct értékének fokozatos emelésére is ad példát. Ugyanez az útmutató külön DNS-engedélyezést ír le, ha a rua riportcím másik domainen van. Ilyen cím használata előtt ellenőrizze a riportokat fogadó szolgáltatóval, hogy a szükséges engedélyező rekord a cél domain DNS-ében létrejött-e.

Ellenőrzőpont: a jelentésekben feltűnő jogos források DMARC-hibáit vizsgálja ki, mielőtt karanténra vált. A riportok nem feltétlenül fedik le az összes fogadót, ezért a fontos üzleti levélfolyamok célba érését is ellenőrizze. Külön figyelmet érdemelnek azok az üzenetek, amelyeket külső szolgáltatás küld a vállalkozás nevében.

Karantén után következhet az elutasítás

Ha a jogos küldők hibáit rendezte, a házirendet először részlegesen érvényesítse. Az alábbi értékek ugyanannak a TXT-rekordnak egymást követő változatai; a ceg.example címet minden változatban cserélje a sajátjára.

1. Kezdő karantén: v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=10. A fogadó a házirenddel érintett, DMARC-on elbukó leveleket például levélszemétként kezelheti.
2. Ha a riportok és a fontos próbaüzenetek nem jeleznek rendezetlen jogos küldőt, emelje fokozatosan a pct értékét 100-ig. Minden emelés után nézze meg újra a jelentéseket és a kézbesítési visszajelzéseket.
3. A karanténszakasz után kezdje részleges elutasítással: v=DMARC1; p=reject; rua=mailto:[email protected]; pct=10. Csak a tapasztalt eredmények alapján emelje tovább a pct értékét.

A pct a DMARC-vizsgálaton elbukó üzenetek közül a közzétett házirenddel érintettek arányát szabályozza, nem a teljes kimenő levélforgalomét. A fogadó rendszer tényleges kezelése eltérhet a kért művelettől. Ha több aldomainről is megy ki levél, ezek küldőit külön vegye számba: saját DMARC-rekord hiányában a szülődomain házirendje rájuk is kiterjedhet.

Teljes elutasításnál is tartsa meg a riportcímet, mert egy később bevezetett számlázó vagy kampányrendszer új hitelesítési hibát hozhat. A levelet egyáltalán nem küldő, parkolt domain más eset: ott a p=reject már a kezdeti házirend is lehet, mivel nincs jogos kimenő forgalom, amelynek a kézbesítését védeni kell.

Olvassa el ezt is:

• Calendly vagy Microsoft Bookings: az előfizetésben kapott eszköz nem tud mindent
• Kincstár vagy bank: 12,3 millió forintnál évi 43 ezer is lehet a különbség
• Lightyear vagy IBKR TBSZ: a havi 2000 forint lehet a választóvonal