用自有網域寄信
機器人可以用 你自己網域 上的位址（例如 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 記錄就會顯示在畫面上。
三筆都是網域 DNS 中的 TXT 記錄。在你管理網域的地方新增：註冊商的控制台或 DNS 服務商處。
下面的值以 example.com 為例，請換成你自己的網域。你網域的正確取值顯示在後台的網域卡片上，請從那裡複製，尤其是 DKIM：它的值包含你自己的公鑰，每個網域各不相同，無法從文件中照抄。
畫面上每筆記錄被拆成兩個獨立欄位——「Host」 與 「Value」，各自帶一個 「Copy」 按鈕。請逐個複製到 DNS 服務商對應的輸入框：這兩部分不能當成一整塊貼上。
| 類型 | 記錄名稱（host） | 值 |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= 後接後台提供的長金鑰 |
| TXT | example.com（網域根） | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
最容易出錯的兩點：
- 許多控制台會自動把網域接到記錄名稱後面。若名稱欄已顯示「.example.com」，就只填
mybot._domainkey，不要填全名，否則會變成mybot._domainkey.example.com.example.com。 - DKIM 的值很長，金鑰內部不能有換行與空白。請用複製按鈕，不要用滑鼠拖曳選取。
若網域已經有 SPF 記錄
一個網域只能有 一筆 SPF 記錄。若你已透過主機、CRM 或其他電子報服務寄信，那筆記錄已經存在。不要再加第二筆——在既有記錄中、結尾的 ~all 之前補上一個 include：
v=spf1 include:spf.yourprovider.tw include:esp.getmybot.dev ~all
一個網域上有兩筆 SPF 記錄，與一筆都沒有是同樣的錯誤：驗證無法通過，因為收信方不知道該相信哪一筆。
請注意：透過別人的記錄「被涵蓋」並不算數。即使你目前的服務商在自家 SPF 裡包含了我們，我們的 include 也必須直接出現在你的記錄中——原因見下文的網域驗證一節。
SPF 為何用 include 而不是 IP 位址
最常見的錯誤，是把在郵件標頭或論壇貼文裡看到的 IP 位址貼上去。請不要這樣做。
include:esp.getmybot.dev 指向我們自行維護的寄信伺服器清單。今天這個名稱背後只有一台中繼伺服器。明天它們可能變多、可能搬遷、可能被替換。屆時我們會在自己這邊更新清單，而 你的記錄照常運作，什麼都不必動。這正是它的意義所在：位址只在一個地方改變，而不是在每位客戶的 DNS 裡改變。
手寫的 IP 位址會在那一刻直接失真。信件開始在 SPF 上失敗，而且毫無預警——後台不會報錯，也不會有通知。你只會從「什麼都沒收到」的客戶那裡得知。
請原樣寫 include:esp.getmybot.dev，不要再加上任何東西。
網域驗證
網域驗證 就是平台自己去查你網域的 DNS，確認三筆記錄都沒問題。三筆全部通過，網域即成為 已驗證，寄信隨之放行。只要有一筆沒通過，網域就一直處於等待狀態。
檢查的不只是「記錄存在」：
| 記錄 | 實際檢查什麼 |
|---|---|
| DKIM | 記錄已發佈，且包含 你自己的 公鑰。別人的 DKIM，或換金鑰後殘留的舊值，都不算通過。 |
| SPF | 記錄存在，而且直接包含 include:esp.getmybot.dev。形似的值，例如 include:esp.getmybot.dev.other-domain.example，不算數。 |
| DMARC | 已發佈一筆記錄且以 v=DMARC1 開頭。政策本身（p=、rua=）不檢查——那是你的決定，不是給我們的授權。 |
DMARC 檢查為何較寬鬆：它告訴收信方 如何處理 DKIM 與 SPF 的結果，卻不賦予我們以你的名義寄信的權利。那份權利只來自前兩筆記錄，而這兩筆都做了完整的內容驗證。
別人的 include 不算數
include:esp.getmybot.dev 必須寫在 你自己的 SPF 記錄裡。若你的 SPF 包含了某家第三方服務商，而那家的記錄又包含了我們，驗證不會認可：平台不會展開別人的 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 加到你已有的東西裡。
若驗證未通過：
- 先看三筆記錄中哪一筆標著「Not passing」、它的說明寫了什麼，再依它處理。
- 確認記錄確實已發佈——許多控制台需要另外按一下「套用變更」。
- 檢查記錄名稱是否出現網域重複（見上文）。
- 確認網域上只有一筆 SPF 記錄，而且我們的 include 就在那筆記錄裡面。
- 稍等片刻再檢查一次：變更可能還沒擴散開來。
驗證通過前無法寄信——這是刻意設計
只要網域尚未通過驗證，信件 就不會寄出。不是「寄出去了但進垃圾郵件」，而是根本不出門：寄送嘗試會以「網域未驗證」的錯誤結束，並記錄在日誌中。
這是刻意設計，不是故障。來自未曾為自己背書的網域的信件，最終會變成垃圾郵件檢舉，而檢舉會傷害平台所有客戶共用的寄信基礎設施的信譽。不寄出一封信，遠比寄出去之後花半年從黑名單爬出來划算。因此這裡是禁止，而不是提醒。
看到這個錯誤時，先檢查 DNS 記錄並按一次檢查，再聯絡客服。絕大多數情況只是記錄名稱裡的一個筆誤。
退訂、檢舉與投遞失敗
三條事先不知道就會覺得意外的規則。
每封行銷信件都帶有一鍵退訂。 平台會自動在信件頁尾加入退訂連結，並加上對應的技術標頭，郵件軟體據此在寄件者位址旁畫出「取消訂閱」按鈕。這一點無法移除——設定裡不行，改版型也不行。退訂立即生效，不必開信，也沒有確認步驟。Gmail 等主流服務對大量寄件者就是這樣要求的：缺少它的信件必然進垃圾郵件。
退訂是終局，介面上無法撤銷。 已退訂的位址不會再收到這個機器人的信。既沒有「還原」按鈕，也不能靠重新匯入名單繞過：退訂絕不會越過本人意願被取消。只有本人才能回來——在你的訂閱表單中重新留下位址。
還有更嚴格的一種情況：若有人在郵件軟體按了 「這是垃圾郵件」，該位址將被永久關閉。即使透過你的表單重新訂閱也打不開——因為我們已經知道上一次的結果，而繼續寄給這類位址，是摧毀網域信譽最快的方式。因法律要求被人工關閉的位址亦同。
硬退信會永久封鎖該位址。 若收件方伺服器回覆「沒有這個信箱」，該位址會被標記為無法投遞並從後續寄送中剔除。這不是暫時狀態：繼續敲一個不存在的信箱，是連同其餘所有位址一起掉進垃圾郵件過濾器的最快途徑。
軟退信（信箱已滿、伺服器暫時無法連線）不會 關閉位址——寄送繼續。
為何「開信數」偏低
郵件統計中有開信數，而它永遠低於真實值。這不是統計出錯，而是開信這件事本身的量測方式所致。
開信是這樣記錄的：郵件軟體在顯示信件時，從伺服器載入一張極小的追蹤圖片。現代軟體預設不載入遠端圖片；而那些會載入的（Apple Mail 及類似的隱私機制）則會提前替所有人載入，包含從未開信的人。前者讓開信被漏掉，後者把開信記到根本不在場的人身上。要更精確地統計開信，沒有任何辦法——我們沒有，別人也沒有。
因此介面在這個數字旁附上說明：它是 下限，而不是精確值。可以用它來橫向比較不同信件（同樣的偏差對所有信件一視同仁），但不要把它當作「有多少人讀了這封信」的答案。
若需要可靠的互動指標，請看 「Link clicks」。點擊連結是真人真實的動作，沒有誰會替他提前點。「Delivered」、「Unsubscribes」、「Complaints」 與 「Bounces」 同樣是精確的：它們由郵件伺服器回報，而不是由信中的一張圖片決定。這些都在同一個 Email 頁面的 「Sending stats」 區塊裡。