tva
← Insights

การตั้งค่ากล่องจดหมายสำหรับ AI Agent เฉพาะโปรเจกต์

ช้าหรือเร็ว AI Agent เฉพาะโปรเจกต์ที่คุณสร้างขึ้นก็ต้องการอีเมลเป็นของตัวเอง รูปแบบ Telegram bot ที่เราอธิบายไว้ใน Building a Project-Specific AI Assistant via Telegram จัดการแชทแบบเรียลไทม์ได้ดี แต่อีเมลเป็นช่องทางที่แตกต่างออกไป ทั้งการแจ้งเตือนจากบริการต่างๆ การยืนยันจากผู้ขาย การรีเซ็ตรหัสผ่านแบบ OAuth และการติดต่อกับคนที่ไม่ได้อยู่บน Telegram คุณอาจจะเลือกส่งทุกอย่างไปยังอีเมลส่วนตัวแล้วยอมรับกับความวุ่นวาย หรือจะให้โปรเจกต์มีกล่องจดหมายเป็นของตัวเองบน dedicated subdomain

คู่มือนี้ครอบคลุมทางเลือกที่สอง นั่นคือ dedicated mailbox บน project subdomain พร้อมการตั้งค่า DKIM, SPF และ DMARC ที่เรียบร้อย รูปแบบนี้ใช้ provider หนึ่งรายสำหรับ DNS (Cloudflare ในกรณีของเรา) และอีก provider หนึ่งรายสำหรับระบบอีเมล (Opalstack) ซึ่งเป็นการตั้งค่าที่ทีมขนาดเล็กส่วนใหญ่มักใช้ นั่นคือ DNS อยู่ที่ provider ที่ apex domain อาศัยอยู่แล้ว ส่วนอีเมลอยู่ที่ provider ที่ให้บริการ IMAP ที่ดี เข้าถึง API ได้สะดวก และมีชื่อเสียงที่รอดพ้นตัวกรองของ Gmail ได้ เราไม่ย้าย DNS ตามอีเมล และเราไม่ย้ายอีเมลตาม DNS ต้นทุนของการรันแยกกันคือ DNS records สามรายการและ mental model หนึ่งอย่าง ได้แก่ DNS provider บอกโลกว่าอีเมลส่งไปที่ไหน ส่วน mail provider รับ เก็บ และเซ็นชื่ออีเมล

การตั้งค่าทั้งหมดใช้เพียง API call สี่ครั้งบวก DNS records สามรายการ หากเตรียมการมาดี จะใช้เวลาราวสิบนาทีตั้งแต่ต้นจนจบ เราจะแสดง call ทั้งหมด การตรวจสอบ และ failure mode ที่เราเจอในครั้งแรก

คู่มือนี้แก้ปัญหาอะไร

  • Project subdomain (system.example.com) ที่ไม่มี mail infrastructure ติดตั้งอยู่
  • อีเมลขาเข้าที่ส่งมายังที่อยู่เฉพาะโปรเจกต์ถูกปฏิเสธเพราะไม่มี MX record
  • อีเมลขาออกจากโปรเจกต์ไม่ผ่านการตรวจสอบ DKIM ที่ Gmail แล้วตกไปอยู่ใน spam
  • SPF และ DMARC record ที่มีอยู่แต่ไม่มีอะไรให้ตรวจสอบความถูกต้อง
  • AI Agent ที่ต้องการช่องทางอีเมลโดยไม่ต้องผ่านบัญชีส่วนตัว

สิ่งที่คุณต้องมี

  • Apex domain ที่คุณควบคุมได้ โดยมี DNS อยู่ที่ provider ที่เปิด API ให้ใช้งาน (Cloudflare, Route53, DigitalOcean DNS เป็นต้น)
  • Mail provider ที่รองรับการเพิ่ม domain ผ่าน API สร้าง DKIM key เมื่อสร้าง domain และเปิด IMAP/SMTP endpoint ให้ใช้งาน (Opalstack, Mailcow, Migadu, Fastmail เป็นต้น)
  • API token ของทั้งสอง provider เก็บไว้ในที่ที่เรียกใช้ผ่าน shell ได้
  • dig, openssl s_client และ Python interpreter สำหรับการตรวจสอบ
  • เวลาราวสิบห้านาที

เหตุใดจึงใช้รูปแบบ Provider แยกกัน

