[ DNS 提供者指南 ]
在123 Reg：設定和驗證中發布電子郵件身份驗證記錄
在 123 Reg 中發布正確的TXT或選擇器記錄，然後區分權威DNS成功與實際的寄件者身份驗證。
由EmailAuth研究團隊提供 · 4 分鐘閱讀
[ 重點 ]
- 僅在權威DNS服務處發布。
- 保留寄件者的確切記錄類型和選擇器擁有者。
- DNS發布和發送者啟動需要單獨的證明。
[ 外帶 ]
DNS發布和發送者啟動需要單獨的證明。
[ 按角色 ]
這對您意味著什麼
選擇您的角色以執行後續實際步驟。
IT/郵件管理員
驗證實際路線
保留前後記錄集並從每個受影響的發送應用程式捕獲一條訊息。
後續步驟
- 將產生的擁有者與每個權威伺服器進行比較。
- 發布後測試來自每個受影響應用程式的一條訊息。
- 發送網域或 DNS 提供者變更後重新測試。
CISO / SecOps
控制授權邊界
批准新增的精確信任並保留針對選擇器或策略衝突的復原計劃。
後續步驟
- 拒絕計劃外的名稱伺服器遷移。
- 記錄必須保留哪些活動選擇器和報告目標。
- 保留批准的恢復和供應商退役決定。
創辦人/非技術人員
擁有發送決定權
為所有寄件者指派一個DNS變更擁有者，以便行銷要求無法默默地取代員工郵件授權。
後續步驟
- 命名共享SPF策略的每個服務的擁有者。
- 批准特定的DNS編輯和後備視窗。
- 啟動前需要受控訊息接受記錄。
[ 常見問題解答 ]
常見問題
我可以新增第二筆SPF TXT記錄嗎？
不是同一個SPF所有者。將合法授權合併到一項經過評估的策略中。
為什麼公共DNS中沒有保存的記錄？
在指責快取之前檢查權限、最終所有者名稱、委託以及記錄是否實際保存。
dig 輸出中的引號是否有多餘字元？
未必。 DNS工具顯示引號的TXT字串；檢查重建的值而不是複製表示標點符號。
發布DKIM是否會開啟簽章？
不可以。發送應用程式必須使用匹配的私鑰和選擇器進行簽署。
變更什麼時候完成？
當權威發布、發送者啟動和受控接收訊息對齊檢查都滿足變更計劃。
[ 來源 ]
來源
- 123 Reg TXT出版
部分 TXT設定和權威名稱伺服器先決條件
- 123 註冊DKIM出版
部分 TXT DKIM發布工作流程
- RFC 7208 SPF
部分 §3.2 多個DNS記錄 · §4.6.4 DNS查找限制
- RFC 6376 DKIM
部分 §3.5 DKIM-Signature頭欄位 · §3.6 金鑰管理與表示 · §6 驗證者操作
- RFC 9989 DMARC
部分 §4.4 識別碼對齊說明 · §5.3 郵件接收器操作
- RFC 1034 DNS概念
部分 §3.6.2 別名與規範名稱 · §4.2 資料庫如何劃分區域
- RFC 2308 DNS負緩存
部分 §5 快取否定答案
[ 詞彙表 ]
詞彙表
- 結盟
- 傳遞身分驗證網域與DMARC的可見寄件人域之間所需的關係。
- 選擇器
- 與簽章域一起使用的DKIM標籤在DNS中尋找其公鑰。
- 權威DNS
- 負責發布相關區域記錄的名稱伺服器服務。
- Return-Path
- SMTP反向路徑的接收訊息追蹤在調查信封身分時很有用。
企業出處
為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。
傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中，手動監督意味著延遲執行、配置漂移和不受監控的影子域。
EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject，保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準，以及人機互動審核能力。
SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密