Defaults.Exposed

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

SPF หยุดทำงานหลังจากเปลี่ยน Email Provider — การแก้ไขหลัง Migration (2026)

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

ตัวเลข ณ 2026-06-29 · methodology v7. ข้อมูล census รวมจากโดเมน 261 ล้านโดเมน ดู วิธีที่เราให้คะแนน

SPF มักเสียหายหลัง email-provider switch เพราะ record ของ provider ใหม่ถูกเพิ่มควบคู่กับอันเก่า v=spf1 records สองรายการคือ permanent error — SPF เป็นโมฆะทั้งหมด 1,013,416 โดเมน — ประมาณหนึ่งในทุก 138 ที่พยายาม SPF — อยู่ในสถานะนั้น ตาม census ของ Defaults.Exposed จากโดเมน 261 ล้านโดเมน รวมมันเป็นหนึ่ง

การแก้ไขใช้เวลาประมาณสิบนาที: สแกนโดเมนเพื่อดูว่า migration ทิ้งอะไรไว้ แสดง SPF record ทุกรายการที่ authoritative nameservers ของคุณ รวมมันเป็น record เดียวที่รวมเฉพาะ provider ใหม่ของคุณ และตรวจสอบใหม่ด้วย dig คู่มือนี้แนะนำแต่ละขั้นตอน บวก DKIM และการตรวจสอบ nameserver ที่ migrations ส่วนใหญ่ลืม

ทำไม SPF ถึงเสียทันทีหลัง migration?

เพราะคู่มือการตั้งค่าของ provider ใหม่บอกว่า “เพิ่ม TXT record นี้” — และคุณทำ ควบคู่กับอันเก่า นั่นคือสิ่งเดียวที่มาตรฐาน SPF ไม่อนุญาต RFC 7208 (§3.2, error result ที่กำหนดใน §4.5) อนุญาตเพียงหนึ่ง v=spf1 record ต่อโดเมน ผู้รับที่พบสองรายการขึ้นไปต้องส่งคืน PermError แทนที่จะเดาว่าอันไหนเป็น authoritative PermError หมายความว่า SPF เป็นโมฆะ: ไม่ใช่ record เก่า ไม่ใช่อันใหม่ ไม่มี SPF เลย

และมันไม่หยุดแค่นั้น DMARC ถือ PermError ว่าเป็น fail ในขา SPF ดังนั้นอีเมลของคุณตอนนี้ขึ้นอยู่กับ DKIM ทั้งหมด ถ้า DKIM ของ provider ใหม่ยังไม่ได้ตั้งค่าด้วย — พบบ่อยกลางๆ migration — คุณกำลังส่งโดยไม่มีการยืนยันตัวตนพอดีตอนที่คุณเปลี่ยนโครงสร้างพื้นฐาน ซึ่งเป็นช่วงที่ผู้รับตรวจสอบคุณอย่างเข้มงวดที่สุด

นี่คือ copy-paste ที่ทำให้การป้องกันเป็นโมฆะเมื่อคุณเปลี่ยน providers และไม่ใช่เรื่องหายาก: 1,013,416 โดเมนเผยแพร่ SPF records สองรายการขึ้นไปตอนนี้ — ประมาณหนึ่งในทุก 138 ของประชากร 139 ล้านรายที่พยายาม SPF ตาม census ของ Defaults.Exposed จากโดเมน 261 ล้านโดเมน (ข้อมูล ณ 2026-06-29) ตัวเลขครบถ้วนบน two-records trap มี report ของตัวเอง หน้านี้คือการแก้ไขขั้นตอน

Migration ทิ้งอะไรไว้?

ห้าสิ่งที่ค้างอยู่ทำให้เกิด SPF failure หลัง migration เกือบทุกครั้ง ตรวจสอบในลำดับนี้:

สิ่งที่ค้างอยู่สิ่งที่คุณเห็นการแก้ไข
SPF record เก่ายังอยู่ใน DNS ควบคู่กับอันใหม่ (v=spf1 records สองรายการ)Checkers รายงาน “multiple SPF records” หรือ PermError; SPF หยุดทำงานทั้งหมดรวมเป็น record เดียว ลบส่วนที่เหลือ — ขั้นตอนด้านล่าง
include: ของ provider เก่าอยู่ใน record เดียวSPF ทำงาน แต่คุณใช้ DNS lookups และเซิร์ฟเวอร์ของ provider เก่ายังส่งในนามคุณได้ลบมันเมื่ออีเมล drain จากระบบเก่าเสร็จ
ไม่ได้เพิ่ม include: ของ provider ใหม่อีเมลจาก provider ใหม่ไม่ผ่าน SPF ที่ผู้รับเพิ่มลงใน record เดียวที่มีอยู่ — ไม่เคยเป็น record ใหม่
DKIM selectors ยังไม่ได้สร้างสำหรับ provider ใหม่dkim=fail หรือลายเซ็นจาก default domain ของ provider; DMARC ไม่มีขาที่สองเผยแพร่ selectors ใหม่ — ขั้นตอน 6 ด้านล่าง
Record อัปเดตเฉพาะที่ nameservers เก่าคำตอบต่างกันขึ้นอยู่กับว่าคุณถาม; failures ที่ไม่สม่ำเสมอแก้ไข zone ที่ authoritative nameservers; ตรวจสอบทั้งสองชุดในช่วง cutover

จะแก้ไขได้อย่างไร? Migration checklist

  1. รัน free scan ที่ defaults.exposed ก่อน อ่าน DNS live ของคุณและบอกว่าคุณมี SPF records หลายรายการ missing include หรือ DKIM gap — วินิจฉัยก่อนแตะสิ่งใด

  2. แสดง SPF record ทุกรายการที่ authoritative nameservers dig +short NS yourdomain.com แล้ว dig +short TXT yourdomain.com @<nameserver> กับหนึ่งในนั้น นับ strings ที่ขึ้นต้นด้วย v=spf1 จำนวนที่ปลอดภัยเพียงอย่างเดียวคือ 1

  3. รวมเป็น record เดียว record เดียว ขึ้นต้นด้วย v=spf1 ที่มี include ของ provider ใหม่และผู้ส่งอื่นที่คุณยังใช้อยู่ (invoicing tool, CRM, newsletter platform) -all หรือ ~all ปลายทางเดียว ตัวอย่าง — Google Workspace เก่า Microsoft 365 ใหม่ กำลัง drain:

    Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"

    ค่า provider และ DNS-panel quirks อยู่ใน setup guides สำหรับ Google Workspace และ Microsoft 365

  4. ลบ records ส่วนเกิน การรวมโดยไม่ลบไม่แก้ไขอะไร — PermError มาจากจำนวน

  5. เก็บ include ของ provider เก่าไว้เฉพาะขณะที่ระบบเก่ายังส่ง — รายงานที่ scheduled, CRM connector เก่า, mailbox ที่ลืม เมื่อ drain เสร็จ ลบมัน: include ที่ล้าสมัยปล่อยให้โครงสร้างพื้นฐานเก่าได้รับอนุญาตส่งในนามคุณ และทุก include ใช้ DNS lookups กับขีดจำกัดที่เข้มงวด 10 รายการของ SPF — อย่างน้อย 797,263 โดเมนได้ทำให้ SPF เป็นโมฆะโดยเกิน limit นั้น (census, 2026-06-29)

  6. ตั้งค่า DKIM ของ provider ใหม่ — และอย่าลบ selectors เก่าตอนนี้ Selectors ใหม่ sign อีเมลใหม่; selectors เก่าต้องคงเผยแพร่ไว้จนกว่าทุกข้อความที่ลงนามด้วยจะถูกส่งและการ forward ใดๆ ตั้งใจแล้ว walk-through ครบใน DKIM failing after switching email tools

  7. ถ้าคุณเปลี่ยน nameservers ด้วย ตรวจสอบทั้งสองชุด DNS migrations มักไปพร้อมกับ email migrations Query ชุด NS เก่าและใหม่โดยตรง (dig TXT yourdomain.com @old-ns และ @new-ns) — จนกว่า registrar delegation จะ propagate อย่างสมบูรณ์ ผู้รับบางรายยังถามเซิร์ฟเวอร์เก่า ดังนั้น record ที่แก้ไขต้องมีอยู่ที่ชุดใดก็ตามที่ตอบ

  8. รัน scan อีกครั้ง และยืนยันว่า SPF แสดง single valid record พร้อม pass

SPF ตรวจสอบโดเมนไหนจริงๆ?

ผู้รับประเมิน SPF กับ Return-Path (RFC5321.MailFrom) domain — bounce address — ไม่ใช่ From header ที่ผู้รับเห็น หลัง migration นี่สำคัญสองครั้ง: provider ใหม่ของคุณอาจใช้ bounce domain ของตัวเองจนกว่าคุณจะกำหนด custom one และ SPF “passing” บนโดเมนที่ไม่ใช่ของคุณจะไม่ align สำหรับ DMARC การแก้ไขสำหรับนั้นคือ DKIM ของ provider ใหม่ ลงนามด้วยโดเมนของคุณ

