DMARC-ийг шууд reject бүү болго: эхлээд хууль ёсны илгээгчдээ ол

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

Ийм дараалал нь байгууллагын нэрийг ашиглан хуурамч захидал илгээхээс хамгаалах бодлогыг чангаруулахдаа өөрийн мэдэгдэл, нэхэмжлэх, ажилтны захидлыг санамсаргүй хориглох эрсдэлийг багасгана. Google Workspace үндсэн шуудангийн үйлчилгээ байлаа ч вэб сайт, маркетинг, хэрэглэгчийн дэмжлэгийн системүүд танай домэйноор тусдаа захидал явуулж болно.

Илгээдэг бүх үйлчилгээг бүртгэ

Ажилтны шуудангаас гадна вэб сайтын маягт, захиалгын мэдэгдэл, нэхэмжлэх, маркетингийн систем, хэрэглэгчийн дэмжлэгийн хэрэгслийг жагсаа. Үйлчилгээ бүрийн харагдах From домэйн, SPF шалгалтад ашигладаг буцах хаягийн домэйн, DKIM гарын үсгийн d= домэйн болон тохиргоог хариуцдаг хүнийг тэмдэглэ. Дэд домэйнээр илгээдэг урсгалыг мөн тусад нь оруул: үндсэн домэйны захидал хэвийн байгаа нь дэд домэйныг шалгасан гэсэн үг биш.

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

Бүртгэсэн үйлчилгээ бүрээр жинхэнэ илгээх замыг ашиглан туршилтын захидал явуулж, хүлээн авсан захидлын толгой хэсгийн баталгаажуулалтын үр дүнг үз. Нийлүүлэгч өөрийн домэйноор DKIM гарын үсэг зурдаг бол танай домэйнээр гарын үсэг зурах тохиргоо байгаа эсэхийг асуу. SPF ашиглах замыг сонговол буцах хаягийн домэйн нийцэж байгаа эсэх, одоогийн SPF бичлэгт хийх өөрчлөлт бусад илгээгчид нөлөөлөх эсэхийг шалга.

SPF эсвэл DKIM тэнцэхээс гадна домэйн нийцэх ёстой

DMARC шалгалтад SPF: pass эсвэл DKIM: pass гэсэн үр дүн дангаараа хүрэлцэхгүй. SPF-ийн хувьд баталгаажсан буцах хаягийн домэйн, DKIM-ийн хувьд хүчинтэй гарын үсгийн d= домэйн нь хэрэглэгчид харагдах From домэйнтэй нийцэх ёстой. Энэ хоёр замын аль нэг нь баталгаажуулалт болон домэйны нийцлийн шалгалтад зэрэг тэнцвэл захидал DMARC-ийг давна.

Жишээ нь, From хаяг танай байгууллагын домэйнтэй боловч гаднын платформ зөвхөн өөрийн домэйноор DKIM гарын үсэг зурж болно. Гарын үсэг хүчинтэй байсан ч From домэйнтэй нийцэхгүй бол тэр нь DMARC-д тус болохгүй. Хэрэв тухайн платформын SPF шалгалт ч танай From домэйнтэй нийцэхгүй бол хууль ёсны захидал DMARC-д унана. Энэ тохиолдолд нийлүүлэгчийн санал болгодог танай домэйны DKIM эсвэл тохируулгатай буцах хаягийн боломжийг ашигла.

Нийцлийн relaxed үндсэн горим нь байгууллагын үндсэн домэйнтэй холбоотой дэд домэйныг зөвшөөрдөг; strict горим яг ижил домэйн шаарддаг. Илгээгч бүрийн From, Return-Path болон DKIM-ийн d= утгыг харьцуулж дуусаагүй байхад strict горим сонгох нь хэрэггүй хүндрэл үүсгэнэ. Туршилтын захидлын толгой хэсэг нэг илгээх замыг харуулдаг тул дараа нь ирэх тайлангаар бодит урсгалыг давхар нягтал.

Тайлан авах хаягтай p=none бичлэг нийтэл

Тайлан хүлээн авах тусгай шуудангийн хайрцаг эсвэл багийн хаяг бэлдээд, түүнд ирсэн захидлыг хэн боловсруулахыг тогтоо. Жишээ болгон example.com домэйнд _dmarc.example.com нэртэй TXT бичлэгийн утгыг v=DMARC1; p=none; rua=mailto:[email protected] гэж өгч болно. Бодит тохиргоонд жишээ домэйн болон хаягийг өөрийнхөөр сольж, хаяг захидал хүлээн авч байгааг шалга. rua талбарт mailto: угтвар хэрэгтэй.

Тайланг өөр домэйнд байрлах үйлчилгээ рүү илгээх бол тэр домэйны эзэмшигч тайлан хүлээн авахыг DNS-ээр зөвшөөрсөн байх шаардлагатай. Энэ зөвшөөрөл байхгүй бол тайлан ирэхгүй байж болох бөгөөд p=none үеийн гол ажиглалт тасарна. Тайлангийн хаягийг өдөр тутмын хувийн шуудантай хольж ашиглахын оронд хариуцсан баг эсвэл тайлан боловсруулах үйлчилгээнд холбох нь ирсэн мэдээллийг алдалгүй ангилахад тустай.

