The Will Will Web

10 月 23 日下午，我收到一封標題為「【TWNIC資安提醒】PHP 出現嚴重漏洞，請儘快更新 / Security Alert: Critical PHP Vulnerabilities, Please Update Now」的通知信。內容談的是 PHP 剛發布的兩個高風險漏洞，時機點很合理，但 Outlook 網頁版在寄件者旁邊跳出警示，說無法驗證這封信是否真的來自該寄件者。

這種畫面很容易讓人直接下結論：不是釣魚信，就是對方的 SPF 設定壞了。但把原始標頭攤開來看，spf=pass 明明白白寫著通過，所以「SPF 沒設好」這個推論立刻站不住腳。問題的關鍵不在 SPF 有沒有通過，而是通過的是哪一個網域。

這篇文章整理我拆解這封信的過程：從 Microsoft 在標頭寫入的驗證結果，到我另外查詢的 DNS 紀錄，再到寄件端與代寄平台應該怎麼修。讀完之後，你也可以用同樣的方法，自己判斷手上那些「未驗證」的信，到底是被偽冒，還是只是寄送設定沒做完整。

本文以 Outlook 網頁版與 Microsoft 365 收信端的標頭為準，DNS 紀錄是我在 2026 年 10 月 23 日晚間查詢的結果，之後寄件端若調整設定，內容可能改變。文中只保留與判讀有關的標頭欄位，收件者與郵件識別碼不公開；寄送平台的 IP 與主機名稱屬於公開的寄信基礎設施。

原始標頭已經指出原因

我先從 Outlook 網頁版的郵件詳細資料取得原始標頭。Microsoft 接收端寫入的 Authentication-Results 標頭如下，我只整理了換行：

Authentication-Results: mx.microsoft.com 1;
  spf=pass (sender IP is 218.32.93.136)
    smtp.mailfrom=ascrm.newermail.com;
  dkim=none (message not signed) header.d=none;
  dmarc=fail action=none header.from=twnic.tw;
  compauth=fail reason=001

逐項對照如下：

我在 Outlook 網頁版看到的寄件者顯示為 [email protected] via ascrm.newermail.com，畫面上的警示與這段標頭的結果完全一致。這裡先把結論講在前面：SPF 通過，但通過的是代寄平台的網域，與畫面上的寄件網域 twnic.tw 不對齊；同時這封信沒有 DKIM 簽章，所以 DMARC 與 compauth 都失敗，Outlook 才會顯示未驗證。

先搞懂幾個容易混在一起的名詞

要看懂上面那段標頭，得先分清楚一封信裡其實有兩個「寄件者」，以及三種驗證機制各自在檢查什麼：

SPF 與 DKIM 本身都不要求 From 與驗證網域一致，是 DMARC 才加上「對齊」這個條件，目的就是防止有人用自己的網域通過 SPF，卻在畫面上顯示成別人的名字。依 Microsoft Learn 的 DMARC 說明，DMARC 的判斷方式如下：

• SPF 通過，且 MAIL FROM 網域與 From 網域對齊。
• DKIM 通過，且簽章的 d= 網域與 From 網域對齊。

兩條路徑只要有一條成立，DMARC 就通過；兩條都不成立，才是 dmarc=fail。

為什麼 SPF 通過，仍然會顯示未驗證？

把這封信套進上面的規則：

也就是說，這封信的 SPF 結果只證明了一件事：218.32.93.136 可以代表 ascrm.newermail.com 寄信。它沒有證明這個 IP 可以代表 twnic.tw 寄信，而 DMARC 要驗證的偏偏是後者。

這不是特例。Microsoft 在 DMARC 疑難排解文件裡，把「非 Microsoft 的服務代你寄信」列為常見的對齊失敗情境，症狀就是 SPF 通過，但 DMARC 失敗；原因是 MAIL FROM 使用了服務自己的網域，又沒有以你的網域簽署 DKIM。我這次碰到的，正是教科書版本。

我另外查了 DNS，結果比原本想的更有意思

標頭只能說明這封信「收到當下」發生了什麼。為了確認寄件端自己是怎麼宣告的，我接著查了 twnic.tw 的 DMARC 與 SPF 紀錄。DMARC 紀錄如下：

_dmarc.twnic.tw  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none 代表網域擁有者要求收件端「失敗了也不要處置，只要回報」，而且沒有設定 aspf 或 adkim，所以對齊模式是預設的寬鬆（relaxed）。這剛好解釋了標頭裡兩個細節：

• dmarc=fail action=none：DMARC 失敗，但依政策不採取動作。
• compauth=fail reason=001：依 Microsoft Learn 的標頭說明，001 代表隱含驗證失敗，原因是寄件網域沒有發布驗證記錄，或是發布的失敗政策較弱，例如 DMARC 的 p=none。

接著是 SPF。twnic.tw 的 SPF 紀錄是一串 include，我逐層展開後發現，其中 _spfv42.twnic.tw 又包含了 spf.neweredm.com：

_spfv42.twnic.tw   TXT  "v=spf1 ip4:59.125.164.91/32 ... include:spf.neweredm.com -all"
spf.neweredm.com   TXT  "v=spf1 ... ip4:218.32.93.0/24 ... ~all"

這個範圍涵蓋了寄件 IP 218.32.93.136，而它的反向解析正是標頭裡的 x136.neweredm.com。換句話說，TWNIC 自己的 SPF 已經授權了這個寄送平台。如果這封信的 MAIL FROM 用的是 twnic.tw 或它的子網域，SPF 不但會通過，還會與 From 對齊，DMARC 也就過關了。

這是這次最值得記錄的地方：問題不在 SPF 清單漏了誰，而是這個平台寄這封信時，MAIL FROM 用的是自己的 ascrm.newermail.com，而不是 TWNIC 的網域。SPF 查的是 MAIL FROM 的網域，所以 TWNIC 在自己的 SPF 裡授權了平台，對這封信完全沒有幫助。

