SPF, DKIM ແລະ DMARC: ຢຸດຄົນປອມ Email ດ້ວຍ Domain ຂອງທ່ານ

ໂທລະສັບທີ່ບໍ່ມີໃຜຢາກໄດ້ຮັບ

ລູກຄ້າໂທມາຖາມວ່າ: "ພວກເຮົາໂອນເງິນໄປບັນຊີໃໝ່ຕາມ Email ຂອງທ່ານແລ້ວ, ເປັນຫຍັງຍັງທວງອີກ?" Email ນັ້ນສະແດງວ່າມາຈາກ [email protected], ມີໂລໂກ້, ມີລາຍເຊັນ ແຕ່ທ່ານບໍ່ເຄີຍສົ່ງ. ການປອມ Email ແບບນີ້ (Business Email Compromise) ເກີດໄດ້ງ່າຍ ເພາະໂປໂຕຄອນ Email (SMTP) ຖືກອອກແບບມາໂດຍບໍ່ກວດຜູ້ສົ່ງ. ໃຜກໍສາມາດສົ່ງ Email ທີ່ສະແດງ Domain ຂອງທ່ານໃນຊ່ອງ From ໄດ້ ຖ້າ Domain ບໍ່ໄດ້ບອກໂລກເປັນຢ່າງອື່ນ. SPF, DKIM ແລະ DMARC ແມ່ນວິທີບອກ.

ເຫດຜົນທີສອງແມ່ນການສົ່ງ Email ໃຫ້ເຖິງ Inbox. ຕັ້ງແຕ່ປີ 2024, Gmail ແລະ Yahoo ກຳນົດໃຫ້ຜູ້ສົ່ງຈຳນວນຫຼາຍ (ເກີນ 5,000 ສະບັບຕໍ່ມື້) ຕ້ອງມີທັງສາມ, ແລະ ຜູ້ສົ່ງທຸກຄົນຕ້ອງມີຢ່າງໜ້ອຍ SPF ຫຼື DKIM. Microsoft ນຳໃຊ້ຂໍ້ກຳນົດຄ້າຍກັນສຳລັບ Outlook.com ຕັ້ງແຕ່ເດືອນພຶດສະພາ 2025, ແລະ ຕັ້ງແຕ່ທ້າຍປີ 2025 Gmail ປະຕິເສດ Email ທີ່ບໍ່ຜ່ານຂໍ້ກຳນົດຢ່າງຈິງຈັງ ແທນທີ່ຈະພຽງແຕ່ເຕືອນ. ເຖິງວ່າບໍລິສັດຂອງທ່ານສົ່ງໜ້ອຍກວ່ານັ້ນຫຼາຍ, Domain ທີ່ບໍ່ມີ Record ເຫຼົ່ານີ້ ກໍມີແນວໂນ້ມເຂົ້າ Spam ຫຼາຍຂຶ້ນ.

ສາມ Record ໃນໜຶ່ງປະໂຫຍກ

• SPF: ລາຍຊື່ Server ທີ່ອະນຸຍາດໃຫ້ສົ່ງ Email ໃນນາມ Domain ນີ້.
• DKIM: ລາຍເຊັນດິຈິຕອນໃນທຸກ Email ທີ່ພິສູດວ່າ Domain ນີ້ເປັນຜູ້ສົ່ງ ແລະ ເນື້ອຫາບໍ່ຖືກແກ້ໄຂ.
• DMARC: ບອກຜູ້ຮັບວ່າຈະເຮັດແນວໃດກັບ Email ທີ່ອ້າງວ່າມາຈາກທ່ານແຕ່ບໍ່ຜ່ານ, ແລະ ສົ່ງ Report ກັບມາ.

ກ່ອນເລີ່ມ: ໃຜຖື DNS ຂອງທ່ານ?

ໃນລາວ ບັນຫາທຳອິດທີ່ພວກເຮົາພົບ ມັກບໍ່ແມ່ນເລື່ອງເຕັກນິກ. ແມ່ນບໍ່ມີໃຜຮູ້ວ່າ DNS ຂອງ Domain .la ຫຼື .com ຢູ່ໃສ ແລະ ລະຫັດເຂົ້າໃຊ້ຢູ່ກັບໃຜ. ຫຼາຍເທື່ອຢູ່ກັບບໍລິສັດເຮັດເວັບທີ່ຈ້າງເມື່ອຫຼາຍປີກ່ອນ. ຊອກຫາໃຫ້ພົບວ່າ DNS ຢູ່ກັບຜູ້ໃຫ້ບໍລິການໃດ, ເອົາບັນຊີມາເປັນຊື່ບໍລິສັດ ແລະ ເປີດ MFA. ຜູ້ທີ່ແກ້ DNS ໄດ້ ຄືຜູ້ທີ່ຄວບຄຸມ Email ທັງໝົດຂອງທ່ານ.

