Outlook 退信 550 5.7.515 怎麼修？用 SPF/DKIM/DMARC 四種組合逐一對照

如果你寄大量商業信給 Outlook、Hotmail、Live 或企業版 Exchange Online 的收件人，遲早會在退信報告裡看到這一行：

550 5.7.515 Access denied, sending domain [example.com] does not meet
the required authentication level

這個錯誤有個很好認的特徵：退信率很高，但延遲率幾乎是零。 一般的聲譽問題會伴隨大量 4xx 暫時退回、信件塞在佇列裡重試，但 5.7.515 不會，微軟直接永久拒收。我看過退信率 33% 的案子，延遲率只有 0.16%。

好消息是，這個錯誤幾乎是所有退信碼裡最好修的一種。它不是聲譽問題、不是內容問題、也不需要放慢速度養網域。它就是一筆 DNS 記錄沒設好，補上去，下一次發送就會恢復。

更好的消息是，微軟已經把答案寫在退信訊息裡了。

先看訊息裡的三個值，不要只看代碼

完整的 5.7.515 退信訊息通常長這樣：

550 5.7.515 Access denied, sending domain [example.com] does not meet
the required authentication level
... Spf=Pass, Dkim=Fail, DMARC=Pass

重點在最後那一行的 Spf= / Dkim= / DMARC=。很多人看到 5.7.515 就直接去查「怎麼跟微軟申請解封」，其實根本不用申請，因為微軟已經逐項告訴你哪一關沒過了。

這裡有個關鍵觀念，是最多人卡住的地方：微軟是三項分開看的，而且要求 SPF 和 DKIM 都要通過。

DMARC 的規則本來是寬鬆的，SPF 或 DKIM 其中一項對齊就算 Pass。但微軟針對大量寄件者的政策更嚴，兩項都要過。所以你會看到很反直覺的組合：DMARC 明明 Pass，信還是被硬退。這不是微軟出錯，是它的門檻本來就比 DMARC 高一階。

四種組合逐一對照

一、Spf=Fail, Dkim=Pass, DMARC=Pass：退信子網域少了 SPF

這是最常被誤判的一種。DKIM 和 DMARC 都好好的，唯獨 SPF 沒過。

原因幾乎都在 Return-Path（envelope from）那個退信子網域，例如 bouncing.example.com。你檢查主網域的 SPF 會發現完全正常，但微軟驗的是 Return-Path 的網域，那個子網域往往根本沒有自己的 SPF 記錄。

怎麼修：查出實際的 Return-Path 網域，幫它建 SPF TXT 記錄，把寄送平台的 IP 段或 include 加進去。

順便一提，這個問題通常不會只影響微軟。同一個 SPF 缺口在 Gmail 那邊會變成 421 4.7.27 SPF alignment failure，兩邊會同時出現。我遇過的案子裡，補一筆 SPF 就同時把 Outlook 硬退和 Gmail 限流一起解決了。Gmail 那側的細節可以看Gmail 421 錯誤完整解讀。

二、Spf=Pass, Dkim=Fail, DMARC=Pass：DKIM 沒設（最反直覺的一種）

這種是純粹的「微軟比 DMARC 嚴」造成的。SPF 過了、DMARC 靠 SPF 對齊也 Pass 了，照 DMARC 的規則這封信完全合格，但微軟看到 DKIM 沒過就硬退。

我手上有個案子的數字很典型：延遲率 0.11%（收件方完全沒在限流），但退信率 23%，其中 85% 全是 5.7.515。光是這一筆沒設好的 DKIM，就造成了八成以上的退信。

怎麼修：把寄送平台給你的 DKIM CNAME 記錄設到 _domainkey 底下。要注意的是，不同平台的 selector 名稱不一樣，而且同一個平台在不同區域的 selector 也不同。如果你用的是 Microsoft Dynamics 365 Marketing 這類有區域劃分的平台，歐洲區和北美區要設的 CNAME 名稱是不同的，複製錯區域的設定會白做一場。設完等 DNS 生效，用網域健檢工具驗一下有沒有真的解得出來。

三、Spf=Pass, Dkim=Pass, DMARC=Fail：對齊沒過，網域沒驗證

兩項驗證各自都通過了，但 DMARC 還是 Fail。這代表對齊（alignment）失敗：SPF 和 DKIM 驗過的網域，跟你 From 顯示的網域不是同一個。

實務上最常見的成因，是在寄送平台裡沒有完成寄件網域的驗證程序。平台會先讓你用它的預設網域寄信，等你把自訂網域的 CNAME 設好、按下驗證，簽章才會換成你自己的網域。沒做這一步，兩項驗證都是用平台的網域過的，對齊自然不成立。

