# 從 TWNIC 資安通知信看 DMARC 網域對齊問題

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

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

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

![一輛載著伺服器的貨車把信件送往收件匣，信封上的封蠟已經破裂，上方兩張網域身分卡片互不相符，收件匣旁出現琥珀色問號警示](https://stwillblogassets.blob.core.windows.net/files/images/2026/10/outlook-unverified-sender-dmarc/banner.webp)

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

* * *

### 原始標頭已經指出原因

我先從 Outlook 網頁版的郵件詳細資料取得原始標頭。Microsoft 接收端寫入的 [Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601) 標頭如下，我只整理了換行：

```
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
```

逐項對照如下：

| 檢查項目 | 這封信的實際結果 | 意義  |
| --- | --- | --- |
| 畫面上的寄件者 `From` | `system@twnic.tw` | 郵件宣稱的寄件身分是 TWNIC |
| SMTP 信封寄件網域 `MAIL FROM` | `ascrm.newermail.com` | 傳送與退信處理使用另一個網域 |
| 實際連入 Microsoft 的伺服器 | `x136.neweredm.com`，IP 為 `218.32.93.136` | 郵件從這個外部寄送系統交給 Microsoft 365 |
| SPF | `pass` | 該 IP 獲得 `ascrm.newermail.com` 授權寄信 |
| DKIM | `none (message not signed)` | **這封信沒有 DKIM 簽章** |
| DMARC | `fail`，驗證對象為 `twnic.tw` | 沒有通過與畫面寄件網域對齊的驗證 |
| Microsoft [複合驗證](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about#composite-authentication) | `compauth=fail reason=001` | Microsoft 的綜合寄件身分驗證也失敗 |

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

* * *

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

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

| 名詞  | 它是什麼 | 這封信的值 |
| --- | --- | --- |
| `From`（[5322.From](https://www.rfc-editor.org/rfc/rfc5322)） | 收件者在郵件軟體看到的寄件者 | `twnic.tw` |
| `MAIL FROM`（[5321.MailFrom](https://www.rfc-editor.org/rfc/rfc5321)） | SMTP 傳送時使用的信封寄件者，退信也送到這裡 | `ascrm.newermail.com` |
| [SPF](https://www.rfc-editor.org/rfc/rfc7208) | 檢查「連線的 IP 是否被 `MAIL FROM` 網域授權」 | 對 `ascrm.newermail.com` 通過 |
| [DKIM](https://www.rfc-editor.org/rfc/rfc6376) | 檢查郵件上的數位簽章，簽章網域記在 `d=` | 沒有簽章 |
| [DMARC](https://www.rfc-editor.org/rfc/rfc7489) | 要求 SPF 或 DKIM 至少一條通過，**而且驗證的網域要與 `From` 對齊** | 兩條路徑都沒有對齊 |

SPF 與 DKIM 本身都不要求 `From` 與驗證網域一致，是 DMARC 才加上「對齊」這個條件，目的就是防止有人用自己的網域通過 SPF，卻在畫面上顯示成別人的名字。依 [Microsoft Learn 的 DMARC 說明](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)，DMARC 的判斷方式如下：

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

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

* * *

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

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

| 比較項目 | 網域  |
| --- | --- |
| SPF 實際驗證的網域 | `ascrm.newermail.com` |
| 畫面 `From` 宣稱的網域 | `twnic.tw` |
| SPF 路徑是否對齊 | **不成立** |
| DKIM 路徑 | **沒有簽章，無從對齊** |

也就是說，這封信的 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:tech@twnic.tw"
```

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

-   `dmarc=fail action=none`：DMARC 失敗，但依政策不採取動作。
-   `compauth=fail reason=001`：依 [Microsoft Learn 的標頭說明](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo)，`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](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo) 這一段：

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

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

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

* * *

### 這封信的內容是否可信？

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

| 郵件主張 | 查證結果 |
| --- | --- |
| 漏洞為 [`CVE-2026-109618`](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)、[`CVE-2026-109619`](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) | PHP 官方 2026 年 10 月 21 日的安全公告確有這兩個漏洞 |
| 兩者評分皆為 9.2 | PHP 官方預告中標示為 [CVSS v4.0](https://www.first.org/cvss/v4-0/) 9.2 |
| 可能造成未經身分驗證的遠端程式碼執行 | 與官方公告一致 |
| 建議盤點、更新、檢查異常 | 官方表示沒有完整的緩解設定，更新是唯一安全的做法 |

官方修補版本為 PHP `8.5.12`、`8.4.27`、`8.3.36`、`8.2.35`。官方對影響範圍的描述，也比信中的概括文字更精確：風險在於**處理網頁請求的 PHP 執行環境**，包括 [PHP-FPM](https://www.php.net/manual/en/install.fpm.php)、[Apache mod\_php](https://www.php.net/manual/en/install.unix.apache2.php)、php-cgi、[FrankenPHP](https://frankenphp.dev/) 與 [LiteSpeed](https://www.litespeedtech.com/)，其中 mod\_php 風險最高。更新之後還要重新啟動 PHP-FPM 與網頁伺服器的工作處理序，新版本才會真的被載入。

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

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

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

* * *

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

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

| 修正項目 | 具體做法 | 預期效果 |
| --- | --- | --- |
| **優先設定[自訂 DKIM](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)** | 讓代寄平台以 `d=twnic.tw` 簽署郵件，並完成對應的 DNS 公鑰或 CNAME 設定 | 收件端取得 `dkim=pass header.d=twnic.tw`，建立與 `From` 對齊的驗證路徑 |
| 設定自訂 `MAIL FROM` | 改用 TWNIC 控制的網域，例如 `bounce.twnic.tw`，並在該網域設定正確的 [SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) | SPF 通過後，在寬鬆對齊模式下可與 `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](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo)
-   [Microsoft Learn：Set up DMARC to validate email in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)
-   [Microsoft Support：Phishing and suspicious behavior in Outlook](https://support.microsoft.com/en-us/outlook/mail/phishing-and-suspicious-behavior-in-outlook)
-   [PHP 官方公告：Critical remote code execution vulnerabilities, update now](https://www.php.net/archive/2026.php#2026-10-21-5)
-   [Microsoft Learn：Email authentication in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about)
-   [Microsoft Learn：Set up SPF in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)
-   [Microsoft Learn：Set up DKIM in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)
-   [RFC 7208：SPF](https://www.rfc-editor.org/rfc/rfc7208)
-   [RFC 6376：DKIM Signatures](https://www.rfc-editor.org/rfc/rfc6376)
-   [RFC 7489：DMARC](https://www.rfc-editor.org/rfc/rfc7489)
-   [RFC 8601：Authentication-Results 標頭](https://www.rfc-editor.org/rfc/rfc8601)
-   [RFC 5321：SMTP](https://www.rfc-editor.org/rfc/rfc5321)
-   [RFC 5322：Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322)