”From” 2 ชั้น — ที่หลายคนไม่รู้#

เอาตรงๆ ครับ — เรื่องนี้ลึกขึ้นอีกชั้น. ใน SMTP คำว่า “From” มี 2 อันที่ไม่เหมือนกัน:

• Envelope From (MAIL FROM) = ที่อยู่ผู้ส่งบน “ซองนอก” — ใช้สำหรับ delivery + bounce. คุณเห็นไม่ได้ (มันอยู่ใน protocol layer)
• Header From (From:) = ที่อยู่ผู้ส่งบน “หัวกระดาษในซอง” — อันที่ Gmail / Outlook ของคุณโชว์

โจรเขียนสองอันให้ไม่ตรงกันได้สบายๆ ครับ. Envelope From เขียนว่า attacker@randomdomain.com — Header From เขียนว่า ceo@yourbank.com — Gmail โชว์ให้คุณเห็นแต่ Header From — คุณเห็น “ceo@yourbank.com” — คุณเชื่อ

นี่คือสาเหตุที่ SPF อย่างเดียว ไม่พอ (เดี๋ยวอธิบายต่อ) — และทำไมต้องมี DKIM + DMARC มาเสริม

FBI BEC Report — $50 พันล้าน ใน 11 ปี#

ทีนี้ — ความเสียหายของระบบที่ไม่มี authentication ระดับโปรโตคอล — มหาศาลขนาดไหน?

FBI Internet Crime Complaint Center (IC3) เผยรายงาน BEC fraud สะสมตั้งแต่ปี 2013-2024 — กว่า $50 พันล้านดอลลาร์ (≈1.75 ล้านล้านบาท) ที่หายไปกับ Business Email Compromise ทั่วโลก. ไม่ใช่ malware. ไม่ใช่ ransomware. แค่ อีเมลปลอม ที่หลอกให้คนโอนเงินผิดบัญชี

แค่ปี 2023 ปีเดียว — IC3 รับรายงาน BEC 21,489 เคส — ความเสียหาย $2.9 พันล้านดอลลาร์

มุมผู้บริหาร: ตัวเลขนี้สำคัญตอนคุยกับ board ครับ. ถ้า board คุณคิดว่า “เราเป็นบริษัทเล็ก ใครจะมาสนใจ” — ลองชี้ให้ดู — BEC ไม่ได้เลือกเหยื่อ. โจรเลือกบริษัทที่ กระบวนการอนุมัติเงินทาง email ไม่มีการ verify ทางอื่น. SME ไทยที่ใช้ Gmail / Outlook แบบ default — ไม่มี SPF/DKIM/DMARC + ไม่มี out-of-band verify — คือ เหยื่อชั้นดี ในสายตาโจร. ความเสียหาย BEC เฉลี่ยเคสละ ~$130,000 (≈4.5 ล้านบาท) — เทียบเท่ากำไรหลายเดือนของ SME ส่วนใหญ่

หน้าตา SPF record — text DNS อ่านง่าย#

SPF เก็บไว้เป็น DNS TXT record ของ domain. ตัวอย่าง record ของบริษัทสมมุติ yourbank.com:

1
yourbank.com.   IN TXT  "v=spf1 ip4:203.0.113.5 ip4:203.0.113.6 include:_spf.google.com -all"

อ่านเป็นภาษาคนได้ว่า:

• v=spf1 = “นี่คือ SPF version 1”
• ip4:203.0.113.5 + ip4:203.0.113.6 = “อนุญาตให้ส่งจาก 2 IP นี้”
• include:_spf.google.com = “ถ้าใช้ Google Workspace ส่งให้ — ก็อนุญาตด้วย”
• -all = “ที่เหลือ — reject หมด” (เครื่องหมาย - แปลว่า hard fail)

เวลามีอีเมลอ้างว่ามาจาก yourbank.com มาถึง Gmail — Gmail เปิด DNS ของ yourbank.com — ดู SPF record — เทียบกับ IP ของผู้ส่งจริง. ตรง → ผ่าน. ไม่ตรง → fail

