Cloudflare DMARC Management 正式上線：統一電子郵件身份驗證管理平台
Cloudflare Blog · 2026-06-16
2026 年 6 月 16 日，Cloudflare 宣布旗下 DMARC Management 服務正式進入 GA（Generally Available）階段，面向所有使用 Cloudflare 託管 DNS 的客戶免費開放。此平台整合 SPF、DKIM、DMARC 與 BIMI 四種電子郵件身份驗證標準，透過統一介面協助網域管理員從「監控模式」逐步推進至「完整執行模式」，毋須手動解析 XML 報告或聘用外部顧問。
電子郵件身份驗證的背景與挑戰
電子郵件欺詐（Email Spoofing）至今仍是最常見的網路攻擊向量之一，根源在於 SMTP 協議本身不驗證寄件人身份。為此業界發展出三層防護機制：SPF 定義哪些 IP 位址可代表網域寄信；DKIM 對信件內容施加加密簽章；DMARC 則綜合 SPF 與 DKIM 的驗證結果，指示收件伺服器對驗證失敗的郵件執行允許、隔離或拒絕動作，並產生聚合報告回傳給網域擁有者。
過去兩年，Google、Microsoft 與 Yahoo 相繼收緊郵件身份驗證要求，對大量郵件寄送者強制要求 DMARC p=reject 或 p=quarantine 政策。Cloudflare 指出，「曾經是最佳實踐的規範，如今已成為強制要求」。然而 DMARC 的部署過程涉及多個 DNS 記錄的協同配置，一旦設定錯誤便可能導致合法郵件被誤退或漏攔截。
原本的問題
SPF 的 DNS 查詢上限問題是企業部署中最常踩到的陷阱。RFC 7208 規定，每次 SPF 評估最多允許 10 次 DNS 查詢；企業若使用多家郵件服務（如 Google Workspace、Salesforce、SendGrid、HubSpot），巢狀的 include 機制很容易超過上限，導致 SPF 評估直接失敗（PermError），使得原本合法的郵件被視為驗證失敗。
此外，DMARC 的聚合報告格式為 XML，內容包含大量 IP 位址與傳送服務資訊，人工解讀報告既費時又需要專業知識。中小型組織往往因此無法及時偵測到網域被冒用的跡象，或遲遲不敢將 DMARC 政策從 p=none（純監控）升級至具備防護效力的 p=quarantine 或 p=reject。
採用的方法
Cloudflare DMARC Management 將所有驗證記錄的狀態集中於單一儀表板，針對四種記錄類型提供自動化分析：
- SPF：偵測重複記錄、計算 DNS 查詢層數、標記過度寬鬆的
+all機制，並識別可合併的 include 來源 - DKIM：驗證公鑰格式是否有效，確認金鑰完整性
- DMARC：顯示目前政策執行層級（none / quarantine / reject），並標示尚未啟用 RUA 報告收集的配置缺口
- BIMI：驗證品牌標誌 URL 格式及 VMC（Verified Mark Certificate）是否存在
SPF Lookup Audit 功能可視覺化整個查詢鏈，明確標示哪一層 include 造成查詢數超標，並提供合併建議，協助管理員在不影響授權來源的前提下壓縮查詢次數。每筆記錄均以通俗語言（而非 RFC 術語）呈現問題說明與修復建議。
報告視覺化介面針對每個傳送來源顯示 IP 位址、服務識別，以及與 Cloudflare 威脅情報資料庫的整合結果，包含地理位置、ASN 資訊與惡意活動關聯性。Investigate 標籤頁讓管理員可直接對可疑來源進行威脅情報查詢，無需切換至另一工具。
實際效果
此次 GA 發布著重在讓組織能夠自助完成從 p=none 到 p=reject 的政策遷移路徑，不再依賴專業服務或手動流程。服務對所有使用 Cloudflare 作為 DNS 供應商的客戶免費提供，透過 Cloudflare 儀表板的「Email > DMARC Management」路徑進入。後續路線圖包含更深層的鑑識報告（Forensic Reporting）、智慧型修復建議，以及與 Cloudflare 電子郵件安全套件更緊密的整合。
Google 推出 TPU Developer Hub：整合 XLA、Pallas 與分散式訓練的技術文件中心
Google Developers Blog · 2026-06-16
2026 年 6 月 16 日，Google 宣布正式推出 TPU Developer Hub，作為 Cloud TPU 開發者的集中式技術文件與程式碼範例平台，涵蓋從預訓練到推論的完整 AI 開發生命週期。此 Hub 整合硬體架構指南、XLA 編譯器最佳化、Pallas 核心開發、分散式訓練配置，以及推論階段的效能調校資源，旨在讓開發者能夠系統性地挖掘 Cloud TPU 的效能潛力。
TPU 軟體堆疊的技術背景
TPU（Tensor Processing Unit）並非通用 GPU，其軟體堆疊在多個層次上與 CUDA 生態系有根本差異。XLA（Accelerated Linear Algebra）是 TPU 的核心編譯器，負責將 JAX、PyTorch/XLA、TensorFlow 等框架的計算圖轉換為高效的 TPU 指令序列；XLA 的 HLO（High Level Operations）中間表示層允許跨設備的最佳化，包括運算子融合（Operator Fusion）與記憶體佈局轉換。
在低層次核心開發方面，Google 近年推出的 Pallas 框架提供類似 Triton 的介面，讓開發者可撰寫自訂 TPU 核心（Kernel），精確控制 HBM 與 VMEM 之間的資料搬移時機，從而針對特定運算（如 Flash Attention 變體）達成接近理論頻寬上限的效能。Pallas 在 JAX 生態系中以 jax.experimental.pallas 提供，Hub 中收錄了對應的最佳化食譜（Recipes）。
Hub 涵蓋的技術主題
TPU Developer Hub 依開發階段組織文件，主要技術主題包含：
- 硬體與基礎設施：TPU 晶片世代（v4 / v5e / v5p / v6e Trillium）的架構差異、消費模式選擇（bare-metal kernel vs. Cloud TPU 服務）
- 編譯器技術：XLA 最佳化旗標、HLO 分析工具、常見效能反模式（如不必要的全精度轉換）
- PyTorch 遷移路徑：從 CUDA 遷移至 PyTorch/XLA 的常見陷阱與解決方案
- 多晶片執行：SPMD（Single Program Multiple Data）分片策略，以及 DCN（Data Center Network）與 ICI（Inter-Chip Interconnect）的拓撲感知分片
- 觀測工具：XProf 遙測工具的使用方式，包含 Trace Viewer 的解讀與效能瓶頸定位
推論最佳化：KV Cache Offloading
在推論場景中，Hub 特別收錄了 KV Cache Offloading 技術的深度文件。大型語言模型在長序列推論時，KV Cache 的記憶體佔用可能遠超 HBM 容量上限；KV Cache Offloading 透過將部分快取卸載至 CPU 記憶體或 SSD，在可接受的延遲代價下支援更長的上下文視窗。此技術在 TPU 上的實作需要精確協調 HBM 與 CPU 記憶體之間的非同步傳輸時序，避免影響推論吞吐量。
Hub 的程式碼食譜（Code Recipes）以可直接執行的開源範例呈現，設計上相容 AI 輔助開發工具，讓開發者可透過對話式工具直接查詢與套用最佳化模式，而不必逐頁閱讀文件。
與既有文件的差異
此前 Cloud TPU 的技術文件散落於 Google Cloud 官方文件、JAX 文件、PyTorch/XLA GitHub wiki 以及各研究論文之間，缺乏一個以「端到端 AI 工作負載開發」為視角的統整入口。TPU Developer Hub 將這些資源依照開發者面臨的實際問題（而非技術元件的邊界）重新組織，並持續以開源食譜的形式更新實戰經驗，填補 API 文件與生產部署之間的落差。
Sign in with Google 新增 OIDC Session Metadata：auth_time 與 amr 支援步驟升級驗證
Google Developers Blog · 2026-06-16
2026 年 6 月 16 日，Google 宣布在「Sign in with Google」流程中新增兩個標準 OIDC（OpenID Connect）宣告（Claims）：auth_time 與 amr（Authentication Methods Reference）。這兩個宣告隨 ID Token 回傳至應用程式後端，讓開發者得以驗證使用者的 Google 工作階段新鮮度，並依據驗證強度實施細粒度的存取控制，在不重建 Google 側身份驗證邏輯的前提下支援步驟升級驗證（Step-Up Authentication）。
OIDC Claims 的技術定義
auth_time 依照 OIDC Core 規範定義為「終端使用者最後一次成功通過身份驗證的時間」，以 Unix epoch 秒數（UTC）表示。此值代表使用者與 Google 之間的工作階段建立時間，而非 ID Token 的簽發時間（iat）或過期時間（exp）；三者在語意上截然不同，混淆使用會導致安全漏洞。OIDC 規範規定，當請求中包含 max_age 參數或應用程式將 auth_time 標記為 Essential Claim 時，此宣告為必填；否則為選填。
amr（Authentication Methods References）是一個 JSON 字串陣列，記錄本次 Google 工作階段所採用的身份驗證方法組合。Google 支援的 amr 值包含：
pwd：密碼驗證mfa：多因素驗證hwk：硬體安全金鑰（如 Titan Security Key）swk：軟體安全金鑰（如 Passkey）tel：電話驗證sms：簡訊驗證碼
amr 值依照 IANA Authentication Method Reference Values 登錄表的標準定義，允許應用程式在不感知 Google 內部身份驗證流程細節的情況下，判斷本次驗證的強度等級。
雙工作階段模型的架構意義
使用「Sign in with Google」的應用程式實際上管理兩個獨立的工作階段：使用者與 Google 的工作階段，以及使用者與應用程式本身的工作階段。傳統作法只能感知後者的存活狀態，無法得知前者的驗證時間或強度；應用程式在更新 access token 時，即使 Google 側工作階段已靜置數小時甚至數天，應用程式仍無從察覺。
auth_time 與 amr 填補了這個資訊缺口。透過這兩個宣告，應用程式可以實作以下安全策略而無需在自身系統中重複實作 Google 的身份驗證邏輯：
- 當 auth_time 距今超過特定門檻（如 4 小時）時，強制要求使用者重新向 Google 驗證身份
- 當敏感操作（如轉帳、修改安全設定）被觸發時，檢查 amr 是否包含
hwk或mfa；若僅有pwd，要求升級至更高強度的驗證 - 依據 amr 值產生稽核日誌，記錄每次高權限操作時所使用的驗證方法
請求 Essential Claims 的方法
開發者若需確保 ID Token 中一定包含 auth_time 與 amr，須在授權請求的 claims 參數中明確標記為 essential: true。以下為授權端點請求範例：
https://accounts.google.com/o/oauth2/v2/auth?
response_type=id_token&
client_id=YOUR_CLIENT_ID&
claims={
"id_token": {
"amr": { "essential": true },
"auth_time": { "essential": true }
}
}標記為 essential 的宣告若 Google 無法提供，授權流程將回傳錯誤，而非靜默省略該宣告，確保應用程式不會在宣告缺失的情況下誤判安全狀態。
實際應用場景
此功能對需要差異化存取控制的應用程式尤為重要。金融類或企業內部系統可依 auth_time 實施「工作階段新鮮度窗口」（Session Freshness Window）：一般操作接受 8 小時內的工作階段，而修改帳號安全設定或執行高價值交易則要求工作階段在 15 分鐘內建立，且 amr 必須包含硬體金鑰驗證。這種基於風險的動態驗證策略取代了過去只能依靠靜態工作階段過期時間的粗粒度控制，同時也降低了對第三方身份驗證中介服務的依賴。
原始來源：Google Developers Blog — Session Metadata in Sign in with Google · OIDC Core 1.0 Specification