2026 年自架電子郵件還值得嗎？

簡短答案

只要把工作拆成兩部分，2026 年自行架設電子郵件服務仍然值得。透過自己的 VPS 接收郵件風險低，而且能正常運作，因為你是接收方，不需要任何人信任你。要寄出大型信箱服務商願意接受的郵件，則是另一項工作。這取決於你繼承的 IP 位址信譽，而不是你自行建立的信譽。

有經驗的操作者實際採用的是混合式架構。自己的伺服器負責保存信箱與封存郵件，對外寄信則透過連接埠 587 上經過驗證的 relay 傳送。雙向完全自行架設在少數特定情境下仍有優勢，相關情況會在本文接近結尾處說明。

自架電子郵件最困難的部分是確保寄達率

安裝郵件伺服器只需一個週末。現代化的堆疊可透過單一 compose 檔案提供 SMTP（simple mail transfer protocol）來傳送郵件、IMAP（internet message access protocol）來讀取郵件、垃圾郵件過濾及 webmail 介面，而 在 VPS 上安裝 Mailcow 郵件伺服器已涵蓋這些內容。安裝本身並不困難。

困難始於您的伺服器向一台由陌生公司管理的機器建立連線，要求對方將郵件放入某人的收件匣。對方沒有理由接受。它會根據多項訊號做出判斷：連線 IP 位址的信譽、您的網域信譽、郵件是否經過驗證，以及對方使用者過去如何處理您的郵件。新寄件者完全沒有歷史紀錄，而沒有歷史紀錄不會被視為中立。系統會將其評估為風險。因此，最初的郵件會進入垃圾郵件資料夾，或在建立足夠模式前暫緩處理。

您會看到拒信。Gmail 會傳送以下格式的永久拒絕訊息：

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft 會傳送不同的訊息，結尾是會變動的封鎖清單代碼：

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

先讀取第一個數字。以 4 開頭的代碼代表暫時性錯誤，因此您的伺服器會保留郵件並重試。以 5 開頭的代碼代表永久性錯誤，因此郵件會立即退回寄件者。持續重複的 4xx 延遲通常是速率限制或信譽限制，可能自行解除；不過，某些 4xx 代碼，例如 Gmail 在收件者收件匣容量已滿時使用的 452 4.2.2，只有在有人處理問題後才會解除。5xx 會永久結束這次傳送嘗試：您的伺服器會停止重試，只有修正原因並重新傳送後，郵件才可能寄達。

為什麼新伺服器寄出的郵件會進入垃圾郵件？

因為這個 IP 位址並不是真正的新位址。你不會取得全新的位址，而是從供應商的位址池取得回收再用的位址，該位址的歷史也會一併保留。如果前一位使用者曾寄送垃圾郵件，你的第一封郵件可能在你寄出第二封之前就遭到拒收。

在此位址上建置任何服務前，先檢查該位址。公開封鎖清單會透過 DNS 回應查詢，並將位址的 4 個八位元組反轉：

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

空白回應表示該位址未列入清單。像 127.0.0.2 這樣的回應表示已列入清單，最後一個八位元組則表示符合的是哪個清單。例外是 127.255.255.0/24 範圍；Spamhaus 保留此範圍供查詢錯誤使用，與該位址本身無關。這項測試有一個常見陷阱：Spamhaus 會拒絕來自大型公共解析器的查詢，因此透過 8.8.8.8 執行相同查詢時，不論實際狀態為何都會回傳 127.255.255.254。這個代碼表示查詢遭到拒絕，不表示該位址已列入清單。請透過自己伺服器的解析器執行查詢，或改用網頁查詢工具。

乾淨的結果是必要條件，但仍然不夠。未列入清單只表示近期沒有人檢舉該位址。這不代表它具備正面聲譽，而真正能讓郵件進入收件匣的是正面聲譽。正面聲譽必須透過數週持續寄送少量、收件者需要的郵件來建立。

鄰近位址也會影響結果，因為部分收件伺服器會以整個網路區塊，而不是單一位址，來評估聲譽。同一個 /24 範圍內的其他客戶開始寄送垃圾郵件時，你的郵件可能因連帶關係而被延遲。這種以區塊為單位的評估方式，也是為什麼 VPS 收件匣會收到帳戶持有人從未傳送之流量的濫用檢舉：檢舉是依位址範圍送達。