SPF

TXT Record ທີ່ Domain ຫຼັກ (yourcompany.la). ສຳລັບ Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

ສຳລັບ Google Workspace ໃຊ້ include:_spf.google.com ແທນ. ຖ້າມີລະບົບອື່ນທີ່ສົ່ງ Email ໃນນາມ Domain (ERP, ລະບົບ Newsletter, ເວັບໄຊ, ເຄື່ອງ Scan ທີ່ສົ່ງຜ່ານ SMTP ຂອງ ISP), ຕ້ອງເພີ່ມທຸກອັນ.

ສອງກົດທີ່ທຳລາຍ SPF ເລື້ອຍທີ່ສຸດ:

• ມີໄດ້ SPF Record ດຽວ ຕໍ່ Domain. ຖ້າມີສອງ, SPF ລົ້ມເຫຼວທັງໝົດ (PermError). ເຮົາພົບເລື້ອຍເມື່ອຜູ້ໃຫ້ບໍລິການເວັບເພີ່ມ Record ຂອງຕົນເອງໂດຍບໍ່ລວມກັບອັນເກົ່າ.
• ບໍ່ເກີນ 10 DNS Lookup. ທຸກ include, a, mx ນັບ, ລວມທັງ include ທີ່ຊ້ອນຢູ່ຂ້າງໃນ. include ດຽວອາດກິນຫຼາຍ Lookup, ໃຫ້ກວດດ້ວຍເຄື່ອງມືກວດ SPF ທຸກຄັ້ງທີ່ແກ້.

-all (Hard Fail) ຫຼື ~all (Soft Fail)? ເມື່ອ DMARC ຢູ່ໃນລະດັບ Enforcement ແລ້ວ, ຜົນສຸດທ້າຍມາຈາກ DMARC; ຫຼາຍຄົນຈຶ່ງໃຊ້ ~all ເພື່ອບໍ່ໃຫ້ Server ບາງແຫ່ງປະຕິເສດ Email ທີ່ Forward ກ່ອນຈະກວດ DKIM. ທັງສອງແບບຮັບໄດ້; ສິ່ງສຳຄັນແມ່ນລາຍການ Server ຕ້ອງຄົບ.

DKIM

Server ທີ່ສົ່ງເຊັນ Email ດ້ວຍ Private Key; Public Key ຢູ່ໃນ DNS ທີ່ <selector>._domainkey.yourcompany.la. DKIM ລອດຈາກການ Forward ໄດ້ດີກວ່າ SPF ເພາະລາຍເຊັນຕິດໄປກັບຂໍ້ຄວາມ.

• Microsoft 365: ເປີດໃນ Defender Portal (Email authentication settings) ແລ້ວເພີ່ມ CNAME ສອງອັນ selector1._domainkey ແລະ selector2._domainkey ຕາມຄ່າທີ່ Portal ສະແດງໃຫ້. ຄັດລອກຄ່າຈາກ Portal ສະເໝີ, ຢ່າພິມເອງ.
• Google Workspace: ສ້າງ Key 2048-bit ໃນ Admin Console, ເພີ່ມ TXT Record ທີ່ google._domainkey, ແລ້ວກົດ Start Authentication.
• ລະບົບອື່ນ (Newsletter, CRM) ສ່ວນຫຼາຍມີ DKIM ຂອງຕົນເອງ; ເປີດໃຫ້ຄົບ ແລະ ໃຫ້ເຊັນດ້ວຍ Domain ຂອງທ່ານ ບໍ່ແມ່ນ Domain ຂອງຜູ້ໃຫ້ບໍລິການ.

ໝາຍເຫດ: ຜູ້ໃຫ້ບໍລິການ DNS ບາງເຈົ້າຈຳກັດຄວາມຍາວ TXT Record ໄວ້ 255 ຕົວອັກສອນຕໍ່ String. Key 2048-bit ຍາວກວ່ານັ້ນ ແລະ ຕ້ອງແບ່ງເປັນຫຼາຍ String. ຖ້າ DKIM ບໍ່ຜ່ານຫຼັງເພີ່ມ Record ໃຫ້ກວດຈຸດນີ້ກ່ອນ.

DMARC

TXT Record ທີ່ _dmarc.yourcompany.la. ເລີ່ມດ້ວຍ:

v=DMARC1; p=none; rua=mailto:[email protected]

ເມື່ອພ້ອມແລ້ວຈະເປັນ:

v=DMARC1; p=reject; rua=mailto:[email protected]

