Defaults.Exposed › การแก้ไข › Guides

อีเมลที่ส่งต่อล้มเหลว SPF — ทำไมคุณไม่สามารถแก้ไขได้ และอะไรที่ใช้งานได้จริง (2026)

เผยแพร่ 2026-07-08

ตัวเลข ณ วันที่ 2026-06-29 · ระเบียบวิธี v7 ข้อมูลสำมะโนรวมทั่ว 261 ล้านโดเมนที่ได้รับการให้คะแนน ดู วิธีที่เราให้คะแนน

คุณไม่สามารถทำให้ SPF ผ่านสำหรับอีเมลที่ส่งต่อได้ — การส่งต่อทำลาย SPF โดยการออกแบบ และการแก้ไขที่ซื่อสัตย์คือ DKIM ที่จัดตำแหน่ง ซึ่งรอดชีวิตจากการส่งต่อ ขนาดคือสำมะโนกว้าง: 7,355,985 ของ 138,927,207 โดเมนที่เผยแพร่ SPF อนุญาต forwarding include ของ Namecheap เพียงอย่างเดียว โดยมีส่วนแบ่ง strict-SPF <0.1% ตามสำมะโน Defaults.Exposed ของ 261 ล้านโดเมน

ด้านล่าง: ทำไมระเบียน SPF ที่คุณเขียนไม่สามารถรอดชีวิตจากการส่งต่อ ทำไม SRS และ ARC ไม่ใช่เครื่องมือที่คุณควบคุม และการแก้ไขที่คงอยู่ — การลงนาม DKIM ด้วยโดเมนของคุณเองเป็นการผ่าน DMARC ของคุณ — บวกกับกรณีหนึ่งที่ทำลาย DKIM ด้วย (mailing list ที่เขียน message ใหม่) และจะทำอย่างไรกับกากนั้น

ทำไมการส่งต่อถึงทำลาย SPF?

Receiver ประเมิน SPF กับ โดเมน Return-Path (RFC5321.MailFrom) ไม่ใช่ header From เมื่อคุณส่งตรง IP ของเซิร์ฟเวอร์ของคุณอยู่ใน SPF record และการตรวจสอบผ่าน เมื่อผู้รับของคุณส่งต่ออีเมลอัตโนมัติ — ไปยัง Gmail ส่วนตัว ผ่าน alias ของมหาวิทยาลัย ผ่านผลิตภัณฑ์การส่งต่อของ registrar — เซิร์ฟเวอร์ของ forwarder ส่งซ้ำมัน มักเก็บโดเมนของคุณบน Return-Path ผู้รับสุดท้ายตอนนี้ถาม: เซิร์ฟเวอร์การส่งต่อนี้ได้รับอนุญาตในระเบียน SPF ของคุณ หรือไม่?

มันไม่ใช่ และมันจะไม่เป็นเลย: คุณไม่ได้เลือก forwarder คุณไม่รู้ว่ามันมีอยู่ และข้อความเดียวกันที่ส่งต่อผ่านบริการอื่นพรุ่งนี้จะล้มเหลวจาก IP อื่น SPF ตอบคำถามหนึ่ง — “IP นี้มาจากเซิร์ฟเวอร์ที่โดเมน Return-Path อนุญาตหรือไม่?” — และสำหรับอีเมลที่ส่งต่อคำตอบที่แท้จริงคือ ไม่ การล้มเหลวคือ SPF ทำงานตามที่ระบุ ไม่ใช่ระเบียนของคุณที่ผิด

สำมะโนแสดงให้เห็นว่าเส้นทางนี้กระแสหลักแค่ไหน: 7,355,985 โดเมนอนุญาต forwarding include ของ Namecheap (spf.efwd.registrar-servers.com) — ผลิตภัณฑ์การส่งต่อของผู้ให้บริการรายเดียว ดึงจาก 139 ล้าน SPF publisher — โดยมีส่วนแบ่ง strict-SPF <0.1% และมีเพียง 0.2% ที่บังคับใช้ DMARC template แบบ soft นั้นไม่ใช่ความประมาทเลินเล่อ: การส่งต่อคือจุดที่ -all แบบ strict ยิงพลาด และผู้ให้บริการที่ผลิตภัณฑ์ คือ การส่งต่อจัดส่งตามนั้น เรื่องราว qualifier เต็มรูปแบบอยู่ใน รายงาน ~all เทียบกับ -all ของเรา และภาพต่อผู้ให้บริการอยู่ใน ผู้ให้บริการอีเมลรายใดให้ SPF ที่แข็งแกร่งที่สุด