開始前要確認的事項：port 25 與 PTR 記錄

對外 TCP port 25 是網際網路上最常遭濫用的連接埠，因此許多 hosting provider 會在新帳戶上預設封鎖它。有些 provider 會在收到申請後開放。有些會等帳戶建立一段時間且具備付款紀錄後才開放。有些則永遠不會開放。有些 provider 也會封鎖 submission port 465 與 587，這會影響本文後續的 relay 設定。各 provider 的政策不同，也會隨時間變更，因此不要把本文、舊論壇文章或任何 provider 的行銷頁面視為目前有效的資訊。請先詢問，並在付款前取得書面答覆。

從伺服器本身測試連線路徑：

nc -vz gmail-smtp-in.l.google.com 25

連線路徑開放時，會在一秒內輸出 succeeded!。連線受阻時，指令會先停住，最後逾時，且不會顯示指出封鎖原因的訊息，因為遭靜默丟棄的封包看起來和一般網路問題完全相同。

第二項要求是 PTR 記錄，也稱為 reverse DNS。接收端會取得與其建立連線的 IP 位址，查詢該位址的 PTR 記錄以取得名稱，再查詢該名稱以取得位址。兩者相符時，稱為 forward-confirmed reverse DNS。這是一項成本低廉的檢查，可確認連線主機確實屬於其聲稱的擁有者。

dig -x 203.0.113.5 +short
dig +short mail.example.com

第一項查詢必須回傳您的郵件主機名稱。第二項查詢必須回傳您一開始使用的相同位址。只有 IP 位址的擁有者能發布其 PTR 記錄，因此這項設定必須由您的 host 代為設定，或在 control panel 中提供設定介面。缺少 PTR 記錄，或使用 203-0-113-5.static.example-isp.net 這類通用名稱，都是明顯的不利訊號，因為實際的郵件伺服器幾乎都有相符的名稱，而大量垃圾郵件來源通常沒有。

如果您的 host 也提供 IPv6，且伺服器偏好使用 IPv6，以上所有要求同樣適用於 IPv6 位址，而且 Gmail 對此更嚴格。從沒有 PTR 記錄的 IPv6 位址透過 IPv6 寄信時，會遭到拒絕，並顯示郵件不符合與 PTR 記錄及驗證相關的 IPv6 寄信準則。如果您無法設定 IPv6 PTR 記錄，請只透過 IPv4 寄送。在 Postfix 中，使用 smtp_address_preference = ipv4 可優先使用 IPv4，使用 inet_protocols = ipv4 則可完全關閉 IPv6。

詢問任何 host 的 3 個問題

1. 新帳戶的對外 TCP port 25 是否開放？如果未開放，開放它的確切流程與處理時間為何？
2. 我能否設定 IPv4 位址與 IPv6 位址的 PTR 記錄？應在哪裡設定？
3. 如果我的位址因為前一位客戶而被列入 blocklist，你們是否會將我移至其他位址？

請在購買前詢問全部 3 個問題，不要等到購買後才詢問。能清楚回答前兩題、但第三題回答否的 host 仍可使用，因為您可以在第 1 天檢查位址並取消服務。不願以書面回答任何一題的 host，已經告訴您在該處執行郵件服務會是什麼情況。

SPF、DKIM 與 DMARC 實際能證明什麼

3 筆 DNS 記錄可證明聲稱來自您網域的郵件確實由獲授權的來源寄出。每一筆記錄回答不同的問題，而第 3 筆只有在了解前 2 筆後才有意義。

SPF（sender policy framework）是 TXT 記錄，列出哪些伺服器可以代表您的網域寄送郵件。收件端會將它與 envelope sender 比對，也就是 SMTP MAIL FROM 命令提供的位址；這不是讀者看到的 From: 標頭。

DKIM（domainkeys identified mail）會在郵件標頭加入密碼編譯簽章，涵蓋郵件本文與指定的標頭清單。對應的公開金鑰會依您選擇的 selector 存放在 DNS 中。任何人都能驗證郵件來自持有您私密金鑰的一方，且傳送途中未遭修改。

