網域別名改變了在服務中使用或接收位址的方式。它本身並不定義放置在出站中的域 DKIM簽名。在對客戶郵件使用別名之前，請檢查透過預期路由發送的訊息並確定服務簽署的身份。
別名也是一個重載的乘積術語。它可以描述備用郵箱位址、附加到租用戶的網域或應用程式層級寄件者身分。此工作流程適用於產生的訊息和DNS證據。在假設特定別名功能支援傳送或自訂網域之前，請查閱目前文件以了解特定別名功能 DKIM.
將接收配置與發送身分分開
首先確定別名的用途。將郵件接收到現有郵箱的地址可能永遠不會被授權用於出站使用。如果支援發送，請確定服務是否保留寄件者中的別名、將其重寫為主地址或透過其他寄件者路由它。
發送後記錄可見的寄件者地址，而不僅僅是在撰寫視窗中選擇的地址。也要記錄任何寄件者欄位和信封身份，但不要將它們與DKIM的 sd 網域混淆。 RFC 6376 §3.5 定義簽章域，與訊息作者的位址不同。 RFC 9989 §4.4 使用作者網域和經過身份驗證的標識符 結盟.
讀取受控訊息上的每個簽名
使用與生產相同的用戶端、API 或委派郵箱路由從別名發送測試。匯出收到的訊息而不對其進行編輯。識別每個DKIM-Signature 、其 d 和 s 值以及可信任接收者的結果。服務可以新增提供者簽章和客戶網域簽章；工具顯示的第一個可能與以下內容無關 DMARC.
對於每個通過的簽名，評估與收到的 From 域的一致性。嚴格模式需要精確的域匹配 RFC 9989 §3.2.10。放鬆模式允許相同的 組織域 在下面 RFC 9989 §4.10.2。兩個不同的註冊網域並不對齊，只因為一個網域是另一個網域在管理入口網站中的別名。
使用小型身分工作表
說明性案例，假設不同的組織域和適用的DMARC策略：主位址是person@company.example ，而傳出別名是person@newbrand.example 。接收者會在newbrand.example看到 From 以及帶有d=company.example.該簽名與newbrand.example不一致。如果另一個傳遞的簽章使用d=newbrand.example,則第二個簽章提供對齊的DKIM路徑。
記錄這兩個結果，而不是稱整個訊息未簽署或說DKIM已損壞。主域下的有效簽章仍然有效DKIM 。缺少的屬性是別名的對齊方式。評價 SPF 在分配總體DMARC結果之前單獨進行。此工作表是一個綜合示例，並非任何服務別名行為的證據。
請求支援的補救措施
詢問提供者是否可以使用別名網域簽署別名郵件，以及是否需要將網域新增為獨特的發送身分。取得其目前的DNS記錄名稱、記錄類型和值。驗證誰控制DNS區域以及提議的變更是否與現有的衝突 選擇器.
不要手動複製主域公鑰並假設服務將使用新的 d 值開始。 DNS發布不能指示任意簽署者更改身分。發送配置和發布的驗證資料必須一致。
在生命週期審核中保留別名
使用這些路由時，請對回覆、行動用戶端和應用程式產生的訊息重複測試。保留一份選擇者到提供者的映射，其中包含別名的企業所有者和註明日期的範例。遷移或停用時，請在刪除委託記錄之前確認其他身分是否仍依賴相同提供者。
閉包語句應該說明測試了哪個別名和路由、通過了哪個 d 域以及是否對齊。如果產品無法提供所需的身份，請記錄該限制並選擇受支援的發送設計，而不是將別名報告為未經限定的身份驗證。
記錄下一個決定
每個實際路由使用一行：請求的別名、接收的來源、每個 d/s 對、可信任結果、對齊模式和剩餘間隙。具有不相關別名 From 的主域通行證是有效的DKIM ，但未對齊DKIM 。在評估SPF和適用的策略之前，請勿將整個郵件稱為DMARC失敗。此處未斷言特定於提供者的別名功能或即時結果。