อีเมลจากโดเมนของคุณเอง

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

ทำไมถ้าไม่มีเรกคอร์ด DNS จดหมายจึงไปไม่ถึง

ลองมองจากฝั่งผู้รับ — Gmail, Outlook หรือเซิร์ฟเวอร์เมลของลูกค้าคุณ มีจดหมายมาถึงซึ่ง อ้างว่า มาจากโดเมนของคุณ แต่มาจากเซิร์ฟเวอร์ที่ไม่ได้เป็นของโดเมนนั้น นี่คือภาพเดียวกันกับการปลอมแปลง: ฟิชชิงทำงานแบบนี้เป๊ะ

วิธีเดียวที่ผู้รับจะแยกแยะได้คือถามตัวโดเมนเอง: «ผู้ส่งรายนี้ทำการแทนคุณจริงหรือไม่» คำตอบนั้นคุณประกาศไว้ใน DNS ของโดเมนตัวเอง เพราะ DNS เป็นที่เดียวที่มีเพียงคุณเท่านั้นควบคุม — และจึงเป็นที่เดียวที่ผู้รับเชื่อถือ

ตราบใดที่ยังไม่มีคำตอบนั้น เซิร์ฟเวอร์เมลที่ทำงานอย่างมีความรับผิดชอบต้องถือว่าจดหมายน่าสงสัย ดีที่สุดคือตกไปอยู่ในกล่องสแปม แย่ที่สุดคือถูกปฏิเสธ และผู้รับจะไม่มีวันรู้ว่ามีจดหมายฉบับนั้นอยู่

ดังนั้นสามเรกคอร์ดด้านล่างจึงไม่ใช่พิธีกรรมหรือช่องติ๊กในหน้าจอ มันคือการอนุญาตของคุณ

สามเรกคอร์ดและหน้าที่ของแต่ละอัน

DKIM — ลายเซ็นที่พิสูจน์ความแท้

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

ถ้าไม่มี DKIM: ไม่มีอะไรให้ตรวจลายเซ็น จดหมายดูเหมือนไม่ได้ลงนามและไร้ความน่าเชื่อถือ และไม่มีการตั้งค่าอื่นใดชดเชยได้ DKIM สำคัญที่สุดในสามอย่าง

SPF — เซิร์ฟเวอร์ใดบ้างที่ส่งแทนคุณได้

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

ถ้าไม่มี SPF: จดหมายมาจากเซิร์ฟเวอร์ที่โดเมนของคุณ «ไม่รู้จัก» สำหรับตัวกรองนี่คือสัญญาณปลอมแปลงคลาสสิก และบวกเพิ่มกับข้อสงสัยอื่น ๆ

DMARC — ผู้รับควรทำอย่างไรเมื่อการตรวจไม่ผ่าน

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

เริ่มจากนโยบายอ่อนที่สุด «รายงานอย่างเดียว» แล้วค่อยเข้มขึ้นภายหลัง เมื่อมั่นใจว่าผู้ส่งที่ถูกต้องทั้งหมดของคุณ (บัญชี CRM จดหมายข่าว บอตนี้) ผ่านการตรวจแล้ว นโยบายเข้มที่เปิดเร็วเกินไปจะเริ่มกินจดหมายของคุณเอง

ถ้าไม่มี DMARC: ผู้รับแต่ละรายตัดสินใจเอง และคุณจะไม่มีวันรู้ว่าเกิดอะไรขึ้นกับจดหมายในนามของคุณ

ต้องเพิ่มเรกคอร์ดใดบ้าง

ก่อนอื่นให้เพิ่มโดเมนในแดชบอร์ด: ส่วน Email → «Sending domains» → ปุ่ม «Add domain» กล่องโต้ตอบมีสามช่อง: ตัว โดเมน เอง (เช่น shop.example.com), ส่วนหน้าของที่อยู่ (ส่วนก่อน @ ปกติคือ noreply) และ ชื่อผู้ส่ง ที่ผู้รับจะเห็นแทนที่อยู่ เมื่อบันทึกแล้ว เรกคอร์ด DNS ของคุณจะปรากฏบนหน้าจอ

ทั้งสามเป็นเรกคอร์ดชนิด TXT ใน DNS ของโดเมนคุณ เพิ่มได้ที่เดียวกับที่คุณจัดการโดเมน: แผงควบคุมของผู้รับจดทะเบียนหรือผู้ให้บริการ DNS