DMARC（domain-based message authentication, reporting and conformance）會將前 2 項驗證結果繫結至可見 From: 標頭中的網域，並告知收件端繫結失敗時應採取的處理方式。

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

關鍵在於 alignment。DMARC 不會因為 SPF 通過就通過。只有在 SPF 或 DKIM 通過，且通過驗證的網域與 From: 標頭中的網域相同時，DMARC 才會通過。這也是轉送郵件會悄悄失敗的原因：將 envelope sender 改寫為自身網域的 relay 仍可通過 SPF，但通過驗證的網域屬於 relay，因此未對齊。除非您自己的 DKIM 簽章存在且有效，否則 DMARC 會失敗。使用發布於您網域下的金鑰簽署後，這個問題就會消失。

Alignment 也能解釋轉寄問題。當 mailing list 或舊的大學信箱將您的郵件轉寄出去時，轉寄伺服器會成為連線 IP 位址，但它不在您的 SPF 記錄中，因此郵件抵達最終目的地時 SPF 會失敗。只要簽署的標頭未被修改，DKIM 就能通過轉寄程序。必須依賴 DKIM 正常運作。

先發布 p=none，並設定 rua= 報告位址。接著讀取 2 週的彙總報告，再逐步收緊政策。這些報告是您唯一能看見他人冒用您的名義寄信的位置，也是找出您遺漏之轉寄服務的唯一方法。直接設定 p=reject 會跳過這個步驟，並在沒有留下故障記錄的情況下中斷合法郵件。

接著端到端測試整條流程。將 1 封郵件寄到您在大型供應商持有的帳戶，然後開啟郵件的原始來源：

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks 會即時輸出 SMTP 交談內容。Postfix 在交付完成時產生的記錄行，若收件伺服器接受郵件，結尾會是 status=sent (250 2.0.0 OK ...)。其他內容會逐字記錄拒絕文字，請搜尋該字串。在已交付郵件的原始來源中，Authentication-Results: 標頭會列出每項檢查、其 pass 或 fail 結果，以及通過驗證的網域。3 項都必須顯示 pass，而且網域必須是您的網域。

如何查明信譽問題？

回饋迴圈是一種機制。信箱服務提供者會在其使用者按下「回報垃圾郵件」按鈕時，將該郵件的副本傳給你。沒有回饋迴圈時，第一個問題徵兆通常是郵件已經投遞失敗，而這時往往已經晚了數週。

各項計畫的運作方式不同，而且並非全部都適用於只有一個位址的單一 VPS。截至 October 2026，Microsoft 提供依位址運作的資料與投訴服務，位址擁有者可以註冊使用；Yahoo 提供以 DKIM 簽署網域為識別依據的投訴回饋迴圈；Google 則在 Postmaster Tools 儀表板中提供垃圾郵件比率等彙總資料，而不是個別投訴。若你尚未向其使用者寄送具一定規模的每日郵件量，這些儀表板可能維持空白或資料不完整。依賴任何服務前，請先閱讀各服務目前的條款，因為這些計畫可能變更，而且沒有任何服務有義務讓你使用。

Google 公布的批次寄件者要求自 February 2024 起生效，是大型收件服務目前要求的最明確公開說明。每天向個人 Gmail 帳戶寄送超過 5,000 封郵件的寄件者，必須使用 SPF 與 DKIM 進行驗證、發布 DMARC 政策、在批次郵件中提供單鍵取消訂閱功能，並將垃圾郵件投訴率維持在 0.3 percent 以下。小型伺服器寄送的個人郵件遠低於這個門檻，但所有寄件量都會受到相同訊號的評估；其中，沒有回饋迴圈就無法得知投訴率。

可行的拆分方式：自行接收郵件，透過 relay 寄出郵件

接收郵件幾乎沒有缺點。沒有人需要信任你，才能接受寄給你的郵件。你的 MX record，也就是指定網域郵件交換伺服器的 DNS record，會指向你的伺服器。寄件者會連線到你，而後續每個決定都由你負責：保留哪些郵件、保留多久、如何建立索引，以及誰可以搜尋。儲存空間成本低，而且你擁有的封存資料不會因其他地方的自動化政策決定而遭到關閉。這項工作確實存在，但範圍明確：維持垃圾郵件篩選器更新、持續更新 TLS（transport layer security）憑證、保留備份，並避免磁碟空間用盡。