ฉันไม่สามารถเพิ่ม IP ของ forwarder ในระเบียน SPF ของฉันได้หรือ?

ไม่ — และเหตุผลคือทั้งบทความ:

1. คุณไม่สามารถระบุ forwarder ได้ ผู้รับใดๆ ที่ไหนก็ได้สามารถส่งต่ออีเมลของคุณผ่านบริการใดๆ ระเบียน SPF ของคุณจะต้องระบุเซิร์ฟเวอร์ที่คุณไม่สามารถรู้ล่วงหน้าได้
2. การระบุพวกมันจะเอาชนะจุดประสงค์ บริการส่งต่อขนาดใหญ่ส่งอีเมลสำหรับลูกค้าหลายล้านราย ใส่ช่วงของพวกมันในระเบียนของคุณและทุกข้อความที่ผู้ใช้รายใดรายหนึ่งส่งต่อ — รวมถึงของ spoofer — ผ่าน SPF ในฐานะคุณ

ตรรกะเดียวกันตัด qualifier ที่ “ทำให้การส่งต่อทำงาน” ออก: qualifier ไม่ใช่เหตุผลที่อีเมลที่ส่งต่อล้มเหลว และเมื่อ DMARC เล่นบทบาทมันเปลี่ยนแปลงน้อยกว่าที่คู่มือส่วนใหญ่อ้าง — ดู ข้อมูล qualifier ระเบียนไม่ใช่คันโยกที่นี่ หยุดดึงมัน

แล้ว SRS และ ARC — พวกมันไม่แก้ไขการส่งต่อหรือ?

พวกมันจัดการกับมัน — แต่ไม่มีอันไหนเป็นของคุณที่จะ deploy:

ข้อมูลและสถานะกลไก ณ วันที่ 2026-06-29

SRS ทำให้ปัญหา SPF ของ forwarder หายไป ไม่ใช่ของคุณ: การเขียน Return-Path ใหม่เปลี่ยน SPF ของใครที่ถูกตรวจสอบ ในขณะที่ header From ของคุณ — โดเมนที่ DMARC ปกป้อง — ไม่ได้รับผลกระทบ ARC เป็นการตัดสินใจความเชื่อถือระหว่างผู้ดำเนินการโครงสร้างพื้นฐาน ถ้าคู่มือบอกให้คุณ “implement SRS” ในฐานะเจ้าของโดเมน มันสับสนคุณกับผู้ให้บริการส่งต่อ

ฉันจะทำให้อีเมลรอดชีวิตจากการส่งต่อได้อย่างไร?

ทำให้ DKIM ที่จัดตำแหน่งกับโดเมนของคุณเป็นการผ่าน DMARC ของคุณ ลายเซ็น DKIM คือการเข้ารหัสลับที่อยู่ใน header ข้อความ: มันตรวจสอบที่ไหนก็ตามที่ข้อความลงเอย มีกี่เซิร์ฟเวอร์ส่งต่อมา ตราบใดที่เนื้อหาที่ลงนามไม่ถูกแก้ไข DMARC ต้องการเพียง หนึ่ง การผ่านที่จัดตำแหน่ง — SPF หรือ DKIM — ดังนั้นเมื่อการส่งต่อฆ่าขา SPF DKIM ที่จัดตำแหน่งยังคงทำให้ข้อความยืนยันตัวตน

