How to update or change the complaint address for JMRP FBLs in SNDS?

Key findings

• Editing restrictions: SNDS does not provide a direct option to edit or manage existing JMRP FBL complaint addresses once they are configured.
• New feed failures: Even when attempting to add a new feed with the same IP addresses, it often gets automatically removed by the system, preventing the update of the complaint address.
• Support challenges: Contacting Microsoft support for JMRP issues can involve navigating multiple redirects, with the designated msn-snds@microsoft.com email address often being unresponsive for extended periods.
• Ownership confusion: Users report that the system may incorrectly perceive them as not being the original owner of a feed, hindering management capabilities, especially in environments with fragmented user access.

Key considerations

• Persistent communication: Given the unresponsiveness, senders may need to repeatedly contact the msn-snds@microsoft.com address and consider current global circumstances that might affect response times.
• Alternative forwarding: If immediate access to complaints is critical, consider setting up email forwarding from the old complaint address to the new one while waiting for Microsoft to process the official change. This is essential for effective feedback loop management.
• System limitations: It is widely believed that there is no direct update function for JMRP feeds. The expected process involves deleting and recreating the feed, although this pathway also faces reported issues.
• SNDS data access: Ensuring continuous access to SNDS and JMRP data is paramount for maintaining good sender reputation. Consider reviewing Microsoft's official deliverability guide for any updated information.

Key opinions

• Lack of control: Marketers feel a distinct lack of control over managing their FBL complaint destinations within SNDS, hindering their ability to adapt to organizational changes.
• Invisible deletions: The automatic removal of newly added feeds (even when correctly configured) is a major concern, as it prevents effective updates and creates uncertainty.
• Support black hole: The unresponsiveness of Microsoft's specific JMRP/SNDS support email (msn-snds@microsoft.com) is a common point of frustration, leaving issues unresolved.
• Operational impact: The inability to easily update FBL addresses directly impacts the efficiency of complaint processing and the overall health of their sending reputation, potentially leading to increased spam classifications or email deliverability issues.

Key considerations

• Escalation paths: Explore any potential alternative escalation paths within Microsoft, even if initial contacts are unresponsive. Document all attempts.
• Temporary forwarding: Establish temporary forwarding rules from the old complaint email address to the new one. This ensures continuous monitoring of feedback, which is crucial for identifying spam traps and managing complaints effectively.
• Account consolidation: If multiple users have fragmented access to SNDS data, consider consolidating access or defining a single, clear owner for JMRP feeds to avoid system confusion.
• Proactive monitoring: Regularly monitor your domain reputation and inbox placement using other tools, as JMRP FBLs are just one component of overall deliverability. Additionally, reviewing general email deliverability guides on feedback loops might offer broader context.

Key opinions

• Functionality gap: Experts confirm that the direct functionality to update an existing JMRP feed (specifically its complaint address) does not exist within SNDS.
• Recreation necessity: The common workaround involves attempting to break and recreate the feed, though this process is not always successful or stable.
• Support persistence: Given the potential for slow responses, experts advise senders to be persistent in their outreach to msn-snds@microsoft.com, considering current staffing or global situations.
• Proactive solutions: It's recommended to explore temporary forwarding solutions for complaint data while waiting for Microsoft to implement official changes, ensuring no feedback is lost.

Key considerations

• Documentation preparation: When contacting Microsoft support, provide comprehensive details about your SNDS account, IP ranges, and the specific issue with changing the complaint address. This can help expedite the process.
• SNDS account management: Ensure your SNDS account has the appropriate user permissions and that the logged-in user is recognized as the primary owner for feed management.
• Postmaster resources: Refer to official Microsoft Postmaster documentation and community forums for any recent updates or known workarounds regarding SNDS functionality. Keeping up to date with outlook's new sender requirements is essential.
• Feedback loop importance: Recognize that JMRP FBLs are a critical component of sender reputation. Timely processing of complaints helps prevent IP blocklistings and ensures optimal inbox placement, which is key to improving deliverability rates.

Key findings

• Purpose focus: Documentation primarily explains that SNDS provides senders with data on IP reputation and complaint rates to assist in deliverability improvement.
• Setup guidance: Guidelines are typically robust for initial registration and adding new IP ranges, emphasizing strict ownership verification for feedback loops.
• Update ambiguity: There is a notable lack of explicit, straightforward documentation detailing how to modify or transfer existing JMRP FBL complaint addresses.
• Feedback loop integrity: Broader RFCs and industry best practices highlight the importance of actively managed and accessible complaint destination addresses for effective spam mitigation.

Key considerations

• Beyond the portal: Since direct portal updates are limited, documentation often implicitly directs users towards email-based support channels for complex changes, even if these channels are slow.
• Data accuracy: Documentation emphasizes that accurate FBL data is essential for identifying compromised accounts or problematic sending patterns, reinforcing the need to keep complaint addresses current.
• Authentication standards: While not directly about JMRP address changes, documentation on email authentication (like DMARC, SPF, and DKIM) often underscores the necessity of managing all aspects of sender identity, including feedback loops, to avoid IP blocklisting.
• System design: The focus on initial setup and security suggests that Microsoft's SNDS infrastructure may prioritize stability and fraud prevention over dynamic administrative flexibility for FBLs, especially regarding existing configurations.