The DAG is using an internal addressing scheme and is not using the 169 address. We've already tried lowering the priority of the cluster adapter binding order per Henrik's article
here but still aren't having luck fixing.

NOTICE: My posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

Toutes les réponses

The step you have shown in the header is very early in the process - it is the initial MAPI transfer and therefore shouldn't be the cause of the email being rejected. It isn't seen by the clients until after connection. How did you come to the conclusion
that was the cause of the problem?

What server is generating the NDR? If it is your server then that is not the cause of the problem because the server that is rejecting it hasn't even seen the headers.

Thanks for the speedy response. Some organizations reject our messages because of the 169 in the header. So the workaround for now is to include the 169 address in our SPF record. But since that's not ideal, we're looking for a fix.
Here's an example of what we're targeting:

NOTICE: My posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.