1. สแกนฟรีที่ defaults.exposed ก่อนแตะ DNS มันแสดงว่าคุณมี DKIM หรือไม่ ว่ามันลงนามด้วย โดเมนของคุณ และ DMARC ของคุณอยู่ที่ไหน — เพื่อให้คุณแก้ไขช่องว่างจริงแทนที่จะต่อสู้กับระเบียน SPF ของคุณ
2. ยืนยันว่าการส่งต่อเป็นปัญหาของคุณจริงๆ ใน header Authentication-Results ของข้อความที่ได้รับผลกระทบ อีเมลส่งตรงผ่าน SPF ในขณะที่สำเนาที่ส่งต่อล้มเหลวจาก IP ของบริการส่งต่อ ถ้า SPF และ DKIM ผ่านแต่ DMARC ยังล้มเหลว คุณมีปัญหาการจัดตำแหน่งแทน — ดู DMARC ล้มเหลวแต่ SPF และ DKIM ผ่าน
3. เปิดใช้งานการลงนาม DKIM ด้วยโดเมนของคุณเอง ที่ทุกบริการส่ง — ผู้ให้บริการ mailbox ก่อน จากนั้น ESP และ sender ที่ทำธุรกรรม ค่าเริ่มต้นของผู้ให้บริการมักลงนามด้วยโดเมนของผู้ให้บริการ ซึ่งไม่จัดตำแหน่ง คุณต้องการ d=yourdomain เริ่มที่ วิธีแก้ไข DKIM พร้อม click-path สำหรับ Google Workspace และ Microsoft 365
4. ตรวจสอบการจัดตำแหน่ง ไม่ใช่แค่การผ่าน โดเมน d= ในลายเซ็นต้องตรงกับโดเมน From ของคุณ; dkim=pass บนโดเมนของคนอื่นไม่ทำอะไรสำหรับ DMARC ของคุณ
5. ทิ้งระเบียน SPF ของคุณไว้คนเดียว เก็บมันให้ถูกต้องสำหรับอีเมลส่งตรงของคุณ — มันยังคงยืนยันตัวตน traffic ส่วนใหญ่ของคุณและยังคงเป็นขาที่สองของ DMARC ของคุณ เพียงแค่หยุดพยายามทำให้มันครอบคลุม forwarder
6. สแกนใหม่ จากนั้น stage การบังคับใช้ DMARC โดยตั้งใจ — ส่วนถัดไป และ คู่มือ rollout p=none ไปสู่ p=reject

การรวมกันนี้ — SPF บวก DMARC ที่บังคับใช้บน DKIM ที่จัดตำแหน่ง — คือ pattern ที่พิสูจน์การส่งต่อ และมันหายาก: ของ 77.5 ล้านโดเมนที่เผยแพร่ ~all มีเพียง 9.2% (7,116,774) ที่สนับสนุนด้วยนโยบาย DMARC ที่บังคับใช้ และเพียง 3.87% ของ 261 ล้านโดเมนที่ได้รับการให้คะแนน (10,092,481) ที่ทำ triad SPF + DKIM + enforced-DMARC ครบ ตามสำมะโน (2026-06-29)

แล้ว mailing list ที่เขียน message ใหม่?

เส้นทางการส่งต่อหนึ่งที่ DKIM ที่จัดตำแหน่งไม่รอดชีวิต: mailing list ที่ แก้ไข ข้อความ — tag หัวเรื่อง [list-name], footer unsubscribe, attachment ที่ถูกลบ เปลี่ยน content ที่ลงนามและ body hash ไม่ตรงอีกต่อไป ดังนั้น DKIM ล้มเหลวด้วย (dkim=fail: body hash did not verify คือคู่มือของความล้มเหลวนั้น) ตอนนี้ขา DMARC ทั้งสองตาย และเฉพาะ list เท่านั้นที่สามารถบรรเทาได้ (From rewriting, ARC sealing)

กากนี้คือสิ่งที่การบังคับใช้ DMARC แบบแบ่งระยะมีไว้สำหรับ การย้ายผ่าน p=quarantine ด้วย pct ramp ในขณะที่คุณดูรายงาน aggregate แสดงว่าอีเมลจริงของคุณเท่าไรที่ไหลผ่าน rewriting list ก่อนที่ นโยบาย p=reject จะเริ่ม bounce มัน อย่าข้ามไป reject บนโดเมนที่ผู้ใช้อาศัยอยู่กับ mailing list; อย่าหยุดที่ p=none ตลอดไปเหมือนกัน คู่มือ rollout แบบแบ่งระยะ เดิน ramp

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