แนวคิดหลักคือ "provider เดียวทำทุกอย่าง" ทั้งเว็บไซต์ DNS และกล่องจดหมายอยู่ที่เดียวกัน วิธีนี้ใช้ได้ดีจนกว่าหนึ่งในสามสิ่งนั้นจะต้องพัฒนาแยกอิสระจากกัน เราได้กล่าวถึง framework สำหรับตัดสินใจระหว่างบริการแบบ bundled กับผู้เชี่ยวชาญเฉพาะทางใน The Self-Hosting Decision: When SaaS Costs More Than Your Own Infrastructure และตรรกะเดียวกันนั้นก็ใช้ได้ที่นี่ในระดับที่เล็กกว่า

ในกรณีของเรา DNS ของ apex domain อยู่ที่ Cloudflare เพราะเราต้องการ AnyCast resolution การ proxy สำหรับ public-facing site และ API สำหรับการจัดการ record อัตโนมัติ ส่วนระบบอีเมลอยู่ที่ Opalstack เพราะต้นทุนต่อ mailbox ของพวกเขาถูกมาก ชื่อเสียงของ IMAP server ดี และ API ของพวกเขาเป็นหนึ่งใน API ที่สะอาดที่สุดในตลาด mail hosting ของ EU เราไม่ย้าย DNS เพื่อตามอีเมล และเราไม่ย้ายอีเมลเพื่อตาม DNS ต้นทุนของการรันแยกกันคือ DNS records สามรายการและ mental model หนึ่งอย่าง ได้แก่ DNS provider บอกโลกว่าอีเมลส่งไปที่ไหน ส่วน mail provider รับ เก็บ และเซ็นชื่ออีเมล

การแยกนี้มีความสำคัญในเชิงปฏิบัติการ เพราะมันจำกัดขอบเขตความเสียหาย การหยุดทำงานของ DNS provider จะหยุดการตัดสินใจ routing อีเมลใหม่ แต่อีเมลที่อยู่ระหว่างทางไปยัง MX host ก็ยังคงส่งถึงได้ การหยุดทำงานของ mail provider จะหยุดการส่ง แต่ DNS lookup ยังคง resolve ได้ หากเราซ้อนทุกอย่างไว้ที่ provider เดียว ทั้งสองชั้นจะล้มเหลวพร้อมกัน ตรรกะเดียวกันนี้ปรากฏใน production architecture สำหรับการซ้อน reverse proxy ของเรา นั่นคือการแยกความรับผิดชอบ โดยแต่ละชั้นสามารถเปลี่ยนแทนได้อิสระ

Dedicated Mailbox, Forwarding Alias หรือ SaaS Inbox

ก่อนที่จะสร้างอะไร ให้เลือกระดับความ dedicated ที่เหมาะสม เพราะทั้งสามตัวเลือกไม่เท่ากัน

Dedicated mailbox หมายความว่ามี inbox จริงที่เก็บอีเมล มี IMAP credential และสามารถทั้งส่งและรับได้ ต้นทุน: ราวหนึ่งถึงสามยูโรต่อเดือนที่ mail provider แบบ self-hosted บวกกับงาน setup API นี่คือสิ่งที่ AI Agent ใช้เมื่อต้องการอ่านอีเมลจริงๆ เช่น วิเคราะห์การยืนยันจากผู้ขายที่เข้ามา จัดการกับการแจ้งเตือนจากบริการ หรือรักษา thread กับมนุษย์ในหลายรอบสนทนา

Forwarding alias หมายความว่ามีที่อยู่เสมือนที่เพียงแค่ redirect ไปยัง inbox ที่มีอยู่แล้ว ต้นทุน: ศูนย์ เป็นแค่การตั้งค่า นี่คือตัวเลือกที่ถูกต้องเมื่อ AI Agent ต้องการแค่รับที่ที่อยู่ที่มี brand ของโปรเจกต์ แต่การอ่านและประมวลผลจริงๆ เกิดขึ้นใน inbox ของมนุษย์ที่มีอยู่แล้ว ข้อแลกเปลี่ยนคือ agent ไม่มี IMAP access ไม่มีการ filter เฉพาะโปรเจกต์ที่ปลายทาง และไม่มีเส้นทาง rollback ที่สะอาดเมื่อโปรเจกต์จบลง เพราะการลบ alias มักถูกลืม

