Forum Discussion
Do we not meet High Volume Sender authentication requirements?
For a customer, we developed some custom sofware that, as a part of it functionality, generates notification mails to their clients. This worked ok for some years, however nowadays these mails are rejected by recipients who have hotmail.com or outlook.com email addresses. The bounce information suggests that this is because the customer are regarded by Outlook as High Volume Senders. We can understand this as there may be a few thousands of their clients who have a hotmail.com or outlook.com email address, each receiving several messages yearly (in a range of at least 1 up to about 10 messages yearly).
Now my question is: it seems to me that we do meet all criteria as published at https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com, however the emails are still being rejected.
Is there anyone who can help us to verify if we do (or do not) meet these criteria? And / or check if this is really the reason for this issue, or do we need to look in a different direction to solve this situation?
As far as we know, this issue is only present with hotmail.com or outlook.com email addresses.
PS Maybe I posted this question in the wrong discussion category. If so, please help me to find the right place. I'm new with the Microsoft Community and the list of categories to select from was a bit overwhelming to me...
1 Reply
The annual number of notifications per recipient is not enough to establish whether the sending domain falls under Microsoft's high-volume requirements. First obtain the exact NDR: the documented 550 5.7.515 error specifically identifies insufficient sender-domain authentication. If that is the code, verify actual messages from your production sending service, not only the existence of DNS records. Microsoft requires SPF and DKIM to pass, a published DMARC policy, and DMARC alignment through at least one of SPF or DKIM with the visible From domain. A third-party sender can publish valid records yet send using an unexpected envelope or signing domain. Capture the sending IP, envelope sender, visible From and DKIM signing domain, together with authentication results from a delivered test. Share sanitized headers and the complete bounce text. If the error code differs, investigate that code rather than assuming this policy explains every rejection.
