你按下「寄出」之後，那封信到底跑去哪裡了？
為什麼有人可以冒用你公司的網域，寄信給你的同事，而收件匣看起來完全正常？
為什麼你系統寄出的通知信，明明程式沒報錯，卻常常安靜地掉進垃圾郵件匣？
這三個問題的答案，其實都藏在同一套流程裡。
Email 是網路上最老的服務之一，老到它的設計裡還留著「大家都是好人」的假設。
我們就從最小的單位開始，一路拆到你能自己解釋為什麼一封信會被擋下來。
開始之前：先確定「信箱」到底是什麼
我們要拆的是一封信的旅程，所以得先講清楚這趟旅程的終點在哪裡。
你在公司電腦上讀過的信，回家打開瀏覽器一樣看得到，手機上也是同一批。
你換過幾次電腦、重灌過系統，那些信也還在。
這代表信不是存在你的任何一台裝置裡，它存在別的地方，你只是連過去看而已。
那個「別的地方」是一台一直開著、專門幫人保管信件的電腦，我們叫它伺服器（server）。
而所謂「你的信箱」，指的就是這台伺服器上的一塊空間，專門存放寄給你的信——它不是一個實體的盒子，也不是你裝的那個 app，就只是伺服器上的一塊空間。
Gmail 的網頁、Outlook、手機上的信件 app，都只是連到那塊空間的檢視器，它們本身不存信。
所以寄信的時候，信不會直接跑到收件人的電腦或手機上。
它會先被送到伺服器，存進收件人的信箱，等收件人自己來讀。
也就是說，要寄成一封信，你得知道兩件事：信要送到哪一台伺服器，還有要存進那台伺服器上的哪一個信箱。
Email 地址：一個地址其實是兩個資訊
一個 email 地址長這樣：alice@example.com。
它被 @ 切成兩半，剛好對應上面那兩個問題。
右邊的 example.com 就是那台伺服器。
左邊的 alice 則是信箱的名字——一台伺服器上有很多個信箱，各自屬於不同的人，信要進哪一個，就是靠這個名字認出來的。
信箱的名字也不一定對應到一個真人。
support 可能是一個會轉發給整個客服團隊的名字，no-reply 可能是一個收到信就直接丟掉的名字。
這些差別全部由這台伺服器自己決定，外面的世界看不到，也不需要知道。
順序不能顛倒，因為送信是分成兩個階段的，而這兩個階段由不同的人管。
第一階段，信在網際網路上找路。
這個階段沒有任何一台設備在意 alice 是誰，大家只看 example.com，想辦法把信丟到那台伺服器上。
第二階段，信抵達 example.com 之後，換這台伺服器自己作主，由它決定 alice 要進哪一個信箱。
有一個現象可以佐證這種「分屬不同管轄」的關係：@ 右邊不分大小寫，Example.com 跟 example.com 是同一台伺服器，因為這是全網路共通的規則。
但 @ 左邊在規格上是可以分大小寫的，Alice 跟 alice 允許是兩個不同的信箱。
實務上幾乎沒有伺服器真的這樣做，但規格保留了這個權利——因為左邊要怎麼解讀，本來就是那台伺服器自己的家務事。
誰在搬這封信？MUA、MTA、MDA
我們已經知道信最後會躺在一台伺服器上，但從你按下寄出到它躺進去之間，中間還有一段路。
這段路不是一台機器走完的，至少有三種角色在接力。
這三個縮寫在後面會一直出現，我們先把它們講清楚。
MUA（Mail User Agent）：你直接操作的那個東西
Gmail 的網頁介面、Outlook、Apple Mail、手機上的信件 app，都是 MUA。
它做的事其實只有兩件：讓你把信寫出來，以及把寫好的信交出去。
不過在講「交給誰」之前，得先補一件前面沒說的事。
前面我們一直在講 alice 的信箱在 example.com 那台伺服器上，但你自己也有一台。
你申請信箱的時候，其實就是跟某一家服務要了一塊空間，那塊空間所在的伺服器，就是你這邊的伺服器。
舉例來說，如果你的地址是 bob@gmail.com，那你這邊的伺服器就是 Google 的，你的信被 Google 保管著。
如果是公司配給你的 bob@mycompany.com，那就是公司自己架的那台，或是公司向外面租的那一台。
換句話說，你自己地址 @ 右邊那半，決定的就是你這邊的伺服器——跟前面拆解 alice 地址時用的是同一條規則。
寄信的時候，MUA 交出去的對象不是對方那台，而是你自己這台。
原因很現實：你的 MUA 握有你這台伺服器的帳號密碼，而對方那台伺服器根本不認得你是誰。
讀信的時候也是同一台——MUA 連上你自己的伺服器，把信取回來顯示給你看。
所以MUA 從頭到尾只跟你自己這邊的伺服器打交道，它不會直接連上對方的伺服器。
你按下寄出的那一刻，信只走了一小段路：從你的裝置到你自己的伺服器，然後就結束了。
剩下那一大段路，是由下一棒接手的。
如果你手動設定過 email，這件事會突然變得很有感。
現在多數人不會遇到，因為 Gmail 的 app 連自家帳號時，設定早就填好了。
但只要你在手機上加一個公司信箱，或是用 Thunderbird 這類軟體接一個比較冷門的信箱，那張設定表就會整張攤在你面前。
而它永遠是兩組：
外寄伺服器（SMTP）：smtp.example.com 連接埠 587
收件伺服器（IMAP）：imap.example.com 連接埠 993
帳號：bob@example.com
密碼：••••••••上面那組回答「信要交給誰」，下面那組回答「等一下要去哪裡把信拿回來」。
兩組常常是不同的主機名稱，連接埠也不一樣，因為寄跟收本來就是兩套不同的協定——後面我們會專門講一節。
括號裡的 SMTP 和 IMAP 就是那兩套協定的名字，現在先記得有這兩個字就好。
不過這張表上真正值得注意的，是它沒有的東西。
從頭到尾沒有任何一欄要你填對方的伺服器。
你的 MUA 根本不需要知道 alice 在哪裡，那是下一棒才要煩惱的事。
MTA（Mail Transfer Agent）：在伺服器之間搬信的程式
Postfix、Exim、Sendmail 都是 MTA，你用的那些寄信服務，背後跑的也是同一類程式。
同一支程式會扮演兩種角色：寄件方的 MTA 替你把信送出去，收件方的 MTA 替收件人把信接下來。
送出去這一段，MTA 要做的事比想像中多。
它得先查出對方的信要送到哪一台機器（下一節就會講它怎麼查），跟那台機器建立連線，再用一套雙方都懂的規則把信交出去。
如果對方沒回應，或是回了「我現在很忙，等一下再來」，MTA 不會直接放棄。
它會把這封信排進佇列（queue），過幾分鐘再試一次，再失敗就隔更久，這樣重試好幾天。
真的都送不出去，它才會產生一封退信通知寄回給你。
這就是為什麼你關掉電腦之後信還是會送達，也是為什麼有些信會莫名其妙晚了十幾分鐘才到。
另外，一封信不一定只經過兩台 MTA。
公司的信可能先經過對外的閘道、再經過掃毒主機，才進到真正的信件主機；設定了自動轉寄的信箱，還會把信再丟給下一台。
每經過一台，那台 MTA 就會在信上蓋一個章，記下自己是誰、什麼時候收到的。
這些章疊起來就是一封信的完整足跡，看一封信的原始內容就能把它整條讀出來。
MDA（Mail Delivery Agent）：把信放進信箱的程式
MTA 負責對外，MDA 負責對內，兩者的分界就在信抵達目的地伺服器的那一刻。
Dovecot、procmail 都是常見的 MDA。
它處理的是「這封信屬於 alice，把它寫進 alice 的信箱」這件事——決定存成什麼格式、放在磁碟的哪個位置，都是它的工作。
但 MDA 不只是把信塞進去而已，這一步是規則生效的地方。
收件人設定的過濾條件在這裡執行：哪些信自動歸到某個資料夾、哪些信標記成重要、哪些信直接丟進垃圾桶。
信箱容量滿了也是在這一步才會發現，這時 MDA 會拒收，讓 MTA 產生一封退信。
三者的順序
收件方的 MTA、MDA 和信箱畫在同一個框裡，因為它們通常就在同一台伺服器上。
這也提醒了一件事：這三個角色是職責的劃分，不是三台不同的機器。
你用 Gmail 的時候，MUA、MTA、MDA 全都是 Google 的東西，你完全感覺不到中間有交接。
但只要有一封信寄不出去、或是進了垃圾桶，你就得知道問題卡在哪一棒——這也是我們要先把它們拆開講的原因。
DNS 與 MX record：怎麼知道信要送去哪台機器
現在你的 MTA 手上有一封要寄到 alice@example.com 的信。
它知道 domain 是 example.com，但 domain 只是一個名字，不是一台機器。
它需要一個 IP 位址才能連線。
這時候就要問 DNS。
DNS（Domain Name System）是網際網路的查號台，你給它一個名字，它給你對應的資料。
但這裡有個關鍵細節：MTA 問的不是「example.com 的網站在哪」，而是「example.com 的信要送給誰」。
這兩個答案可以完全不一樣。
網站可能放在自己的機房，信卻交給 Google 代收。
負責回答收信問題的，是一種叫做 MX record（Mail Exchanger record）的 DNS 紀錄。
我們可以直接用 dig 指令查查看：
dig MX example.com +short實際查一個有在收信的網域，你會看到類似這樣的結果：
10 mail1.example.com.
20 mail2.example.com.前面的數字叫 priority（優先權），數字越小優先權越高。
MTA 會先試 mail1，連不上或對方回報忙碌，才退而求其次去試 mail2。
這就是為什麼大公司的信在主要伺服器掛掉時還是收得到——備援本來就寫在 DNS 裡。
拿到主機名稱之後，MTA 再查一次 A record 或 AAAA record 取得 IP：
dig A mail1.example.com +short到這一步，MTA 終於知道要把 TCP 連線開去哪裡了。
送信的路線不是寫在信裡，而是收件方自己在 DNS 上公告的，任何人都查得到。
SMTP：兩台伺服器之間的對話
連線建立之後，兩台 MTA 開始講話。
它們講的語言叫 SMTP（Simple Mail Transfer Protocol），預設走 25 port。
SMTP 有一個對新手很友善的特性：它是純文字的，而且是一問一答。
你甚至可以自己手動打出一封信。
下面是一段簡化過的 SMTP 對話，C: 是寄件方（client），S: 是收件方（server）：
S: 220 mail1.example.com ESMTP ready
C: EHLO mail.mycompany.com
S: 250-mail1.example.com
S: 250 STARTTLS
C: MAIL FROM:<bob@mycompany.com>
S: 250 OK
C: RCPT TO:<alice@example.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: Bob <bob@mycompany.com>
C: To: Alice <alice@example.com>
C: Subject: Hello
C:
C: This is the body of the message.
C: .
S: 250 OK: queued as 3F2A1B
C: QUIT
S: 221 Bye一行一行看，這段對話做了五件事：
EHLO 是自我介紹，順便問對方「你支援哪些功能」，對方會回一串能力清單（例如支援 STARTTLS 加密）。
MAIL FROM 宣告寄件人，RCPT TO 宣告收件人——注意這兩個指令是在信件內容之外的。
DATA 之後才開始傳真正的信件內容，以單獨一行的 . 表示結束。
伺服器每一步都回一個三位數的狀態碼，2xx 是成功，4xx 是暫時性失敗（稍後重試），5xx 是永久失敗（退信）。
那個 4xx 很值得記住：收件方伺服器可以合法地說「我現在不想收，等一下再來」。
這個機制叫 greylisting，是很常見的擋垃圾信手段，也是為什麼有些信會延遲幾分鐘才到。
SMTP 就是一場結構化的文字對話，寄件人、收件人、內容是分三次講出來的。
收信端：IMAP 與 POP3
信送到了、也寫進 alice 的信箱了，但 alice 的手機怎麼把信抓出來？
答案是：換一套協定。
SMTP 只負責送，不負責收，這是很多人搞混的地方。
從伺服器把信取回來，用的是另外兩套協定：POP3 或 IMAP。
這兩套是二選一，而它們的差別只有一個：信到底該放在誰那裡。
POP3：下載後刪除
POP3 的做法是把信整包下載到你的裝置，然後從伺服器上刪掉。
下載完之後，伺服器上就不再有這封信，你的裝置是唯一還存著它的地方。
這在只有一台裝置的年代很合理，信件也不會佔用伺服器的空間。
但只要你多了第二台裝置就會出事：手機把信抓走之後，電腦再連上去就什麼也拿不到了。
IMAP：伺服器才是本體
IMAP 的做法剛好相反，信一直留在伺服器上，你的裝置只是同步一份檢視。
不只信件本身，連「已讀」「移到某個資料夾」這些狀態也會同步回伺服器。
所以你在手機上標記已讀，電腦上立刻就跟著變成已讀——因為兩台看的是同一份資料。
現在的信箱服務幾乎都預設用 IMAP，原因就是大家早就不只用一台裝置收信了。
三個協定的分工
把 SMTP、POP3、IMAP 放在一起對照，整張圖就完整了：
兩個容易搞混的 port
port 25 跟 587 都是拿來寄信的，但用的人不一樣。
25 是 MTA 之間互相傳信用的，587 是給你的 MUA 交寄用的。
現在絕大多數 ISP 都封鎖對外的 25 port，這也是為什麼你在家裡的網路上很難自己架伺服器直接寄信。
讓收件方相信你：SPF、DKIM、DMARC
SMTP 當年設計的時候，預設大家都是好人。
回想一下前面那段 SMTP 對話，把 DATA 之後的部分抓出來看：
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: Bob <bob@mycompany.com> ← 收件匣上顯示的寄件人，就是這一行
C: To: Alice <alice@example.com>
C: Subject: Hello
C:
C: This is the body of the message.
C: .DATA 之後的每一行，都是寄件方自己一個字一個字打進去的。
問題就在這裡：From: 那行既然是寄件方打的，收件方的伺服器根本不會去查它是真是假。
你可能會想：前面不是說過，MUA 不會直接連上對方的伺服器嗎？
那句話講的是一般信件 app 的運作方式，不是技術上做不到。
收件方的伺服器本來就得對全世界開著，不然別人的信要怎麼進得來？
所以只要我願意，我可以跳過自己的伺服器，直接連上 alice 那一台，把剛剛那段對話自己打一遍。
然後在 From: 那行填上 it@example.com。
這個地址跟 alice@example.com 是同一個網域，看起來就是她公司裡的人。
信送到之後，alice 的收件匣顯示的寄件人就是公司的 IT 部門，但這封信其實是我寄的。
後來補上的解法有三個，而且它們全都建立在你已經懂的東西上——DNS 紀錄。
網域擁有者把驗證資訊公告在 DNS 上，收件方 MTA 收信時去查，查完就知道該不該信。
SPF：誰可以代表這個網域寄信
SPF（Sender Policy Framework）的想法很簡單：與其相信信上寫的，不如直接去問網域的主人。
alice 的伺服器接到一通連線的時候，手上有兩個線索：對方機器的 IP 位址，以及對方聲稱這封信是從哪個網域寄出來的。
於是它可以回頭查那個網域的 DNS，看看主人有沒有公告過「哪些機器才算是我的人」。
而那份公告，就是網域擁有者放在 DNS 上的一筆 TXT record：
example.com. TXT "v=spf1 include:_spf.google.com ip4:203.0.113.5 -all"include:_spf.google.com 表示「Google 的寄信伺服器也算我授權的」。
ip4:203.0.113.5 表示這個 IP 也可以。
-all 是最關鍵的結尾：除了上面列的，其他一律不合格（用 ~all 則是軟性失敗，只做標記）。
收件方拿連線來源的 IP 去比對這份清單，在上面就過關，不在上面就是 SPF 失敗。
但光有 SPF 擋不住偽造，因為 SPF 看的網域，跟收件匣顯示的網域不是同一個。
把攻擊者實際打的那段對話攤開來看就很清楚了：
C: MAIL FROM:<attacker@evil.com> ← SPF 檢查的是這一行，而且會通過
C: RCPT TO:<alice@example.com>
C: DATA
C: From: IT 部門 <it@example.com> ← alice 收件匣看到的是這一行，沒人檢查
C: Subject: 請立即重設密碼前面講過，MAIL FROM 是在信件內容之外的指令，SPF 檢查的就是這一行聲稱的網域。
而 evil.com 是攻擊者自己的網域，他用自己的機器寄自己網域的信，SPF 當然通過。
至於 alice 收件匣上顯示的，是 DATA 之後 From: 那一行——SPF 從頭到尾沒有看過它。
這個破綻最後是靠 DMARC 補起來的，但在那之前還缺一塊拼圖。
因為 SPF 只管「這封信是誰寄的」，完全沒管「信在路上有沒有被動過手腳」——那是下一個機制的工作。
DKIM：這封信中途有沒有被改過
DKIM（DomainKeys Identified Mail）用的是數位簽章。
寄件方會先把信件內容算成一段固定長度的字串，這段字串可以想成信的指紋——內容只要動一個字，算出來的指紋就完全不一樣。
但光把指紋附在信上沒有用。
攻擊者改完內容之後，大可以順手把指紋也重算一遍貼上去，收件方一比對還是一樣的。
所以指紋不能就這樣裸著送，得先上一道鎖，而這道鎖用的是一對鑰匙。
這對鑰匙是配對的：私鑰只有網域擁有者自己留著，公鑰則公開給所有人拿。
它們的特性是，用私鑰鎖起來的東西，只有對應的那把公鑰打得開。
反過來說，一段東西如果能用 example.com 的公鑰打開，就證明它一定是被 example.com 的私鑰鎖上的——因為別人沒有那把私鑰。
於是流程變成這樣：寄件方用私鑰把指紋鎖起來，跟著信一起送出去，這就是簽章。
收件方收到之後做兩件事：用公鑰把鎖打開、拿到原本的指紋，再用同一套算法把手上這封信重新算一次指紋。
然後比對這兩段。
信被改一個字，重算的指紋就對不上；而攻擊者也沒辦法補一個新簽章，因為上鎖要用私鑰，那把鑰匙只有 example.com 自己有。
實際附在信裡的簽章長這樣：
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
h=from:to:subject:date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eMbmSDBqXAM...d=example.com 是簽名的網域，s=selector1 是選用哪把金鑰。
收件方拿這兩個值組出一個 DNS 查詢位置 selector1._domainkey.example.com，去取公鑰：
dig TXT selector1._domainkey.example.com +short"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."拿到公鑰，就能把簽章裡的指紋拆出來了。
h=from:to:subject:date 列出簽章涵蓋了哪些欄位，這幾項只要有任何一個在路上被改掉，驗證就會失敗。
DKIM 證明的是「這封信確實由持有 example.com 私鑰的人送出，而且內容沒被動過」。
注意它跟 SPF 的差別：SPF 檢查連線的 IP，DKIM 檢查信件本身，所以信被轉寄之後 SPF 通常會壞掉，DKIM 卻還能通過。
DMARC：失敗了該怎麼辦
現在回到 SPF 留下的那個破綻。
前面兩個機制各驗了一部分，但都沒有管到「收件匣上顯示的寄件人是誰」，而且驗失敗的時候也沒規定該怎麼處理。
把攻擊者那封信再攤開一次，這次連 DKIM 也一起看：
C: MAIL FROM:<attacker@evil.com> ← SPF 檢查這一行 → 通過
C: RCPT TO:<alice@example.com>
C: DATA
C: DKIM-Signature: ... d=evil.com ← DKIM 檢查這一行 → 也通過
C: From: IT 部門 <it@example.com> ← alice 看到的是這一行 → 沒人管
C: Subject: 請立即重設密碼evil.com 是攻擊者自己的網域，他有那台機器、也有那把私鑰，所以 SPF 和 DKIM 對 evil.com 都是合法通過的。
問題是通過的那個網域是 evil.com，而 alice 看到的卻是 example.com——兩個機制都沒有人負責把這兩件事湊在一起看。
DMARC（Domain-based Message Authentication, Reporting and Conformance）補上這兩個洞。
一樣是一筆 DNS TXT record，放在固定的 _dmarc 子網域：
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:reports@example.com; pct=100"p=reject 是政策：驗證沒過就直接退掉（其他選項是 none 只觀察、quarantine 丟垃圾匣）。
rua= 是接收彙整報告的信箱，你會收到「誰用你的網域寄了信、通過率多少」的統計。
pct=100 表示這個政策套用在百分之百的信件上。
而 DMARC 真正的核心是 alignment（對齊）：SPF 或 DKIM 通過的那個網域，必須跟收件匣上顯示的寄件人網域是同一個。
這句話就是解藥。
回到上面那段對話：通過驗證的是 evil.com，From: 那行卻是 example.com，兩邊對不起來，DMARC 就判定失敗，信被 p=reject 擋掉。
三者的分工整理成一句話：SPF 檢查寄信的機器，DKIM 檢查信件內容，DMARC 檢查這兩者跟顯示出來的寄件人對不對得上。
這三個機制都只是 DNS 上的一筆文字紀錄，但它們合起來才補上了 SMTP 當年留下的信任缺口。
實務應用：為什麼你的信進了垃圾桶
把上面的東西串起來，就能診斷開發者最常遇到的那個問題。
系統寄出的通知信、驗證信、密碼重設信，寄不到，或是進垃圾匣。
依照這趟旅程的順序檢查，大部分原因都跑不掉這幾個：
DNS 那一關
MX record 設了嗎？SPF 有沒有涵蓋你實際用來寄信的服務？
很常見的錯誤是換了寄信服務，但 SPF 裡的 include: 還留著舊的那一家。
另一個是同一個網域放了兩筆 SPF record——這在規格上是無效的，結果是整個 SPF 直接失敗。
驗證那一關
DKIM 的金鑰有沒有真的發布到 DNS？DMARC 有沒有設？
沒有 DMARC 的網域，現在會被主流信箱視為風險較高，尤其是大量寄送的情況。
IP 信譽那一關
這是最容易被低估的一項。
自己架 MTA 從一個乾淨的新 IP 開始寄信，收件方對這個 IP 完全沒有歷史紀錄，預設就是不信任。
要養起信譽需要時間跟穩定的寄送量，還要處理退信、bounce 管理、黑名單申訴。
內容那一關
退訂連結、List-Unsubscribe header、純文字版本（不要只寄 HTML）、避免整封信只有一張大圖。
取捨：自己架，還是交給寄送服務
自己架 SMTP 寄交易信
常見的理由是「不想依賴第三方」，但要付的代價是這些：
- 要自己維護 SPF / DKIM / DMARC
- 要自己養 IP 信譽，新 IP 初期投遞率通常很難看
- 要自己處理退信、黑名單、每家信箱不同的頻率限制
- 出問題時你沒有任何投遞數據可以看
自架的成本不在於把信送出去，而在於讓別人願意收，而後者是長期的維運工作。
交給成熟的寄送服務
SES、SendGrid、Postmark 這類服務把上面那些事包起來了：
- 用他們已經養好的 IP 池，起步的投遞率就是可用的
- DKIM 簽章由服務端處理，你只要照指示加幾筆 DNS record
- 有開信、退信、投遞失敗的儀表板可以查
代價是多一個外部相依、按量計費，寄件網域也要照他們的規則設定。
什麼時候自架仍然合理？
內部網路的信、法規要求信件不得離開自有基礎設施、量大到外部服務的費用超過維運成本的時候。
判斷的標準不是技術上做不做得到，而是你願不願意長期投入在信譽維護上。
重點整理
- 你的信箱不是手機裡那個 app，而是某台一直開著的伺服器上的一塊空間，app 只是連過去看的檢視器。
- Email 地址的
@右邊決定是哪一台伺服器，左邊決定那台伺服器上的哪一個信箱。 - 寄信是接力：MUA 只把信交給你自己的伺服器，中間的路由 MTA 走完，最後由 MDA 把信放進收件人的信箱。
- 信要送到哪一台機器，是收件方自己在 DNS 的 MX record 上公告的，數字越小優先權越高。
- MTA 送不出去不會直接放棄，會把信排進佇列重試好幾天，真的不行才產生退信。
- SMTP 只管寄，收信要靠 IMAP（伺服器是本體、多裝置同步）或 POP3（下載後刪除）。
- SMTP 不驗證寄件人，
From:那一行誰都能寫，這是偽造信件的根源。 - SPF 檢查寄信的機器，DKIM 檢查信件內容有沒有被動過，DMARC 檢查這兩者跟收件匣顯示的寄件人對不對得上。
- 信進垃圾桶，按 DNS 設定、驗證機制、IP 信譽、信件內容這個順序查，幾乎都找得到原因。
- 自架寄信伺服器的難處不是把信送出去，而是讓收件方願意收。