SaaS inbox หมายความว่าใช้บริการอย่าง Postmark, Mailgun Inbound หรือ AWS SES พร้อม receive rule ต้นทุน: การคิดค่าบริการต่อข้อความบวกกับงาน engineering สำหรับเชื่อม AI Agent เข้ากับ webhook receiver นี่คือตัวเลือกที่ถูกต้องเมื่อ agent ต้องจัดการ volume สูง routing อีเมลตาม header rule หรือ trigger workflow อัตโนมัติต่อข้อความ สำหรับ agent เฉพาะโปรเจกต์ที่จัดการอีเมลหลักร้อยฉบับต่อเดือน นี่คือ overkill

สำหรับกรณีการใช้งานใน โพสต์เรื่อง Telegram AI assistant นั่นคือ operator หนึ่งคน ผู้ร่วมงานสองคน และบอทที่ขับเคลื่อนโดย Claude dedicated mailbox คือตัวเลือกที่เหมาะสมที่สุด agent ได้ที่อยู่จริงที่สามารถอ่านด้วย IMAP ส่งด้วย SMTP และมีชีวิตหรือตายอย่างสะอาดไปพร้อมกับโปรเจกต์

ขั้นตอนที่ 1: ลงทะเบียน Subdomain ในระบบอีเมลของคุณ

Mail provider ต้องรู้ว่า project subdomain ของคุณเป็นหนึ่งในdomain ของตนก่อน จึงจะรับอีเมลให้ได้ นี่คือ call ที่สร้าง DKIM key pair ด้วย

POST https://my.mailhost.example/api/v1/domain/create/
Authorization: Token <YOUR_MAIL_API_TOKEN>
Content-Type: application/json

[{"name": "system.example.com"}]

response มีสามฟิลด์ที่คุณต้องสนใจ ได้แก่ domain UUID (ซึ่งคุณต้องใช้สำหรับการลบและการ map ที่อยู่ในภายหลัง), state (โดยปกติจะเป็น PENDING_CREATE สักไม่กี่วินาทีแล้วจึงเปลี่ยนเป็น READY) และฟิลด์ dkim_record พร้อม TXT value ที่ format เรียบร้อยแล้วสำหรับวางใน DNS:

{
  "id": "<DOMAIN_UUID>",
  "state": "PENDING_CREATE",
  "name": "system.example.com",
  "dkim_record": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."
}

รอ poll จนกว่า state จะเปลี่ยนเป็น READY แล้วเก็บค่า dkim_record ไว้ คุณจะนำไปวางตรงๆ ใน DNS provider ในขั้นตอนถัดไป หาก create call ล้มเหลวพร้อม error invalid hostname สาเหตุที่พบบ่อยที่สุดคือ mail provider ของคุณรองรับเฉพาะ second-level domain และไม่ยอมรับ subdomain สามระดับ เปิด support ticket ได้เลย เราไม่เคยพบ provider ที่ปฏิเสธสิ่งนี้จริงๆ

ตรวจสอบขนาด DKIM key ก่อนดำเนินต่อ ค่า dkim_record ที่ต่ำกว่าราว 250 bytes คือ RSA key ขนาด 1024-bit ส่วน key ขนาด 2048-bit มีความยาวราว 380–420 bytes NIST เลิกใช้ RSA 1024-bit ในปี 2013 และ Gmail, Microsoft, Yahoo และ AWS SES ถือว่า 2048-bit เป็น baseline ของปี 2026 — key ขนาด 1024-bit ยังคงตรวจสอบความถูกต้องได้แต่ถูกมองว่าเป็น signal ที่อ่อนแอในตัวกรอง spam ของ enterprise หาก provider อนุญาตให้เลือกขนาดได้ ให้เลือก 2048 การที่ provider มีค่า default เป็น 1024 เท่านั้นถือเป็น signal สำหรับการเลือก provider

ขั้นตอนที่ 2: ตั้งค่า DNS Records

Records สามรายการ ทั้งหมดสร้างที่ DNS provider ของคุณสำหรับ project subdomain ไม่มีรายการใดที่ proxy ผ่าน Cloudflare edge ได้ MX และ TXT record ต้องเป็น DNS-only และ Cloudflare API จะ fallback เป็น DNS-only แบบเงียบๆ หากคุณตั้ง proxied: true แต่ตั้งค่าอย่างชัดเจนจะสะอาดกว่า