Email ຜ່ານ DMARC ເມື່ອ SPF ຫຼື DKIM ຜ່ານ ແລະ Domain ທີ່ຜ່ານນັ້ນ ກົງ (Align) ກັບ Domain ໃນຊ່ອງ From ທີ່ຜູ້ໃຊ້ເຫັນ. ນີ້ແມ່ນເຫດຜົນທີ່ລະບົບ Newsletter ທີ່ສົ່ງຜ່ານ Domain ຂອງຜູ້ໃຫ້ບໍລິການເອງ ຈະບໍ່ຜ່ານ DMARC ຈົນກວ່າທ່ານຈະຕັ້ງ DKIM ດ້ວຍ Domain ຂອງທ່ານ.

Report rua ມາເປັນໄຟລ໌ XML ທີ່ອ່ານຍາກ. ໃຊ້ເຄື່ອງມືວິເຄາະ DMARC (ມີທັງແບບຟຣີ ແລະ ແບບເສຍເງິນ) ເພື່ອເບິ່ງວ່າ IP ໃດສົ່ງໃນນາມທ່ານ ແລະ ຜ່ານ ຫຼື ບໍ່ຜ່ານ. ຖ້າສົ່ງ Report ໄປ Domain ອື່ນ (ເຊັ່ນ ຂອງຜູ້ໃຫ້ບໍລິການວິເຄາະ), Domain ນັ້ນຕ້ອງມີ Record ອະນຸຍາດຮັບ Report ແທນທ່ານ. ບໍລິການທີ່ດີຈະຕັ້ງໃຫ້ເອງ.

ການປ່ຽນແປງໃນມາດຕະຖານປີ 2026

ເດືອນພຶດສະພາ 2026, IETF ພິມມາດຕະຖານ DMARC ສະບັບປັບປຸງ (DMARCbis, RFC 9989). ສິ່ງທີ່ກະທົບງານປະຈຳວັນ:

• Tag pct ຖືກຍົກເລີກ ເພາະຜູ້ຮັບແຕ່ລະເຈົ້າປະຕິບັດບໍ່ຄືກັນ. ແທນດ້ວຍ t=y (ໂໝດທົດສອບ: ຢ່າບັງຄັບໃຊ້ Policy). ການຄ່ອຍໆເພີ່ມ pct=25, pct=50 ບໍ່ແມ່ນວິທີທີ່ແນະນຳອີກແລ້ວ.
• ມີ Tag np ສຳລັບ Subdomain ທີ່ບໍ່ມີຢູ່ແທ້, ເຊິ່ງຄົນປອມມັກໃຊ້ ເຊັ່ນ billing.yourcompany.la.
• Record ເກົ່າຍັງໃຊ້ໄດ້ຢູ່. Tag ທີ່ຍົກເລີກຈະຖືກມອງຂ້າມ, ບໍ່ເຮັດໃຫ້ Record ພັງ.

ຕົວຢ່າງ: ບໍລິສັດ 60 ຄົນ ທີ່ມີ 4 ລະບົບສົ່ງ Email

SPF ສຸດທ້າຍມີ include ພຽງອັນດຽວ, Newsletter ຜ່ານ DMARC ດ້ວຍ DKIM, ແລະ ຊື່ສຽງຂອງ Domain ຫຼັກບໍ່ຂຶ້ນກັບແຄມເປນການຕະຫຼາດ. ການແຍກ Newsletter ໄປ Subdomain ແມ່ນສິ່ງທີ່ພວກເຮົາແນະນຳເກືອບທຸກຄັ້ງ: ຖ້າແຄມເປນໜຶ່ງຖືກລາຍງານ Spam ຫຼາຍ, Email ໃບແຈ້ງໜີ້ຍັງໄປຮອດ.

ແຜນ 6–8 ອາທິດ

ອາທິດ 1. ລາຍການທຸກລະບົບທີ່ສົ່ງ Email ໃນນາມ Domain. ຖາມຝ່າຍບັນຊີ, ການຕະຫຼາດ ແລະ HR ດ້ວຍ, ບໍ່ແມ່ນແຕ່ IT. ເປີດ DKIM ແລະ ແກ້ SPF ໃຫ້ຄົບ.

ອາທິດ 1–4. ເຜີຍແຜ່ DMARC p=none ພ້ອມ rua. ອ່ານ Report ທຸກອາທິດ. ທ່ານຈະເຫັນລະບົບທີ່ລືມໄປ ແລະ ອາດເຫັນຄົນທີ່ກຳລັງປອມ Domain ຂອງທ່ານຢູ່ແລ້ວ.

ອາທິດ 4–6. ເມື່ອລະບົບແທ້ທັງໝົດຜ່ານ, ປ່ຽນເປັນ p=quarantine. ຖ້າມີຫຼາຍ Subdomain, ໃຫ້ບັງຄັບໃຊ້ເທື່ອລະ Subdomain ແທນການໃຊ້ pct.