ทำไม SPF อย่างเดียว — ไม่พอ#

ครับ มาถึงปัญหา. SPF มี 3 ช่องโหว่ใหญ่ ที่คนทำ security ต้องรู้:

ปัญหาที่ 1 — SPF ตรวจแค่ Envelope From ไม่ตรวจ Header From. จำที่เล่าข้างบนได้ไหมครับ? โจรเขียน Envelope From เป็น attacker@randomdomain.com (ที่ตัวเองเป็นเจ้าของ — มี SPF ถูกต้อง) — แล้วเขียน Header From (ที่คนเห็น) เป็น ceo@yourbank.com. SPF pass — แต่คนถูกหลอก

ปัญหาที่ 2 — SPF พังตอน forward. ลองนึก — เลขาที่ทำงาน forward อีเมลของ CEO ไปให้ทีม. ตอน forward — IP ผู้ส่งเปลี่ยนเป็น IP ของบริษัทเลขา ไม่ใช่ของ CEO. SPF เลย fail. อีเมลที่ legit แต่ forward ผ่านมือกลาง → โดน reject

ปัญหาที่ 3 — SPF มี limit 10 DNS lookup. บริษัทใหญ่ที่ใช้ MailChimp + SendGrid + Salesforce + Google Workspace + … — record บวมเกิน lookup limit → SPF break เงียบๆ. นี่คือ pattern ที่บริษัทไทยเจอบ่อย — ติด SPF ครั้งแรกแล้ว 3 ปีต่อมา record บวมเพราะเพิ่ม SaaS เรื่อยๆ — fail แบบไม่รู้ตัว

มุมผู้บริหาร: ถ้าทีม IT บอกว่า “เรามี SPF แล้ว ปลอดภัย” — ขอตอบกลับว่า “SPF อย่างเดียวไม่กัน spoofing ของ Header From”. นี่คือ pattern คลาสสิคของวงการ — บริษัทเซ็ต SPF เป็น ~all (soft fail แทน -all hard fail) เพื่อ “กันพลาด” — แล้วลืมไปว่าตัวเองเหลือ protection แค่ครึ่ง. ขอให้ทีมตรวจ SPF record ของ domain ทุกตัวที่บริษัทใช้ส่งอีเมล (รวม domain ที่ไม่ได้ใช้ส่ง — ต้อง publish v=spf1 -all เพื่อกันคนอื่นมาปลอม)

หัวใจของ DKIM — เซ็นจดหมายด้วย private key#

ลองนึกระบบไปรษณีย์โบราณครับ — ขุนนางส่งจดหมายราชการ. ก่อนปิดซอง — หยดขี้ผึ้งร้อนลงตรงฝา — แล้ว ประทับตราของตัวเอง ลงไป. ตรานี้ทำขึ้นเองไม่ได้ — ถ้าใครเปิดซองอ่านกลางทาง — ขี้ผึ้งแตก — เห็นรอย. ถ้าใครพยายามปลอมตรา — ลายไม่ตรงกับลายของจริงที่ขึ้นทะเบียนไว้

DKIM ทำแบบเดียวกันด้วย crypto ครับ:

1. ฝั่งผู้ส่ง — บริษัทสร้าง key pair (private + public — จาก EP.21). เก็บ private key ไว้กับตัว. publish public key ไว้ใน DNS ของ domain
2. ส่งอีเมล — mail server เซ็น (sign) header + body ของอีเมลด้วย private key — แปะ signature ไว้ในหัวอีเมล
3. ฝั่งผู้รับ — Gmail/Outlook ดึง public key จาก DNS ของผู้ส่ง — verify signature
4. ถ้า signature ตรง = อีเมลนี้มาจากเจ้าของ private key จริง + เนื้อหาไม่ถูกแก้กลางทาง

นี่คือพลังของ DKIM ครับ — มันไม่ใช่แค่ “อีเมลนี้มาจากใคร” — แต่ “อีเมลนี้ ทั้งหัวและเนื้อ ไม่ถูกแก้กลางทาง”