MX records สองรายการบอกผู้ส่งว่าจะส่งอีเมลไปที่ไหน mail provider ส่วนใหญ่รัน MX host สองตัวหรือมากกว่าด้วย priority เท่ากันสำหรับ round-robin failover:

POST https://api.dnsprovider.example/zones/<ZONE_ID>/dns_records

{"type":"MX","name":"system.example.com",
 "content":"mx1.de.mailhost.example","priority":10,
 "ttl":3600,"proxied":false}

{"type":"MX","name":"system.example.com",
 "content":"mx2.de.mailhost.example","priority":10,
 "ttl":3600,"proxied":false}

DKIM TXT record ใช้ค่า dkim_record จากขั้นตอนที่ 1 วางไว้ที่ dkim._domainkey.<subdomain>:

{"type":"TXT",
 "name":"dkim._domainkey.system.example.com",
 "content":"v=DKIM1; k=rsa; p=MIGfMA0G...",
 "ttl":3600,"proxied":false}

หาก DKIM public key ยาวกว่า 255 bytes (ซึ่งเป็นกรณีของ RSA key 2048-bit) คุณต้องแบ่งออกเป็น chunk ที่มี quote หลายอัน: "chunk1" "chunk2" DNS provider ส่วนใหญ่จัดการการแบ่งนี้อัตโนมัติใน API หากของคุณไม่ทำ การแบ่ง chunk ต้องทำที่ฝั่งของคุณ

SPF และ DMARC record ที่ตั้งค่าครั้งเดียวบน subdomain เองและบน _dmarc.<subdomain> SPF บอก receiver ว่า IP ใดบ้างที่อนุญาตให้ส่งสำหรับ domain นี้ DMARC บอกว่าจะทำอย่างไรเมื่อ SPF หรือ DKIM ล้มเหลว:

{"type":"TXT","name":"system.example.com",
 "content":"v=spf1 include:spf.mailhost.example ~all",
 "ttl":3600,"proxied":false}

{"type":"TXT","name":"_dmarc.system.example.com",
 "content":"v=DMARC1; p=none; rua=mailto:[email protected]; aspf=r; adkim=r",
 "ttl":3600,"proxied":false}

เริ่มต้น DMARC ด้วย p=none นี่คือโหมด monitoring receiver จะส่ง aggregate report ไปยังที่อยู่ rua แต่ไม่มีอีเมลถูกปฏิเสธตาม policy วิธีการ rollout มาตรฐานคือสองถึงหกสัปดาห์ที่ p=none จนกว่า aggregate report จะแสดงว่าอีเมลที่ถูกต้องสอดคล้องอย่างน้อย 98% จากนั้นค่อยเพิ่มอย่างค่อยเป็นค่อยไปผ่าน tag pct= เช่น p=quarantine; pct=25 สองสัปดาห์ จากนั้น pct=75 จากนั้น pct=100 และสุดท้าย p=reject การข้ามขั้นตอนนี้แล้วไปที่ p=reject ทันทีบน domain ใหม่ล้วนๆ เป็นวิธีที่แน่นอนในการทำให้อีเมลที่ถูกต้องของตัวเองหายไปก่อนที่คุณจะตรวจสอบ DKIM signing path

ขั้นตอนที่ 3: สร้าง Mailbox และ Address Mapping

data model ของ mail provider โดยทั่วไปมีสอง resource แยกกัน ได้แก่ mailuser (IMAP account พร้อม credential และ quota) และ address (string local@domain ที่ routing อีเมลไปยัง mailuser) ทั้งสองแยกกันเพราะ mailuser เดียวกันสามารถเป็นปลายทางสำหรับที่อยู่หลายรายการบน domain เดียวกันหรือต่างกันได้

สร้าง password ที่แข็งแกร่งและสร้าง mailuser naming convention ต่างกันตาม provider รูปแบบทั่วไปคือ <local>_<domain-with-underscores> ระวังขีดจำกัดความยาว provider ส่วนใหญ่จำกัด mailuser name ที่ 32 ตัวอักษร ซึ่งเกินได้ง่ายบน subdomain ที่ยาวกว่า:

import secrets, string
alphabet = string.ascii_letters + string.digits + "!@#%^&*-_=+"
password = ''.join(secrets.choice(alphabet) for _ in range(32))

