什麼是 ARC（已驗證接收鏈）？

定義

已驗證接收鏈是定義於 RFC 8617 的電子郵件驗證標準，於 2019 年 7 月發布。它的目的在於解決 SPF 與 DKIM 長期存在的弱點：當郵件透過中介伺服器轉送，而非由寄件者直接送達收件者時，兩者往往無法正常運作。

直接寄信給收件者時，SPF 與 DKIM 檢查通常都會通過，DMARC 也會通過。問題出在郵件中途經過第三方的時候。郵件群組、設定自動轉寄的帳號或安全閘道，經常會修改郵件內容，例如改寫主旨、加上頁尾，或從不同的 IP 位址轉送郵件。這些變動會破壞原本的 DKIM 簽章，並讓 SPF 結果失效，導致即使郵件完全正當，DMARC 仍可能判定失敗。

ARC 由包含 Google 及其他大型郵件業者工程師在內的產業團體所設計，目的就是讓收件端能辨識這種情況。收件端不必只根據最後一站看到的失效驗證結果來判斷，而是可以讀取 ARC 鏈，得知郵件在中介節點處理之前其實已正確通過驗證。

運作方式

ARC 的運作方式是：每個參與的中介節點在轉送郵件前，都會在郵件中加入一筆經過加密簽章的記錄，稱為 ARC 集合（ARC set）。每個 ARC 集合由三個標頭欄位組成，並附有一個實例編號，讓整條鏈可以依序讀取。

第一個欄位是 ARC-Authentication-Results，記錄中介節點收到郵件當下所觀察到的 SPF、DKIM 與 DMARC 結果快照，等同於凍結了該節點的驗證判定。

第二個欄位是 ARC-Message-Signature，作用與 DKIM 簽章十分相似。它是針對郵件在鏈中該時點的標頭與內文所做的加密簽章，將所記錄的驗證結果與當時的實際內容綁定在一起。

第三個欄位是 ARC-Seal，這個簽章涵蓋先前整條 ARC 標頭鏈，而不只是目前這一組。封印中帶有一個鏈驗證標記，寫作 cv，用來回報目前為止鏈的狀態：none 表示這是第一站，pass 表示先前每一組 ARC 集合都驗證無誤，fail 則表示鏈中有某部分無法驗證。

郵件經過多台支援 ARC 的伺服器時，實例編號會隨每一站遞增。進行驗證的收件伺服器會依序讀取各組 ARC 集合，確認沒有缺漏，檢查每個封印是否回報先前的項目皆有效，並驗證最新的郵件簽章。只要整條鏈完整無誤，收件端就能信任第一站所記錄的驗證結果。

對電子郵件送達率的重要性

ARC 之所以重要，是因為轉寄與郵件群組無所不在，而缺少 ARC 時，它們會在不知不覺中讓正當郵件遭到拒收。員工將公司郵件轉寄到個人信箱、討論群組在每封郵件加上頁尾、第三方安全設備掃描收到的郵件，這些都會破壞 DKIM 或 SPF，但與郵件本身是否真實毫無關係。

當網域擁有者發布嚴格的 DMARC 政策（例如 p=reject）時，這些失效的驗證結果通常會導致轉寄副本被丟棄。收件者永遠收不到原本預期的郵件，從外部看來就像是一次原因不明的投遞失敗。ARC 為最終收件端提供足夠的脈絡，做出更好的判斷。如果 ARC 鏈顯示郵件在受信任的中介節點修改之前已正確通過驗證，收件端就可以選擇投遞該郵件，而不是對誠實的轉寄套用嚴格政策。

必須準確理解 ARC 能做什麼、不能做什麼。ARC 不會凌駕 DMARC，也不保證郵件一定送達，它只是一個訊號。收件端仍會自行決定要對某條 ARC 鏈給予多少信任，而這份信任取決於簽署該鏈之中介節點的信譽。ARC 只是消除了一個常見又惱人的誤判拒收來源，讓正當郵件有更好的機會進入收件匣。

VeriMails 如何處理

VeriMails 是電子郵件驗證服務，因此專注於送達率中另一個互補的環節。ARC 保護的是已經在中介節點之間傳送的郵件，而 VeriMails 則在您按下寄送之前就開始運作，確認名單上的地址真實存在且能夠收信。

針對每個要檢查的地址，VeriMails 都會執行語法驗證、MX 記錄查詢、DNS 檢查、與收件郵件伺服器進行即時 SMTP 交握、Catch-all（全收）偵測、拋棄式地址偵測及職能信箱偵測。綜合這些檢查，就能在地址進入行銷活動之前判斷它是否可送達，並以清楚的送達分類協助您做出行銷活動決策。

這兩種作法相輔相成。ARC 以及由 SPF、DKIM 與 DMARC 組成的整體驗證機制，透過證明郵件真實可信來保護您的寄件信譽。VeriMails 則從另一個方向保護同樣的信譽：將無效與有風險的地址排除在名單之外，減少退信與垃圾郵件檢舉。您可以透過 VeriMails REST API 逐一驗證地址，也可以上傳 CSV 檔批次驗證；每個新帳戶都附贈 100 點永不過期的免費點數，無需信用卡。

常見問題