Defaults.Exposed › การแก้ไข › SPF (Sender Policy Framework)

วิธีแก้ไข SPF (Sender Policy Framework)

SPF คือบรรทัดในการตั้งค่าโดเมนของคุณที่แสดงรายชื่อบริการเมลใดที่ได้รับอนุญาตให้ส่งอีเมลในนามธุรกิจของคุณ หากไม่มี ใครก็ตามทั่วโลกสามารถส่งอีเมลที่ดูเหมือนมาจากคุณ — และอีเมลแท้จริงของคุณเองมีแนวโน้มมากขึ้นที่จะตกอยู่ใน spam ของลูกค้า

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

สิ่งนี้อาจทำให้คุณเสียค่าใช้จ่าย

• นักต้มตุ๋นส่งอีเมลให้ลูกค้าของคุณใบแจ้งหนี้ 'จากคุณ' พร้อมรายละเอียดธนาคารของพวกมันเอง และได้รับการชำระเงิน คุณพบสัปดาห์ต่อมาเมื่อลูกค้าถามว่าสินค้าของพวกมันอยู่ที่ไหน — และตอนนี้มันคือชื่อเสียงของคุณ และอาจเป็นความรับผิดชอบของคุณ
• ใบเสนอราคา ใบแจ้งหนี้ และการตอบกลับของคุณตกอยู่ใน spam ของลูกค้าอย่างเงียบๆ เพราะผู้ให้บริการรายใหญ่ไม่สามารถยืนยันว่ามาจากคุณจริงๆ ดีลเย็นชาและคุณไม่เคยรู้ว่าทำไม
• นักต้มตุ๋นแอบอ้างเป็นเจ้าของหรือฝ่ายการเงินของคุณและส่งอีเมลให้พนักงานขอการชำระเงินเร่งด่วนหรือบัตรของขวัญ — ข้อความปรากฏจากโดเมนของคุณอย่างแท้จริง ดังนั้นมีคนจ่าย
• ผู้มีโอกาสเป็นลูกค้าที่ใหญ่กว่า IT หรือการตรวจสอบความปลอดภัยตรวจสอบโดเมนของคุณ เห็นว่าไม่มีการป้องกัน sender และปฏิเสธคุณหรือทำให้คุณแก้ไขมันก่อนที่พวกมันจะลงนาม — ทำให้คุณสูญเสียดีลหรือล่าช้าหลายสัปดาห์
• คุณคิดว่าคุณได้รับการปกป้องเพราะมีระเบียน SPF อยู่ — แต่มันถูกตั้งเป็น 'soft fail' โดยไม่มีอะไรบังคับ หรือมันเสียหายอย่างเงียบๆ ดังนั้นเมลที่ปลอมแปลงยังคงผ่านไปได้

เหตุใดจึงสำคัญ การปลอมแปลงที่อยู่ 'from' บนอีเมลทำได้ง่ายอย่างเหลือเชื่อและไม่มีค่าใช้จ่ายสำหรับผู้โจมตี SPF เป็นวิธีที่ถูกที่สุดและเร็วที่สุดในการทำให้โดเมนของคุณยากต่อการแอบอ้างและรักษาเมลที่ถูกต้องของคุณออกจาก spam Google และ Yahoo ตอนนี้ junk หรือปฏิเสธเมลจากโดเมนที่ไม่ได้รับการรับรองอย่างแข็งขัน ดังนั้นนี่ไม่ใช่ตัวเลือกอีกต่อไป — มันเป็นสิ่งจำเป็นสำหรับการส่งอีเมลของคุณเลย

วิธีแก้ไข ทีละขั้นตอน

1. แสดงรายการทุกบริการที่ส่งในนามของคุณ. เขียนทุกบริการที่ส่งอีเมลโดยใช้โดเมนของคุณ — ผู้ให้บริการกล่องรับจดหมายของคุณบวกกับเครื่องมือออกใบแจ้งหนี้ CRM จดหมายข่าว หรือ helpdesk
2. สร้างระเบียน SPF หนึ่งอัน. สร้าง TXT record เดียวที่ domain root เริ่มต้นด้วย v=spf1 พร้อม include: สำหรับแต่ละ sender ลงท้ายด้วย ~all อย่าเผยแพร่ระเบียน SPF สองอัน
3. อยู่ใต้ 10 DNS lookups. SPF อนุญาตสูงสุด 10 DNS lookups หากเกินกว่านั้น ระเบียนล้มเหลว ลบ include ที่ไม่ใช้หรือทำให้แบนเพื่ออยู่ใต้ขีดจำกัด
4. บังคับใช้ด้วย DMARC ไม่ใช่ -all. เผยแพร่ ~all และบังคับใช้ด้วย DMARC policy ของ reject แทนที่จะพึ่งพา -all คนเดียว — การป้องกันเดียวกันโดยไม่ทำลายเมลที่ forward
5. ยืนยันว่ามันทำงาน. ตรวจสอบโดเมนของคุณใหม่เพื่อยืนยันว่า SPF ผ่านและไม่ใช่ soft-failing หรือเสียหายอย่างเงียบๆ

