Gmail 550 5.7.26 "The Sender Is Unauthenticated": การแก้ไข ตามลำดับข้อกำหนด (2026)

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

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

Gmail ส่งคืน 550 5.7.26 เมื่อข้อความของคุณล้มเหลวการตรวจสอบ SPF และ DKIM แก้ไขโดยทำให้อย่างน้อยหนึ่งใน SPF หรือ DKIM ผ่านสำหรับโดเมน sending ของคุณ — sender ส่วนใหญ่ขาดสิ่งนี้: ของ 12,145,313 โดเมนที่อนุญาตเซิร์ฟเวอร์ของ Google ผ่าน _spf.google.com มีเพียง 18.5% ที่บังคับใช้ DMARC ตามสำมะโน Defaults.Exposed ของ 261,086,232 โดเมน

การแก้ไขคืองาน DNS ไม่ใช่ support ticket: ยืนยันว่า sending IP ของคุณมี reverse DNS ทำให้ SPF หรือ DKIM ผ่านสำหรับโดเมนที่ Gmail ตรวจสอบจริงๆ จากนั้นทำให้ DKIM จัดตำแหน่งกับ From address ของคุณและเผยแพร่ระเบียน DMARC ด้านล่างคือ requirement order เต็มรูปแบบ บวกตาราง decoder สำหรับตระกูล 550 5.7.26 และ sibling code ของมัน

Gmail error 550 5.7.26 หมายความว่าอะไร?

ตั้งแต่ข้อกำหนด sender ปี 2024 ของ Google ทุก sender ไปยัง Gmail — ไม่ใช่แค่ bulk sender — ต้องผ่านอย่างน้อยหนึ่งใน SPF หรือ DKIM สำหรับโดเมน sending ล้มเหลวทั้งคู่และ Gmail reject ที่เวลา SMTP ด้วย 550 5.7.26 แทนที่จะส่งไปยัง spam

เวอร์ชัน full-text ปัจจุบันอ่านว่า: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” bounce เก่าในธรรมชาติอาจยังคง carry คำอธิบายก่อนหน้าของ Google (“This mail is unauthenticated, which poses a security risk…”) และมี rate-limit sibling — 421 4.7.26 This email has been rate limited because it is unauthenticated — ด้วยสาเหตุเดียวกัน

550 5.7.26 ไม่ใช่ข้อความเดียวแต่เป็นส่วนหนึ่งของ ตระกูล code และคำอธิบายบอกคุณว่าขาใดล้มเหลว: reference ปัจจุบันของ Google เก็บ string 5.7.26 สาม (unauthenticated, SPF hard fail, DMARC policy) และย้ายความล้มเหลว SPF-only และ DKIM-only ของ bulk-sender ไปยัง code ของตัวเอง 5.7.27 และ 5.7.30 อ่านข้อความที่แน่นอนก่อนที่คุณจะแตะ DNS — มันคือการวินิจฉัยแรกของคุณ

ขนาดของช่องว่างคือเหตุผลที่ bounce นี้พบบ่อย: 12,145,313 โดเมนอนุญาตเซิร์ฟเวอร์อีเมลของ Google ในระเบียน SPF ของตน (ของ 138,927,207 โดเมนทั่วโลกที่เผยแพร่ SPF) แต่มีเพียง 18.5% ที่มีนโยบาย DMARC ที่บังคับใช้และเพียง 8.0% ใช้ strict SPF (-all) ส่วนใหญ่ Google-hosted sender ไม่ตรงตามกฎ bulk-sender ของ Google เอง — และ Gmail ตอนนี้บังคับใช้พื้นฐานกับทุกคน

คุณมี variant 550 5.7.26 ใด — หรือ sibling code?

จับคู่ข้อความ bounce ที่คุณได้รับกับตารางนี้ คำพูดที่อ้างตาม reference SMTP error ปัจจุบันของ Google — ตรวจสอบกับ NDR จริงของคุณเสมอ เนื่องจาก Google แก้ไขคำอธิบายเป็นระยะๆ

