DMARC-ийг шууд reject бүү болго: нэг mailto алдаа хамгаалалтыг чимээгүй унтраана

Домэйнээ хуурамч From хаягаар илгээсэн захидлаас хамгаалахын тулд хууль ёсны илгээгчдээ бүртгэж, тэдний SPF эсвэл DKIM баталгаажуулалт From домэйнтэй нийцэж байгааг эхлээд шалга. Дараа нь DNS-д зөв rua=mailto: хаягтай p=none DMARC бичлэг нийтэлж, тайлангаар бодит урсгалаа нягталсны дараа quarantine, эцэст нь reject рүү шилжүүл. Google Workspace-ийн DMARC заавар ч тайлан авах тусгай хаяг бэлдэж, бодлогыг p=none-оос шатлан чангатгахыг зөвлөдөг.

DNS-д TXT бичлэг харагдах нь тайлан очиж, хамгаалалт төлөвлөснөөр ажиллаж байгааг батлахгүй. Tranco жагсаалтын шилдэг 100 мянган домэйныг шинжилсэн 2026 оны DMARC судалгаанд rua эсвэл ruf хаягийн mailto: угтвар дутсан нь нийтлэг алдаа байв. RFC 9990-ийн тайлан хүргэх дүрэм алдаатай тайлангийн URI-г үл тоохыг зөвлөдөг. Ганц rua хаяг буруу бол тайлан ирэхгүй байж болно; p=none үед DMARC өөрөө шалгалтад унасан захидлыг хориулахгүй тул чангатгах шийдвэрийн үндэс чимээгүй алга болно. Энэ алдаа бүх хүлээн авагч хүчинтэй p=reject бодлогыг үл тооно гэсэн үг биш.

DMARC-ийг хэрэгжүүлэх долоон шат