# จากนั้น:
POST /api/v1/mailuser/create/
[{"name": "bot_system_example_com",
  "imap_server": "<IMAP_SERVER_UUID>",
  "password": password}]

เมื่อ mailuser อยู่ในสถานะ READY ให้สร้าง address mapping ที่เชื่อม local@subdomain กับมัน:

POST /api/v1/address/create/
[{"source": "[email protected]",
  "destinations": ["<MAILUSER_UUID>"],
  "forwards": []}]

array forwards ใช้สำหรับที่อยู่ภายนอกเพิ่มเติมที่ต้องการรับสำเนา ปล่อยว่างไว้หากคุณไม่ต้องการ forward mailbox ไปยัง inbox ของมนุษย์แบบ parallel ซึ่งเป็น pattern ที่มีประโยชน์ในช่วง handover ของโปรเจกต์แต่ยุ่งยากในระยะยาว

ขั้นตอนที่ 4: ตรวจสอบการตั้งค่าแบบครบวงจร

การตรวจสอบสี่อย่างตามลำดับ อย่าข้ามการทดสอบ self-loopback เพราะนั่นคือการทดสอบเดียวที่ยืนยันว่า inbound routing ถึง mailbox จริงๆ

DNS propagation Provider แบบ Cloudflare-class AnyCast โดยทั่วไปจะ propagate ภายในไม่ถึงหนึ่งนาที วน loop จนกว่า record ทั้งสองจะปรากฏ:

for i in $(seq 1 36); do
  mx=$(dig +short system.example.com MX)
  dkim=$(dig +short dkim._domainkey.system.example.com TXT)
  if [ -n "$mx" ] && [ -n "$dkim" ]; then break; fi
  sleep 5
done
echo "MX: $mx"
echo "DKIM: $dkim"

IMAP login ยืนยันว่า credential ใช้งานได้และ mailbox มี inbox รองรับอยู่จริง:

openssl s_client -crlf -connect imap.mailhost.example:993 -quiet
a1 LOGIN bot_system_example_com <password>
a2 SELECT INBOX

response ที่คาดหวัง: a1 OK Logged in ตามด้วย SELECT ที่ยืนยัน EXISTS 0 บน mailbox ใหม่

Self-loopback การทดสอบ end-to-end ที่ดีที่สุด ได้แก่ ส่งอีเมลจากที่อยู่ใหม่กลับมาหาตัวเองแล้วตรวจสอบว่ามาถึงใน IMAP การทดสอบนี้ตรวจสอบเส้นทางทั้งหมด ได้แก่ SMTP authentication, DKIM signing, MX resolution, การรับอีเมล, การส่งไปยัง mailbox, IMAP visibility โดยไม่ต้องพึ่งพาตัวกรอง spam ของ mail provider ภายนอกใดๆ:

import smtplib, ssl, imaplib, time
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "[email protected]"
msg["To"]   = "[email protected]"
msg["Subject"] = "loopback test"
msg.set_content("hello self")

with smtplib.SMTP("smtp.mailhost.example", 587) as s:
    s.starttls(context=ssl.create_default_context())
    s.login("bot_system_example_com", "<password>")
    s.send_message(msg)

time.sleep(10)
imap = imaplib.IMAP4_SSL("imap.mailhost.example", 993)
imap.login("bot_system_example_com", "<password>")
imap.select("INBOX")
typ, search = imap.search(None, "ALL")
print("inbox count:", len(search[0].split()))

ใน header ของอีเมลที่ส่งถึง ให้มองหาบรรทัด Authentication-Results การตั้งค่าที่ถูกต้องจะแสดง spf=pass พร้อม smtp.mailfrom ที่ถูกต้องและ header DKIM-Signature พร้อม d=<subdomain ของคุณ> และ s=dkim หากสิ่งเหล่านั้นมีอยู่ ทุกส่วนของ chain ทำงานได้ ตัวแปรที่เหลือเพียงอย่างเดียวคือ receiver ภายนอกรู้สึกอย่างไรกับคุณ ซึ่ง DMARC report จะบอกคุณในช่วงวันถัดไป