เวอร์ชันสั้น

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

SPF (Sender Policy Framework) คือการแก้ไข มันเป็นบรรทัดข้อความเดียวในการตั้งค่า DNS ของโดเมนของคุณที่แสดงรายชื่อบริการเมลใดที่ได้รับอนุญาตจริงๆ ให้ส่งอีเมลในนามของคุณ ผู้ให้บริการเมลรับ — Gmail, Outlook, ทุกคน — ตรวจสอบรายการนั้นก่อนตัดสินใจว่าข้อความจริงหรือไม่ ไม่มีรายการ หรือรายการที่อ่อนแอ และพวกมันไม่มีอะไรให้ยึด

หน้านี้ครอบคลุมสองสิ่งที่ต้องถูกต้องทั้งคู่: ว่าระเบียน SPF มีอยู่หรือไม่ และ ว่ามันเข้มงวดพอที่จะทำงานจริงๆ ไหม

สิ่งนี้อาจทำให้คุณสูญเสียอะไร

• การเปลี่ยนเส้นทางใบแจ้งหนี้ อาชญากรส่งอีเมลให้ลูกค้าของคุณที่ดูเหมือนมาจากคุณอย่างแน่นอน แนบใบแจ้งหนี้ที่ดูจริงพร้อมบัญชีธนาคารของพวกมันเอง ลูกค้าของคุณจ่าย สิ่งแรกที่คุณได้ยินคือการตามเก็บที่ถามว่าออร์เดอร์อยู่ที่ไหน ตอนนี้มีลูกค้าที่โกรธ การชำระเงินไปถึงอาชญากร และการสนทนาที่ยากเกี่ยวกับใครแบกรับการสูญเสีย
• การหลอกลวง CEO/finance อีเมลปรากฏว่ามาจากเจ้าของต่อผู้จัดบัญชีของคุณ: “ความโปรดปราน — คุณสามารถผลักดันการชำระเงินนี้ผ่านก่อนสิ้นวันได้ไหม?” เพราะข้อความปรากฏจากโดเมนของคุณอย่างแท้จริง มันไม่กระตุ้นสัญชาตญาณของใคร เงินออกจากอาคาร
• ภาษี deliverability ที่เงียบ ใบเสนอราคาและใบแจ้งหนี้ของคุณเริ่มตกอยู่ใน spam ของลูกค้าเพราะ Gmail และ Yahoo ไม่สามารถยืนยันว่ามาจากคุณจริงๆ คุณไม่ได้รับการตีกลับ คุณไม่ได้รับข้อผิดพลาด — ดีลแค่เงียบ
• สัญญาที่สูญหาย การจัดซื้อหรือทีมความปลอดภัยของลูกค้าที่ใหญ่กว่ารันการตรวจสอบพื้นฐานบนโดเมนของคุณ พวกมันเห็นว่าไม่มีการรับรอง sender และทำเครื่องหมายคุณเป็นความเสี่ยง กรณีที่ดีที่สุด คุณรีบแก้ไขภายใต้ความกดดันเส้นตาย กรณีที่เลวร้ายที่สุด พวกมันไปหาคู่แข่งที่ผ่าน

มันคืออะไรจริงๆ

เมื่ออีเมลมาถึง เซิร์ฟเวอร์เมลรับต้องการรู้สิ่งหนึ่ง: นี่มาจากคนที่อ้างจริงๆ ไหม? SPF ตอบบางส่วนของคำถามนั้น

คุณเผยแพร่บรรทัดข้อความสั้นๆ ในการตั้งค่า DNS ของโดเมนของคุณ — “TXT record” — ที่ตั้งชื่อบริการเมลที่ได้รับอนุญาตส่งในนามของคุณ บางอย่างเช่น:

v=spf1 include:_spf.google.com include:sendgrid.net -all