為什麼它仍然進得了收件匣？

原始標頭裡還有 X-Forefront-Antispam-Report 這一段：

X-Forefront-Antispam-Report:
  SCL:1;
  SFV:NSPM;
  CAT:NONE;

其中 SFV:NSPM 表示垃圾郵件篩選階段把這封信判為非垃圾郵件。寄件身分驗證失敗與郵件仍然被投遞，是可以同時發生的。Microsoft 文件對 compauth 的說明寫得很清楚：即使複合驗證失敗，只要其他評估沒有顯示可疑，郵件仍可能被允許。再加上 twnic.tw 的 DMARC 是 p=none，收件端本來就沒有被要求要隔離或拒收。

所以這個警示的性質比較像是「Outlook 提醒你：我沒辦法替這個寄件者背書」，而不是「這封信一定有問題」。

這封信的內容是否可信？

這是另一個必須分開看的問題。寄件身分驗證失敗，與信件內容是否正確，是兩回事。我直接對照了 PHP 官方公告，信中的說法大致都有依據：

官方修補版本為 PHP 8.5.12、8.4.27、8.3.36、8.2.35。官方對影響範圍的描述，也比信中的概括文字更精確：風險在於處理網頁請求的 PHP 執行環境，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed，其中 mod_php 風險最高。更新之後還要重新啟動 PHP-FPM 與網頁伺服器的工作處理序，新版本才會真的被載入。

目前我手上的證據可以支持三個結論：

• 漏洞消息確實存在。
• 這封信沒有通過與 twnic.tw 對齊的寄件身分驗證。
• TWNIC 的 SPF 紀錄已列出這個寄送平台，因此它很可能是 TWNIC 授權的群發通知；但標頭與 DNS 仍然不能取代 TWNIC 本身的確認。

Microsoft 也提醒過，未通過驗證的郵件不一定是惡意郵件。所以不能只憑「未驗證」就斷定是假信，也不能只憑內容正確就認定是官方寄送。實務上最穩的做法，是不要依賴信中的連結，直接從 PHP 官方網站與你的作業系統供應商查更新。

根本修正應在寄件端或代寄平台完成

收件者能做的有限，真正要修的是寄送端。如果這確實是 TWNIC 授權的群發通知，寄送平台需要補上與 twnic.tw 對齊的驗證，做法有兩種：

自訂 DKIM 是我會優先建議的做法，因為簽章跟著郵件走，不受信封寄件者影響，轉寄時也比 SPF 穩定。若選擇自訂 MAIL FROM，有兩個細節要注意：

• SPF 不會繼承到子網域。使用 bounce.twnic.tw 時，必須在該子網域另外發布 SPF，授權寄送平台的 IP 範圍。
• 要確認 DMARC 的 SPF 對齊模式。預設的寬鬆模式允許子網域對齊；若設定了 aspf=s，就要求網域完全一致，子網域會失敗。twnic.tw 目前沒有設定這個參數，所以預設是寬鬆。

還有一個很容易修錯的地方：如果 MAIL FROM 仍然是 ascrm.newermail.com，再怎麼調整 twnic.tw 的 SPF 記錄，都修不了這次的對齊問題。從上一節的 DNS 查詢可以看到，這個平台早就在 TWNIC 的 SPF 裡了，這封信依然失敗，正好說明這條路走不通。

設定完成後，應該用新寄出的測試信確認標頭裡出現 dmarc=pass 與 compauth=pass。等這兩項穩定通過，再考慮把 DMARC 政策從 p=none 逐步提高到 p=quarantine 與 p=reject，才能真正擋掉偽冒 twnic.tw 的信件。

總結

這次的追查，讓我再次確認「spf=pass」不能單獨解讀，一定要看 smtp.mailfrom 是哪一個網域，再拿它跟 From 比對。整理成幾句話：

• Outlook 顯示未驗證的真正原因：SPF 通過的是 ascrm.newermail.com，與畫面上的 twnic.tw 不對齊；加上沒有 DKIM 簽章，所以 dmarc=fail、compauth=fail reason=001。
• 信件仍然進入收件匣：twnic.tw 的 DMARC 是 p=none，驗證失敗不會被要求處置，其餘篩選也判為非垃圾郵件。
• 這不代表 SPF 清單有漏：TWNIC 的 SPF 已經包含這個平台，缺的是 MAIL FROM 與 From 的對齊，或是以 twnic.tw 簽署的 DKIM。
• 內容與來源要分開判斷：PHP 漏洞有官方公告，這件事是真的；但來源驗證沒通過，仍然值得寄件端補強。

如果你自己的網域也使用第三方寄送平台發送通知信、電子報或行銷信，建議現在就去看一眼自己寄出去的信，在 Gmail 或 Outlook 的原始郵件中，檢查 dkim 的 header.d 與 spf 的 smtp.mailfrom 是不是你的網域。很多「未驗證」的警示，其實一個 DKIM 設定就能解決。

相關連結

• Microsoft Learn：Anti-spam message headers
• Microsoft Learn：Set up DMARC to validate email in Microsoft 365
• Microsoft Support：Phishing and suspicious behavior in Outlook
• PHP 官方公告：Critical remote code execution vulnerabilities, update now
• Microsoft Learn：Email authentication in Microsoft 365
• Microsoft Learn：Set up SPF in Microsoft 365
• Microsoft Learn：Set up DKIM in Microsoft 365
• RFC 7208：SPF
• RFC 6376：DKIM Signatures
• RFC 7489：DMARC
• RFC 8601：Authentication-Results 標頭
• RFC 5321：SMTP
• RFC 5322：Internet Message Format