寄出郵件時，才是你需要付費避開棘手問題的地方。將伺服器設定為透過 port 587，將所有外寄郵件交給經過驗證的 relay，而不是透過 port 25 直接與外界通訊。在 Postfix 的 main.cf 中：

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

使用編輯器將認證資訊寫入 /etc/postfix/sasl_passwd，避免密碼進入 shell history。這是一行設定，而且左側的主機名稱必須與 relayhost 中顯示的內容完全一致：

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

重新載入後寄出的郵件會記錄 relay=smtp.relay.example[...]:587 和 status=sent。如果日誌行顯示 SASL authentication failed，表示認證資訊未被接受。常見原因是 sasl_passwd 中的主機名稱與 relayhost 中的寫法不同，因為查詢會進行完全字串比對。

這種拆分方式有效，是因為 relay 擁有累積多年成功寄信紀錄的地址，而維護這項信譽就是其主要業務。你仍保有網域、信箱、封存資料，以及離開的能力，因為更換 relay 只需修改一行設定和一筆 DNS record。你放棄的是 relay 業者對外寄郵件的機密性。這就是這種安排的實際代價，應該事先決定，而不是事後才發現。

第一天就值得再進行一項分離設定。所有大量寄送的郵件都應從專用子網域寄出，並使用專用的 DKIM key：電子報使用 news.example.com，個人郵件使用 mail.example.com。信譽會附加在寄件網域上，因此 自行代管的 Listmonk 電子報若收到較高的投訴率，就不會連帶影響你的個人郵件。

完整自架仍然適用的情況

數量。每月數百封郵件時，按郵件計費的 relay 通常負擔得起；到了數百萬封，就不再划算。達到這個規模後，你可以負擔專用 IP 位址，以及讓這些位址建立信譽所需的 warmup 排程。

管轄權。當法規或合約要求郵件不得儲存在第三方磁碟上時，投遞品質就不是決定因素。你根本無法使用 relay。

無法購買的控制權。保留規則可依照你的政策，而不是方案層級；每項服務使用不同的位址，方便追查洩漏來源；篩選功能執行你自己的程式碼；也不會由無申訴機制的系統決定停權。

郵件完全不離開你的網路。警示與其他機器對機器郵件完全沒有投遞問題，因為兩端都由你管理。由本機 SMTP 伺服器將郵件投遞到你自己的信箱，就是完整的解決方案。這也是透過 MCP（model context protocol）為助理提供專用自架信箱時採用的模式。若負責發送警示的機器位於其他地方的私有網路，則可在 VPS 上設定 Tailscale 子網路路由器，讓這些機器連往該信箱，完全不必向網際網路公開連接埠。

如果你確實要直接對外寄信，請先讓位址逐步建立信譽。每日先以低數量寄給預期會收到你郵件的人，在數週內逐步增加數量，絕不要從沒有歷史紀錄的位址突然大量寄信。信譽來自長期被接受且少有抱怨的郵件，因此，沒有歷史紀錄的位址突然出現寄送高峰，看起來就和伺服器遭到入侵完全相同，也會被同樣處理。

執行郵件伺服器的第一年要花多少成本？

第一週是建置期：安裝套件、設定 DNS 紀錄與 TLS 憑證、傳送第一批測試郵件，以及將 DMARC 設為 p=none。

第 2 到第 6 週是沒有人會事先規劃的部分。你會閱讀 DMARC 彙總報告，找出原本不知道的對齊問題，發現破壞 SPF 的轉寄服務，接著將政策改為 p=quarantine，之後再改為 p=reject。這段期間會決定自架郵件是否成為你的例行工作，或變成讓你厭煩的事情。

之後大致會穩定在每月約 1 小時：更新套件、確認憑證已續期而不是假設它會自動完成、從備份測試還原、查看磁碟使用量成長情況，以及查詢 1 次封鎖清單。