ค่าด้านล่างใช้ example.com เป็นตัวอย่าง — ให้แทนด้วยโดเมนของคุณ ค่าที่แน่นอนสำหรับโดเมนของคุณแสดงอยู่บนการ์ดโดเมนในแดชบอร์ด ให้คัดลอกจากที่นั่น โดยเฉพาะ DKIM: ค่าของมันมีกุญแจสาธารณะของคุณเอง ซึ่งต่างกันในแต่ละโดเมนและหยิบจากเอกสารไม่ได้

บนหน้าจอ เรกคอร์ดแต่ละอันถูกแยกเป็นสองช่องต่างหาก — «Host» และ «Value» — แต่ละช่องมีปุ่ม «Copy» ของตัวเอง ให้คัดลอกทีละช่องไปใส่ในช่องที่ตรงกันของผู้ให้บริการ DNS ของคุณ: สองส่วนนี้วางรวมเป็นก้อนเดียวไม่ได้

สองจุดที่คนพลาดบ่อยที่สุด:

• แผงควบคุมหลายเจ้าเติมชื่อโดเมนต่อท้ายให้เอง ถ้าช่องชื่อแสดง «.example.com» อยู่แล้ว ให้ใส่แค่ mybot._domainkey ไม่ใช่ชื่อเต็ม ไม่เช่นนั้นจะกลายเป็น mybot._domainkey.example.com.example.com
• ค่า DKIM ยาวมากและต้องไม่มีการขึ้นบรรทัดใหม่หรือช่องว่างภายในกุญแจ ให้คัดลอกด้วยปุ่ม ไม่ใช่การลากเมาส์

ถ้าโดเมนมีเรกคอร์ด SPF อยู่แล้ว

โดเมนหนึ่งมีเรกคอร์ด SPF ได้เพียง หนึ่ง รายการ ถ้าคุณส่งจดหมายผ่านโฮสติ้ง CRM หรือบริการจดหมายข่าวอื่นอยู่แล้ว เรกคอร์ดนั้นมีอยู่ อย่าเพิ่มอันที่สอง — ให้เติม include อีกหนึ่งอันลงในเรกคอร์ดเดิม ก่อน ~all ที่ท้ายสุด:

v=spf1 include:spf.ผู้ให้บริการของคุณ include:esp.getmybot.dev ~all

การมีเรกคอร์ด SPF สองรายการบนโดเมนเดียวคือความผิดพลาดเดียวกับไม่มีเลย: การตรวจไม่ผ่าน เพราะผู้รับไม่รู้ว่าจะเชื่ออันไหน

ข้อควรทราบ: การ «ครอบคลุม» ผ่านเรกคอร์ดของคนอื่นไม่เพียงพอ ต่อให้ผู้ให้บริการปัจจุบันของคุณ include เราไว้ใน SPF ของเขาเอง include ของเราก็ต้องอยู่ในเรกคอร์ดของคุณโดยตรง — เหตุผลอยู่ด้านล่างในหัวข้อการยืนยันโดเมน

ทำไม SPF ต้องใช้ include ไม่ใช่หมายเลข IP

ความผิดพลาดที่พบบ่อยที่สุดคือวางหมายเลข IP ที่เห็นในเฮดเดอร์จดหมายหรือในกระทู้ อย่าทำแบบนั้น

include:esp.getmybot.dev คือตัวชี้ไปยังรายการเซิร์ฟเวอร์ส่งของเราเองที่เราดูแลอยู่ วันนี้ชื่อนี้ชี้ไปยังเซิร์ฟเวอร์รีเลย์เพียงเครื่องเดียว พรุ่งนี้อาจมีมากขึ้น อาจย้ายที่ หรือถูกเปลี่ยน เมื่อถึงเวลานั้นเราจะอัปเดตรายการที่ฝั่งเรา และ เรกคอร์ดของคุณจะทำงานต่อไปโดยไม่ต้องแก้อะไรเลย นี่คือเหตุผลทั้งหมด: ที่อยู่เปลี่ยนที่เดียว ไม่ใช่ใน DNS ของลูกค้าทุกราย

หมายเลข IP ที่พิมพ์เองจะเลิกเป็นความจริงในทันทีที่มีการเปลี่ยนแปลง จดหมายจะเริ่มไม่ผ่าน SPF โดยไม่มีคำเตือนใด ๆ — ไม่มีข้อผิดพลาดในแดชบอร์ด ไม่มีการแจ้งเตือน คุณจะรู้จากลูกค้าที่บอกว่า «ไม่ได้รับอะไรเลย»