หน้าตา DKIM ในชีวิตจริง#

DKIM signature ที่แปะมาในอีเมล (อยู่ใน raw header — Gmail มี “Show original”) หน้าตาประมาณนี้:

1
DKIM-Signature: v=1; a=rsa-sha256; d=yourbank.com; s=mail2024;
2
        h=from:to:subject:date; bh=K9p3...; b=R5xQ...

• d=yourbank.com = ลงนามในนามของ domain นี้
• s=mail2024 = ใช้ selector ชื่อ “mail2024” (บริษัทมี key หลายตัวได้ — selector เป็นชื่อระบุว่า key ไหน)
• bh=... = hash ของ body (จาก EP.22)
• b=... = signature ที่เซ็นด้วย private key

ผู้รับเปิด DNS ที่ mail2024._domainkey.yourbank.com → เจอ public key → verify → ตรง = ผ่าน

DKIM แก้ปัญหา forward ของ SPF#

จุดสำคัญที่ DKIM ดีกว่า SPF ครับ — DKIM survive การ forward

เพราะ signature เซ็นเนื้อ + header สำคัญของอีเมล — ไม่ได้เซ็น IP. ใครเอา raw email ไป forward — signature ยังตรงอยู่ — ผู้รับปลายทาง verify ได้

นี่คือเหตุผลที่วงการ standard คือ “ทั้ง SPF + DKIM” ไม่ใช่อย่างใดอย่างหนึ่ง

แต่ DKIM ก็มี gap ของตัวเอง#

ครับ DKIM ไม่ใช่กระสุนวิเศษ:

• ไม่บังคับ Header From — เช่นเดียวกับ SPF. DKIM signature ลงนามในนามของ domain ใน d= tag — ไม่จำเป็นต้องตรงกับ Header From ที่คนเห็น. โจรเซ็นด้วย domain ที่ตัวเองคุม — แต่ Header From เป็นของบริษัทเหยื่อ → DKIM ผ่านในมุม technical แต่คนยังถูกหลอก
• Key หมุนไม่บ่อย = เสี่ยง — key 1024-bit ที่ใช้นานๆ → ถ้า leak → โจรเซ็นแทนได้ตลอด. ปัจจุบัน standard คือ 2048-bit + หมุน key อย่างน้อยปีละครั้ง
• Replay attack — ถ้าโจรเก็บอีเมล signed valid 1 อันไว้ → forward ไป target ใหม่ → signature ยังตรง. ระดับโปรเลย

จุด gap ตรง “Header From ไม่ตรงกับ DKIM d=” นี่แหละ — คือเหตุผลที่ต้องมีชั้นที่ 3

มุมผู้บริหาร: เวลาคุยกับ vendor email หรือ outsource IT — ขอให้ confirm ว่า DKIM ใช้ key 2048-bit ไม่ใช่ 1024-bit เก่า + มี process หมุน key (key rotation) อย่างน้อยปีละ 1 ครั้ง. นี่คือ checklist พื้นฐานที่ vendor ส่วนใหญ่ทำได้ — แต่ถ้าไม่ถามจะไม่ทำ. และอย่ายอม disable DKIM ตอนเจอปัญหา deliverability — ขอให้ debug แทน. การ disable DKIM ระยะยาว = เปิด domain ให้โจรเซ็นปลอม

3 อย่างที่ DMARC ทำที่ SPF + DKIM ทำเดี่ยวๆ ไม่ได้#

อย่างแรก — Alignment (การจัดให้ตรงกัน). DMARC บังคับว่า domain ใน Header From (ที่คนเห็น) ต้องตรงกับ domain ที่ผ่าน SPF หรือ DKIM. ปิด gap “Header From ปลอม” ที่ SPF + DKIM ทำเดี่ยวๆ จับไม่ได้

อย่างที่สอง — Policy (นโยบายตอน fail). DMARC ให้เจ้าของ domain ประกาศ 3 ระดับว่า “ถ้าอีเมลในนามผมที่ fail SPF+DKIM — ทำยังไง”:

• p=none = monitor only — ไม่ทำอะไรกับ user — แค่ส่ง report กลับมา. เป็น mode สำหรับ “เริ่มต้น” เพื่อดูข้อมูล
• p=quarantine = ส่งเข้า junk/spam folder
• p=reject = bounce/ปฏิเสธไม่รับเลย — ระดับ enforce เต็มที่

อย่างที่สาม — Reporting (รายงานกลับ). DMARC ส่ง report rua (aggregate) + ruf (forensic) กลับมาให้เจ้าของ domain ทุกวัน — บอกว่ามีใครพยายามส่งอีเมลในนามคุณบ้าง — ผ่านกี่ตัว fail กี่ตัว มาจาก IP ไหน

หน้าตา DMARC record#

1
_dmarc.yourbank.com.   IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-report@yourbank.com; pct=100; aspf=s; adkim=s"

อ่านเป็นภาษาคน:

• p=reject = “อีเมลปลอม → reject เลย”
• rua=mailto:... = “ส่ง aggregate report มาที่อีเมลนี้”
• pct=100 = “บังคับ policy 100% ของอีเมล”
• aspf=s + adkim=s = “strict alignment — domain ต้องตรงเป๊ะ”

Roadmap การเซ็ต DMARC ในชีวิตจริง#

นี่คือ pattern ที่บริษัททั่วโลกใช้กันครับ — อย่ากระโดดไป p=reject วันแรก (เสี่ยงตัด legit email พังหมด):

1. เดือน 1-2 — p=none + เปิด rua report → รอดู report 4-8 อาทิตย์ — ดูว่าอีเมล legit ของบริษัทอยู่ที่ไหนบ้าง (MailChimp / Google / SendGrid / SaaS)
2. เดือน 3-4 — เพิ่ม SPF + DKIM ให้ครบทุก sender ที่เจอใน report
3. เดือน 5 — เปลี่ยนเป็น p=quarantine; pct=10 → 25 → 50 → 100 (ค่อยๆ เพิ่ม)
4. เดือน 6-9 — p=reject; pct=100 — finish

นี่คือ playbook ที่ Cisco / Microsoft / รัฐบาลสหรัฐ (BOD 18-01 ปี 2017 บังคับทุกหน่วยงาน federal ทำ DMARC reject) — ใช้กัน

Gmail + Yahoo + Apple บังคับ DMARC ปี 2024#

ครับ — และนี่คือเหตุที่ EP นี้สำคัญตอนนี้

ตั้งแต่ กุมภาพันธ์ 2024 — Gmail + Yahoo + Apple iCloud Mail ออก policy ใหม่ — ถ้าคุณส่งอีเมลเกิน 5,000 ฉบับ/วัน ไปหา user ของพวกเขา — บังคับต้องมี:

• SPF + DKIM ครบทั้ง 2
• DMARC อย่างน้อย p=none (พร้อม report)
• Header From alignment
• One-click unsubscribe สำหรับ marketing
• Spam complaint rate < 0.3%

ถ้าไม่มี — อีเมลของคุณ โดน reject หรือเข้า spam ทั้งหมด. บริษัท SaaS, ecommerce, newsletter ที่ใช้ Gmail/Yahoo/Apple เป็น customer base ใหญ่ — ปี 2024 ทุกบริษัทต้องเร่งเซ็ต DMARC ภายในไตรมาส 1

มุมผู้บริหาร: ถ้าบริษัทคุณส่งอีเมลถึงลูกค้าจำนวนมาก (newsletter / order confirmation / billing) และยังไม่มี DMARC — คุณมีปัญหาเร่งด่วน ครับ. ไม่ใช่แค่ security risk — มันคือ deliverability risk ที่กระทบรายได้โดยตรง. อีเมล order confirmation ตกใน spam = ลูกค้าไม่รู้ว่าสั่งสำเร็จ = refund + support ticket + churn. ตั้งทีมเร่ง roadmap DMARC ภายในไตรมาสนี้ — มี vendor 3rd party (Valimail, dmarcian, EasyDMARC) ที่ทำ managed service ราคาเอื้อมถึงสำหรับ SME