External outbound ส่งอีเมลหนึ่งฉบับไปยังที่อยู่ภายนอกที่คุณตรวจสอบได้ เช่น Gmail ส่วนตัว inbox งานแยกต่างหาก หรืออะไรก็ได้ที่อยู่นอกระบบ ยืนยันว่ามาถึง inbox ไม่ใช่ spam หากตกไปอยู่ใน spam ในการส่งครั้งแรกสุดจาก domain ใหม่ สาเหตุที่พบบ่อยที่สุดคือชื่อเสียงของ sender domain ที่ยังไม่มีอยู่ การ warm up เป็นไปอย่างค่อยเป็นค่อยไป แต่อีเมลทดสอบฉบับเดียวควรผ่านได้อย่างสะอาดเพราะ receiver ประเมิน DKIM และ SPF จากคุณสมบัติของตัวเอง ไม่ใช่จากปริมาณการส่งในอดีต

ปัญหาที่พบบ่อย

ขีดจำกัด 32 ตัวอักษรของ mailuser name จะเกิดขึ้นเมื่อ subdomain บวก local part ของคุณยาวกว่าที่คาดไว้ backoffice_dashboard_system_example_com มีสามสิบเก้าตัวอักษรและถูกปฏิเสธ ส่วน bo_dashboard_system_example_com มีสามสิบเอ็ดตัวอักษรซึ่งพอดี เลือกตัวย่ออย่างมีสติแทนที่จะให้ API บังคับกลางการ deploy

กับดัก Cloudflare proxy UI ของ Cloudflare อนุญาตให้คุณ toggle orange-cloud proxy สำหรับ record ใดก็ได้ สำหรับ A/AAAA บน web origin คุณมักต้องการเปิดไว้ สำหรับ MX record มันต้องปิดเสมอ Cloudflare ไม่ proxy อีเมล กับดักคือเมื่อคุณเปิด proxy แบบ mass ผ่าน script แล้วรวม MX record เข้าไปด้วยโดยไม่ได้ตั้งใจ Cloudflare จะ drop proxy flag แบบเงียบๆ สำหรับ type ที่ไม่รองรับ ดูเหมือนว่าทำงานได้ แต่คุณเสียเวลาหลายนาทีในการ debug ว่าไม่มีอะไรผิดปกติ

Greylisting ในอีเมลขาเข้าแรก ระบบอีเมลบางครั้ง greylist ข้อความแรกจากผู้ส่งที่ไม่รู้จัก response ชั่วคราว 4xx ขอให้ผู้ส่ง retry ภายในไม่กี่นาที Gmail จะ retry อัตโนมัติ หากการทดสอบ smoke test ขาเข้าครั้งแรกดูเหมือนล้มเหลว ให้รอสิบห้านาทีก่อนประกาศว่าพัง

เพดาน DNS lookup ของ SPF SPF มีขีดจำกัดที่แน่นอนของ DNS lookup สิบครั้งระหว่างการประเมิน (RFC 7208 §4.6.4) include:spf.mailhost.example หนึ่งรายการนับเป็น lookup หนึ่งครั้งแม้ว่า include นั้นจะ resolve ไปเป็น IP หลายสิบรายการภายใน คุณจะชนเพดานนี้ก็ต่อเมื่อเริ่มผสม sender หลายราย เช่น การเพิ่ม include:_spf.resend.com ในภายหลังสำหรับ marketing pipeline วางแผน SPF record สำหรับรายการ sender ระยะยาว ไม่ใช่แค่รายแรก

dkim_privkey ว่างเปล่าฝั่ง mail provider บาง provider เปิด endpoint สร้าง domain ที่สำเร็จแต่ไม่ได้สร้าง DKIM key จริงๆ ต้องการ call แยก "enable DKIM" ตรวจสอบว่าฟิลด์ dkim_record ใน create response ของคุณไม่ว่างเปล่าก่อนดำเนินต่อ หากว่างเปล่า ให้ตรวจสอบเอกสารของ provider สำหรับ call รอง

การ monitoring การ deploy อย่างไม่รอบคอบ หากคุณดูแล domain หลายสิบรายการ DKIM record ที่ไม่ดีหรือปลายทาง DMARC report ที่หมดอายุจะไม่ปรากฏใน routine monitoring เว้นแต่คุณจะตรวจสอบอย่างตั้งใจ ขั้นตอน health check รายเดือนของเราสำหรับ self-hosted service มีขั้นตอน mail-record audit รวมอยู่ด้วยเพื่อเหตุผลนี้

