關於本影片

影片中的地址均為範例。文件驗證需要付費帳號。

影片文字稿

1. 00:00你在建置什麼

   冷郵件靠三樣東西運作：你擁有的網域、你能控制的郵箱，以及一個仍然有效的寄信登入。預算表裡常把三樣東西混為一談。帳號是一個郵箱身分，名單是聯絡人資料，開通（provisioning）則是在你控制的網域上建立寄信能力。只有最後一項才是基礎架構。有個簡單的測試：你能說出每個郵箱是誰建立的嗎？今天由誰在營運？誰擁有管理權限？三個問題都答得上來，這份寄信能力才算是你的。

2. 00:34網域與郵箱

   先從你擁有的網域開始。條件合適時，用與主品牌分開的網域寄信。這樣你對信譽的控制更清楚，也能把風險擋在核心網域之外。然後給每個網域加幾個郵箱。每個收件匣都需要一位負責人、一份書面的用途說明和一項存取政策，否則資安團隊接手的就是沒人能解釋的憑證。接下來，為每個寄信網域做驗證設定。SPF 指明哪些伺服器可以代表這個網域寄信。DKIM 附上一個收件方可以驗證的簽章。DMARC 把這些結果與可見的 From 網域關聯起來，並為驗證失敗設定處理政策。然後放慢節奏。新郵箱需要循序漸進地提升寄信量。如果一下子塞進大量郵件，再乾淨的設定也白費了。

3. 01:18SMTP 健康

   接下來是大多數團隊會跳過的部分。郵件投遞要回答兩個不同的問題：這個應用程式能不能透過這台伺服器提交郵件？收件方該不該信任這個網域？SMTP 驗證回答第一個問題，SPF、DKIM 和 DMARC 回答第二個。可以想成員工識別證和公司信紙：識別證讓你進門，信紙向外界表明你是誰，有了一個不等於有了另一個。登入有固定的順序。你的應用程式連線後傳送 EHLO，伺服器列出它支援的方式，應用程式選擇一種並傳送 AUTH。代碼 235 表示接受，535 表示拒絕。而 535 並不總是密碼錯誤，也可能是帳號被封鎖、登入方式被停用，或者服務商拒絕傳統的登入方式。密碼正確並不能說明問題已經解決。連接埠也很重要。25 埠主要用於伺服器之間的中繼，587 埠用於郵件提交，通常搭配 STARTTLS，465 埠從一開始就是加密的。如果用戶端和伺服器預期的不一致，在登入之前就會失敗。這裡有一條規矩：永遠不要靠關閉 TLS 來解決登入失敗，那樣可能暴露憑證，而真正的問題依然存在。密碼不變，也可能失效，因為服務商正在從基本登入轉向 OAuth。微軟計劃在 2026 年 12 月之後，對現有的 Exchange Online 租用戶預設停用基本 SMTP 驗證。所以要把它們都記下來：每個提交郵件的 CRM 工作流程、表單、帳單應用程式和指令碼。對每一個，記錄帳號、連接埠與加密方式、登入方式和負責人。

4. 03:03逐一測試故障

   然後有意識地測試四種故障。提交：應用程式能透過 TLS 登入嗎？網域：你的記錄與 From 地址一致嗎？資料：新地址和匯入的地址有沒有檢查過？信譽：退信和投訴有沒有在上升？登入成功只能證明一件事：你可以提交郵件。它並不能證明對方的郵箱真的存在。驗證會查詢網域的 MX 記錄，然後與接收方伺服器進行一次 SMTP 對話，不會寄出任何郵件。有些伺服器對每個地址都說可以，BillionVerify 把這類地址回報為 catch-all，而未知結果不收費。單個檢查可以使用每天的免費積分，驗證文件則需要付費帳號。擁有網域，指定負責人，測試登入，檢查地址。這樣的設定，你可以衡量、修復，也能長期維護。

5. 03:54免費開始

   每天使用帳號可獲得 20 個免費積分，每月最多 600 個，無需信用卡。造訪 billionverify.com 開始使用。

本影片中展示的工具

• 批量購買電子郵件帳號：風險與替代方案指南