เงื่อนไขของ BIMI — DMARC ต้องผ่านก่อน#

BIMI ไม่ใช่อยู่ๆ ก็ใช้ได้. มีเงื่อนไข 3 ข้อ:

1. DMARC ของคุณต้อง p=quarantine หรือ p=reject ขึ้นไป (p=none ใช้ไม่ได้)
2. ต้องมี VMC (Verified Mark Certificate) — certificate ที่ออกโดย CA (Entrust, DigiCert) ยืนยันว่า โลโก้นี้เป็นของบริษัทคุณจริง (ลงทะเบียน trademark แล้ว) — ราคา ~$1,500/ปี
3. โลโก้ต้องเป็น SVG รูปแบบเฉพาะ (SVG Tiny PS)

publish ไว้ใน DNS:

1
default._bimi.yourbank.com.   IN TXT  "v=BIMI1; l=https://yourbank.com/logo.svg; a=https://yourbank.com/vmc.pem"

Gmail เห็น record → verify VMC → ดึงโลโก้ → แสดงในกล่อง

แล้ว BIMI คุ้มไหม?#

เอาตรงๆ ครับ — คุ้มสำหรับแบรนด์ที่ส่งอีเมลถึง consumer จำนวนมาก (ธนาคาร, ecommerce, ไลน์การบิน, telecom). studies จาก Validity + Verizon Media รายงาน CTR เพิ่ม 10-21% หลัง implement BIMI. สำหรับ B2B ที่ส่งอีเมลภายในวงเล็ก — ROI ไม่ชัด

แต่ที่สำคัญที่สุด — BIMI = แรงจูงใจให้บริษัททำ DMARC reject. เพราะแบรนด์อยากได้โลโก้ในกล่อง → ต้องเร่ง DMARC ให้ถึง p=reject → security ดีขึ้นพร้อม. นี่คือ pattern ที่วงการชอบ — “ผูกแรงจูงใจ marketing เข้ากับ security control”

มุมผู้บริหาร: ถ้าบริษัทคุณเป็น consumer brand ที่ใช้อีเมลเป็น channel หลัก (B2C ecommerce, banking, airline) — BIMI ควรอยู่ใน roadmap ปีนี้ครับ. ค่า VMC ปีละ ~$1,500 (≈53,000 บาท) ถูกมากเทียบกับการที่ Gmail แสดงโลโก้ของคุณข้างทุกอีเมล — เพิ่ม brand recall + ลด phishing impersonation. ถ้าเป็น B2B — DMARC p=reject ก่อน, BIMI ทีหลัง

3 เทคนิคที่ BEC ใช้#

เทคนิคที่ 1 — Display Name Spoofing

อีเมลที่ส่งมามีลักษณะนี้:

1
From: "สมชาย ใจดี - CEO" <ceo.sombat.fake@gmail.com>

ในกล่องจดหมายของคุณบนมือถือ — เห็นแค่ “สมชาย ใจดี - CEO” — ที่อยู่ที่ปลอม (@gmail.com) ถูกซ่อนเพราะ UI แคบ. คุณคิดว่าเป็น CEO จริง. SPF + DKIM + DMARC ทั้งหมดผ่าน เพราะอีเมลส่งจาก Gmail จริง — Gmail มี SPF/DKIM/DMARC ของตัวเองที่ valid

ทุก control ปลายทาง pass หมด. แต่คุณถูกหลอก เพราะคุณ ไม่ได้อ่านที่อยู่อีเมลเต็ม

เทคนิคที่ 2 — Lookalike Domain

โจรซื้อ domain ที่ใกล้เคียงกับของบริษัท. เช่น:

• บริษัทจริง: coca-cola.com
• โจรซื้อ: coca-cola.co (ตัด m) / coca-c0la.com (เลข 0 แทน o) / соса-соlа.com (อักษร Cyrillic ที่หน้าตาเหมือน Latin — homograph attack)

