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 延後處理通常表示速率限制或信譽限制，可能會自行解除。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.0/8 內的回應表示該位址已列入清單，最後一個八位元組則表示符合哪個清單。這項測試有一個常見陷阱：Spamhaus 會拒絕經由大型公共 DNS resolver 傳入的查詢，因此，透過 8.8.8.8 執行相同查詢時，不論實際狀態為何，都會回傳 127.255.255.254。這個代碼表示查詢遭到拒絕，不代表該位址已列入清單。請透過自有伺服器的 resolver 執行查詢，或改用網頁查詢工具。

查詢結果乾淨是必要條件，但仍然不夠。未列入清單只表示近期沒有人針對該位址提出申訴。這不代表該位址具備正面信譽，而正面信譽才是郵件真正進入收件匣的關鍵。這種信譽必須透過數週持續寄送少量且收件者需要的郵件來建立。

鄰近位址也會影響結果，因為有些收件方會以整個網路區段，而不是單一位址，評估信譽。當同一個 /24 範圍內的其他客戶開始寄送垃圾郵件時，你的郵件可能因連帶關係而遭到延遲。這種以區段為單位的評估方式，也是 VPS 收件匣會收到帳戶持有人從未寄出的流量之濫用申訴 的原因：申訴會隨著位址範圍而來。

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

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

直接從伺服器測試連線路徑：

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

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

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

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

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

如果你的主機也配置了 IPv6，且伺服器偏好使用 IPv6，以上所有要求同樣適用於 IPv6 位址，而且 Gmail 對此更嚴格。從沒有 PTR 記錄的位址透過 IPv6 寄信，會遭拒收，並顯示郵件不符合 IPv6 寄送指引中關於 PTR 記錄與驗證的要求。如果你無法設定 IPv6 PTR 記錄，請只透過 IPv4 寄信。在 Postfix 中，使用 smtp_address_preference = ipv4 可優先使用 IPv4，使用 inet_protocols = ipv4 可完全關閉 IPv6。

要向任何主機商詢問的三個問題

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

在購買前就詢問這三個問題，不要等到購買後才問。若主機商清楚回答前兩個問題，並對第三個問題回答「否」，仍然可以使用，因為你可以在第一天檢查位址，必要時取消服務。若主機商不願以書面回答任何一個問題，這已經說明了在該主機上執行郵件服務會是什麼情況。

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。截至 2026 年 8 月，Microsoft 提供按位址計算的資料與投訴服務，位址擁有者可以申請註冊；Yahoo 提供以 DKIM 簽署網域為識別依據的投訴回饋迴路；Google 則在資訊主頁中提供彙總的信譽資料，而不是個別投訴。Google 的資訊主頁必須等你每天向其使用者傳送具一定規模的郵件後才會顯示資料。在依賴任何一項服務前，請先閱讀其最新條款，因為這些計畫可能變更，而且沒有任何一項服務保證提供存取權。

Google 公布、並自 2024 年 2 月起生效的大量寄件者要求，是目前大型收件方對寄件者期望的最明確公開說明。每天向個人 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 子網路路由器，讓這些機器連往該信箱，完全不必向網際網路公開連接埠。

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

執行 mail server 的第一年要花多少成本？

第一週是建置階段：安裝套件、設定 DNS records、TLS certificates、寄送第一批測試郵件，並在 p=none 設定 DMARC。

第二週到第六週才是大多數人沒有規劃的部分。你會閱讀 DMARC aggregate reports，找出原本不知道的 alignment 問題，發現會破壞 SPF 的 forwarder，接著將 policy 移至 p=quarantine，之後再移至 p=reject。這段期間會決定 self-hosting 對你而言是日常工作，還是令人厭煩的負擔。

之後每月大約需要 1 小時：更新套件、確認 certificate renewal 確實完成而不是直接假設成功、從 backup 執行一次 restore test、查看磁碟成長情況，以及查詢一次 blocklist。

另外還有無法排程的那一週。某個 address 可能因為你沒有做過的事情而被列入清單。大型 receiver 可能變更規則，導致你的郵件再次進入 spam。Queued mail 不等於遺失的郵件：Postfix 預設會重試 deferred message 5 天，由 maximal_queue_lifetime = 5d 設定，因此持續數小時的中斷只會增加延遲，不會造成其他損失。持續 1 週的中斷則會造成郵件遺失。

Backup MX record 的實際效果不如表面上看起來理想。寄件伺服器本來就會自行重試數天，因此只負責佇列郵件的 secondary 幫助不大。更糟的是，若 secondary 接受你網域的郵件，卻不知道哪些 address 實際存在，就會接收寄往不存在 address 的郵件，接著將其退回給偽造的寄件者，讓你的 backup 成為 backscatter 來源。應將資源投入 monitoring，以及實際測試過的 restore。

請用你評估伺服器上其他項目時會提出的問題來判斷整體價值：擁有這項服務，是否能提供你無法購買的東西？對 mailboxes 和 archive 而言，答案通常是肯定的。對陌生收件者的 outbound delivery 而言，答案通常是否定的。這也是判斷其餘 2026 年值得 self-hosting 的項目清單 時所使用的標準。

FAQ

如果我的 VPS 提供商封鎖對外連線的 port 25，我還能自架電子郵件嗎？

可以接收郵件，也可以透過 relay 寄信。外寄封鎖不會影響郵件送達伺服器的 port 25。外寄郵件會透過 port 587 上經過驗證的 relay 傳送，而提供商通常不會封鎖此連接埠。port 25 關閉後，您無法直接將郵件投遞到其他郵件伺服器，因為伺服器之間的投遞依定義使用 port 25。請使用 nc -vz gmail-smtp-in.l.google.com 25 進行測試。連線停頓後逾時，表示該連接埠已遭封鎖。

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

驗證只能證明郵件由誰寄出，不能證明收件者需要這封郵件。三項驗證全部通過後，郵件會從未識別狀態變成已識別；接著，接收端會評估您的 IP 位址與網域聲譽，而新寄件者尚未建立這些聲譽。請持續數週，以少量寄送收件者預期會收到的郵件，逐步建立聲譽。接著確認 PTR 記錄與郵件主機名稱能雙向對應，並檢查郵件內容沒有自行引入扣分因素，例如連結縮網址服務或不熟悉的追蹤網域。

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

若要直接外寄郵件，需要。郵件伺服器需要一個由您控制 PTR 記錄、且聲譽只屬於您的位址；就此而言，VPS 位址本身已是專用位址。您無法控制的是該位址過去的使用紀錄，以及同一網路區段中其他位址的聲譽。若改用 relay 外寄郵件，relay 的位址會承擔其聲譽，而您的伺服器只需接受入站連線。

將主要電子郵件位址移至自架伺服器安全嗎？

請分階段遷移，不要一次切換。讓現有信箱繼續運作，將您的伺服器新增為第二個目的地，並在數週內將副本轉寄到該伺服器，同時閱讀 DMARC 報告並確認郵件能雙向正常流動。測試郵件正確抵達一週後，再變更 MX 記錄。最容易造成遺憾的故障，是切換時遺失入站郵件；而入站郵件無法重新建構。

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

由您自己的伺服器管理信箱與封存資料，並將外寄郵件交給 port 587 上經過驗證的 relay。您擁有資料與網域，也能完全避開聲譽問題。日後若改變決定，變更成本仍然很低，因為 relay 只需修改一行設定與一筆 SPF 記錄，之後替換 relay 只需一個下午。