Code	Bounce text พูดว่า (fragment)	อะไรล้มเหลว	การแก้ไขอยู่ที่ไหน
550 5.7.26 (unauthenticated)	“This email has been blocked because the sender is unauthenticated … authenticate with either SPF or DKIM”	ไม่มีทั้ง SPF และ DKIM ผ่าน	คู่มือนี้ ขั้นตอน 2–4
550 5.7.26 (SPF hard fail)	“has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks”	ระเบียน SPF แบบ strict ของคุณไม่อนุญาต sending IP	ขั้นตอน 3 ด้านล่าง + แก้ SPF
550 5.7.26 (DMARC policy)	“Unauthenticated email from [domain] is not accepted due to domain’s DMARC policy”	นโยบาย DMARC ของคุณเอง reject อีเมลที่ไม่จัดตำแหน่ง	ขั้นตอน 4 ด้านล่าง
550 5.7.27 (bulk, SPF)	“didn’t pass SPF authentication … Gmail requires bulk email senders to authenticate their email with SPF”	SPF ล้มเหลว และคุณอยู่ใน bulk-sender tier	ขั้นตอน 3 ด้านล่าง + แก้ SPF
550 5.7.30 (bulk, DKIM)	“didn’t pass DKIM authentication … Gmail requires bulk email senders to authenticate their email with DKIM”	ไม่มีลายเซ็น DKIM ที่ถูกต้อง และคุณอยู่ใน bulk-sender tier	ขั้นตอน 3 ด้านล่าง + แก้ DKIM
550 5.7.29 (bulk, TLS)	“wasn’t sent over a TLS connection”	Bulk mail ส่งโดยไม่มี TLS	ขั้นตอน 6 ด้านล่าง
550 5.7.25	”doesn’t have a PTR record”	ไม่มี reverse DNS (PTR) บน sending IP	ขั้นตอน 2 ด้านล่าง
421-4.7.0	”try again later” / unusual traffic	การเลื่อนชั่วคราว — reputation หรือ rate ไม่ถาวร	Retry; ตรวจสอบขั้นตอน 2–3 และขั้นตอน 8
550 5.7.28	”unusual rate of unsolicited email”	Sending-rate / spam-rate limit	ขั้นตอน 8 ด้านล่าง
550-5.7.1	”message blocked” / policy text	Policy, spam, หรือการปฏิเสธ IPv6-without-PTR	ดู คู่มือ Gmail 550-5.7.1

คุณจะแก้ไข 550 5.7.26 ตาม requirement order ได้อย่างไร?

Google ไม่เผยแพร่ “check order” ตามตัวอักษร — แต่ข้อกำหนดของมันสะสมเชิงตรรกะ ดังนั้นทำงานผ่านพวกมันใน requirement order นี้ sender ส่วนใหญ่ถูก unblock หลังจากขั้นตอน 3; ทำรายการให้เสร็จอยู่ดี เพราะขั้นตอนภายหลังคือสิ่งที่ทำให้คุณออกจาก spam เมื่อคุณออกจาก bounce