怎麼修：回到寄送平台的網域設定，把自訂寄件網域的驗證流程走完。

這種案子的特徵是拖很久都不會自己好。我追過一個超過 40 天沒處理的，退信率從 17% 一路爬到 26%，而且完全沒有好轉跡象，因為 DNS 沒動，微軟的判定就永遠一樣。

四、DMARC=None：沒有 DMARC 記錄，或有兩筆

None 不是 Fail，意思是微軟找不到可用的 DMARC 記錄。有兩種可能：

1. 你根本沒設 DMARC。補一筆 v=DMARC1; p=none; rua=mailto:... 就好，p=none 只監控、不會擋自己的信。
2. 你設了兩筆。 這個陷阱很陰險：_dmarc.example.com 底下有兩筆 TXT 記錄時，依照規範這等同無效，微軟會直接判成 None。最常發生在集團公司，母公司統一部署了一筆，子公司的行銷團隊自己又加了一筆。

第二種我遇過真實案例，客戶查了快一個月都想不通「我明明設了 DMARC」，答案是設了兩次。

怎麼修：先確認 _dmarc 底下只有一筆記錄，刪掉多的那筆，再補上或修正內容。DMARC 本身的觀念可以參考SPF / DKIM / DMARC 入門。

五、三項全 Fail：這個子網域什麼都沒設

Spf=Fail, Dkim=Fail, DMARC=Fail 通常出現在新啟用的寄件子網域上。主網域設定得好好的，但行銷團隊新開了一個 news.example.com 或 mailing.example.com 來寄電子報，沒有人記得子網域需要自己的一套設定。

怎麼修：SPF 和 DKIM 都要設在實際寄件的那個子網域上。DMARC 比較特別，設在主網域即可，子網域會繼承。

一張對照表

別跟 550 5.4.1 搞混了

微軟還有另一個 550 開頭的常客，長這樣：

550 5.4.1 Recipient address rejected: Access denied

同樣是微軟、同樣是 550、同樣寫著 Access denied，但這兩個要做的事完全相反：

• 5.7.515 是「你的網域不合格」，問題在寄件方，補 DNS 就能修，名單完全沒問題。
• 5.4.1 是「這個信箱不存在或已停用」，問題在收件名單，通常是 B2B 名單裡的人離職了、企業信箱被停用。DNS 補到天荒地老都沒用，該做的是把地址清掉，完整判讀見550 5.4.1 Access denied 是什麼意思。

同樣容易混淆的還有 451 4.4.4 ATTR5，那個更陰險：它是 4xx 暫時碼、看起來會重試，實際上代表對方整間公司的信箱訂閱已經沒了，永遠送不到，判讀見451 4.4.4 ATTR5 是什麼。

判斷方法很簡單：5.7.515 集中在同一個寄件網域的所有收件人身上，5.4.1 則是散落在名單裡的個別地址。 如果你的退信報告裡兩種都有，代表你同時有設定問題和名單問題，要分開處理。

收到 5.7.515，照這個順序做

1. 先把完整 DSN 訊息挖出來，特別是 Spf= / Dkim= / DMARC= 那一行。只看代碼修不了，看到那三個值才知道要補哪一筆。
2. 確認 Return-Path 的網域，不是 From 的網域。前者才是 SPF 驗的對象，也是最多人查錯地方的一步。
3. 對照上面那張表，找出缺的那一筆 DNS。
4. 設好之後等 DNS 生效，用網域健檢工具確認三項都解得出來，別靠猜。
5. 下一次發送觀察退信率。5.7.515 修好之後是立即見效的，不像聲譽問題要養好幾週。如果沒降，回到第一步重新看 DSN，多半是另一項也有問題。

一個提醒：不要因為退信率高就急著降速或換網域。 5.7.515 跟發送量、跟聲譽都沒有關係，降速不會讓微軟改變判定，換網域反而是把聲譽打掉重練。這是少數「純粹是設定問題」的退信碼，修設定就好。

一句話總結

550 5.7.515 是微軟在說「你的驗證沒達標」，而且它已經把是哪一項沒過寫在訊息裡了。看懂 Spf= / Dkim= / DMARC= 這三個值的組合，你就能直接對應到要補哪一筆 DNS，不用申請解封、不用降速、不用等聲譽恢復。

如果你看著一堆退信報告，抓不出完整的 DSN 訊息、或者補了 DNS 退信率還是降不下來，歡迎找我聊聊，我幫你把退信資料拆開來看，找出真正卡住的那一筆設定。