เพิ่ม SPF แล้ว Google Search Console หลุด? นี่คือสาเหตุ

คุณเพิ่ม SPF record เพื่อไม่ให้อีเมลตกไปอยู่ใน Spam หนึ่งสัปดาห์ต่อมา Google Search Console แจ้งว่าเว็บไซต์ของคุณ Not verified ทั้งที่ไม่มีใครแตะ Search Console เลย สองเรื่องนี้เกี่ยวข้องกันบ่อยกว่าที่คิด และมันเกิดขึ้นกับเราด้วย

คำตอบสั้น ๆ: SPF และโค้ดยืนยันของ Google อยู่ใน TXT record ของโดเมนหลักเหมือนกัน หน้าจัดการ DNS จำนวนมากเก็บค่าเหล่านี้ไว้ใน record เดียว ถ้าคุณแทนที่ record นั้นด้วยบรรทัด SPF อย่างเดียว โค้ด Google ก็หายไป Search Console จะตรวจโค้ดเป็นระยะ และเมื่อไม่พบ การยืนยันของคุณจะหมดอายุ วิธีแก้คือเพิ่มค่าเดิมกลับเข้าไปข้าง SPF ไม่ใช่แทนที่

ทำไมการเปลี่ยนอย่างหนึ่งทำให้อีกอย่างพัง

TXT record ของโดเมนหลัก (example.com ไม่ใช่ www) เป็นเหมือนชั้นวางที่ใช้ร่วมกัน โดยทั่วไปจะมี:

• SPF บรรทัดที่ขึ้นต้นด้วย v=spf1 ซึ่งบอกว่าเซิร์ฟเวอร์ใดส่งอีเมลแทนโดเมนของคุณได้
• google-site-verification=… ซึ่งพิสูจน์กับ Search Console ว่าคุณเป็นเจ้าของโดเมน
• หลักฐานความเป็นเจ้าของอื่น ๆ: MS=… สำหรับ Microsoft 365, facebook-domain-verification=…, apple-domain-verification=… และอื่น ๆ ในทำนองเดียวกัน

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

Google ระบุผลที่ตามมาชัดเจน: เพื่อให้ยังคงได้รับการยืนยัน อย่าลบ DNS record แม้การยืนยันจะสำเร็จไปแล้ว Search Console จะตรวจเป็นระยะว่าโค้ดยังอยู่ ถ้าไม่อยู่ คุณจะได้รับคำเตือน และหลังช่วงผ่อนผัน property จะเสียเจ้าของที่ยืนยันแล้ว

สิ่งที่เกิดขึ้นกับเรา

วันที่ 19 ตุลาคม 2026 เราตั้งค่าอีเมล Google Workspace ให้ 6 โดเมนที่เราดูแล คือผลิตภัณฑ์ของเราเอง 5 ตัวและเว็บช็อปของลูกค้า 1 ราย การตั้งค่าแทนที่ TXT record ของโดเมนหลักแต่ละโดเมนด้วยบรรทัด SPF ของ Workspace อีเมลทำงานได้ปกติ ไม่มีอะไรดูผิดปกติ

เจ็ดวันต่อมา วันที่ 26 ตุลาคม สองโดเมนแสดง Not verified ใน Search Console เมื่อตรวจทั้งหกโดเมน พบว่าทุกโดเมนสูญเสียค่า google-site-verification เราใช้เวลาสิบนาทีหาสาเหตุ โดยเทียบ TXT record ปัจจุบันกับสิ่งที่มีอยู่เมื่อหนึ่งสัปดาห์ก่อน

• เรากู้ค่าเดิมกลับมาอย่างไร: โดเมนอยู่บน AWS Route 53 ซึ่งบันทึกทุกการเปลี่ยนแปลง DNS ไว้ใน CloudTrail (เก็บ 90 วัน) ทุกเหตุการณ์ ChangeResourceRecordSets ยังมี record เดิมอยู่ รวมถึงโค้ด Google
• วิธีแก้: เราเพิ่มโค้ด Google แต่ละตัวกลับไปข้างบรรทัด SPF ใน record เดียวกัน แล้วกด Verify ใน Search Console ทั้งหกโดเมนได้รับการยืนยันอีกครั้งภายในวันเดียว
• ความเสียหาย: ครั้งนี้ไม่มี เพราะเราพบขณะที่ Google ยังอยู่ในช่วงผ่อนผัน ถ้าปล่อยไว้ เราจะเสียสิทธิ์เข้าถึงข้อมูลการค้นหาและการตั้งค่าของ 6 เว็บไซต์

