Sender Policy Framework (SPF): ชั้นการป้องกันในโครงสร้างพื้นฐานของอีเมล

คุณเคยมีคน (อย่างขี้เล่นหรือคิดร้าย) หยิบโทรศัพท์และส่งข้อความหาใครบางคนที่แอบอ้างเป็นคุณหรือไม่? รู้สึกไม่ค่อยดีเลยใช่ไหม? แม้ว่าคุณจะชี้แจงความจริงกับผู้รับแล้ว พวกเขาก็มักจะระมัดระวังข้อความทั้งหมดของคุณในอนาคต และคุณอาจจะระมัดระวังมากขึ้นอีกมากที่คุณปล่อยให้ใครยืมโทรศัพท์ของคุณ ความเชื่อใจถูกทำลาย

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

โชคดีที่เรารู้เคล็ดลับง่ายๆ ที่ไม่เป็นความลับในการปกป้องชื่อเสียงของแบรนด์คุณ เรียกว่า Sender Policy Framework (SPF) และเป็นตัวช่วยชีวิตชื่อเสียงของอีเมล

เมื่ออีเมลถูกส่งจากเซิร์ฟเวอร์หนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่ง จะใช้โปรโตคอลการถ่ายโอนเมลอย่างง่าย (SMTP) เพื่อรับข้อความจากผู้ส่งไปยังผู้รับ ในฐานะบริการ SMTP Twilio SendGrid ช่วยอำนวยความสะดวกในกระบวนการนี้

จุดอ่อนด้านความปลอดภัยประการหนึ่งในโครงสร้างพื้นฐานของอีเมลคือความสามารถของผู้ส่งหรือโฮสต์ใดๆ ในการระบุตัวตน และอีเมลของพวกเขา เป็นโดเมนใดๆ ที่พวกเขาต้องการ (เช่นเดียวกับที่ผู้คนสร้างบัญชี Twitter ของ Donald Trump จำนวน TONS ) ซึ่งทำให้ยากสำหรับผู้รับที่จะเชื่อว่าข้อความนั้นจริง ๆ แล้วมาจากใคร นอกจากนี้ยังทำให้ผู้ส่งรู้สึกไม่สบายใจที่จะรู้ว่าใครก็ตามที่นั่นสามารถส่งอีเมลจากโดเมนของตน และอาจสร้างความเสียหายต่อชื่อเสียงของแบรนด์ได้

ผู้รับสูญเสียความไว้วางใจในความถูกต้องของอีเมลและผู้ส่งเป็นผู้หลอกลวงที่หวาดระแวงกำลังวางตัวเป็นแบรนด์ของพวกเขา ไม่ดีสำหรับทุกคน! ส่วนหนึ่งของการแก้ปัญหาคือระเบียน SPF ที่จัดเก็บไว้ในระเบียน txt ใน DNS ในบทความนี้ เราจะมาสำรวจทุกสิ่งที่ SPF—จากสิ่งที่เป็นเพื่อค้นหาข้อผิดพลาดด้วยตัวคุณเอง เราจะครอบคลุมทั้งหมด

บันทึก SPF คืออะไร?

SPF ย่อมาจาก Sender Policy Framework เป็นวิธีการตรวจสอบสิทธิ์อีเมลที่ช่วยระบุเซิร์ฟเวอร์อีเมลที่ได้รับอนุญาตให้ส่งอีเมลจากโดเมนใดโดเมนหนึ่ง การใช้โปรโตคอลการตรวจสอบความถูกต้องนี้ ISP สามารถระบุได้ว่าเมื่อใดที่ผู้ปลอมแปลงและฟิชเชอร์พยายามปลอมแปลงอีเมลจากโดเมนของคุณเพื่อส่งอีเมลที่เป็นอันตรายถึงผู้ใช้ของคุณ

ด้วยค่า SPF ผู้รับจะรู้สึกมั่นใจว่าข้อความอีเมลที่ได้รับมาจากผู้ที่พวกเขาคาดหวัง และผู้ส่งสบายใจได้เพราะรู้ว่าฟิชเชอร์ไม่ได้หลอกลวงอีเมลหรือฟิชชิงผู้ชมจากแบรนด์ของตน

ในทางเทคนิคแล้ว ระเบียน SPF คือข้อความสั้นๆ ที่ผู้ดูแลระบบของโดเมนเพิ่มลงในระเบียน txt ระเบียน txt ถูกจัดเก็บไว้ใน DNS (ระบบชื่อโดเมน) ควบคู่ไปกับระเบียน A, PTR และ MX ระเบียน SPF จะมีลักษณะดังนี้:

“v=spf1 ip4:12.34.56.78 รวม:example.com -all”

SPF ทำงานอย่างไร

