有了適用的政策和完整的評估， SPF 和 DKIM 都可以透過 DMARC 在以下情況下失敗 RFC 9989 §5.3.5。當這些機制驗證的網域與人們在寄件者地址中看到的網域不一致時，就會發生這種情況。
每種機制都回答不同的問題。 SPF檢查連線來源是否授權用於評估的信封身分。 DKIM驗證與簽章網域關聯的簽章。然後， DMARC檢查傳遞的身份是否與可見的寄件者域具有所需的關係。診斷這個問題的方法是比較這些身份，而不是計算綠色通行證標籤。
從收到的訊息中收集身份
從接收系統取得原始訊息，包括其可信賴的身份驗證結果。不受信任的發送者可以提供任意標頭「通過」；確定生成證據的接收邊界 RFC 8601 §7.1.
記錄這些欄位：
- 證據：從領域可見；它所建立的內容：作者域，即可見寄件者地址中的網域
- 證據： SPF結果與評估 郵件來自 身分;它所建立的內容：連接來源是否已獲得該信封身分的授權
- 證據：每個DKIM結果及其 d= 域；它建立了什麼：驗證了哪個域的簽名
- 證據：適用的aspf和adkim模式；它所建立的內容：是否需要精確或寬鬆的領域關係
- 證據：可信的DMARC結果和診斷背景；它建立了什麼：接收者觀察到的評估
在下面 RFC 5321 §4.4，對於普通訊息，傳遞的 Return-Path 可以幫助識別信封回郵身份。將其與受信任的SPF結果和路由證據相關聯，而不是假設顯示字段講述了整個SMTP故事。
工作範例：兩次通過，沒有對齊的身份
這是一個綜合說明，假設適用的有效策略和已完成的檢查，而不是捕獲的客戶訊息：
- 欄位：來自；觀察值： accounts@example.com
- 領域： SPF ；觀察值：傳遞給bounce.example.net
- 領域： DKIM ；觀察值：透過d=example.org
- 領域： DMARC 結盟;觀察值：傳遞的域均不與example.com一致
這兩種機制都成功地完成了自己的工作。兩者都沒有建立所需的關係 example.com，因此它們不為該可見的 From 域提供DMARC傳遞路徑。
支援的修復可能會配置客戶網域 DKIM簽名。另一種可能性是受支援的自訂信封域，它產生通過的對齊SPF路徑。哪個選項可用取決於實際發送的產品和路線。
不要發明DNS值。從服務獲取支援的配置，以正確的所有者名稱發布它，啟用相關的發送功能並透過相同的應用程式工作流程發送新的測試。
正確應用嚴格對齊和寬鬆對齊
透過嚴格對齊，相關域必須完全匹配 RFC 9989 §3.2.10.2，對於任一機制。相關的DKIM和SPF標識符在 RFC 9989 §4.4.1 和 RFC 9989 §4.4.2， 分別。透過寬鬆的協調， DMARC在以下方面使用適用的組織域關係和發現規則： RFC 9989 §4.10.2.
對於一個簡單的說明案例，傳遞信封身分位於 bounce.example.com 可以與 From 域對齊 example.com 在寬鬆的SPF排列下。它不滿足嚴格的SPF對齊，因為兩個名稱不同。
不要將組織域發現概括為始終採用最後兩個標籤的規則。域邊界和目前DMARC發現規則很重要。檢查更複雜的域結構的實際策略和實作。
當存在多個DKIM簽章時，請檢查所有相關簽章。一個未對齊的傳遞簽名不會使單獨的對齊的傳遞簽名無效。相反，失敗簽章中存在您的網域不會建立通過路徑。
在發送服務中尋找支援的身份設置
這通常出現在團隊開始使用 CRM、計費工具或活動服務之後。供應商表示已啟用身份驗證，但一些收件人拒絕這些訊息。如果平台驗證自己的域名，而企業顯示您的域名，則這兩種說法都可能成立。
請操作員顯示受影響的郵件並解釋可見的寄件者、信封寄件者和簽名網域。有用的解決方案表明實際的業務工作流程透過受支援的一致身分進行發送。顯示兩個綠色勾號的螢幕截圖是不夠的。
讓應用程式所有者參與其中。正確的解決方案可能是該服務中的設定或特定於計劃的功能，而不是員工郵件平台的變更。
透過原來的路線測試修正
透過受影響的服務發送受控替換訊息。將其寄件者域、信封身分和每個相關的DKIM簽章與先前的範例進行比較。將可信任接收器結果和設定變更放在一起。
如果簡單的直接測試通過，但業務路由仍然失敗，請檢查轉送、網關和訊息修改。他們可以更改保留的身份驗證路徑。還要區分DMARC通行證和收件匣放置；接收器可以應用額外的過濾 RFC 9989 §5.4.
使用 Microsoft 365指南 或者 Google Workspace指南 這些系統是實際的發送者。如果訊息使用其他應用程序，請調查該應用程式自己的路由。使用 總結報告 在觀察到的流量中尋找相同的模式。
確定失敗告訴你什麼
對準失敗會產生技術結果。它本身並不能確定該訊息是否合法、未經授權的服務、轉發傷亡或冒充嘗試。
在批准新信任之前，需要提供寄件者的所有者和商業目的。共享基礎設施和可識別的提供者名稱是有用的線索，但它們並不能證明您的組織已授權該帳戶或工作流程。
記錄可接受的修復範圍。一致的簽名身分可以滿足DMARC ，而帳戶隨後會受到威脅或應用程式會產生不安全的內容。繼續進行帳戶控制、應用程式驗證和敏感交易的獨立批准。
實用的外賣
當受影響的工作流程產生具有可信任傳遞對齊結果的新訊息時，請關閉問題。將身份比較和配置變更放在一起。這既解釋了原始訊息失敗的原因，也解釋了修正有效的原因。
明確下一步的決定
對於兩次通過的裝置，記錄「沒有對齊的通過路徑」而不是「 SPF損壞」。選擇要修復的服務支援的身份，並將變更保留為掛起狀態，直到新的相同工作流程訊息得到驗證。如果策略發現或DNS處理不完整，請勿強制將觀察結果標記為通過/失敗標籤； RFC 9989 §5.3.6 單獨處理所需的DNS錯誤。未執行客戶配置或交付測試。