เป็นคำพูดง่ายๆ นั่นอ่านว่า: “เมลแท้จริงจากเราก็มาจากเซิร์ฟเวอร์ของ Google และเซิร์ฟเวอร์ของ SendGrid — ปฏิเสธสิ่งใดก็ตามที่อ้างว่าเป็นเรา”

สองส่วนที่สำคัญสำหรับเกรดของคุณ:

1. ระเบียนมีอยู่ไหม? นี่เป็นส่วนใหญ่ (มันแบกน้ำหนักสูงสุดของการตรวจสอบอีเมลเดียวใดๆ) ไม่มีระเบียนหมายความว่าผู้รับไม่มีรายการที่จะตรวจสอบ ดังนั้นการแอบอ้างเปิดกว้าง ยังมีโหมดความล้มเหลวที่ละเอียดอ่อน: ถ้าโดเมนของคุณมีระเบียน SPF สองอันหรือมากกว่า กฎบอกว่าทั้งหมดไม่ถูกต้อง — ดังนั้นคุณไม่มี SPF เลย แม้ว่าดูเหมือนว่ามี

2. นโยบายเข้มงวดพอไหม? ระเบียนสามารถมีอยู่แต่ยังไม่มีประสิทธิภาพ การลงท้าย — กลไก “all” — เป็นคำสั่งให้ผู้รับ:

   • -all (hard fail) — ปฏิเสธสิ่งใดก็ตามที่ไม่อยู่ในรายการ แข็งแกร่งที่สุด คะแนนเต็ม
   • ~all (soft fail) + DMARC ที่ตั้งเป็น reject — การตั้งค่าที่แนะนำสมัยใหม่ การป้องกันเทียบเท่ากับ hard fail โดยไม่มีความเสี่ยงของเมลที่ forward ที่ถูกต้องตีกลับ คะแนนเต็ม
   • ~all + DMARC ที่ตั้งเป็น quarantine — ยอมรับได้ อ่อนแอกว่าเล็กน้อย
   • ~all คนเดียว (ไม่มีการบังคับ DMARC) — อ่อนแอ กับดักที่ธุรกิจหลายรายตกเข้าไปคิดว่าพวกมันได้รับการปกป้อง
   • ?all (neutral) — ไม่ให้การป้องกัน
   • +all — อันตรายอย่างแข็งขัน: มันบอกโลกว่าใครก็ตามอาจส่งในนามของคุณ อย่าใช้สิ่งนี้

ยังมีความล้มเหลวล่องหนอีกอัน: SPF อนุญาตให้ trigger ได้สูงสุด 10 DNS lookups เมื่อมันถูกประเมิน ซ้อน include: มากเกินไปและระเบียนเกินขีดจำกัดนั้น ณ จุดนั้นผู้รับถือว่าทั้งอันเสียหาย

สิ่งที่ “ดี” ดูเหมือน: ระเบียน SPF หนึ่งอันพอดี แสดงรายการทุกบริการที่ส่งเมลในนามของคุณอย่างถูกต้อง ลงท้ายด้วย -all (หรือ ~all คู่กับ DMARC ที่ p=reject) และอยู่ใต้ขีดจำกัด 10-lookup อย่างสบาย

วิธีแก้ไข (ฟรี ~10 นาที)

ส่งส่วนนี้ให้ผู้ที่จัดการโดเมนหรือเว็บไซต์ของคุณ — และสังเกตว่าการแก้ไขฟรี เป็นการเปลี่ยนแปลงการตั้งค่า DNS ไม่ใช่ผลิตภัณฑ์ที่คุณซื้อ

ขั้นที่ 1 — แสดงรายการทุกบริการที่ส่งอีเมลในนามของคุณ นี่คือส่วนที่คนทำผิด เขียนทั้งหมดออกมา: ผู้ให้บริการกล่องรับจดหมาย (Google Workspace, Microsoft 365, ฯลฯ) บวกกับเครื่องมือจดหมายข่าว CRM helpdesk แพลตฟอร์ม e-commerce app ออกใบแจ้งหนี้/บัญชี และระบบจอง

ขั้นที่ 2 — เผยแพร่ TXT record หนึ่งอัน ที่ root domain ของคุณ รวมบรรทัด “include” สำหรับ sender ทั้งหมดของคุณในระเบียนเดียว:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• SendGrid: include:sendgrid.net
• Mailchimp: include:servers.mcsv.net
• Zoho: include:zoho.eu (หรือ domain ที่เหมาะสมตามภูมิภาค)

ระเบียนรวมมีลักษณะเช่น:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