บรรทัดข้อความด้านบนใช้เพื่อบอกเซิร์ฟเวอร์ SMTP ที่ได้รับซึ่งโฮสต์ได้รับอนุญาตให้ส่งอีเมลจากโดเมนที่กำหนด

เร็กคอร์ด SPF มักจะได้รับการตรวจสอบตั้งแต่เนิ่นๆ ในการสนทนา SMTP ก่อนที่เนื้อความของข้อความจะถูกส่งออกไป เมื่อมีการพยายามส่งข้อความ การเชื่อมต่อ TCP จะเปิดขึ้นระหว่างผู้ส่งและเซิร์ฟเวอร์ที่รับ

เมื่อสร้างการเชื่อมต่อแล้ว จะมีการออกคำสั่ง HELO ซึ่งบอกเซิร์ฟเวอร์ที่รับว่าโดเมนใดพยายามส่งเมล ตามด้วยคำสั่ง MAIL FROM ที่บอกเซิร์ฟเวอร์ที่รับว่าข้อความนั้นมาจากที่อยู่อีเมลใด โดเมนที่พบในคำสั่ง MAIL FROM (หรือเรียกอีกอย่างว่าเส้นทางซองจดหมายจากและส่งคืน) คือโดเมนที่ใช้สำหรับการตรวจสอบระเบียน SPF

สมมติว่าได้รับข้อความแล้ว และที่อยู่ MAIL FROM คือ [email protected] เซิร์ฟเวอร์ที่รับจะตรวจสอบระเบียน DNS สาธารณะสำหรับ example.com และค้นหาระเบียน TXT ที่ขึ้นต้นด้วย v=spf1 หากไม่มีระเบียน TXT ที่ขึ้นต้นด้วย v=spf1 การตรวจสอบสิทธิ์จะผ่าน หากมีระเบียน TXT มากกว่าหนึ่งรายการที่มี v=spf1 ข้อผิดพลาดอาจเกิดขึ้น

สมมติว่าพบแล้ว และดูเหมือนว่าตัวอย่างของเราเมื่อก่อน:

“v=spf1 ip4:12.34.56.78 รวม:example.com -all”

เซิร์ฟเวอร์ที่รับจะตรวจสอบเพื่อดูว่าที่อยู่ IP ของไคลเอ็นต์ SMTP ที่พยายามส่งข้อความนั้นรวมอยู่ในระเบียน SPF หรือไม่ หากที่อยู่ IP อยู่ในรายการ ข้อความจะผ่านการตรวจสอบสิทธิ์ SPF

สิ่งสำคัญ: ทำลายสถิติ SPF แต่ละชิ้น

ระเบียน SPF ประกอบด้วยกลไกต่างๆ ได้แก่:

รวม

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

อา

ตามด้วยชื่อโดเมน อย่างไรก็ตาม ในกรณีนี้ SPF จะตรวจสอบที่อยู่ IP ที่เชื่อมโยงกับโดเมนนั้น หากตรงกับ IP ของผู้ส่ง ก็จะผ่าน และการตรวจสอบ SPF จะหยุดลง ถ้าไม่อย่างนั้นก็ย้ายไปที่กลไกถัดไป

MX

คล้ายกับ “เอ” ตามด้วยชื่อโดเมนเสมอ หากโดเมนที่ระบุแก้ไขเป็นที่อยู่ IP ของไคลเอ็นต์ที่ส่ง การตรวจสอบสิทธิ์จะผ่าน และการตรวจสอบ SPF จะเสร็จสิ้น ถ้าไม่อย่างนั้นก็ย้ายไปที่กลไกถัดไป

IP4 และ IP6

ตามด้วยที่อยู่ IP หรือช่วง CIDR เฉพาะเสมอ หาก IP ของไคลเอนต์ที่ส่งแสดงอยู่หลังกลไก IP4 หรือ IP6 การรับรองความถูกต้องจะผ่านและการตรวจสอบ SPF จะเสร็จสิ้น ถ้าไม่อย่างนั้นก็ย้ายไปที่กลไกถัดไป

PTR

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

เปลี่ยนเส้นทาง

แม้ว่าในทางเทคนิคจะเป็นตัวดัดแปลง ไม่ใช่กลไก แต่สิ่งนี้จะช่วยให้ผู้ดูแลระบบของโดเมนชี้โดเมนไปยังระเบียน SPF ของโดเมนอื่นได้ หากใช้ฟังก์ชัน REDIRECT จะไม่มีกลไกอื่นรวมอยู่ในระเบียน SPF รวมถึงกลไก "ทั้งหมด" บันทึกการเปลี่ยนเส้นทางตัวอย่าง: “v=spf1 redirect:example.com”