โจรเซ็ต SPF + DKIM + DMARC ของ domain ปลอมตัวเองให้ valid 100% — ส่งอีเมลออกมา. ผู้รับเห็น ceo@coca-cola.co — อ่านผ่านๆ — เชื่อ. ทุก security control technical pass — เพราะ domain นั้นจริง — แค่ไม่ใช่ของบริษัทที่ผู้รับคิด

เทคนิคที่ 3 — Compromise Legitimate Account

โจรไม่ปลอมเลย. เขาเข้าถึงบัญชีจริงของพนักงานในบริษัท (ผ่าน phishing password / MFA bypass / token theft จาก EP ก่อนหน้า). พอเข้าได้ — โจรใช้ บัญชีจริง ส่งอีเมลออก. SPF pass. DKIM pass. DMARC pass. BIMI โชว์โลโก้บริษัทจริง — เพราะมันคือบริษัทจริง

นี่คือ pattern ที่อันตรายที่สุด — เพราะไม่มี email security control ตัวไหน detect ได้. control ต้องอยู่ที่ identity (EP.10-17) + behavioral analytics

3 เคสคลาสสิคของวงการ#

Toyota Boshoku — $37 ล้าน, 2019

Toyota Boshoku คือบริษัทลูกของ Toyota ที่ทำชิ้นส่วนรถยนต์. สิงหาคม 2019 — แผนกการเงินยุโรปได้รับ “อีเมลจาก executive” สั่งให้โอนเงินไปบัญชีต่างประเทศเป็นส่วนหนึ่งของ “การเปลี่ยนแปลงการชำระเงิน”. พนักงานทำตาม. โอนไปแล้ว ¥4 พันล้านเยน (≈$37 ล้าน). ตอนรู้ตัว — เงินหายแล้ว

วิธีการ — ที่ Toyota Boshoku เปิดเผยภายหลัง — เป็น lookalike domain + display name spoofing ผสมกัน. SPF + DKIM ของอีเมลปลอม pass (เพราะส่งจาก domain ของโจรเอง) — ไม่มี out-of-band verification (โทรกลับยืนยัน)

Ubiquiti Networks — $46.7 ล้าน, 2015

Ubiquiti (ผู้ผลิตอุปกรณ์เครือข่าย) — แผนกการเงินในฮ่องกงได้อีเมลจากคนที่ ปลอมเป็น executive ของ Ubiquiti เอง สั่งให้โอนเงินจำนวนมหาศาลไปบัญชีต่างประเทศ. โอนไป $46.7 ล้านก่อนจะรู้ว่าเป็นเรื่องหลอก. กู้กลับมาได้บางส่วนเท่านั้น

นี่คือเคสที่ทำให้ SEC ในอเมริกาเริ่มให้ความสนใจ BEC ในระดับ public company filing risk

Crelan Bank — €70 ล้าน, 2016

Crelan Bank ในเบลเยียม — เป็นเคส BEC ที่ใหญ่ที่สุดในประวัติศาสตร์ธนาคารยุโรปตอนนั้น. €70 ล้าน หายไปจากการที่พนักงานเชื่ออีเมลปลอมที่อ้างว่ามาจาก CEO. ธนาคาร ไม่เปิดเผยรายละเอียด technique แต่ผู้สืบสวนบอกว่าเป็น classic CEO fraud

Defense จริงๆ ของ BEC = “ออกจากอีเมล”#

นี่คือบทเรียนใหญ่ครับ — BEC ไม่ถูกป้องกันด้วย technology อย่างเดียว เพราะมัน exploit สายตามนุษย์ + กระบวนการของบริษัท. ทาง defense ที่ effective ที่สุด — เป็น process control ไม่ใช่ technical control:

1. Out-of-band verification — ทุกการโอนเงิน > X บาท หรือ ทุกการเปลี่ยนบัญชีปลายทาง — ต้องโทรกลับยืนยันที่เบอร์ที่บันทึกในระบบ (ไม่ใช่เบอร์ในอีเมล). หลักการเดียวที่กัน BEC ได้จริง
2. Dual approval — เงินก้อนใหญ่ต้องมีอนุมัติ 2 คนจากช่องทางที่แยกกัน
3. Training พนักงาน — สอนให้สังเกต: อ่าน Header From เต็ม / hover ดู link / สงสัยทุกอีเมลที่บอกว่า “ด่วน” + “เปลี่ยนบัญชี”
4. Banner ใน inbox — Microsoft 365 / Google Workspace มี feature ติดแบนเนอร์ “This email is from outside your organization” กับทุกอีเมลจากภายนอก — เปิดไว้

มุมผู้บริหาร: ถ้าบริษัทคุณยังไม่มี process โทรกลับยืนยันก่อนโอน สำหรับเงินก้อนใหญ่หรือเปลี่ยนบัญชีปลายทาง — นั่นคือ gap อันดับ 1 ของบริษัทคุณตอนนี้ ครับ ใหญ่กว่า SPF/DKIM/DMARC ทุกตัวรวมกัน. เคส Toyota Boshoku, Ubiquiti, Crelan — ทุกเคสมี email security technical พร้อม. ที่พังคือ process การอนุมัติเงิน. ออก memo + ใส่ในระเบียบการเงินทันที — ค่าใช้จ่าย 0 บาท, ป้องกันเงินหลายสิบล้านได้

2 leader takeaways#

ข้อที่ 1 — ถ้าบริษัทคุณยังไม่มี DMARC p=reject — มีปัญหา 2 ด้านพร้อมกัน: (ก) security — domain คุณถูกใช้ปลอม phishing ได้ฟรี — แบรนด์เสียหายที่คุณไม่เห็น (ข) deliverability — Gmail/Yahoo/Apple ปี 2024 กรอง email ของบริษัทที่ไม่มี DMARC ลง spam — กระทบ revenue ตรงๆ. roadmap 6-9 เดือน: p=none → quarantine → reject เริ่มไตรมาสนี้

ข้อที่ 2 — แต่ DMARC ครบยังไม่จบ ครับ. BEC = process problem, not protocol problem. เงินก้อนใหญ่ + การเปลี่ยนบัญชีปลายทาง — ทุกธุรกรรมต้องมี out-of-band verification (โทรกลับเบอร์ที่บันทึกในระบบ ไม่ใช่เบอร์ในอีเมล). ค่าใช้จ่าย 0 บาท — กันเงินหลายสิบล้านที่เคสคลาสสิคของวงการสูญเสียไป

Email security ของเมืองดิจิทัลครบแล้วครับ. มาถึงหัวข้อ สุดท้ายของ Part 3 — ที่จะปิดเรื่อง “ของในเซฟ” ของเรา

ครับ — เราพูดเรื่อง security มาตั้งแต่ EP.18 — ปกป้อง confidentiality + integrity + availability ของข้อมูล. แต่มีอีกแนวคิดที่อยู่ข้างกัน + ใหญ่ขึ้นเรื่อยๆ ในยุค AI ที่ชื่อว่า — Privacy

หลายคนคิดว่า security = privacy. ไม่ใช่ครับ. Security คือ “ใครเข้าถึงข้อมูลได้บ้าง”. Privacy คือ “ควรเก็บข้อมูลพวกนี้ตั้งแต่แรกหรือเปล่า”. ต่างกันคนละชั้น

EP.26 — Privacy Engineering: เก็บน้อย ใช้น้อย ลบเมื่อหมดเวลา — ผมพาคุณดู Data Minimization / Purpose Limitation / Storage Limitation, Anonymization vs Pseudonymization, k-anonymity, Differential Privacy ที่ Apple ใช้, และเคสคลาสสิคของวงการ — Netflix de-anonymization ปี 2007 + Cambridge Analytica — ที่เปลี่ยนวิธีคิดเรื่อง privacy ของวงการตลอดกาล. ผู้พิทักษ์สิทธิ์ของชาวเมือง มาเจอกันต่อ EP.26 ครับ