你可以把 Email 寄送的過程想像成**「古代送信」，而 SMTP（寄信協定）本身設計得非常老舊且沒有安全感，就像一個毫無防備的郵差**。
為什麼 Gmail、Outlook 會把你的信當垃圾信？核心原因只有一個：「身分不明，缺乏信任」。
以下是用最白話的方式解釋這「三大護法」加上「黑名單」的運作邏輯：
1. 根本原因：SMTP 的天生缺陷
SMTP 協定在幾十年前發明時，並沒有設計「驗證身分」的功能。
這意味著，任何人都可以躲在暗巷裡，寫一封信，然後在信封寄件人（From）填上 president@whitehouse.gov。郵差（SMTP）根本看不出來這是假的，照樣幫你送。
為了防止這種「冒名頂替」，現代郵件系統發展出了三道檢查關卡：
2. 第一關：SPF (Sender Policy Framework) —— 「警衛與訪客名單」
- 概念：這是一份白名單。
- 運作：Gmail 收到你的信時，會去查你的 DNS（警衛室）問：「請問 IP
1.2.3.4 (這位郵差) 有資格代表 mydomain.com 送信嗎？」
- 如果沒有 SPF：Gmail 覺得這個郵差是隨便路過的，可疑 –> 垃圾信。
- 如果有 SPF：確認這是在名單上的合法郵差 –> 通過。
3. 第二關：DKIM (DomainKeys Identified Mail) —— 「完整的蠟封」
- 概念：這是一個數位簽名（防偽標籤）。
- 運作：就算郵差是對的，信件內容有沒有在半路被駭客竄改過？或者這是不是別人偽造了你的信頭？DKIM 就像是在信封口蓋了一個**「獨一無二的火漆蠟封」**（私鑰加密）。
- 沒有 DKIM：Gmail 收到信，發現信封沒封口，誰都能塞廣告進去 –> 垃圾信。
- 有 DKIM：Gmail 用你的公鑰檢查蠟封，發現完好無損 –> 確認是原廠出品，內容未被竄改。
4. 第三關：DMARC —— 「老闆的指令」
- 概念：這是一本指導手冊。
- 運作：如果有駭客偽造了你的信，導致 SPF 或 DKIM 檢查失敗了，Gmail 該怎麼辦？是直接丟掉？還是放進垃圾桶？還是通知你？DMARC 就是你（網域擁有者）告訴 Gmail：「如果有人冒充我（驗證失敗），請直接把它拒絕（Reject）！」
- 沒有 DMARC：Gmail 雖然抓到了假信，但不知道怎麼處理，可能會為了怕誤判而勉強收下，但也降低了你網域的權威性。
5. 隱藏大魔王：IP 信譽 (IP Reputation) —— 「前科紀錄」
就算你上述三種證件都齊全了，為什麼還會進垃圾桶？
- 原因：因為送信的那個 IP 位址（例如 AWS EC2 的 IP）可能有**「前科」**。
- 情境：如果上一位租用這個 IP 的人是用來發送百萬封詐騙信的，這個 IP 就會在國際反垃圾組織（如 Spamhaus）的黑名單上。
- 結果：Gmail 一看：「喔，這個 IP 是個慣犯！」不管你的證件多齊全，直接拒收。
總結
這就是為什麼我們要用 AWS SES：
- 解決 IP 前科：Amazon 會維護 IP 的清潔度，確保它們不在黑名單上。
- 解決 SPF/DKIM：讓 Gmail 相信**「這封信真的是你寄的，而且你授權了 Amazon 幫你跑腿」。
下面讓我們詳細講述設定的流程
1. AWS SES 前置作業 (在 AWS Console 操作)
這部分需要在 AWS 網頁介面上完成，請確保您選對了 Region (區域)（選有支援 SES 的區域）。
A1. 驗證網域 (Verify Domain)
- 進入 SES Console -> Configuration -> Identities。
- 點擊 Create identity -> 選擇 Domain。
- 輸入您的網域
mydomain.com。
- Publish DNS records to Route53: 請「不要」勾選此選項（保持未勾選狀態，除非您用Route53 管理您的網域）。
- Advanced DKIM settings: 選擇 Easy DKIM (預設值)。
- DKIM signing key length: 選擇 RSA_2048_BIT (比較通用) 或 1024 都可以。
- 點擊 Create identity。
A2. 獲取 CNAME 紀錄 (DKIM)
建立完成後，畫面會跳轉到該網域的詳細資訊頁面。往下滑，您會看到一個 「DKIM DNS records」 的區塊。
這裡會有 3 組 CNAME 紀錄。AWS 會給您兩個欄位：
- Name (主機名稱 / Host)
- Value (內容 / Target)
A3. 到您的 DNS 託管商新增紀錄
現在，請開另一個分頁，登入您的 DNS 管理後台。
您需要將那 3 組 CNAME 逐一新增進去。
⚠️ 超級重要的陷阱 (請務必注意)
大多數 DNS 託管商（如 Cloudflare, GoDaddy）在輸入「Name (Host)」時，會自動幫您補上網域後綴。
- AWS 顯示的 Name：
abcde12345._domainkey.mydomain.com
- 您在 DNS 後台只需輸入：
abcde12345._domainkey
如果您把整串貼上去，就會變成 ...mydomain.com.mydomain.com，導致驗證失敗！
A4. 除了 CNAME，別忘了 SPF (重要！)
因為您要透過 AWS SES 寄信，您必須在 DNS 告訴全世界：「AWS SES 是我授權的寄件人」。
請在您的 DNS 後台檢查 TXT 紀錄 (SPF)：
- 如果本來沒有 SPF 紀錄： 新增一條 TXT 紀錄：
- Host/Name:
@
- Value:
v=spf1 include:amazonses.com ~all
- 如果原本已經有 SPF 紀錄 (例如原本是設給 EC2 本機寄信)： 請修改原本那條紀錄，把 AWS SES 加進去。
- 舊的可能長這樣：
v=spf1 mx ip4:1.2.3.4 ~all
- 修改後：
v=spf1 mx ip4:1.2.3.4 include:amazonses.com ~all
(重點就是一定要出現 include:amazonses.com 這段文字)
設定完後，通常等待 5 分鐘到 1 小時，回到 AWS SES Console 重新整理頁面，當 Status 變成綠色的 Verified，就代表成功了！如果沒成功，請檢查你輸入的DNS資訊是否正確，任何微小的錯誤都會導致驗證失敗
B. 申請移出沙盒 (Production Access) 剛開通的 SES 處於「沙盒模式 (Sandbox)」，只能寄信給「已經驗證過」的 Email。您必須申請移出沙盒才能寄給外面的陌生人。
- 在 SES Console 首頁上方會看到一個藍色警告條。
- 點擊 Request production access。
- 填寫用途（用英文寫：My mail server is for personal business communication, not for marketing spam…）。
- 通常需要等待數小時到一天審核。
在填寫用途這一欄，由於我是差不多十年前申請的，當時隨便填都會過。現在不一樣了，建議你參考以下模版：
Hello AWS Support Team,
I am requesting to move my Amazon SES account out of the sandbox. I use this domain for my personal IT blog and my personal email communications.
1. How I build my mailing list: I do not buy, rent, or use any marketing mailing lists. The emails are strictly for my personal 1-on-1 communications and a few users who explicitly register on my personal WordPress site.
2. What kind of emails I send: There are two main use cases:
Personal Email Routing: I use SES as an SMTP relay for my personal custom domain email (e.g., admin@thetmfamily.com) for daily 1-on-1 correspondence.
System Notifications: I use it to send transactional emails for my WordPress blog, such as password resets and comment notifications. I DO NOT send newsletters or marketing campaigns.
3. How I handle Bounces and Complaints: Protecting the SES sender reputation is my top priority.
I have enabled the SES Account-level suppression list to automatically stop sending emails to addresses that result in a hard bounce or complaint.
Since this is a personal domain, the outbound volume is extremely low and highly targeted. Any bounced email from my WordPress system will be manually investigated and removed from the database.
Thank you for your review.
個模版強調了三件事：
坦承「雙軌並行」：直接告訴審核員你有兩個用途（Personal Email Routing 與 System Notifications），這完美解釋了為什麼你的發信量可能很低，但又確實有對外發信的剛性需求。
強調「極低風險」：在第三點特別加入了「The outbound volume is extremely low and highly targeted (發信量極低且對象明確)」，這句話對 AWS 審核員來說是一顆超級定心丸，代表你絕對不可能成為發送海量垃圾信的源頭。
無敵護城河：「SES Account-level suppression list」這個底層防禦機制的關鍵字，確保能順利通過機器人的初步審查。
這裡面提到了Account-level suppression list這個東西，這是SES內建的防護機制，這個機制就像是一個「自動黑名單防火牆」。
沒有開啟以前：如果有個白目讀者亂填信箱 fake123@gmail.com，你的 WordPress 每次有新文章就寄給他，每次都被 Gmail 判定「查無此人 (Hard Bounce)」。連續幾次之後，Gmail 就會把你的網域列入黑名單，AWS 也會把你的 SES 帳號停權。
開啟這個機制後：第一次寄給 fake123@gmail.com 發生退信時，AWS SES 會立刻、默默地把這個信箱加入你的「帳戶黑名單」中。
保護生效：下次你的 WordPress 又傻傻地要把信寄給 fake123@gmail.com 時，信件一送到 AWS SES，SES 就會直接把它丟掉，根本不會寄出去給 Gmail。這樣就完美保護了你的發信信譽 (Reputation)！
Suppression list 開啟的方法如下：
登入 AWS Console，搜尋並進入 Amazon SES 儀表板。
在左側選單直接找 Suppression list (隱藏名單 / 抑制清單)。
裡面會有一個區塊叫做 Account-level settings (帳戶層級設定)。
點擊 Edit (編輯)，確保Enabled 被勾選了、並且 suppression reasons 選擇 BOUNCE (退信) 和 COMPLAINTS (客訴)。
C. 取得 SMTP 帳號密碼 (關鍵！) 注意：這不是您登入 AWS 的 IAM 帳號，這是 SES 專用的。
- 進入 SES Console -> SMTP Settings。
- 記下 SMTP Endpoint (例如：
email-smtp.us-east-1.amazonaws.com)。
- 點擊 Create SMTP credentials。
- AWS 會產生一組 IAM User Name、Smtp Username 和 Smtp Password。
- 請務必下載 CSV 或複製下來！ 這個長得很像亂碼的密碼只會顯示這一次。
2. 安裝 SASL 相依套件
Postfix 需要這個套件才能拿著帳號密碼去向 AWS SES 登入。
sudo apt update
sudo apt install libsasl2-modules postfix-pcre -y
3. 設定 Postfix 指定 Relay Host
我們要修改 main.cf，告訴 Postfix：「以後寄給外部的信，不要自己送，全部轉交給 AWS SES。」
開啟設定檔：
sudo nano /etc/postfix/main.cf
請找到 relayhost 這一行（預設可能是空的），並在檔案的最下方加入/修改以下設定區塊：
# ==============================
# AWS SES Relay Configuration
# ==============================
# 1. 指定 AWS SES 的伺服器 (請換成您在步驟 1-C 看到的 Endpoint)
# 注意：要把網址用中括號 [] 包起來，並指定 :587
# 中括號的意思是「不要查 MX 紀錄，直接連線」，這能加速連線
relayhost = [email-smtp.us-east-1.amazonaws.com]:587
# 2. 啟用 SASL 認證 (Postfix 作為客戶端向 SES 登入)
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = login
# 3. 強制使用 TLS 加密 (AWS 要求一定要加密)
smtp_use_tls = yes
smtp_tls_security_level = encrypt
smtp_tls_note_starttls_offer = yes
# 4. 指定 CA 憑證位置 (確保能驗證 AWS 的 SSL 憑證)
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
存檔離開。
4. 建立密碼檔 (sasl_passwd)
我們要把剛剛從 AWS 拿到的 SMTP 帳號密碼寫入檔案。
建立新檔案：
sudo nano /etc/postfix/sasl_passwd
貼上以下內容（請替換成您自己的資料）： 格式：[Endpoint]:587 Username:Password
[email-smtp.us-east-1.amazonaws.com]:587 AKIAIOSFODNN7EXAMPLE:AgGbq...VERY...LONG...PASSWORD...
(注意：前面的 Endpoint 也要加上中括號 []，必須跟 main.cf 裡寫的一模一樣)
存檔離開。
5. 雜湊密碼並保護檔案
這個檔案裡有明碼密碼，非常危險，我們要把權限鎖死，並轉換成 Postfix 讀得懂的 hash 檔。
# 1. 轉換成資料庫格式 (會產生 sasl_passwd.db)
sudo postmap hash:/etc/postfix/sasl_passwd
# 2. 將檔案的所屬群組改為 postfix (這樣 postfix 才有資格讀)
sudo chgrp postfix /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
# 4. 移除明碼檔案 (或是移到安全的地方備份)
# 這裡我們先改權限讓 root能讀寫 postfix能讀，確保安全
sudo chmod 0640 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
# 3. 重啟 Postfix
sudo systemctl restart postfix
6. 最終驗收：寄信到 Gmail
現在，請再次打開您的郵件軟體（手機或電腦），透過您的 Mail Server 寄一封信給您的 Gmail。
觀察重點：
- 檢查 Log (
/var/log/mail.log)： 您應該會看到類似這樣的訊息： status=sent (250 Ok ...) 且會顯示連線到 email-smtp.us-east-1.amazonaws.com。
- 檢查 Gmail 收件匣： 打開收到的信，點擊「顯示原始郵件 (Show Original)」。
- SPF: PASS
- DKIM: PASS (如果您在 AWS 有開啟 DKIM)
- DMARC: PASS (如果您 DNS 有設對)
- Encryption: Standard encryption (TLS)
如果 Log 顯示 Authentication failed：
- 檢查
sasl_passwd 裡的帳號密碼是否填錯（是 SMTP 帳號，不是 IAM 帳號）。
- 檢查
relayhost 和 sasl_passwd 裡的中括號 [] 是否一致。
- 記得每次改完
sasl_passwd 都要執行 sudo postmap hash:/etc/postfix/sasl_passwd。
全系列總結
恭喜您！經過這長途跋涉，您已經完成了一項許多工程師都覺得頭痛的任務。
您現在擁有一台：
- 獨立自主 的郵件伺服器 (Linux + Postfix + Dovecot)。
- 資料庫管理 的虛擬帳號系統 (MariaDB + SHA512)。
- 企業級 的傳輸安全性 (TLS + Let’s Encrypt)。
- 高信譽 的寄信通道 (AWS SES)。
現在，您可以自由地開設無限個 Email 帳號，掌控自己的數據，並享受自架服務的樂趣了！另外特別推薦使用Roundcube webmail作為你的Webmail解決方案，這個老牌的Webmail解決方案不但更新頻繁，還有強大的社群以及外掛程式（例如兩步驟驗證2FA等等），絕對值得您一試！
第一章：架構規劃與環境準備
第二章：基礎建設篇——DNS、SSL 與資料庫
第三章：郵差的武裝——安裝 Postfix 並連接資料庫
第四章：安裝與設定 Dovecot (最後一塊拼圖)。
第五章：驗收時刻——全流程測試
第六章：設定 AWS SES Relay (讓信件使命必達)