รัน การสแกนฟรี ก่อน มันอ่าน SPF, DKIM, DMARC และ DNS setup live ของคุณและแสดงว่าขาใดล้มเหลวจริงๆ — วินิจฉัยก่อนที่คุณจะแตะ DNS
ให้ reverse DNS (PTR) แก่ sending IP ของคุณ IP ที่เชื่อมต่อต้องมีระเบียน PTR ที่ hostname resolve กลับไปยัง IP เดียวกัน ผู้ให้บริการกระแสหลักจัดการสิ่งนี้ให้คุณ; มันกัดคนที่ส่งจากเซิร์ฟเวอร์ของตัวเอง (และเป็นเรื่องทั้งหมดอยู่เบื้องหลัง sibling code 550 5.7.25)
ให้ SPF หรือ DKIM ผ่าน guardrail หนึ่งตัวก่อน: receiver ประเมิน SPF กับโดเมน Return-Path (RFC5321.MailFrom) ไม่ใช่ header From — ตรวจสอบว่าโดเมนใดที่อีเมลของคุณ bounce กลับจริงๆ ก่อนตัดสินใจว่า SPF “ควร” ผ่าน เพิ่มบริการ sending จริงของคุณในระเบียน SPF ของโดเมนนั้น (walkthrough SPF เต็มรูปแบบ) หรือเปิดใช้งานการลงนาม DKIM ที่ผู้ให้บริการ (walkthrough DKIM เต็มรูปแบบ) ทั้งคู่ผ่านแก้ไขการบล็อก 550 5.7.26 พื้นฐาน
ทำให้ DKIM จัดตำแหน่งกับโดเมน From ของคุณ สำหรับ bulk sending — และสำหรับ DMARC — Gmail ต้องการการยืนยันตัวตน สำหรับโดเมนใน From address ของคุณ ไม่ใช่ค่าเริ่มต้นของผู้ขาย ผู้ใช้ Google Workspace: เผยแพร่ DKIM key ของคุณเอง (การตั้งค่า Workspace DKIM); ลายเซ็น gappssmtp.com เริ่มต้นผ่าน DKIM แต่ไม่จัดตำแหน่ง — กับดักที่มี คู่มือของตัวเอง DKIM ที่จัดตำแหน่งยังรอดชีวิตจากการส่งต่อ ซึ่ง SPF ไม่เคยทำ
เผยแพร่ระเบียน DMARC ข้อกำหนด sender ของ Google ขอให้มีอย่างน้อย p=none พร้อมที่อยู่ reporting มันคือการแก้ไข DNS ห้านาที — ดู “DMARC policy not enabled” สำหรับก้าวแรกที่ซื่อสัตย์และสิ่งที่ p=none ทำและไม่ปกป้อง
ส่งผ่าน TLS เซิร์ฟเวอร์อีเมลหรือผู้ให้บริการสมัยใหม่ใดๆ ทำสิ่งนี้โดยค่าเริ่มต้น; ถ้าคุณ run MTA ของตัวเอง ยืนยันว่า outbound TLS เปิดอยู่ — bulk mail โดยไม่มีมันตอนนี้ bounce ด้วย code ของตัวเอง 550 5.7.29
เพิ่ม RFC 8058 one-click unsubscribe (header List-Unsubscribe + List-Unsubscribe-Post) สำหรับ marketing และ subscribed mail
รักษา spam rate ต่ำกว่า 0.10% ใน Google Postmaster Tools — และอย่าปล่อยให้ถึง 0.30% เพดานข้อกำหนดของ Google คือ 0.3%; คำแนะนำของมันคือรักษาให้ต่ำกว่า 0.10% ลงทะเบียนโดเมนของคุณที่นั่น; มันคือ report card ของ Google เกี่ยวกับคุณ และ spam-rate threshold คือข้อกำหนดที่ระเบียน DNS ไม่สามารถแก้ไขได้

สิ่งหนึ่งที่รายการนี้จะไม่ทำ: ทำให้คุณออกจาก third-party blocklist การยืนยันตัวตนหยุดการปฏิเสธ unauthenticated ของ Gmail; IP ที่มีประวัติ spam คือปัญหา reputation ด้วยเส้นทางการทำความสะอาดของตัวเอง — การแก้ไข auth ป้องกันการกลับเป็นซ้ำ มันไม่ได้ delist คุณ

กฎ bulk-sender ใช้กับคุณหรือไม่ถ้าคุณส่งน้อยกว่า 5,000 อีเมลต่อวัน?

Checklist เต็มรูปแบบ — การยืนยันตัวตนที่จัดตำแหน่ง, เผยแพร่ DMARC, one-click unsubscribe, spam rate limits — ใช้อย่างเป็นทางการที่ 5,000+ ข้อความต่อวันไปยัง Gmail และ code เฉพาะ bulk (5.7.27, 5.7.29, 5.7.30) มาจาก tier นั้น แต่พื้นฐานการยืนยันตัวตน (SPF หรือ DKIM ผ่าน, PTR ที่ถูกต้อง) ถูกบังคับใช้กับ ทุกคน ซึ่งเป็นเหตุผลที่ sender ขนาดเล็กได้รับ 550 5.7.26 เช่นกัน ปฏิบัติต่อขั้นตอน 1–5 เป็นบังคับที่ volume ใดก็ตาม ขั้นตอน 7–8 เป็นบังคับทันทีที่คุณส่งในจำนวนมาก ชุดข้อกำหนดเต็มรูปแบบสำหรับผู้ให้บริการทั้งสองอยู่ในบทความข้อมูลของเราเกี่ยวกับ ข้อกำหนด sender ของ Google และ Yahoo

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