p=none нь DMARC-д унасан захидалд домэйны DMARC бодлогоор хорио тавихыг хүсэхгүй гэсэн утгатай. Гэхдээ хүлээн авагчийн бусад спам шүүлтүүр хэвээр ажилладаг тул захидал бүр үндсэн хавтсанд очих баталгаа биш. Үндсэн домэйноос гадна дэд домэйнээр захидал явуулдаг бол тэдгээрийн бодлогыг хэрхэн хамруулахыг нийтлэхээс өмнө шийд.

DNS бичлэг болон бодит илгээлтийг тулгаж шалга

DNS удирдлагад TXT төрлийг сонгож, нэрийн талбарт _dmarc, утгын талбарт бэлдсэн DMARC мөрийг оруул. Зарим DNS үйлчилгээ домэйны нэрийг өөрөө залгадаг тул хадгалсны дараа бичлэг _dmarc.танай-домэйн нэрээр харагдаж байгааг шалга. Хэрэв DMARC бичлэг аль хэдийн байгаа бол давхар бичлэг үүсгэхгүйгээр одоогийн утгыг нягталж шинэчил.

DNS-ээ Cloudflare-д удирддаг бол Cloudflare-ийн security records заавар дахь Email → DMARC Management → Email record overview → View records замаар SPF, DKIM, DMARC бичлэгүүдээ харж болно. Өөр DNS үйлчилгээний цэс өөр нэртэй байж болох ч шалгах зүйл нь нийтлэгдсэн бичлэгийн нэр, төрөл, утга юм.

Нэгтгэсэн тайланд харагдах илгээгчийн IP хаяг, захидлын тоо, SPF болон DKIM-ийн үр дүнг бүртгэлтэйгээ тулга. Тайлан дахь IP хаяг үйлчилгээний нэрийг өөрөө хэлэхгүй тул гэрээ, үйлчилгээний тохиргоо болон туршилтын захидлын толгой хэсгээр эзнийг нь тогтоо. Танихгүй эх үүсвэр бүр халдлага байх албагүй; бүртгэлээс хоцорсон хууль ёсны үйлчилгээ ч байж болно. Харин мэдэгдэж буй үйлчилгээний урсгал DMARC-д унаж байвал домэйны нийцлийг нь зассаны дараа шинэ тайлангаар үр дүнг шалга.

Quarantine-аас reject рүү буцаах цэгтэй шилж

p=quarantine руу шилжих босго нь мэдэгдэж буй илгээгчдийн захидал DMARC-д тэнцэж, тайланд үлдсэн уналтын шалтгаан тодорхой болсон байх явдал. Quarantine бодлого унасан захидлыг сэжигтэй гэж үзэхийг хүлээн авагчаас хүсдэг тул шилжсэний дараа захидал спам хавтсанд орж байгаа эсэхийг ажигла. p=reject нь унасан захидлыг хүлээн авахаас татгалзах хүсэлт учраас энэ шатанд хүргэлтийн алдаа илүү ноцтой үр дагавартай.

Өмнөх заавруудад бодлогыг захидлын тодорхой хувьд үйлчлэх pct тагтай жишээ бий. Харин шинэ RFC 9989 стандарт pct тагийг хассан: хүлээн авагчид дундаж хувь хэмжээг жигд хэрэгжүүлдэггүй байжээ. Тиймээс pct утгыг хүргэлтийн эрсдэлийг найдвартай хязгаарлах арга гэж тооцохгүй; бодлогын шат бүрийг тайлан болон бодит хүргэлтийн үр дүнгээр шийд.

1. p=none үеийн тайлангаас мэдэгдэж буй илгээгч бүрийг олж, DMARC-д унасан хууль ёсны урсгалын SPF, DKIM эсвэл домэйны нийцлийг зас.
2. Одоогийн TXT утгыг хадгалж, p=quarantine руу шилж. Хүлээн авагчийн спам хавтас болон тайлан дахь өөрчлөлтийг хяна.
3. Хууль ёсны илгээлт хэвийн байвал p=reject рүү шилжиж, тайлангийн хяналтыг үргэлжлүүл. Хүргэлт доголдвол хадгалсан утгаар өмнөх бодлогод буцаж, нөлөөлсөн илгээгчийг зас.

Буцаах шийдвэр гаргах хүн, шалгах тайлан, өмнөх TXT утгыг шилжилт бүрийн өмнө бэлд. DNS-ийн өөрчлөлт бүх хүлээн авагчид нэгэн зэрэг хүрдэггүй тул бодлогыг буцаасан даруйд хүргэлт хаа сайгүй хэвийн болно гэж үзэж болохгүй.

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

• DMARC-ийг шууд reject бүү болго: нэг mailto алдаа хамгаалалтыг чимээгүй унтраана
• Dependabot PR-ийг шууд бүү merge хий: production scope-оо эхлээд шалга
• AWS-ийн хөнгөлөлтөд шууд бүү түгж: ашиглаагүй цаг буцаад ирэхгүй