ให้พิมพ์ include:esp.getmybot.dev ตรงตัว และอย่าเติมอะไรเพิ่ม

การยืนยันโดเมน

การยืนยันโดเมน คือการที่แพลตฟอร์มเข้าไปดู DNS ของโดเมนคุณเอง และยืนยันว่าทั้งสามเรกคอร์ดเรียบร้อย ถ้าผ่านครบทั้งสาม โดเมนจะได้สถานะ ยืนยันแล้ว และอนุญาตให้ส่งได้ ตราบใดที่ยังมีข้อใดไม่ผ่าน โดเมนจะยังรออยู่

สิ่งที่ตรวจไม่ใช่แค่ «มีเรกคอร์ดอยู่»:

ทำไม DMARC จึงตรวจหลวมกว่า: มันบอกผู้รับว่า ให้ทำอย่างไร กับผลของ DKIM และ SPF แต่ไม่ได้ให้สิทธิ์เราส่งในนามคุณ สิทธิ์นั้นมาจากสองเรกคอร์ดแรกเท่านั้น และทั้งคู่ถูกตรวจเนื้อหาอย่างครบถ้วน

include ของคนอื่นไม่นับ

include:esp.getmybot.dev ต้องอยู่ใน เรกคอร์ด SPF ของคุณเอง ถ้า SPF ของคุณ include ผู้ให้บริการรายอื่น แล้วเรกคอร์ดของรายนั้น include เราอีกที การตรวจจะไม่นับให้ เพราะแพลตฟอร์มไม่ไล่ตามลูกโซ่ include ของคนอื่น เหตุผลง่าย ๆ คือทำให้คำตอบของคำถาม «โดเมนนี้อนุญาตเราหรือไม่» ชัดเจนไม่กำกวม

ในทางปฏิบัติ: ต่อให้มั่นใจว่า «ครอบคลุมผ่านผู้ให้บริการแล้ว» ก็ให้เติม include ของเราลงในเรกคอร์ดของคุณโดยตรง เรื่องเดียวกันนี้เขียนอยู่บนหน้าจอเองด้วย ในคำอธิบายของเรกคอร์ด SPF: ถ้าโดเมนมีเรกคอร์ด SPF อยู่แล้ว ให้เติมค่า include:... เข้าไปในนั้น แทนที่จะแทนที่เรกคอร์ดทั้งอัน เพราะโดเมนอาจส่งจดหมายผ่านทางอื่นด้วย คำแนะนำนั้นแสดงอยู่ตลอด ไม่ใช่โผล่มาหลังการตรวจล้มเหลว

DNS ไม่ได้อัปเดตทันที หลังบันทึกเรกคอร์ดที่ผู้รับจดทะเบียน ข้อมูลต้องกระจายไปยังเนมเซิร์ฟเวอร์: ปกติเป็นนาที บางครั้งเป็นชั่วโมง นาน ๆ ครั้งถึงหนึ่งวัน ขึ้นกับผู้ให้บริการและค่า TTL นี่เป็นเรื่องปกติและไม่ได้อยู่ในมือเรา

แต่ก็ไม่ต้องนั่งรอเฉย ๆ แพลตฟอร์มตรวจโดเมนที่รออยู่เองทุก หนึ่งชั่วโมง แต่บนการ์ดโดเมนมีปุ่ม «Verify now» — เป็นการตรวจแบบเดียวกันที่รันทันที พร้อมผลลัพธ์บนหน้าจอ ให้กดทันทีหลังบันทึกเรกคอร์ด: ถ้าพิมพ์ผิดคุณจะรู้ในหนึ่งวินาที ไม่ใช่หนึ่งชั่วโมง กดกี่ครั้งก็ได้

สถานะของโดเมนเห็นได้บนการ์ด: «Pending verification», «Verified» หรือ «Not verified» ตราบใดที่ยังไม่ยืนยัน การ์ดจะมีคำเตือน «Sending from this domain is disabled until it is verified.» ด้วย

ผลลัพธ์ไม่ได้บอกแค่ «ไม่ผ่าน» เรกคอร์ดทั้งสามมีสถานะของตัวเองบนหน้าจอ — «Passing», «Not passing» หรือ «Not checked yet» — และมีบรรทัดอธิบายของตัวเองว่าอะไรผิด

สำหรับ SPF หน้าจอแยกสองสถานการณ์ออกจากกัน และนี่คือความแตกต่างที่สำคัญที่สุดในกระบวนการทั้งหมด:

• โดเมนไม่มีเรกคอร์ด SPF เลย ให้เผยแพร่ขึ้นมาใหม่ ด้วยค่าจากตารางด้านบน
• มีเรกคอร์ด SPF อยู่แล้วแต่ไม่มี include ของเราอยู่ในนั้น ให้เติม include ลงในเรกคอร์ด ที่มีอยู่: อย่าสร้างอันที่สองและอย่าแทนที่ทั้งอัน ข้อความเดียวกันนี้ยังครอบคลุมกรณีลูกโซ่อย่างชัดเจนด้วย: ถ้า include มาถึงเราผ่านเรกคอร์ด SPF ของผู้ให้บริการรายอื่นเท่านั้น จะไม่นับ เพราะไม่มีการไล่ตามลูกโซ่

กรณีที่สองคือจังหวะที่สับสนที่สุดของกระบวนการทั้งหมด: เรกคอร์ดมีอยู่แล้ว คุณเพิ่งอ่านทวนด้วยตาตัวเอง แต่การตรวจยังปฏิเสธ ตอนนี้ข้อความแจ้งข้อผิดพลาดบอกตรงกับคำแนะนำที่แสดงอยู่ตลอดข้างเรกคอร์ดเป๊ะ ๆ คือให้เติม include ของเราลงในสิ่งที่คุณมีอยู่แล้ว

ถ้าการตรวจไม่ผ่าน:

1. อ่านว่าเรกคอร์ดใดในสามอันขึ้นว่า «Not passing» และคำอธิบายของมันว่าอย่างไร แล้วทำตามนั้น
2. ตรวจว่าเรกคอร์ดถูกเผยแพร่จริง — แผงควบคุมหลายเจ้าต้องกด «นำการเปลี่ยนแปลงไปใช้» แยกต่างหาก
3. ตรวจชื่อเรกคอร์ดว่าโดเมนซ้ำซ้อนหรือไม่ (ดูด้านบน)
4. ตรวจว่ามีเรกคอร์ด SPF เพียงอันเดียว และ include ของเราอยู่ในเรกคอร์ดนั้นเอง
5. รอสักครู่แล้วตรวจใหม่: การเปลี่ยนแปลงอาจยังกระจายไม่ทั่ว

ก่อนยืนยันสำเร็จ การส่งจะไม่ทำงาน — ตั้งใจให้เป็นเช่นนั้น

ตราบใดที่โดเมนยังไม่ได้รับการยืนยัน จดหมาย จะไม่ถูกส่ง ไม่ใช่ «ส่งแล้วตกสแปม» — แต่ไม่ออกไปเลย: ความพยายามส่งจบด้วยข้อผิดพลาดเรื่องโดเมนยังไม่ยืนยัน และเห็นได้ในบันทึก

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

ถ้าคุณเห็นข้อผิดพลาดนี้ ให้ตรวจเรกคอร์ด DNS และกดยืนยันก่อนเขียนหาฝ่ายสนับสนุน ในกรณีส่วนใหญ่อย่างท่วมท้นสาเหตุคือพิมพ์ชื่อเรกคอร์ดผิด

การยกเลิกรับข่าว การร้องเรียน และการตีกลับ

สามกฎที่ทำให้คนแปลกใจถ้าไม่รู้มาก่อน

จดหมายการตลาดทุกฉบับมีปุ่มยกเลิกรับข่าวในคลิกเดียว แพลตฟอร์มเติมลิงก์ยกเลิกในส่วนท้ายจดหมายและเฮดเดอร์ทางเทคนิคที่ทำให้โปรแกรมเมลวาดปุ่ม «ยกเลิกการติดตาม» ข้างที่อยู่ผู้ส่งให้เอง เอาออกไม่ได้ — ทั้งด้วยการตั้งค่าและด้วยการจัดหน้าจดหมาย การยกเลิกมีผลทันที ไม่ต้องเปิดจดหมายและไม่มีขั้นตอนยืนยัน Gmail และผู้ให้บริการรายใหญ่อื่นกำหนดสิ่งนี้กับผู้ส่งจำนวนมาก: จดหมายที่ไม่มีมันจะตกสแปมแน่นอน