此外，還有無法排程的那一週。某個位址因為你沒有做過的行為而被列入封鎖清單。大型收件方變更規則，導致你的郵件再次進入垃圾郵件資料夾。佇列中的郵件不等於遺失的郵件：Postfix 預設會重試傳送延遲的郵件 5 天，這項設定由 maximal_queue_lifetime = 5d 控制，因此持續數小時的中斷通常只會造成延遲，不會造成其他損失。例外情況是某封郵件在中斷開始前就已延遲數天，可能會在中斷期間達到這項限制，並退回給寄件者。持續 1 週的中斷則會造成郵件遺失。

備援 MX 紀錄的效果不如表面上看起來可靠。寄件伺服器本來就會自行重試數天，因此只負責排隊的次要伺服器幫助有限。更嚴重的是，如果次要伺服器接受寄往你網域的郵件，卻不知道哪些位址確實存在，就會接收寄往不存在位址的郵件，接著將其退回偽造的寄件者，讓你的備援伺服器成為 backscatter 的來源。應將時間花在監控，以及實際測試過的還原程序上。

請用你評估這台伺服器其他項目時會問的問題來判斷整體價值：擁有這項服務，是否能提供你無法購買的東西？對信箱與郵件封存而言，答案通常是肯定的。對寄送郵件給陌生收件者而言，答案通常是否定的。這也是評估其餘 2026 年值得自架的項目清單 時所用的相同標準。

FAQ

如果 VPS 供應商封鎖對外連線埠 25，我還能自行架設電子郵件嗎？

可以接收郵件，也可以透過 relay 傳送郵件。傳入郵件會抵達伺服器的 25 埠，因此對外連線遭封鎖不會影響收信。對外郵件則會透過已驗證的 relay，從 587 埠送出；大多數供應商都會開放此連接埠。但並非所有供應商都如此：例如 DigitalOcean 預設會封鎖每個 Droplet 的 25、465 和 587 埠，因此也要詢問 587 埠是否受限；若該連接埠也已關閉，請確認 relay 是否提供其他連接埠或 HTTPS 傳送 API。當 25 埠關閉時，無法直接將郵件投遞到其他郵件伺服器，因為伺服器之間的郵件傳遞按定義使用 25 埠。使用 nc -vz gmail-smtp-in.l.google.com 25 進行測試。若連線停滯後逾時，表示該連接埠遭到封鎖。

為什麼 SPF、DKIM 和 DMARC 都通過，郵件仍會進入垃圾郵件？

驗證只能證明郵件由誰寄出，不能證明收件者需要這封郵件。3 項驗證全部通過，只能讓你的郵件從未識別狀態變成已識別；接著，收件方會評估你的 IP 位址與網域信譽，而新的寄件者尚未建立這些信譽。請持續數週傳送少量、收件者預期會收到的郵件，逐步建立信譽。接著確認 PTR 記錄與郵件主機名稱能雙向對應，並檢查郵件內容本身沒有造成額外扣分，例如使用縮網址服務或不熟悉的追蹤網域。

自行架設郵件伺服器需要專用 IP 位址嗎？

若要直接對外投遞郵件，需要。郵件伺服器需要一個由你控制 PTR 記錄、且信譽只屬於你的位址；VPS 位址本身已符合專用位址的定義。但你無法控制該位址的歷史紀錄，也無法控制同一網路區段中的鄰近位址。若改用 relay 傳送對外郵件，relay 的位址會承擔信譽，而你的位址只需接受傳入連線。

將主要郵件位址移到自行架設的伺服器安全嗎？

請分階段遷移，不要一次切換。維持現有信箱運作，將自有伺服器加入為第二個目的地，並在數週內轉寄副本到該伺服器，同時查看 DMARC 報告並確認雙向郵件流量正常。等測試郵件持續一週正確抵達後，再變更 MX 記錄。最容易造成遺憾的是切換過程遺失傳入郵件，而傳入郵件遺失後無法重建。

要維持郵件控制權，最精簡的架構是什麼？

由自有伺服器負責信箱與封存，對外郵件則交由 587 埠上的已驗證 relay 傳送。你能掌握資料與網域，也能完全避開信譽問題。日後即使改變決定，變更成本仍然很低，因為 relay 只需修改一行設定與一筆 SPF 記錄，之後替換它只需一個下午。