
DMARC pa bllokuar email-in: kalimi gradual shmang dështimet

Për të aktivizuar DMARC pa ndërprerë dërgimin e ligjshëm, niseni me p=none dhe raporte përmbledhëse, identifikoni çdo shërbim që dërgon me domenin tuaj dhe forconi politikën vetëm pasi të keni korrigjuar dështimet e tij. Udhëzimi i Google për kalimin gradual rekomandon një javë monitorim me p=none dhe shqyrtim të përditshëm të raporteve përpara kalimit te quarantine. Një javë është pikënisje për të mbledhur të dhëna; nëse disa shërbime dërgojnë rrallë, monitorimi duhet të zgjasë derisa të shfaqen edhe ato.
Mesazhi kalon DMARC kur kalon SPF ose DKIM dhe domeni i kontrollit që kaloi përputhet me domenin e dukshëm në fushën From. Dokumentacioni i Microsoft për DMARC tregon se edhe spf=pass dhe dkim=pass mund të shoqërohen me dmarc=fail kur asnjëri domen nuk përputhet me From. Prandaj kontrolloni si raportet, ashtu edhe kokën Authentication-Results të mesazheve provë përpara se të kërkoni karantinim ose refuzim. Politika p=none nuk kërkon bllokim për shkak të DMARC, por filtrat e tjerë të marrësit mund të ndikojnë përsëri në dorëzim.
Inventarizoni dërguesit e domenit
Filloni me çdo rrugë dërgimi që vendos domenin tuaj në From, jo vetëm me postën e punonjësve. Përfshini shërbimin kryesor të postës, formularët e faqes, njoftimet e aplikacionit ose të dyqanit, faturat automatike, platformat e marketingut dhe shërbimet që përdorin nëndomene. Për secilin shënoni administratorin përgjegjës, adresën From, shërbimin dërgues dhe mundësinë për të përdorur domenin tuaj në MAIL FROM ose në nënshkrimin DKIM.
Ky inventar ju ndihmon të dalloni një shërbim të harruar nga përdorimi i paautorizuar i domenit. Kur një raport tregon një adresë IP të panjohur, krahasojeni me dërgesat dhe shërbimet tuaja përpara se ta autorizoni në SPF. Përfshini në prova edhe mesazhet që dërgohen vetëm pas një veprimi të caktuar, si një porosi ose rivendosje fjalëkalimi; mungesa e tyre në raportet e para nuk tregon se konfigurimi është i plotë.
Rregulloni SPF, DKIM dhe përputhjen e domeneve
SPF verifikon nëse serveri lejohet të dërgojë për domenin në MAIL FROM. DKIM verifikon nënshkrimin e mesazhit dhe domenin e tij, të shënuar si d=. DMARC e përdor një rezultat vetëm kur ai kontroll kalon dhe domeni përputhet me From. Në mënyrën e parazgjedhur të përputhjes, një nëndomen i të njëjtit domen organizativ mund të pranohet; mënyra strikte kërkon përputhje të saktë.
Dërgoni mesazhe provë nga secili shërbim te një kuti ku mund të hapni kokat e plota. Në Authentication-Results krahasoni header.from me smtp.mailfrom për SPF dhe me header.d për DKIM, pastaj lexoni rezultatin dmarc=pass ose dmarc=fail. Nëse SPF kalon për domenin e ofruesit, ndërsa From përdor domenin tuaj, kërkoni një MAIL FROM të personalizuar ose nënshkrim DKIM me domenin tuaj. Shtimi i një IP-je në SPF nuk e zgjidh vetë mospërputhjen e domeneve.
Ridrejtimi i postës mund të prishë SPF, sepse mesazhi mbërrin nga një server tjetër. Një nënshkrim DKIM që mbetet i vlefshëm dhe i përputhur mund ta ruajë kalimin e DMARC; nëse një listë postare ndryshon përmbajtjen, mund të prishet edhe nënshkrimi. Përsëritini provat pas çdo ndryshimi në DNS ose te shërbimi dërgues dhe lexoni rezultatin te marrësi, jo vetëm gjendjen që shfaq paneli i ofruesit.
Publikoni rekordin DNS dhe mblidhni raportet
Në DNS krijoni një rekord TXT me emrin _dmarc. Për domenin e kushtëzuar example.com, një vlerë fillestare është v=DMARC1; p=none; rua=mailto:[email protected]. Zëvendësoni adresën me një kuti që merr postë dhe që mund ta administroni. Kërkimi TXT për _dmarc.example.com duhet të kthejë rekordin e publikuar; kontrolloni edhe që në atë emër të mos keni disa rekorde DMARC që krijojnë paqartësi.
Adresa rua kërkon raporte përmbledhëse nga marrësit që i dërgojnë ato. Raportet mund të tregojnë burimin e dërgimit, numrin e mesazheve, rezultatet e autentikimit dhe veprimin e marrësit, por nuk përbëjnë regjistër të çdo mesazhi. Nëse i dërgoni raportet te një adresë në domen tjetër, administratori i atij domeni duhet të autorizojë marrjen e tyre me rekordin DNS përkatës. Mbajeni këtë kusht në plan përpara se të përdorni një shërbim të jashtëm raportimi.
Vendosni kur dërguesit janë gati
Në raportet përmbledhëse ndani burimet që njihni nga ato që nuk i njihni. Për një burim të ligjshëm me dështime, shihni veçmas rezultatin teknik të SPF ose DKIM dhe përputhjen e domenit përkatës me From. Një rezultat autentikimi që kalon, por nuk përputhet, kërkon ndryshim të MAIL FROM ose të domenit të nënshkrimit DKIM. Një burim i panjohur që dështon mund të jetë përpjekje për falsifikim dhe nuk duhet autorizuar vetëm për të pastruar raportin.
Përpara forcimit të politikës, kërkoni prova nga rrjedhat kryesore dhe nga dërguesit që punojnë rrallë. Vlerësoni edhe ankesat për mesazhe që nuk mbërrijnë: jo të gjithë marrësit dërgojnë raporte DMARC. Nëse një rrjedhë e ligjshme vazhdon të japë dmarc=fail, mbajeni politikën e monitorimit derisa të gjeni shkakun. Caktoni kush i lexon raportet dhe kush mund të ndryshojë rekordin DNS nëse shfaqet një problem pas forcimit.
Kaloni te quarantine dhe vlerësoni me kujdes reject
Kur dërguesit e njohur kalojnë DMARC, mund ta provoni zbatimin fillimisht në një nëndomen dërgues të kontrolluar me rekord të vetin, për shembull _dmarc.njoftime.example.com për mesazhe që përdorin njoftime.example.com në From. Kjo e kufizon provën te një rrjedhë që mund ta vëzhgoni veçmas. Për atë rrjedhë, ndryshimi në p=quarantine kërkon që marrësit t'i trajtojnë si të dyshimta mesazhet që dështojnë; veprimi përfundimtar varet nga sistemi marrës.
Një hollësi e rëndësishme për rekordet e reja është se standardi RFC 9989 e ka hequr etiketën pct dhe e përshkruan zbatimin e saj me përqindje si të pasaktë në praktikë. Ai shton t=y për modalitetin e provës, por kjo nuk është garanci që çdo marrës do ta trajtojë njësoj: sistemet që zbatojnë rregullat e mëparshme mund ta shpërfillin etiketën e re. Për këtë arsye, një rekord si p=quarantine; pct=5 nuk është mbrojtje e sigurt ndaj ndikimit te mesazhet e ligjshme. Mbështeteni kalimin te korrigjimi i dërguesve, provat dhe raportet.
Pas një periudhe me quarantine pa dështime të pashpjeguara të dërguesve tuaj, shqyrtoni p=reject për rrjedhat ku mund të kontrolloni nënshkrimin DKIM dhe pasojat e ridrejtimit. Për domenet nga të cilat përdoruesit shkruajnë edhe në lista postare, standardi paralajmëron për probleme përputhshmërie me reject dhe këshillon monitorim më të gjatë përpara çdo vendimi. Nëse shfaqet një dërgues i ligjshëm që dështon, ktheni politikën në fazën e mëparshme dhe korrigjoni rrugën e tij. Vazhdoni të merrni raportet rua edhe pasi të keni forcuar politikën, sepse shërbimet dërguese mund të ndryshojnë.
Lexoni gjithashtu:
Artikuj të ngjashëm


DocuSign apo Dropbox Sign: volumi i kontratave vlen më shumë se marka

Oferta e punës kërkon para? Tre kontrolle para se të përgjigjesh

NVIDIA vendos rojë jashtë agjentit AI: izolimi premtohet në milisekonda

Airtable apo Notion: databaza më e fortë kushton dyfish për ekipin

Llogari WhatsApp po komprometohen në Kosovë: KOS-CERT heton rastet
Abonohuni në buletinin tonë
Merrni lajmet më të fundit për Web3, AI dhe kripto direkt në kutinë tuaj postare.