การยกเลิกเป็นที่สิ้นสุด และยกเลิกย้อนกลับจากหน้าจอไม่ได้ ที่อยู่ที่ยกเลิกแล้วจะไม่ได้รับจดหมายจากบอตนี้อีก ไม่มีปุ่ม «กู้คืน» และไม่มีทางลัดด้วยการนำเข้ารายชื่อซ้ำ: การยกเลิกจะไม่ถูกล้มข้ามหัวเจ้าตัว เขากลับมาได้ทางเดียวคือมาสมัครในฟอร์มของคุณเองอีกครั้ง

ยังมีกรณีที่เข้มกว่านั้น: ถ้ามีคนกด «นี่คือสแปม» ในโปรแกรมเมล ที่อยู่นั้นจะถูกปิดถาวร แม้สมัครใหม่ผ่านฟอร์มของคุณก็เปิดไม่ได้ — เพราะเรารู้แล้วว่าครั้งก่อนจบอย่างไร และการส่งไปยังที่อยู่แบบนั้นทำลายชื่อเสียงโดเมนได้เร็วที่สุด ที่อยู่ที่ถูกปิดด้วยมือตามข้อเรียกร้องทางกฎหมายก็ทำงานแบบเดียวกัน

การตีกลับถาวรปิดที่อยู่ตลอดไป ถ้าเซิร์ฟเวอร์ของผู้รับตอบว่าไม่มีกล่องจดหมายนั้น ที่อยู่จะถูกทำเครื่องหมายว่าส่งไม่ได้และตัดออกจากการส่งครั้งต่อไป นี่ไม่ใช่สถานะชั่วคราว: การพยายามส่งไปยังกล่องที่ไม่มีอยู่ต่อไปคือทางลัดสู่ตัวกรองสแปม พร้อมกับที่อยู่อื่น ๆ ทั้งหมด

การตีกลับชั่วคราว (กล่องเต็ม เซิร์ฟเวอร์ล่มชั่วคราว) ไม่ ปิดที่อยู่ — การส่งดำเนินต่อ

ทำไมตัวเลขการเปิดอ่านจึงต่ำกว่าความจริง

สถิติอีเมลมีตัวเลขการเปิดอ่าน และมันต่ำกว่าความจริงเสมอ นี่ไม่ใช่ข้อผิดพลาดในการนับ แต่เป็นเพราะวิธีวัดการเปิดอ่านเอง

การเปิดอ่านถูกบันทึกเมื่อโปรแกรมเมลโหลดภาพติดตามขนาดจิ๋วจากเซิร์ฟเวอร์ตอนแสดงจดหมาย โปรแกรมสมัยใหม่โดยค่าเริ่มต้นไม่โหลดภาพจากระยะไกล ส่วนโปรแกรมที่โหลด (Apple Mail และกลไกความเป็นส่วนตัวคล้ายกัน) ก็โหลดล่วงหน้าแทนทุกคน รวมถึงคนที่ไม่เคยเปิดจดหมาย กรณีแรกทำให้การเปิดอ่านหายไป กรณีที่สองทำให้ถูกนับให้คนที่ไม่ได้อยู่ตรงนั้น ไม่มีวิธีนับการเปิดอ่านให้แม่นกว่านี้ — ทั้งสำหรับเราและสำหรับใครก็ตาม

ด้วยเหตุนี้หน้าจอจึงมีข้อความกำกับข้างตัวเลข: นี่คือ ขอบเขตล่าง ไม่ใช่ตัวเลขที่แม่นยำ ใช้มันเพื่อเปรียบเทียบจดหมายระหว่างกัน ซึ่งความคลาดเคลื่อนเดียวกันมีผลกับทุกฉบับ แต่อย่าใช้ตอบคำถามว่า «มีกี่คนอ่านจดหมายฉบับนี้»

ถ้าต้องการตัวชี้วัดการมีส่วนร่วมที่เชื่อถือได้ ให้ดู «Link clicks» การคลิกลิงก์คือการกระทำจริงของคนจริง ไม่มีใครทำแทนล่วงหน้าได้ «Delivered», «Unsubscribes», «Complaints» และ «Bounces» ก็นับได้แม่นยำเช่นกัน: สิ่งเหล่านี้รายงานโดยเซิร์ฟเวอร์เมล ไม่ใช่โดยภาพในจดหมาย ทั้งหมดนี้อยู่ในบล็อก «Sending stats» บนหน้าจอ Email เดียวกัน

อ่านต่อ

• ช่องทาง — หลายช่องทางและความสามารถของแต่ละช่องทาง
• การกระจายข่าว — การส่งจำนวนมาก
• การวิเคราะห์ — ดูตัวเลขได้ที่ไหน