บทเรียนที่เราเขียนไว้ใน runbook ของเราเอง: ก่อนแก้ไข TXT record ของโดเมนหลักทุกครั้ง ให้ดูว่าข้างในมีอะไร และเก็บไว้ทั้งหมด

วิธีตรวจโดเมนของคุณเอง

เปิด terminal แล้วรัน:

dig TXT example.com +short

บน Windows: nslookup -type=TXT example.com หรือใช้เครื่องมือค้น DNS ออนไลน์ใดก็ได้ คุณควรเห็นประมาณนี้:

"v=spf1 include:_spf.google.com ~all"
"google-site-verification=AbC123..."

ตรวจสามอย่าง:

• โค้ด Google ยังอยู่ไหม? ถ้าตั้ง Search Console ไว้สำหรับโดเมนนี้ แต่ไม่มีบรรทัด google-site-verification การยืนยันจะหมดอายุ
• มีบรรทัด SPF เพียงบรรทัดเดียวไหม? สองบรรทัดที่ขึ้นต้นด้วย v=spf1 ถือเป็นข้อผิดพลาดตามมาตรฐาน SPF (RFC 7208) เซิร์ฟเวอร์อีเมลปลายทางจะมองว่า SPF ของคุณใช้งานไม่ได้ ถ้าคุณส่งผ่านสองบริการ ให้รวมเป็นบรรทัดเดียว: v=spf1 include:_spf.google.com include:mailgun.org ~all
• หลักฐานอื่นยังอยู่ไหม? Microsoft, Meta, Apple และรายอื่นก็ตรวจโค้ดของตนเช่นกัน

DKIM และ DMARC ไม่เสี่ยงในกรณีนี้ เพราะอยู่ภายใต้ชื่อของตัวเอง (selector._domainkey.example.com และ _dmarc.example.com) ไม่ได้อยู่ที่โดเมนหลัก

หลุดไปแล้ว? วิธีแก้

1. หาค่าเดิม ดูประวัติการเปลี่ยนแปลงหรือ audit log ของผู้ให้บริการ DNS (Route 53: CloudTrail เก็บ 90 วัน) ผู้รับจดโดเมนบางรายก็เก็บประวัติไว้ ไม่มีประวัติ? เริ่มการยืนยันใหม่ใน Search Console แล้วระบบจะให้ค่า TXT มาเพิ่ม
2. เพิ่ม ไม่ใช่แทนที่ ใส่โค้ด Google กลับเป็นอีกหนึ่งบรรทัดใน TXT record เดียวกัน ข้าง SPF และทุกอย่างที่มีอยู่
3. รอ DNS ปกติไม่กี่นาที อย่างมากเท่า TTL ของ record (มักหนึ่งชั่วโมง)
4. กด Verify ใน Search Console ที่ property ซึ่งขึ้น Not verified
5. ตรวจว่าอีเมลยังผ่าน ส่งอีเมลทดสอบไปที่ Gmail แล้วหา spf=pass ใต้ Show original

วิธีป้องกันไม่ให้เกิดซ้ำ

• ก่อนแก้ไข TXT record ให้คัดลอกเนื้อหาปัจจุบันไปเก็บไว้ที่อื่น
• เลือกการเปลี่ยน DNS ที่เพิ่มค่า มากกว่าแบบที่แทนที่ record ใน Route 53 หมายถึงให้อ่าน record set ก่อน แล้วบันทึกรายการที่รวมครบทั้งหมด
• ทำรายการสั้น ๆ ว่า TXT ของโดเมนหลักแต่ละโดเมนต้องมีอะไรบ้าง ใช้เวลาห้านาที แต่ช่วยประหยัดความสับสนไปหนึ่งสัปดาห์
• หลังเปลี่ยน DNS ทุกครั้ง ให้ตรวจ Search Console และส่งอีเมลทดสอบในวันเดียวกัน

ปัญหาโดเมน อีเมล และ DNS เป็นส่วนหนึ่งของบริการช่วยเหลือฉุกเฉินของเรา เราหาสาเหตุ แก้ไข และบอกคุณว่าเกิดอะไรขึ้น หากมีปัญหาอีเมลเพิ่มเติม อ่านทำไมอีเมลจากเว็บไซต์ของคุณไม่เข้า

บทความที่เกี่ยวข้อง

• อีเมลจากเว็บไม่เข้า หรือเข้า Spam? สาเหตุและวิธีแก้
• SSL หมดอายุ หรือโดเมนหมดอายุ? วิธีแก้และกู้เว็บไซต์คืน
• SEO สำหรับนักพัฒนา: สิ่งที่ต้องสร้างไว้ตั้งแต่วันแรก