กลไก "INCLUDE" "A" "MX" "PTR" "EXISTS" และ "REDIRECT" ล้วนต้องการการค้นหา DNS ดังนั้นจึงมีได้ไม่เกิน 10 รายการ ดูเหมือนง่ายเพียงพอ แต่ยังรวมถึงการค้นหา DNS ที่ซ้อนกันด้วย ซึ่งหมายความว่า "INCLUDE" ที่นำไปสู่ระเบียน SPF อื่นที่มีกลไก "INCLUDE" อีกสองกลไกจะนับเป็นการค้นหา DNS สามครั้ง พวกเขาเพิ่มขึ้นอย่างรวดเร็ว!

แล้วลูกค้า Twilio SendGrid ล่ะ?

ผู้ส่งส่วนใหญ่ของเราตั้งค่า CNAME ที่ชี้โดเมนที่ส่งของตนไปที่ sendgrid.net ซึ่งหมายความว่าเซิร์ฟเวอร์ที่รับจะเห็น CNAME ที่ชี้ไปที่ sendgrid.net และตรวจสอบระเบียน SPF นั้นแทน ดังนั้นอย่าแปลกใจถ้าระเบียน SPF ส่วนใหญ่ที่คุณค้นหาเหมือนกัน

สำหรับคำถามเฉพาะเพิ่มเติมของ Twilio SendGrid โปรดดูที่หน้าเอกสาร Sender Policy Framework ของเรา มีคำตอบเพิ่มเติมสำหรับคำถามและสถานการณ์ทั่วไป

ฉันจะตรวจสอบบันทึก SPF ของฉันได้อย่างไร

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

ระเบียน SPF แต่ละรายการจะแตกต่างกันเล็กน้อย แต่คุณควรตรวจสอบเพื่อให้แน่ใจว่าถูกต้อง ต่อไปนี้คือเครื่องมือสามอย่างที่สามารถช่วยตรวจสอบบันทึกของคุณ:

• เครื่องมือทดสอบ SPF ของ Scott Kitterman : ตรวจสอบว่ามีระเบียน SPF สำหรับโดเมนของคุณแล้วหรือไม่ ตรวจสอบความถูกต้องหรือทดสอบประสิทธิภาพ
• OpenSPF.org : ตรวจสอบชุดของแบบฟอร์มและผู้ทดสอบทางอีเมล์
• การตรวจสอบระเบียน SPF: การตรวจสอบระเบียน SPF ทำหน้าที่เป็นการค้นหาระเบียน SPF และตัวตรวจสอบความถูกต้อง จะค้นหาระเบียน SPF สำหรับชื่อโดเมนที่สอบถามและเรียกใช้การทดสอบวินิจฉัยกับระเบียน โดยเน้นข้อผิดพลาดที่อาจส่งผลต่อความสามารถในการส่งอีเมล
• ตัวช่วยสร้าง SPF : ตัวช่วยสร้าง SPF เป็นเครื่องมือสร้างระเบียน SPF บนเบราว์เซอร์ กรอกแบบฟอร์มและเว็บไซต์จะสร้างระเบียน SPF ให้กับคุณ

ทำให้กรอบนโยบายผู้ส่งมีความสำคัญ

พูดง่ายๆ ก็คือ ข้อความอีเมลที่เป็นอันตรายทำร้ายธุรกิจของคุณและทำให้ช่องอีเมลเสื่อมคุณภาพ เมื่อฟิชเชอร์เห็นโดเมนที่มีการป้องกัน Sender Policy Framework พวกเขาจะมีแนวโน้มมากขึ้นที่จะไปยังเป้าหมายที่ง่ายกว่า แม้ว่า SPF จะไม่ป้องกันสแปม แต่ก็สามารถทำหน้าที่เป็นตัวยับยั้งและทำให้คุณเสี่ยงต่อการถูกโจมตีน้อยลง และใครไม่ต้องการสิ่งนั้นใช่ไหม นั่นเป็นเหตุผลที่เราสนับสนุนให้ไคลเอ็นต์อีเมลทั้งหมดสร้างระเบียน SPF

เมื่อรวมกับ Sender ID, DKIM และ DMARC แล้ว SPF จะมอบการรักษาความปลอดภัยอีเมลในระดับพิเศษที่จะสนับสนุนผู้ใช้ของคุณได้ดียิ่งขึ้นด้วยการช่วยให้ ISP ระบุอีเมลของคุณได้อย่างเหมาะสมและในทางกลับกันก็คือผู้ส่งอีเมลขยะ

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ SPF และโปรโตคอลการตรวจสอบสิทธิ์อื่นๆ ให้ดาวน์โหลด SendGrid Email Infrastructure Guide