กำลัง migrate และ rebrand พร้อมกัน?

เปลี่ยนโดเมนด้วยรวมกับ provider? ถือว่าเป็นสองงาน โดเมนใหม่ต้องการ stack ครบ — SPF, DKIM, DMARC — ตั้งแต่วันแรก ใช้ new-domain email checklist โดเมนเก่ายังคง authenticate ตราบเท่าที่มี forwarding หรือ reply traffic ผ่านมัน และถูกล็อคลงอย่างชัดเจน (ไม่ใช่แค่ถูกทิ้ง) เมื่อมัน park แล้ว โดเมนเก่าที่มี SPF ที่เสียเหลืออยู่ครึ่งๆ กลางๆ คือเป้าหมาย spoofing ที่สวมชื่อเก่าของคุณ

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

ฉันสามารถเก็บ SPF records สองรายการไว้ระหว่าง migrate ได้หรือไม่? ไม่ ไม่มีระยะเวลาผ่อนผันในมาตรฐาน — v=spf1 records สองรายการคือ PermError ตั้งแต่ช่วงเวลาที่รายการที่สองมีอยู่ และ 1,013,416 โดเมนอยู่ในสถานะนั้น ณ census (2026-06-29) รูปแบบที่ปลอดภัยสำหรับ migration คือ record เดียวที่มี includes ของทั้งสอง providers ในช่วง overlap

ฉันควรเก็บ include ของ provider เก่าไว้นานแค่ไหน? จนกว่าไม่มีอะไรส่งผ่าน provider เก่า — โดยทั่วไปความยาวของ overlap window ของคุณ วันถึงสองสามสัปดาห์ ดู Return-Path ของสิ่งที่ยังมาถึงผ่านระบบเก่า เมื่อ traffic นั้นหยุด ลบ include และตรวจสอบ lookup count ของคุณ

ทำไม checker ยังแสดง record เก่าของฉันหลังจากแก้ไขแล้ว? DNS caching ให้เกียรติ TTL ของ record และถ้า nameservers ของคุณเปลี่ยน resolvers บางรายยังถาม set เก่า ตรวจสอบโดยตรงที่ authoritative nameservers ด้วย dig TXT yourdomain.com @<ns> — ถ้าคำตอบถูกต้องที่นั่น การแก้ไขเสร็จแล้วและ caches จะตามทัน ถ้าผิดที่ชุด NS หนึ่ง ดู ‘SPF record not found’ — สาเหตุที่แท้จริง

ฉันต้องเปลี่ยน DMARC เมื่อเปลี่ยน provider หรือไม่? มักจะไม่ใช่ record ตัวเอง — มันระบุ report mailbox และนโยบายของคุณ ไม่ใช่ provider ของคุณ แต่ ผลลัพธ์ DMARC ของคุณขึ้นอยู่กับ SPF และ DKIM ที่คุณ migrate แล้ว คาดว่าจะมีการลดลงใน reports ระหว่าง cutover และยืนยันว่าทั้งสอง legs ผ่านก่อนเพิ่มความเข้มงวดของนโยบาย เริ่มที่ แก้ไข SPF ถ้า scan แสดงว่า SPF leg ยังล้มเหลว

ส่ง report ให้เจ้าของ

ถ้าคุณทำ migration นี้สำหรับลูกค้า จบด้วยหลักฐาน รัน free scan อีกครั้งเมื่อการรวมไปถึงแล้วและส่ง graded report ให้เจ้าของธุรกิจ: SPF, DKIM และ DMARC ผ่านบน provider ใหม่ ในภาษาธรรมดา มีวันที่ นั่นคือ artifact ที่พวกเขาจัดเก็บสำหรับการต่ออายุ cyber-insurance และ supplier security questionnaire ครั้งต่อไป — หลักฐานว่า migration ทิ้งโดเมนที่ได้รับการ authenticate ดียิ่งกว่าที่เริ่มต้น

ตรวจสอบโดเมนของคุณ → · DKIM failing after switching email tools → · ‘SPF record not found’ — สาเหตุที่แท้จริง → · วิธีที่เราให้คะแนน → · ข้อมูลรวมเท่านั้น ข้อมูลจัดเก็บและประมวลผลใน EU