ขั้นที่ 3 — เริ่มอย่างปลอดภัย จากนั้นบังคับใช้ ในขณะที่คุณยืนยันว่ารายการ sender ของคุณครบถ้วน เผยแพร่ด้วย ~all (soft fail) เพื่อไม่มีอะไรที่ถูกต้องถูกบล็อกโดยบังเอิญ เมื่อคุณยืนยันว่าเมลแท้จริงทั้งหมดยังไหล เพิ่มความเข้มงวดเป็น -all (hard fail) — หรือดีกว่า เก็บ ~all และเพิ่ม DMARC policy ของ p=reject

ขั้นที่ 4 — ตรวจสอบให้แน่ใจว่าคุณมีระเบียน ONE อย่างแน่นอน ถ้ามีระเบียน SPF เก่าอยู่แล้ว แก้ไขอันนั้นแทนที่จะเพิ่มอันที่สอง

ขั้นที่ 5 — ดูจำนวน lookup ถ้าคุณมี sender หลายราย คุณสามารถเกิน 10-lookup limit บางผู้ให้บริการเสนอ “SPF flattening” หรือลบ sender ที่คุณไม่ใช้อีกต่อไป

ขั้นที่ 6 — ตรวจสอบโดเมนของคุณใหม่ เพื่อยืนยันว่ามันผ่านตอนนี้

ข้อผิดพลาดทั่วไป

• ระเบียน SPF สองอัน ความล้มเหลวที่เงียบที่สุดที่สุด การเพิ่มระเบียนใหม่แทนที่จะแก้ไขที่มีอยู่ทำให้ทั้งสองไม่ถูกต้อง ต้องมีหนึ่งอันพอดี
• หยุดที่ ~all และสมมติว่าเสร็จแล้ว Soft fail โดยไม่มี DMARC ข้างหลังเป็นจุดกึ่งกลางที่อ่อนแอ — มันดูกำหนดค่าแล้วแต่แทบไม่ปกป้องคุณ
• ลืม sender การเพิ่มความเข้มงวดเป็น -all ก่อนแสดงรายการ app ออกใบแจ้งหนี้ CRM หรือเครื่องมือจดหมายข่าวจะเริ่มบล็อกเมลของแท้ของคุณเอง แสดงรายการทุกอย่างก่อน
• เป่า 10-lookup limit include: แต่ละอันสามารถเชื่อมต่อไปยัง lookup เพิ่มเติม มากเกินไปและระเบียนถือว่าเสียหาย
• ใช้ +all สิ่งนี้อนุญาตให้อินเทอร์เน็ตทั้งหมดส่งในนามของคุณอย่างชัดเจน มันแย่กว่าไม่มีระเบียน อย่าเผยแพร่มัน

SPF อยู่ที่ไหนในแผนของคุณ

SPF เป็นรากฐาน แต่มันเป็นสามชั้น DKIM เพิ่มลายเซ็นการเข้ารหัสที่พิสูจน์ว่าข้อความไม่ถูกดัดแปลง และ DMARC คือคำสั่งที่ผูก SPF และ DKIM เข้าด้วยกันและบอกผู้รับว่าจะทำอะไรกับเมลที่ล้มเหลว — รวมถึงการบล็อกการแอบอ้างชื่อ “from” ที่มองเห็นที่ลูกค้าของคุณเห็น แก้ไข SPF ก่อน (มันเป็นชัยชนะที่เร็วที่สุดและแบกน้ำหนักมากที่สุด) จากนั้นเพิ่ม DKIM และ DMARC เพื่อปิดประตูอย่างสมบูรณ์

ตั้งค่าบนโฮสต์ของคุณ

ทีละขั้นตอนสำหรับผู้ให้บริการยอดนิยม:

• ตั้งค่า SPF บน GoDaddy
• ตั้งค่า SPF บน Namecheap
• ตั้งค่า SPF บน Cloudflare
• ตั้งค่า SPF บน Google Workspace
• ตั้งค่า SPF บน Microsoft 365
• ตั้งค่า SPF บน Squarespace
• ตั้งค่า SPF บน Wix
• ตั้งค่า SPF บน AWS Route 53
• ตั้งค่า SPF บน Hostinger
• ตั้งค่า SPF บน Porkbun
• ตั้งค่า SPF บน IONOS
• ตั้งค่า SPF บน Bluehost

สถานการณ์ทั่วไป

• SPF failing for your SaaS tools
• PermError: too many DNS lookups
• 'SPF record not found' but you have one
• SPF broke after switching provider
• Forwarded email fails SPF
• Contact-form emails going to spam

คำถามที่พบบ่อย