การส่งต่อทำลาย DKIM ด้วยหรือไม่? การส่งต่อแบบธรรมดา ไม่: ลายเซ็นเดินทางพร้อมข้อความและตรวจสอบที่ผู้รับสุดท้าย DKIM ล้มเหลวเฉพาะเมื่อ content ที่ลงนามถูกแก้ไขระหว่างส่ง — tag หัวเรื่องของ mailing list และ footer เป็นกรณีคลาสสิก — ซึ่งเป็นเหตุผลที่กากของ list ถูกจัดการโดย DMARC policy staging ไม่ใช่สิ่งใดใน DNS

ฉันควรเปลี่ยนจาก -all เป็น ~all เพื่อให้การส่งต่อหยุดล้มเหลวหรือไม่? การเปลี่ยน qualifier จะไม่ทำให้ forwarder ผ่าน — มันไม่ใช่เหตุผลที่พวกมันล้มเหลว มันน่าบอกว่า forwarding include ของ Namecheap, 7,355,985 โดเมนและประชากรเฉพาะส่งต่อที่ใหญ่ที่สุดของสำมะโน (2026-06-29) จัดส่งด้วยส่วนแบ่ง strict-SPF <0.1%: soft SPF เป็น template ที่ ถูกต้อง สำหรับผลิตภัณฑ์ส่งต่อ ดู รายงาน ~all เทียบกับ -all สำหรับสิ่งที่ qualifier เปลี่ยนจริงๆ

ทำไมอีเมลของฉันผ่าน SPF เมื่อส่งตรงแต่ล้มเหลวเมื่อมีคนส่งต่อ? Receiver ตรวจสอบว่า IP ของเซิร์ฟเวอร์ส่งสุดท้าย ได้รับอนุญาตโดยระเบียน SPF ของโดเมน Return-Path ของคุณหรือไม่ ส่งตรง: เซิร์ฟเวอร์ของคุณ ในระเบียนของคุณ ผ่าน ส่งต่อ: เซิร์ฟเวอร์ของ forwarder ไม่อยู่ในระเบียนของคุณ ล้มเหลว ระเบียนของคุณไม่เปลี่ยน — IP ที่ส่งเปลี่ยน

ฉันสามารถตั้งค่า SRS เพื่อแก้ไขนี้ได้หรือไม่? เฉพาะเมื่อคุณ เป็น forwarder SRS ทำงานบนเซิร์ฟเวอร์ที่ทำการส่งต่อ และแม้แต่ที่มันทำงาน การผ่าน SPF ที่ได้เป็นของโดเมนของ forwarder และไม่จัดตำแหน่งกับ From ของคุณ — DMARC ของคุณยังต้องการขา DKIM

SPF ไม่มีประโยชน์ถ้าการส่งต่อทำลายมันอยู่ดีหรือไม่? ไม่ อีเมลส่วนใหญ่ถูกส่งตรงซึ่ง SPF ทำงานตามที่ตั้งใจไว้ และมันยังคงเป็นขาหนึ่งของสอง DMARC ของคุณ ของ 261,086,232 โดเมนในสำมะโน (2026-06-29) 138,927,207 เผยแพร่ SPF — เก็บของคุณให้ถูกต้องผ่าน หน้าแก้ไข SPF และปล่อยให้ DKIM รับกากที่ส่งต่อ

ส่งรายงานให้เจ้าของ

หากคุณแก้ไขปัญหานี้สำหรับลูกค้าหรือนายจ้างของคุณ ปิดลูปด้วยหลักฐาน เมื่อ DKIM ด้วยโดเมนที่กำหนดเอง live และ DMARC ถูก staged รันใหม่ การสแกนฟรี และส่งต่อรายงานที่ได้รับการให้คะแนนให้เจ้าของธุรกิจ: มีวันที่ ภาษาธรรมดา แสดงว่าโดเมนยังคงยืนยันตัวตนแม้เมื่ออีเมลถูกส่งต่อ นั่นคือสิ่งประดิษฐ์สำหรับการต่ออายุประกันภัยไซเบอร์และแบบสอบถามผู้จัดหาถัดไป — ก่อนและหลังที่มีการบันทึก ไม่ใช่ “ฉันเปิดบางอย่าง”

ตรวจสอบโดเมนของคุณ → · DMARC ล้มเหลวแต่ SPF และ DKIM ผ่าน → · แก้ DKIM → · วิธีที่เราให้คะแนน → · ข้อมูลรวมเท่านั้น ข้อมูลถูกจัดเก็บและประมวลผลในสหภาพยุโรป