E-mailek ellenőrzése a DMARC segítségével
Tipp
Tudta, hogy ingyenesen kipróbálhatja az Office 365-höz készült Microsoft 365 Defender 2. csomagjának funkcióit? Használja az Office 365-höz készült Defender 90 napos próbaverzióját a Microsoft 365 Defender portál próbaverziós központjában. Itt megtudhatja, hogy ki regisztrálhat, és mik a próbaverzió feltételei.
A következőkre vonatkozik:
- Exchange Online Védelmi szolgáltatás
- Office 365-höz készült Microsoft Defender 1. és 2. csomag
- Microsoft 365 Defender
A tartományalapú üzenethitelesítés, -jelentéskészítés és -megfelelőség (DMARC) együttműködik a küldőszabályzat keretrendszerével (SPF) és a DomainKeys Identified Mail (DKIM) szolgáltatással a levélküldők hitelesítéséhez.
A DMARC biztosítja, hogy a cél levelezőrendszerek megbízzanak a tartományból küldött üzenetekben. A DMARC SPF és DKIM használatával nagyobb védelmet nyújt a szervezeteknek az e-mailek hamisítása és adathalászata ellen. A DMARC segít a levelezőrendszereknek eldönteni, hogy mi a teendő a tartományból érkező olyan üzenetekkel, amelyek nem ellenőrzik az SPF- vagy DKIM-ellenőrzéseket.
Tipp
A Microsoft Intelligent Security Association (MISA) katalógusában megtekintheti a Microsoft 365-höz DMARC-jelentéskészítést kínáló külső gyártókat.
Hogyan működik együtt az SPF és a DMARC az e-mailek védelme érdekében a Microsoft 365-ben?
Az e-mailek több feladói vagy feladói címet is tartalmazhatnak. Ezeket a címeket különböző célokra használjuk. Vegyük például az alábbi címeket:
"Levél feladója" cím: Azonosítja a feladót, és megadja, hogy hová küldje a visszaküldési értesítéseket, ha bármilyen probléma merülne fel az üzenet kézbesítésével kapcsolatban (például nem kézbesítési értesítések). Az E-mail feladója cím az e-mail-üzenet boríték részén jelenik meg, és nem jelenik meg az e-mail-alkalmazás, és néha 5321.MailFrom címnek vagy fordított elérési útnak is nevezik.
"Feladó" cím: A feladói címként a levelezőalkalmazás által megjelenített cím. A feladói cím azonosítja az e-mail szerzőjének címét. Vagyis az üzenet írásáért felelős személy vagy rendszer postaládája. A Feladó címet néha 5322.From címnek is nevezik.
Az SPF egy DNS TXT rekordot használ egy adott tartomány engedélyezett küldő IP-címeinek listázására. Az SPF-ellenőrzések általában csak az 5321.MailFrom címmel végezhetők el. Az 5322.From cím nincs hitelesítve, ha önmagában használja az SPF-t, ami lehetővé teszi, hogy a felhasználó olyan üzenetet kapjon, amely megfelelt az SPF-ellenőrzéseknek, de 5322.From feladói címmel rendelkezik. Vegyük például ezt az SMTP-átiratot:
S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.com
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .
Ebben az átiratban a feladó címei a következők:
Mail from address (5321.MailFrom): phish@phishing.contoso.com
Feladó címe (5322.From): security@woodgrovebank.com
Ha konfigurálta az SPF-t, akkor a fogadó kiszolgáló ellenőrzi a levelezési cím phish@phishing.contoso.com. Ha az üzenet a tartomány phishing.contoso.com érvényes forrásából származik, akkor az SPF-ellenőrzés sikeres lesz. Mivel az e-mail ügyfélprogram csak a Feladó címet jeleníti meg, a felhasználó azt látja, hogy ez az üzenet security@woodgrovebank.com érkezett. Csak az SPF esetén a woodgrovebank.com érvényessége soha nem lett hitelesítve.
A DMARC használatakor a fogadó kiszolgáló ellenőrzi a Feladó címet is. Ha a fenti példában egy DMARC TXT rekord van érvényben a woodgrovebank.com, akkor a Feladó cím ellenőrzése sikertelen lesz.
Mi az a DMARC TXT rekord?
Az SPF DNS-rekordjaihoz hasonlóan a DMARC rekordja egy DNS-szövegrekord (TXT), amely segít megelőzni a hamisítást és az adathalászatot. A DMARC TXT rekordokat a DNS-ben teheti közzé. A DMARC TXT rekordok ellenőrzik az e-mailek eredetét úgy, hogy ellenőrzik egy e-mail szerzőjének IP-címét a küldő tartomány állítólagos tulajdonosával szemben. A DMARC TXT rekord az engedélyezett kimenő e-mail-kiszolgálókat azonosítja. A cél levelezőrendszerek ezután ellenőrizhetik, hogy a fogadott üzenetek hitelesített kimenő e-mail kiszolgálókról származnak-e.
A Microsoft DMARC TXT rekordja a következőképpen néz ki:
_dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"
A Microsoft 365-höz DMARC-jelentéskészítést kínáló külső szállítókért látogasson el a MISA-katalógusba.
A DMARC beállítása bejövő levelekhez
A DMARC-t nem kell beállítania a Microsoft 365-ben kapott e-mailekhez. Mindent elintéztek. Ha szeretné megtudni, hogy mi történik azokkal a levelekkel, amelyek nem továbbítja a DMARC-ellenőrzéseket, olvassa el, hogyan kezeli a Microsoft 365 a DMARC-t sikertelenül kezelő bejövő e-maileket.
A DMARC beállítása a Microsoft 365-ből kimenő levelekhez
Ha a Microsoft 365-öt használja, de nem használ egyéni tartományt (onmicrosoft.com használ), az SPF már be van állítva, és a Microsoft 365 automatikusan létrehoz egy DKIM-aláírást a kimenő levelekhez (az aláírásról további információt a DKIM és a Microsoft 365 alapértelmezett viselkedése című témakörben talál). A DMARC szervezet számára történő beállításához meg kell adnia a DMARC TXT rekordot a onmicrosoft.com tartományhoz, és közzé kell tennie a DNS-ben a Office 365 Felügyelet Center > Settings > Domains > kattintson onmicrosoft.com tartományra > Rekord hozzáadása elemre.
Ha egyéni tartománnyal rendelkezik, vagy helyszíni Exchange-kiszolgálókat használ a Microsoft 365-tel együtt, manuálisan kell beállítania a DMARC-t a kimenő levelekhez. A DMARC egyéni tartományhoz való beállítása az alábbi lépéseket tartalmazza:
1. lépés: A tartomány érvényes levelezési forrásainak azonosítása
Ha már beállította az SPF-t, akkor már elvégezte ezt a gyakorlatot. A DMARC-vel kapcsolatban további szempontokat is figyelembe kell venni. A tartomány levelezési forrásainak azonosításakor válaszoljon az alábbi két kérdésre:
Milyen IP-címek küldenek üzeneteket a tartományomból?
A harmadik felektől a nevemben küldött e-mailek esetében az 5321.MailFrom és az 5322.From tartomány egyezik?
2. lépés: Az SPF beállítása a tartományhoz
Most, hogy már rendelkezik az összes érvényes feladó listájával, az SPF beállításának lépéseit követve megakadályozhatja a hamisítást.
Ha például contoso.com levelet küld Exchange Online, egy helyszíni Exchange-kiszolgálóról, amelynek IP-címe 192.168.0.1, és egy webalkalmazás, amelynek IP-címe 192.168.100.100, az SPF TXT rekord a következőképpen néz ki:
contoso.com IN TXT " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"
Ajánlott eljárásként győződjön meg arról, hogy az SPF TXT rekord figyelembe veszi a külső feladókat.
3. lépés: A DKIM beállítása az egyéni tartományhoz
Az SPF beállítása után be kell állítania a DKIM-et. A DKIM lehetővé teszi digitális aláírás hozzáadását az üzenetfejlécben lévő e-mailekhez. Ha nem állítja be a DKIM-et, hanem engedélyezi, hogy a Microsoft 365 a tartomány alapértelmezett DKIM-konfigurációját használja, a DMARC sikertelen lehet. Ez a hiba azért fordulhat elő, mert az alapértelmezett DKIM-konfiguráció az eredeti onmicrosoft.com tartományt használja 5321.MailFrom címként, nem pedig az egyéni tartományként. Ez eltérést okoz az 5321.MailFrom és az 5322.From cím között a tartományából küldött összes e-mailben.
Ha olyan külső feladókkal rendelkezik, amelyek az Ön nevében küldenek leveleket, és az általuk küldött e-mailek nem egyeznek az 5321.MailFrom és az 5322.From címmel, a DMARC nem fog működni az adott e-mail esetében. Ennek elkerülése érdekében be kell állítania a DKIM-et a tartományához kifejezetten a külső feladóval. Ez lehetővé teszi, hogy a Microsoft 365 hitelesítse a külső szolgáltatásból származó e-maileket. Ugyanakkor lehetővé teszi másoknak, például a Yahoo, a Gmail és a Comcast számára, hogy ellenőrizzék a harmadik fél által nekik küldött e-maileket, mintha Ön küldte volna az e-mailt. Ez azért hasznos, mert lehetővé teszi az ügyfelek számára, hogy bizalmi kapcsolatot építsenek ki a tartományával függetlenül attól, hogy hol található a postaládájuk, és a Microsoft 365 ugyanakkor nem jelöl meg egy üzenetet levélszemétként a hamisítás miatt, mert átmegy a tartomány hitelesítési ellenőrzésein.
Ha útmutatást szeretne a DKIM beállításához a tartományhoz, beleértve a DKIM beállítását a külső feladók számára a tartomány hamisításához, olvassa el a DKIM használata az egyéni tartományból küldött kimenő e-mailek érvényesítéséhez című témakört.
4. lépés: A tartomány DMARC TXT rekordjának létrehozása
Bár vannak más szintaxisbeállítások is, amelyek itt nem szerepelnek, ezek a Microsoft 365 leggyakrabban használt beállításai. A tartomány DMARC TXT rekordjának létrehozása a következő formátumban:
_dmarc.domain TTL IN TXT "v=DMARC1; p=policy; pct=100"
Hely:
domain is the domain you want to protect. Alapértelmezés szerint a rekord védi a tartományból és az összes altartományból érkező leveleket. Ha például dmarc.contoso.com ad meg _, akkor a DMARC megvédi a tartományból és az összes altartományból érkező leveleket, például housewares.contoso.com vagy plumbing.contoso.com.
A TTL-nek mindig egy óra megfelelőnek kell lennie. A TTL-hez használt egység óra (1 óra), perc (60 perc) vagy másodperc (3600 másodperc) szerint változhat a tartomány regisztrálójától függően.
a pct=100 azt jelzi, hogy ezt a szabályt az e-mailek 100%-ában kell használni.
policy specifies what policy you want the receiving server to follow if DMARC fails. A szabályzatot beállíthatja egyikre sem, karanténba helyezheti vagy elutasíthatja.
A DMARC Microsoft 365-ben való implementálásával kapcsolatos ajánlott eljárásokban szereplő fogalmak megismerésével további információt kaphat arról, hogy mely lehetőségeket érdemes használnia.
Példák:
A szabályzat nincs értékre van állítva
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=none"Karanténba helyezett szabályzat
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=quarantine"Elutasításra beállított szabályzat
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=reject"
Miután létrehozta a rekordot, frissítenie kell a rekordot a tartományregisztrálónál.
DMARC Mail (nyilvános előzetes verziójú funkció)
Figyelemfelhívás
Előfordulhat, hogy a levelek nem naponta lesznek elküldve, és maga a jelentés is megváltozhat a nyilvános előzetes verzióban. A DMARC összesített jelentés e-mailjei a fogyasztói fiókoktól (például hotmail.com, outlook.com vagy live.com fiókoktól) várhatók.
Ebben a példában a DMARC TXT rekord: dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1", láthatja a rua címét, amely ebben az esetben az Agari vállalat által feldolgozott. Ez a cím "összesített visszajelzések" küldésére szolgál elemzéshez, és jelentés létrehozására szolgál.
Tipp
Látogasson el a MISA-katalógusba , és tekintse meg a Microsoft 365-höz DMARC-jelentéskészítést kínáló külső gyártókat. A DMARC "rua" címekkel kapcsolatos további információkért lásd az IETF.org tartományalapú üzenethitelesítési, jelentéskészítési és megfelelőségi (DMARC) szolgáltatását.
Ajánlott eljárások a DMARC Microsoft 365-ben való implementálásakor
A DMARC-t fokozatosan implementálhatja anélkül, hogy ez hatással lenne az e-mail-forgalom többi részére. Hozzon létre és implementáljon egy bevezetési tervet, amely az alábbi lépéseket követi. Mielőtt továbblépne a következő lépésre, végezze el ezeket a lépéseket először egy altartománysal, majd más altartományokkal, végül pedig a szervezet legfelső szintű tartományával.
A DMARC implementálásának hatásának monitorozása
Kezdje egy egyszerű figyelési módú rekorddal egy olyan altartományhoz vagy tartományhoz, amely azt kéri, hogy a DMARC-fogadók statisztikát küldjenek az adott tartományt használó üzenetekről. A figyelési módú rekord egy DMARC TXT rekord, amelynek házirendje nincs (p=none). Számos vállalat tesz közzé egy DMARC TXT rekordot p=none használatával, mert nem biztos abban, hogy egy szigorúbb DMARC-szabályzat közzétételével mennyi e-mailt veszíthetnek el.
Ezt még azelőtt is megteheti, hogy implementálta volna az SPF-et vagy a DKIM-et az üzenetkezelési infrastruktúrában. A DMARC használatával azonban nem lehet majd hatékonyan karanténba helyezni vagy elutasítani a leveleket, amíg nem valósítja meg az SPF és a DKIM protokollt is. Az SPF és a DKIM bevezetésekor a DMARC-n keresztül létrehozott jelentések az ellenőrzésen áteső üzenetek számát és forrásait adják meg, szemben azokkal, amelyek nem. Könnyen láthatja, hogy a jogszerű forgalom mekkora részét fedezik vagy nem fedik le, és elháríthatja a problémákat. Azt is látni fogja, hogy hány csaló üzenetet küld a rendszer, és honnan küldi őket.
Kérje meg, hogy a külső levelezőrendszerek karanténba helyezik a DMARC-t meghibásodó leveleket
Ha úgy véli, hogy a jogszerű forgalom egészét vagy nagy részét az SPF és a DKIM védi, és tisztában van a DMARC implementálásának hatásával, alkalmazhat karanténszabályzatot. A karanténszabályzat egy DMARC TXT rekord, amelynek házirendje karanténba van állítva (p=karantén). Ezzel arra kéri a DMARC-fogadókat, hogy a DMARC-t nem tartalmazó tartományból érkező üzeneteket az ügyfelek postaládái helyett egy levélszemétmappába helyezzenek.
Kérje meg, hogy a külső levelezőrendszerek ne fogadják el a sikertelen DMARC-üzeneteket
Az utolsó lépés egy elutasítási szabályzat implementálása. Az elutasítási házirend egy DMARC TXT rekord, amelynek házirendje elutasításra van állítva (p=reject). Amikor ezt teszi, arra kéri a DMARC-fogadókat, hogy ne fogadják el azokat az üzeneteket, amelyek nem hajtják végre a DMARC-ellenőrzéseket.
DMARC beállítása altartományhoz
A DMARC úgy van megvalósítva, hogy egy szabályzatot TXT rekordként tesz közzé a DNS-ben, és hierarchikus (például egy contoso.com számára közzétett szabályzat sub.domain.contonos.com vonatkozik, kivéve, ha az altartományhoz külön szabályzat van definiálva). Ez azért hasznos, mert a szervezetek kisebb számú magas szintű DMARC-rekordot adhatnak meg a szélesebb lefedettség érdekében. Ügyeljen arra, hogy explicit altartományI DMARC-rekordokat konfiguráljon, ha nem szeretné, hogy az altartományok örököljék a legfelső szintű tartomány DMARC-rekordját.
Helyettesítő karakteres szabályzatot is hozzáadhat a DMARC-hoz, ha az altartományok nem küldenek e-mailt az
sp=rejectérték hozzáadásával. Például:_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
Hogyan kezeli a Microsoft 365 a sikertelen DMARC kimenő e-maileket?
Ha egy üzenet kimenő a Microsoft 365-ből, és a DMARC meghiúsul, és a szabályzatot p=karantén vagy p=reject értékre állította, az üzenet a magas kockázatú kézbesítési készleten halad át a kimenő üzenetekhez. A kimenő e-mailek nincsenek felülbírálva.
Ha közzétesz egy DMARC elutasítási szabályzatot (p=reject), a Microsoft 365-ben egyetlen másik ügyfél sem tudja meghamisításra használni a tartományát, mert az üzenetek nem fogják tudni átadni az SPF-t vagy a DKIM-et a tartomány számára, amikor a szolgáltatáson keresztül kimenő üzenetet továbbít. Ha azonban közzétesz egy DMARC elutasító házirendet, de nem rendelkezik az összes e-mail-hitelesítéssel a Microsoft 365-ön keresztül, előfordulhat, hogy a rendszer levélszemétként jelöli meg a bejövő e-maileket (a fent leírtak szerint), vagy a rendszer elutasítja, ha nem teszi közzé az SPF-t, és megpróbálja kimenőként továbbítani a szolgáltatáson keresztül. Ez például akkor fordul elő, ha elfelejti belefoglalni azoknak a kiszolgálóknak és alkalmazásoknak az IP-címét, amelyek a tartomány nevében küldenek leveleket a DMARC TXT rekord létrehozásakor.
Hogyan kezeli a Microsoft 365 a sikertelen DMARC bejövő e-maileket?
Ha a küldő kiszolgáló DMARC-házirendje azp=reject, Exchange Online Védelmi szolgáltatás (EOP) hamisként jelöli meg az üzenetet az elutasítása helyett. Más szóval a bejövő e-mailek esetében a Microsoft 365 ugyanúgy kezeli p=reject és p=quarantine kezeli. A rendszergazdák meghatározhatják, hogy milyen műveletet hajtanak végre az adathalászat elleni szabályzatban hamisításként besorolt üzeneteken.
A Microsoft 365 azért van így konfigurálva, mert néhány megbízható e-mail sikertelen lehet a DMARC-n. Előfordulhat például, hogy egy üzenet sikertelen lesz a DMARC-n, ha egy levelezőlistára kerül, amely ezután továbbítja az üzenetet az összes lista résztvevőjének. Ha a Microsoft 365 elutasítja ezeket az üzeneteket, a felhasználók elveszíthetik a megbízható e-maileket, és nem kaphatják meg. Ehelyett ezek az üzenetek továbbra is sikertelenek lesznek a DMARC-n, de levélszemétként lesznek megjelölve, és nem lesznek elutasítva. Ha szeretné, a felhasználók továbbra is megkaphatják ezeket az üzeneteket a beérkezett üzenetek között az alábbi módszerekkel:
A felhasználók e-mail ügyfélprogramjukkal egyenként adhatnak hozzá megbízható feladókat.
A rendszergazdák a hamisintelligencia-megállapítással vagy a bérlői engedélyezési/tiltólistával engedélyezhetik a hamisított feladótól érkező üzeneteket.
A rendszergazdák létrehoznak egy Exchange-alapú levélforgalmi szabályt (más néven átviteli szabályt) minden olyan felhasználó számára, aki engedélyezi az adott feladóknak az üzeneteket.
További információ: Megbízható feladók listáinak létrehozása.
Hogyan használja a Microsoft 365 a hitelesített fogadott láncot (ARC)
A Microsoft 365 összes üzemeltetett postaládája mostantól az ARC előnyeit élvezheti az üzenetek jobb kézbesíthetőségével és a hamisítás elleni fokozott védelemmel. Az ARC megőrzi az összes résztvevő közvetítő vagy ugrás e-mail-hitelesítési eredményeit, ha az e-mailt a forráskiszolgálóról a címzett postaládájába irányítja. Az ARC előtt az e-mail-útválasztás közvetítői által végrehajtott módosítások, például a továbbítási szabályok vagy az automatikus aláírások DMARC-hibákat okozhatnak, mire az e-mail eléri a címzett postaládáját. Az ARC használatával a hitelesítési eredmények titkosítási megőrzése lehetővé teszi, hogy a Microsoft 365 ellenőrizze az e-mail feladójának hitelességét.
A Microsoft 365 jelenleg az ARC használatával ellenőrzi a hitelesítési eredményeket, ha a Microsoft az ARC Sealer, de a jövőben tervezi a külső ARC-tömítők támogatását.
A DMARC-implementáció hibaelhárítása
Ha a tartomány MX rekordjait konfigurálta, ahol nem az EOP az első bejegyzés, a DMARC-hibák nem lesznek kényszerítve a tartományra vonatkozóan.
Ha Ön ügyfél, és a tartomány elsődleges MX rekordja nem az EOP-ra mutat, akkor nem élvezheti a DMARC előnyeit. A DMARC például nem fog működni, ha az MX rekordot a helyszíni levelezési kiszolgálóra irányítja, majd összekötő használatával irányítja az e-maileket az EOP-ba. Ebben a forgatókönyvben a fogadó tartomány az egyik Accepted-Domains, de nem az EOP az elsődleges MX. Tegyük fel például, hogy contoso.com az MX-jét önmagára irányítja, és az EOP-t használja másodlagos MX rekordként, a contoso.com MX rekordja a következőképpen néz ki:
contoso.com 3600 IN MX 0 mail.contoso.com
contoso.com 3600 IN MX 10 contoso-com.mail.protection.outlook.com
Az összes vagy a legtöbb e-mail először mail.contoso.com lesz átirányítva, mivel ez az elsődleges MX, majd a levelek az EOP-ba lesznek irányítva. Bizonyos esetekben előfordulhat, hogy egyáltalán nem is listázhatja az EOP-t MX rekordként, és egyszerűen csatlakoztathatja az összekötőket az e-mailek átirányításához. A DMARC-ellenőrzés első lépésének nem kell az EOP-nak lennie. Csak biztosítja az ellenőrzést, hogy biztos lehessen abban, hogy minden helyszíni/nem O365-kiszolgáló DMARC-ellenőrzéseket fog végezni. A DMARC a DMARC TXT rekord beállításakor érvényesíthető az ügyfél tartományához (nem a kiszolgálóhoz), de a kényszerítés tényleges végrehajtása a fogadó kiszolgáló feladata. Ha az EOP-t állítja be fogadó kiszolgálóként, akkor az EOP elvégzi a DMARC kényszerítését.
További információ
További információra van szüksége a DMARC-ról? Ezek az erőforrások segíthetnek.
A levélszemét elleni üzenetfejlécek tartalmazzák a Microsoft 365 által a DMARC-ellenőrzésekhez használt szintaxist és fejlécmezőket.
Take the DMARC Training Series from M3AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
Használja a dmarcian ellenőrzőlistát.
Lépjen közvetlenül a forráshoz a DMARC.org.
Lásd még
Az SPF beállítása a Microsoft 365-ben a hamisítás megakadályozása érdekében
A DKIM használata az egyéni tartományból küldött kimenő e-mailek ellenőrzéséhez a Microsoft 365-ben
Megbízható ARC-feladók használata megbízható levélfolyamokhoz