識別域發送的每種方式
Simply.com 可以託管郵箱、網站和DNS ，但這些角色並不能使使用該網域的每個應用程式都遵循相同的郵件路徑。從路由清單開始：網路郵件、設定的郵件用戶端、網站聯絡表單、訂單通知和任何外部服務。請注意應用程式在哪裡運作、它提交到哪個伺服器以及業務期望的可見發送者。
本指南涵蓋 Simply.com 公共郵件文件中指定的路由。它不會將提供者的簽名承諾擴展到不相關的新聞通訊平台、其他地方託管的伺服器或使用其他傳輸的腳本。現有帳戶也需要檢查；新託管計劃的記錄預設值並不能證明舊的或外部管理的區域具有相同的記錄。
查看記錄的記錄而不覆蓋區域
Simply.com 的身份驗證指南 列出了 SPF 授權include:spf.simply.com和兩個 DKIM CNAME：simplycom1。 _domainkey為dkim1.simply.com和 simplecom2。 _domainkey到dkim2.simply.com 。其SPF範例假設郵件僅透過 Simply.com 發送。它將連接埠 587 上的 webmail、 websmtp.simply.com和smtp.simply.com命名為簽章路由。
將這些視為記錄的公共值，而不是您網域中觀察到的記錄。在進行授權更改之前匯出目前區域。識別權威DNS提供者並確認其介面期望的所有者格式。如果它自動附加網域，請防止後綴重複。將發布的結果與所需的完全限定名稱進行比較，而不是依賴表單的視覺外觀。
對於SPF ，在更改策略之前清點其他合法服務。 RFC 7208 描述單一策略選擇規則和 DNS查找限制。查看組合評估，包括嵌套包含，而不是僅計算頂層可見的術語。保留現有的服務權限，除非其所有者已確認停用。
讓網站郵件使用預期的傳輸方式
這 腳本郵件指南 描述了在連接埠 587 上向websmtp.simply.com進行身份驗證的提交，其中 STARTTLS 支援 Simply.com 網路伺服器上的腳本。它將該路由與 PHP mail() 區分開來，並限制該服務用作一般用戶端或外部託管中繼。它還警告不要將其視為大容量散裝平台。
檢查正在運行的應用程式實際上做了什麼。郵件插件可以安裝但被停用、被另一個外掛程式覆蓋或被特定表單繞過。記錄應用、有效的運輸和負責的維護人員。成功的密碼重設通知不一定會驗證透過不同程式庫傳送的商務擴充。
使用組織核准的憑證管理流程進行任何後續配置。請勿將密碼放入工作表、 DNS 、螢幕截圖或支援範例中。此草案不會登入、安裝外掛程式、更改應用程式設定或傳輸憑證。
將託管DMARC策略作為單獨的決策進行審查
Simply.com 記錄了預設的_dmarc CNAME 造訪dmarc.simply.com並將拒絕描述為其標準策略。在決定組織是否應該保留提供者管理的策略或管理自己的策略之前，請檢查目前所有者及其有效答案。外部託管區域可能有所不同，現有的自訂策略可能包括報告或 結盟 設定業務需求。
不要添加 TXT記錄 位於同一所有者的現有CNAME旁邊。如果核准的變更取代了別名，請記錄舊答案、預期的新策略、報告目的地和復原流程。在將報告傳輸到新目的地之前，請確認報告收件人和任何所需的授權。這是網域策略工作，而不是檢查兩個簽章記錄的必然副作用。
DKIM透過簽章網域來驗證責任，而不是單一人類作者的身分或權限。提供者的解釋有時會將政策和交付壓縮為簡單的承諾。使用 RFC 9989 對於協定解釋：對齊很重要，接收器處理並不能保證每個合法訊息都到達收件匣或每個 網路釣魚 訊息消失。將身份驗證接受和收件人放置作為單獨的措施。
驗證兩個選擇器和活動簽名
一個提供者可以發布多個 選擇器 出於營運原因。確認兩個記錄的 CNAME 按預期存在，而不假設特定訊息必須使用哪一個。從受控接收的訊息中，捕獲每個DKIM簽章域和選擇器。 RFC 6376 定義這些欄位如何識別驗證金鑰。
如果簽章失敗，則將DNS解析、意外簽章身分和訊息修改分開。如果沒有出現預期的簽名，請在更換金鑰之前調查提交路徑。使用非預期傳輸的表單不會因為網域具有有效的 CNAME 而成為記錄的簽章路徑。
捕獲 信封寄件人 以及。經過審查的 Simply.com 來源並未建立通用的使用者可設定自訂 Return-Path 特徵。不要從郵箱地址或回覆目的地推斷。記錄觀察到的身份和提供對齊的機制。
將轉發的訊息保留在不同的測試組中
Simply.com 的 轉發指南 警告外部轉送可能不可靠，因為轉送路徑可能會影響SPF或DKIM 。因此，轉送的訊息不能用作原始出站路由的唯一測試。
首先測試從網路郵件和應用程式路徑的直接傳遞。如果轉發是業務需求，請將其新增為單獨的行，其中包含原始接收者觀察結果和最終接收者觀察結果。調查相關簽名是否存在以及最終接收者評估的身份。不要僅僅因為稍後的轉發更改了發送伺服器而擴大原始寄件者的SPF權限。
使用路線覆蓋範圍工作表
Simply.com 信箱和網站工作表（使用此處所述的欄位建立單獨的審核記錄）包括每個傳輸的一行、有效的DNS策略、目前簽章選擇器和最終接收器結果。使用DNS證據保留受控的訊息標識符和觀察時間。為每個應用程式記錄單獨的結果，而不是在一個樣本後寫「網站郵件已通過」。
當業務所有者識別寄件者和回覆行為時，路由已準備好接受批准，郵件管理員可以識別一致的傳遞機制，並且恢復所有者可以解釋如何反轉特定變更。未觀察到的字段仍待處理。
涉及聯絡表的虛構診斷案例
僅虛構的書面案例：SCOM-01 規定網路郵件來自help@repair.example ，並傳遞d=repair.example.聯絡表單具有相同的 From，但運行 PHP mail()，而不是記錄的經過身份驗證的腳本提交路徑；其DKIM和SPF結果未知。應用程式維護者必須檢查有效傳輸，提出支援的修正並單獨測試表單。訂單通知仍然是第三個未經測試的途徑。未存取任何應用程式設定、憑證、 DNS或訊息。
恢復並維護特定路線的證據
在推出之前，保留先前的DNS和應用程式設定並同意誰可以恢復它們。如果更改後的表單遺失了郵件，請暫停該應用程式更改，而不是削弱每個寄件者的網域策略。當現有訊息或另一個已配置的路由可能仍在使用選擇器時，請避免刪除該選擇器。
在託管行動裝置、郵件外掛程式變更、 SMTP變更、新的外部寄件者和 DMARC 原則變更後重新測試。這是一份未出版的紀錄片草稿。帳戶檢查、即時DNS 、收到的訊息證據、原始範圍驗收、目視審查和 SME 人工簽核仍然懸而未決。
將傳遞的訊息與執行準備分開
RFC 9989 第 7.4 節要求發布p=reject網域具有有效的DKIM ，並警告間接郵件互通性。單一對齊的SPF結果本身並不能證明拒絕策略的推出是合理的。與此提供者設定分開審查所有合法路由和策略所有權。