550 5.7.26 หมายความว่าโดเมนหรือ IP ของฉันอยู่ใน blocklist หรือไม่? ไม่ มันคือความล้มเหลวการยืนยันตัวตน ไม่ใช่การตัดสิน reputation — Gmail กำลังพูดว่า “พิสูจน์ว่าคุณเป็นใคร” ไม่ใช่ “เรารู้ว่าคุณเป็น spammer” นั่นคือข่าวดี: มันแก้ไขได้ทั้งหมดใน DNS ข่าวร้ายคือมันปกติแค่ไหน — ทั่วสำมะโนของ 261,086,232 โดเมน (ณ วันที่ 2026-06-29) มีเพียง 10.59% ที่มีนโยบาย DMARC ที่บังคับใช้

การแก้ไข SPF เพียงอย่างเดียวจะหยุด bounce ได้หรือไม่? มักใช่ สำหรับ variant พื้นฐาน — Gmail ต้องการ อย่างน้อยหนึ่งใน SPF หรือ DKIM แต่ SPF ถูกประเมินกับโดเมน Return-Path และพังภายใต้การส่งต่อ ดังนั้น DKIM ที่จัดตำแหน่ง (ขั้นตอน 4) คือการแก้ไขที่คงทน มีเพียง 8.0% ของ 12,145,313 โดเมน Google-hosted sender domain ใช้ strict SPF (ข้อมูล ณ 2026-06-29) ดังนั้นไม่ว่าจะอย่างไรคุณจะนำหน้า

ฉันใช้ Google Workspace — ทำไม Google ถึง bounce อีเมลของฉันเอง? เพราะ Gmail ยืนยันตัวตน โดเมน ไม่ใช่ mailbox provider Workspace domain ที่ไม่มีระเบียน SPF และไม่มี custom DKIM key ส่งอีเมลที่ Google เองไม่สามารถตรวจสอบได้ — ของ 12,145,313 โดเมนที่อนุญาตเซิร์ฟเวอร์ของ Google มีเพียง 18.5% ที่มี enforcing DMARC (ข้อมูล ณ 2026-06-29) การเป็นลูกค้า Google และตรงตามกฎของ Google คือสิ่งที่แตกต่างกัน

หลังจากการแก้ไข DNS Gmail จะรับอีเมลของฉันได้นานแค่ไหน? ทันทีที่ระเบียนใหม่มองเห็น — โดยทั่วไปไม่กี่นาทีถึงสองสามชั่วโมง สูงสุด 48 ชั่วโมงสำหรับ TTL ที่ช้า การแก้ไข auth กระทำทันทีกับการตรวจสอบ 550 5.7.26; การฟื้นตัว spam-rate และ reputation (421-4.7.0, 5.7.28) ใช้เวลาหลายวันถึงหลายสัปดาห์ของการส่ง clean

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

ถ้าคุณแก้ไขสิ่งนี้สำหรับลูกค้า อย่าปิด ticket ด้วย “bounce resolved” รัน การสแกนฟรี ใหม่หลังจากการเปลี่ยน DNS และส่งต่อรายงานที่ได้รับการให้คะแนนให้เจ้าของธุรกิจ มันแสดงในภาษาธรรมดาว่าโดเมนของพวกเขาตอนนี้ยืนยันตัวตนอีเมลและยังขาดอะไร — หลักฐานที่พวกเขาต้องการสำหรับการต่ออายุประกันภัยไซเบอร์และแบบสอบถามความปลอดภัยผู้จัดหา คุณแก้ไข bounce; รายงานพิสูจน์มัน

ตรวจสอบโดเมนของคุณฟรี

ดูว่าขาใดของ SPF, DKIM และ DMARC ที่ Gmail ล้มเหลวคุณ — เป็นส่วนตัวและเฉพาะเจ้าของ

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