1. Илгээгчдээ бүртгэ. Ажилтны шуудангаас гадна нэхэмжлэл, захиалгын мэдэгдэл, нууц үг сэргээх захидал, маркетингийн платформ, CRM, вэбсайтын маягт зэрэг танай домэйныг From хаягт ашигладаг систем бүрийг жагсаа. Системийн хариуцагч, үйлчилгээ үзүүлэгч, илгээдэг домэйн, туршилтын захидлыг тэмдэглэ. Ховор ажилладаг автомат мэдэгдлийг орхивол алдаа нь бодлого чангарах үед л хүргэлтийн асуудал болж илэрч магадгүй.
2. SPF ба DKIM-ийн нийцлийг шалга. SPF-ийн pass үр дүн дангаараа DMARC-д тэнцэхгүй: SPF-д шалгасан envelope sender буюу Return-Path домэйн хэрэглэгчид харагдах From домэйнтэй нийцэх шаардлагатай. DKIM-ийн хувьд хүчинтэй гарын үсгийн d= домэйн From домэйнтэй нийцсэн байна. Эдгээр замын аль нэг нь баталгаажуулалт болон нийцлийн шалгалтыг хамт давбал DMARC тэнцэнэ; хоёуланг заавал давуулах шаардлагагүй. Үйлчилгээ үзүүлэгч өөрийн Return-Path домэйныг ашигладаг бол танай домэйнтэй нийцсэн DKIM гарын үсэг тохируулж болох эсэхийг асуу. Дэд домэйнтэй илгээгчдэд анхнаасаа хэт хатуу нийцэл шаардах нь хууль ёсны урсгалыг унагаж болзошгүй.
3. Тайлан авах тусгай хаяг бэлд. Жишээ нь [email protected] гэсэн хайрцаг эсвэл тайлан боловсруулах үйлчилгээ ашиглаж болно; example.com бол зөвхөн орлуулах домэйн. Хаяг захидал хүлээн авч байгаа эсэх, тайланг хэн тогтмол үзэхийг урьдчилан шийд. Хүлээн авах хаяг хамгаалж буй домэйноос өөр домэйнд байвал тэр домэйны DNS-д тайлан хүлээн авах зөвшөөрөл хэрэгтэй. Өөрийн нэр дээрх хайрцаг руу тайлан чиглүүлэх нь хариуцагч солигдоход хяналт тасрах эрсдэлтэй.
4. TXT бичлэгээ нийтэлж, буцааж унш. Нөхцөлт жишээнд _dmarc.example.com нэртэй TXT бичлэгийн утга нь v=DMARC1; p=none; rua=mailto:[email protected] байна. DNS самбар example.com-ийг нэрийн ард автоматаар нэмдэг бол зөвхөн _dmarc гэж оруулах шаардлагатай байж болно. v=DMARC1-ийг эхэнд тавьж, талбаруудыг цэгтэй таслалаар тусгаарлан, p=none-ийг дараа нь бичих нь ойлгомжтой тохиргоо болно. rua хаягийн өмнөх mailto: угтварыг, мөн хаягийн өөрийн бичлэгийг тус тус шалга. Самбарт хадгалсан мөрийг бус, нийтлэгдсэн DNS хариуг DMARC шалгагчаар уншуул: нэр давхардах, тусгаарлагч солигдох, бичлэг буруу хуулах зэрэг алдаа энд илэрнэ.
5. p=none үед тайлан цуглуул. Энэ бодлого DMARC-аас шалтгаалан захидлыг хориулах хүсэлт тавихгүй, харин rua тайлан илгээж буй эх үүсвэр, SPF ба DKIM-ийн үр дүн, From домэйны нийцлийг харахад тусална. Танил бус IP гарч ирлээ гээд SPF-д шууд нэмэх хэрэггүй; эхлээд тухайн урсгал танай бүртгэлд байгаа эсэхийг тогтоо. Бүртгэлтэй үйлчилгээ унаж байвал туршилтын захидлын Return-Path, DKIM d= болон From домэйныг тулгаж үз. Тайлан ирэхгүй бол эхлээд TXT мөр, rua хаяг, хайрцгийн хүлээн авах чадвар, шаардлагатай бол гаднын домэйны зөвшөөрлийг шалга; тайлангүй хугацааг амжилттай ажиглалт гэж тооцож болохгүй.
6. quarantine рүү хяналттай шилж. Мэдэгдэж буй хууль ёсны илгээгчид DMARC-д тэнцэж, тайлан дахь үл таних эх үүсвэрийг ялгаж чаддаг болсон үед p=quarantine болго. Ингэснээр хүлээн авагч шалгалтад унасан захидлыг спамд ангилж болно. Төлбөрийн мэдээлэл, захиалгын мэдэгдэл, нууц үг сэргээх захидал зэрэг чухал урсгалын хүргэлтийг тусад нь ажигла. Зөвхөн тайлангийн ерөнхий дүнг харахаас гадна эдгээр урсгалын бодит туршилтын захидал очиж буй эсэхийг шалгавал аль үйлчилгээний тохиргоо засах шаардлагатайг олно.
7. reject-ийг баталгааны дараа идэвхжүүл. Мэдэгдэж буй хууль ёсны урсгал DMARC-д тэнцэж, quarantine үеийн хүргэлтийн асуудал шийдэгдсэн бол p=reject рүү шилжүүл. Энэ нь DMARC-д унасан захидлыг хүлээн авахаас татгалзах хүсэлтийг хүлээн авагчид өгнө; хүлээн авагч өөрийн бодлогын дагуу эцсийн шийдвэрээ гаргаж болно. Дараа нь шинэ илгээх үйлчилгээ нэмэх бүрдээ түүнийг бүртгэлд оруулж, SPF эсвэл DKIM-ийн нийцлийг захидлаар дахин шалга. Нэг удаагийн амжилттай тохиргоо ирээдүйн бүх илгээгчийг автоматаар баталгаажуулахгүй.

Хэзээ түр буцах вэ?

Тайлан дахь DMARC алдаа бүрийг хуурамч илгээлт гэж үзэж болохгүй. IP, үйлчилгээ эсвэл дэд домэйн танай илгээгчдийн бүртгэлд байвал түүний баталгаажуулалтыг засах хүртэл дараагийн хатуу бодлого руу бүү шилж. Бүртгэлд байхгүй эх үүсвэрийг зөвхөн тайланд гарсан гэдэг шалтгаанаар SPF-д зөвшөөрөх нь хамгаалах зорилгыг сулруулна. Илгээгчдийн бүртгэл, тайлангийн үр дүн, туршилтын захидал хоорондоо таарч байвал шат ахих үндэслэл бүрдэнэ.

quarantine эсвэл reject идэвхжүүлсний дараа хууль ёсны чухал захидал саатвал өмнөх ажиллаж байсан бодлогод түр буцаж, аль илгээгчийн SPF эсвэл DKIM-ийн нийцэл алдагдсаныг зас. Харин тайлан ирэхээ больсон бол эхлээд rua=mailto: мөр болон хүлээн авах хайрцгийг шалга; тайлангүй байдал нь хүргэлт хэвийн байгааг нотлохгүй. Засварын дараа нийтлэгдсэн DNS утга, шинээр ирсэн тайлан, бодит туршилтын захидлаар тухайн урсгал сэргэсэн эсэхийг нягтал.

Мөн уншаарай:

• AI агентыг prompt injection-оос хамгаалах нь: prompt дангаараа хүрэлцэхгүй
• n8n-ийг өөрийн серверт байрлуулах нь: нэг encryption key бүх нууцыг аварна