การข้าม MTA-STS ที่มีให้ใช้งาน MTA-STS เผยแพร่ policy ที่บังคับให้ผู้ส่งใช้ TLS กับ MX host ของคุณและตรวจสอบ certificate Gmail, Microsoft 365 และ Yahoo ตรวจสอบสิ่งนี้ การนำไปใช้งานทั่วอินเทอร์เน็ตยังอยู่ต่ำกว่าหนึ่งเปอร์เซ็นต์ ดังนั้น policy ที่ valid จึงเป็น signal ชื่อเสียงเล็กน้อย ข้อแลกเปลี่ยนคือ operational: policy ที่ชี้ไปยัง MX host ที่ล้มเหลวการตรวจสอบ TLS จะบล็อก inbound ที่ถูกต้อง หาก provider ของคุณเปิด MTA-STS ให้ enable หลังจาก DKIM และ DMARC เสถียรแล้ว

เส้นทาง Rollback

หากการตรวจสอบล้มเหลวหรือคุณตัดสินใจว่าโปรเจกต์ไม่จำเป็นต้องมี mailbox เป็นของตัวเอง การทำความสะอาดเป็น idempotent และใช้เวลาห้านาที:

  1. POST /api/v1/address/delete/ พร้อม address UUID
  2. POST /api/v1/mailuser/delete/ พร้อม mailuser UUID
  3. POST /api/v1/domain/delete/ พร้อม mail-system domain UUID (การนี้จะลบ DKIM key ด้วย)
  4. DELETE /zones/<zone>/dns_records/<id> สำหรับแต่ละ DNS record สามรายการ

ลำดับมีความสำคัญเพราะ provider บางรายปฏิเสธการลบ domain ในขณะที่ยังมี address ติดอยู่ การทำในลำดับย้อนกลับยังให้จุดที่เหมาะสมในการหยุดและตรวจสอบ หากขั้นตอนที่ 1 ล้มเหลวเพราะมีอีเมลใน mailbox ที่คุณลืมไป คุณยังไม่ได้ทำลาย routing ระดับ DNS

การทิ้ง SPF และ DMARC record ไว้บน subdomain หลัง rollback ไม่เป็นอันตราย พวกมันตรวจสอบกับอะไรไม่ได้ แต่ก็บอก receiver ในอนาคตว่า subdomain นี้ไม่ได้ส่งอีเมลที่ถูกต้องอย่างชัดเจน ซึ่งเป็นประโยชน์เล็กน้อยในการป้องกัน spoofing เราถือว่าพวกมันเปิดโดย default เมื่อมีอยู่แล้ว การคิดแบบ "ของตกค้างที่ปลอดภัย" นี้เป็นตรรกะเดียวกับที่เราใช้กับ disaster recovery สำหรับ self-hosted service: รูปแบบ cleanup-after มีความสำคัญพอๆ กับรูปแบบการติดตั้ง

สรุป

Mailbox เฉพาะโปรเจกต์ไม่ใช่ infrastructure มันเป็น operational primitive เล็กๆ ที่ทำให้ AI Agent หรือกระบวนการอัตโนมัติอื่นๆ กลายเป็นผู้เข้าร่วมชั้นหนึ่งใน workflow ที่ใช้อีเมล รูปแบบ API call สี่ครั้งข้างต้นสามารถ port ได้อย่างสะอาดระหว่าง mail provider ส่วน DNS record ก็ port ได้อย่างสะอาดระหว่าง DNS provider สิ่งที่คุ้มค่าที่จะทำให้ถูกต้องคือขอบเขตระหว่างสองระบบ ว่า record อยู่ที่ไหน failure mode มีลักษณะอย่างไร และจะตรวจสอบ end-to-end อย่างไรโดยไม่ต้องพึ่งพาตัวกรอง spam ของ counterparty ภายนอกว่าจะทำงานได้

หากคุณต้องการความช่วยเหลือในการออกแบบ stack เฉพาะโปรเจกต์ ไม่ว่าจะเป็น Telegram agent, mailbox, document intake หรืออื่นๆ tva สามารถช่วยได้

Insights ที่เกี่ยวข้อง

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

การสร้าง AI Assistant เฉพาะโปรเจกต์ผ่าน Telegram

ปรับจูน Hermes-Style Agent ให้เติบโตไปพร้อมกับโปรเจกต์

การสร้าง AI Agent Skill สำหรับ Workflow ธุรกิจเฉพาะทาง