ทำไมอีเมลที่คุณส่งต่อให้ตัวเองถึงลงเอยในสแปม

ตั้งค่าการส่งต่ออัตโนมัติจากบัญชีเก่าไปยังบัญชีใหม่ และจดหมายบาง封จะหายไปอย่างเงียบๆ เข้าไปในสแปม — ไม่ใช่เพราะผู้ให้บริการของคุณเสีย แต่เพราะการส่งต่อเขียนใหม่ว่าใครเป็นผู้ส่งข้อความ โดยไม่เขียนใหม่หลักฐานการเข้ารหัส SPF ตรวจสอบเซิร์ฟเวอร์ที่ผิด ผลการตัดสินใจ DMARC พลิกไปสู่ความล้มเหลว และอีเมลที่ถูกต้องตามกฎหมายที่คุณส่งให้ตัวเองจะถูก隔离 วิธีแก้ไขมีชื่อ: ARC ที่กำหนดไว้ใน RFC 8617 ย้อนกลับไปในปี 2019

ทำไมการส่งต่อทำให้อีเมลของฉันล้มเหลว SPF

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

ตอนนี้ส่งต่อใบเสร็จนั้นจาก Gmail ของคุณไปยังที่อยู่ใหม่ เซิร์ฟเวอร์ของ Google ส่งต่อไปข้างหน้า เซิร์ฟเวอร์รับสุดท้ายจะรันการตรวจสอบ SPF และถาม: Google ได้รับอนุญาตให้ส่งสำหรับ bank.com หรือไม่ ไม่ใช่ SPF ล้มเหลว เอกสารประกอบของ Google Workspace เองแสดงให้เห็นอย่างชัดเจน — อีเมลที่ส่งต่อมาล้มเหลว SPF เพราะเซิร์ฟเวอร์ส่งต่อไม่ได้อยู่ในระเบียน SPF ของโดเมนดั้งเดิม ไม่มีการปลอมแปลง การตรวจสอบเพียงแต่มองที่ฮอปที่ผิด

ดังนั้นทำไมจึงส่งไปยังสแปม

DMARC SPF ที่ล้มเหลวอย่างเดียวนั้นเคยรอดพ้นไป DMARC เปลี่ยนมันให้เป็นผลการตัดสินใจ DMARC ผูกสัมพันธ์ SPF และ DKIM เข้าด้วยกัน และบอกผู้รับว่าต้องทำอย่างไรเมื่อทั้งสองล้มเหลว: ไม่มีอะไร隔离 หรือปฏิเสธ ในปี 2024 ผู้ส่งขนาดใหญ่ไม่มีตัวเลือก — Google และ Yahoo เริ่มต้นกำหนดให้ DMARC สำหรับใครก็ตามที่ส่งข้อความมากกว่า 5,000 ข้อความต่อวันให้ผู้ใช้ของพวกเขา

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

ARC คืออะไร และมันแก้ไขปัญหานี้ได้จริงหรือไม่

ARC — Authenticated Received Chain, RFC 8617 — ให้ผู้ส่งต่อที่ซื่อสัตย์ได้การรับรองว่าอีเมลผ่านการตรวจสอบสิทธิ์ ก่อน ที่มันสัมผัสมัน เซิร์ฟเวอร์ส่งต่อจะประทับตราข้อความด้วยระเบียนที่ปิดล็อกกล่าวว่า "เมื่อสิ่งนี้ถึงฉัน SPF และ DKIM ถูกต้อง — เชื่อใจคำพูดของฉันสำหรับขาที่คุณไม่สามารถตรวจสอบได้" ผู้รับสุดท้าย หากเชื่อถือผู้ส่งต่อนั้น สามารถแทนที่ DMARC ล้มเหลวและส่งมอบได้

จุดบกพร่องอยู่ในคำว่า "หากเชื่อถือ" ARC ไม่ใช่รหัสผ่าน มันคือระบบชื่อเสียง ผู้รับชั่งน้ำหนักว่า ARC sealer นั้นเป็นตัวดำเนินการที่รู้จักและประพฤติตนดี Google ทั้งประทับตรา ARC headers และให้เกียรติจากผู้ส่งที่มันเชื่อถือ ซึ่งเป็นเหตุผลว่าทำไมการส่งต่อ Gmail-to-Gmail มักจะรอดพ้นไป ในขณะที่การส่งต่อผ่านรีเลย์มหาวิทยาลัยบางแห่งไม่รอดพ้น

หากคุณรัน forwarding ด้วยตัวเอง สองการเคลื่อนไหวที่เป็นรูปธรรมจะช่วยได้ ใช้ Server-Side Redirect / SRS-style rewriting หากโฮสต์ของคุณมี ซึ่งเขียนใหม่ผู้ส่งซองจดหมายเพื่อให้การตรวจสอบ SPF เทียบกับตัวส่งต่อ ของคุณ แทนโดเมนดั้งเดิม และเลือกการส่งต่อระหว่างผู้ให้บริการที่ทั้งคู่รองรับ ARC ถ้าคุณกำลังรวมบัญชีและต้องการให้ปลายทางเพียงแค่จัดการกับความยุ่งเหยิงการตรวจสอบสิทธิ์เพื่อคุณ นั่นคือท่อประปาอย่างแม่นยำที่ แพลตฟอร์มอีเมล AI ถูกสร้างมาเพื่อดูดซับ

เมื่อไหร่ควรหยุดตำหนิผู้ให้บริการของฉัน

เมื่อรูปแบบคือ "เฉพาะอีเมลที่ส่งต่อล้มเหลว" ผู้ให้บริการกำลังทำงานได้อย่างถูกต้อง — โปรโตคอลคือปัญหา นี่คือสัญญาณ: เปิดหัวข้อของข้อความที่หายไปและมองหาบรรทัด Authentication-Results ถ้าคุณเห็น spf=fail พร้อมกับการส่ง IP ที่อยู่กับผู้ส่งต่อแทนที่จะเป็นผู้ส่งต้นฉบับ นั่นคือ SPF ที่ตรวจสอบฮอปที่ผิด ถ้า dkim=fail ปรากฏบนอีเมลที่ไปผ่านรายชื่อหรือรีเลย์ที่แก้ไขข้อความ นั่นคือลายเซ็นที่บิดเบี้ยว ไม่ใช่การปลอมแปลง

ความจริงที่ไม่สบายใจคือการตรวจสอบสิทธิ์ของอีเมลถูกเชื่อมต่อ ชั้นต่อชั้น ในสองทศวรรษต่อระบบที่ไม่เคยสมมติว่าใครจะโกหก SPF มาในปี 2006 DKIM ในปี 2007 DMARC ในปี 2015 ARC ในปี 2019 — แต่ละอันแพทช์รูที่อันสุดท้ายเปิด การส่งต่อคือจุดต่อที่ทั้งสี่คนสัมผัสกัน และกล่องจดหมายของคุณคือจุดที่คุณรู้สึกถึงความเสียดสี