ອາທິດ 6–8. ປ່ຽນເປັນ p=reject. ຕິດຕາມ Report ຕໍ່ ເພາະລະບົບໃໝ່ທີ່ຝ່າຍອື່ນຊື້ມາ ຈະປາກົດໃນ Report ກ່ອນທີ່ຈະມີໃຜບອກ IT.

Domain ທີ່ບໍ່ສົ່ງ Email ເລີຍ (Domain ສຳຮອງ, ຊື່ເກົ່າຂອງບໍລິສັດ): ຕັ້ງ v=spf1 -all ແລະ v=DMARC1; p=reject; ໄດ້ທັນທີ.

ກວດຜົນ: ສົ່ງ Email ໄປບັນຊີ Gmail, ເປີດ "Show original" ແລ້ວເບິ່ງວ່າ SPF, DKIM ແລະ DMARC ເປັນ PASS ທັງສາມ.

ສິ່ງທີ່ພວກເຮົາພົບເລື້ອຍ

• SPF ສອງ Record ຫຼັງຍ້າຍ Hosting ເວັບ.
• p=none ທີ່ຕັ້ງໄວ້ສອງປີ ແລະ ບໍ່ມີໃຜອ່ານ Report. ມັນບໍ່ປ້ອງກັນຫຍັງ.
• ກະໂດດໄປ p=reject ໃນມື້ດຽວ ແລ້ວ Email ໃບແຈ້ງໜີ້ຈາກ ERP ຫາຍ ລູກຄ້າບໍ່ໄດ້ຮັບ.
• Mailbox ສ່ວນໜຶ່ງຢູ່ Hosting ເກົ່າ ອີກສ່ວນຢູ່ Microsoft 365, ແລ້ວ SPF ມີແຕ່ອັນດຽວ.
• ຄິດວ່າ DMARC ປ້ອງກັນ Domain ທີ່ຄ້າຍກັນ ເຊັ່ນ yourc0mpany.la ຫຼື yourcompany-la.com. ມັນບໍ່ປ້ອງກັນ. ສ່ວນນີ້ຕ້ອງໃຊ້ Email Filtering ແລະ ການຝຶກພະນັກງານໃຫ້ຮູ້ທັນ Phishing.

ນອກເໜືອຈາກ DNS

SPF, DKIM ແລະ DMARC ປ້ອງກັນ Domain ຂອງທ່ານ ບໍ່ໃຫ້ຖືກປອມ. ມັນບໍ່ໄດ້ກວດເນື້ອຫາຂອງ Email ທີ່ເຂົ້າມາ. ສຳລັບສ່ວນນັ້ນ:

ສຳລັບການໂອນເງິນ, ກົດທີ່ດີທີ່ສຸດບໍ່ແມ່ນເຕັກນິກ: ທຸກການປ່ຽນເລກບັນຊີທະນາຄານ ຕ້ອງໂທຢືນຢັນກັບເບີທີ່ມີຢູ່ໃນແຟ້ມແລ້ວ, ບໍ່ແມ່ນເບີໃນ Email.

ເມື່ອ DMARC ຢູ່ລະດັບ quarantine ຫຼື reject ແລ້ວ ທ່ານສາມາດພິຈາລະນາ BIMI ເພື່ອສະແດງໂລໂກ້ໃນ Inbox ທີ່ຮອງຮັບ; Gmail ຕ້ອງການໃບຢັ້ງຢືນໂລໂກ້ (VMC ຫຼື CMC) ນຳ.

ຖ້າອົງກອນຍັງໃຊ້ Email ຟຣີ (Gmail ຫຼື Yahoo ສ່ວນຕົວ) ສຳລັບວຽກ, ຂັ້ນຕອນທຳອິດແມ່ນຍ້າຍມາໃຊ້ Email ທຸລະກິດທີ່ມີ Domain ຂອງຕົນເອງ. ທ່ານບໍ່ສາມາດຕັ້ງ DMARC ໃຫ້ gmail.com ໄດ້.

ສົ່ງຊື່ Domain ມາໃຫ້ພວກເຮົາ

ພຽງແຕ່ຊື່ Domain ກໍພໍ; Record ເຫຼົ່ານີ້ເປັນຂໍ້ມູນສາທາລະນະ. ພວກເຮົາຈະກວດ SPF, DKIM ແລະ DMARC ທີ່ມີຢູ່ ແລະ ສົ່ງ Record ທີ່ແກ້ໄຂແລ້ວກັບໄປ ພ້ອມໃຫ້ທ່ານຄັດລອກໃສ່ DNS ໄດ້ເລີຍ.