PCPILOT · 工程師思路系列

一封信為什麼會被退回
——郵件信任體系三十年演變

規則不是憑空訂的,是被逼出來的。今天的標準,是三十年來人與垃圾郵件博弈的妥協結果。

你有沒有遇過這種情況:信寄出去,對方說沒收到,查了一下,原來進了垃圾桶,或者直接被退信。

收信方的伺服器不是隨機擋信的。它在執行一套規則——一套從 1980 年代到現在,被現實一次次逼著修改的規則。

要理解這套規則為什麼長成今天這個樣子,得從頭說起。

純真年代:信任是預設值

網際網路的前身 ARPANET,是 1960 年代末美國國防部和學術機構搭起來的封閉網路。用的人彼此認識,不是研究員就是工程師,根本沒有「壞人會進來」這個預設。

1982 年定案的 SMTP(簡單郵件傳輸協議)就是在這個背景下設計的。協議的名字裡有個「簡單」,不是謙虛,是真的很簡單——任何人架一台伺服器,就能對任何人寄信,沒有身份驗證,沒有來源確認。

📌 SMTP 是什麼?

Simple Mail Transfer Protocol,1982 年制定,至今仍是所有電子郵件傳輸的底層協議。它規定了郵件伺服器之間怎麼對話、怎麼傳遞信件——但原始設計完全沒有驗證寄件人身份的機制。

這個設計在當時沒有問題。網路是封閉的,用戶是可信的,「簡單」就是美德。問題是,網際網路後來沒有維持封閉。

垃圾郵件的反撲:反解成為第一道門

1990 年代,網際網路向公眾開放,商業化浪潮湧入。原本安靜的學術網路,瞬間擠進了各種人。

1994 年,兩位美國律師對幾千個新聞群組大量發送廣告,這通常被認為是史上第一封現代意義的垃圾郵件。之後的十年,垃圾郵件量以指數成長——2003 年前後,全球電子郵件流量裡,垃圾郵件一度佔到 80% 以上

收信方的伺服器需要一個快速判斷的方法。反解(PTR record)就是在這個時期成為業界慣例的。

📌 什麼是反解(PTR record)?

DNS 正解是「把網域名稱查成 IP」,反解是反過來——「把 IP 查成對應的主機名稱」。例如把 203.x.x.x 查出來得到 mail.pcpilot.com.tw

重點:PTR 記錄不是由網域擁有者設定,而是由持有該 IP 的 ISP 設定。你控制不了它,只能請求 ISP 幫你加。

當時的邏輯很直覺:


正經公司有固定 IP,ISP 會幫它設好反解,查得到主機名稱

隨便一台家用電腦、被駭的機器、臨時架的垃圾郵件伺服器——通常沒有反解

這個假設在 2000 年代初期大致成立。反解成為全球收信伺服器的標準篩選條件之一,沒有反解就直接退信或扣分。規則有效,業界跟進,沿用下來。

世界變了,規則來不及跟上

問題是,世界在 2010 年代之後改變得很快,但反解這個慣例沒有跟著改變。

1

IPv4 耗盡,固定 IP 越來越貴
2011 年,IANA 宣布 IPv4 位址全數分配完畢。固定 IP 資源稀缺,ISP 開始縮減固定 IP 的分配,PPPoE 用戶拿到固定 IP 越來越難,也越來越貴。「正經公司才有固定 IP」這個前提開始鬆動。
2

雲端 VM 興起,合法伺服器沒有反解
AWS、GCP、Azure 的 VM 大量被用來架郵件伺服器。這些 IP 的反解記錄不完整或預設指向雲端供應商的通用主機名,不符合傳統慣例,大量合法的企業郵件被誤判。
3

ISP 撤回對 PPPoE 用戶的反解服務
垃圾郵件發送者大量濫用 PPPoE 固定 IP 架設臨時郵件伺服器,導致這類 IP 段的信譽整體惡化。ISP 為了保護自己的 IP 信譽,索性全面停止為 PPPoE 用戶提供反解申請服務。合法的中小企業自架郵件伺服器,成了這場博弈的無辜受害者。

反解從「合理的篩選門檻」,變成了「誤傷合法用戶的鈍器」。
規則本身沒有錯,是它賴以成立的前提消失了。

更精準的驗證體系:從 IP 身份到網域真實性

業界的解決方向,不是放寬反解要求,而是發展出一套更精準的驗證機制——驗證的對象從「這個 IP 是誰的」,轉移到「這封信是不是真的由這個網域授權發出的」。

機制 驗證什麼 出現年份
SPF 這個 IP 有沒有被網域擁有者授權寄信 2003
DKIM 這封信有沒有被網域私鑰簽章、內容有沒有被竄改 2004
DMARC SPF / DKIM 沒過,要退信、隔離還是放行,由網域擁有者自己訂政策 2012

這三個機制疊在一起,比反解更難偽造,也更公平——因為它們不在乎你的 IP 是固定還是浮動,是自家機房還是雲端 VM,只在乎你有沒有這個網域的合法授權。

現代收信伺服器(Gmail、Outlook)看的是綜合評分:

反解有沒有 → 有加分,沒有扣分(不再是一票否決)
SPF 有沒有過 → 沒過直接懷疑
DKIM 有沒有簽 → 沒簽大扣分
DMARC 政策 → 決定最終處置方式
IP 黑名單 → 在名單上直接擋
歷史寄信信譽 → 長期累積,最難造假

Resend:現代信任體系的具體實踐

Resend 這類現代郵件發送服務,是在上面這套體系成熟之後才出現的。它的設計,把所有驗證機制整合進一個商業模型裡。

四層把關機制
第一層:網域驗證
要使用 Resend 寄信,必須先在 DNS 加入指定的 TXT / CNAME 記錄,證明你是這個網域的真實擁有者。沒有通過驗證的網域,無法寄信。
第二層:API Key 綁定
每組 API Key 可以限定只能使用特定網域寄信。Key 洩漏了,拿去也只能用你的網域名義發信,亂發的法律責任還是你的——讓濫用者有所顧忌。
第三層:即時行為監控
退信率、垃圾郵件投訴率、寄信量暴增……系統持續追蹤每個帳號的行為指標,超過門檻自動暫停,需人工審核才能恢復。
第四層:信譽共同體壓力
所有 Resend 客戶共用同一批出站 IP。一個帳號濫發垃圾郵件,這批 IP 被 Gmail 列入黑名單,其他所有合法客戶的信也跟著進垃圾桶。Resend 有強烈的商業動機主動清理濫用者——不是道德,是生意。

對沒有反解、沒有固定 IP 的中小企業來說,透過 Resend 中繼寄信,等於借用了它長期建立的信譽資產——SPF、DKIM、DMARC 全部齊備,歷史寄信信譽良好,大型收信方都認識它。

你的信件內容是你的,寄件網域是你的。改變的只有「誰幫你送出去」。

以前:「你是誰?」——靠 IP 反解判斷。

現在:「你的網域是不是真的?信有沒有被授權簽發?」——靠 SPF/DKIM/DMARC 判斷。

今天的標準不是終點,只是這個時代的妥協結果。規則一直在被現實修正,而推動修正的力量,從來都是濫用者和合法用戶之間不斷移動的邊界。

τ
Mr. τ
風雲網通系統有限公司 PCPiLOT · 工程師思路系列

#電子郵件
#SMTP
#SPF
#DKIM
#DMARC
#Resend
#資安科普
#工程師思路
Last modified: 2026-09-18

Author

Comments

Write a Reply or Comment

Your email address will not be published.