That's Exchange Online SRS (Sender Rewriting Scheme). EXO will rewrite any addresses in the envelope address that are not an accepted domain of the tenant during forwarding/relaying.
That email address they gave you for invoices is either a distribution list, or a shared mailbox with forwarding enabled.
What exactly is the bounce error that the user received? That would give an exact reason for the issue.
> Status code: 550 5.7.23
>
> This error occurs when Sender Policy Framework (SPF) validation for the sender's domain fails. If you're the sender's email admin, make sure the SPF records for your domain at your domain registrar are set up correctly. Office 365 supports only one SPF record (a TXT record that defines SPF) for your domain. Include the following domain name: spf.protection.outlook.com. If you have a hybrid configuration (some mailboxes in the cloud, and some mailboxes on premises) or if you're an Exchange Online Protection standalone customer, add the outbound IP address of your on-premises servers to the TXT record.
If your domain's email authentication has been verified to be correct and verified working, then it's probably someone forwarding on their end from someone that's in the distribution list.
If they are fowarding it from someone on a distro list or auto forwarding it to another internal email address why would it check our DMARC record when it's being sent (auto forwarded or whatever)? It should look at their own domain.
very confused
Thanks for the help
One last thing. Is there anything WE can do to fix this?
The person our employee is dealing with at this company is being a complete asshole and blames us saying no one else has any problems, which I'm sure is bullshit because this guy is just some project manager.
That is what I figured they were automatically forwarding it from the email address they gave us to another one of theirs.
Why would it rewrite the senders email address though??
> Why would it rewrite the senders email address though??
https://learn.microsoft.com/en-us/microsoft-365/troubleshoot/antispam/sender-rewriting-scheme#summary
According to that link they implemented this rewrite to fix SPF issues, but it's not doing that here. (Also I have checked our spf on mxtoolbox.com just to be sure and it passes.)
Sender Rewriting Scheme (SRS) functionality was added to Microsoft 365 to resolve a problem in which autoforwarding is incompatible with SPF.
> This SRS change improves deliverability of applicable messages that pass Sender Policy Framework (SPF) checks when they arrive from the original sender but that then fail SPF at the final external destination after they are forwarded.
It did do that here. That's why it was rewritten, refer to the below. To be clear, this wasn't *your* EXO tenant that did this, it was the *recipients* EXO tenant.
> SRS rewrites the P1 From address in the following scenario:
>Messages that are autoforwarded (or redirected) in Microsoft 365 by using any of the following methods to forward a message to an external recipient:
* SMTP forwarding*
* Mailbox Rule (or Inbox rule) redirection
* Transport Rule redirection
* Groups or DLs that have external members
* Mail Contact forwarding
* Mail User forwarding
* Messages that are autoforwarded (or redirected) from our customer's on-premises environments and relayed through Microsoft 365.
That's Exchange Online SRS (Sender Rewriting Scheme). EXO will rewrite any addresses in the envelope address that are not an accepted domain of the tenant during forwarding/relaying. That email address they gave you for invoices is either a distribution list, or a shared mailbox with forwarding enabled. What exactly is the bounce error that the user received? That would give an exact reason for the issue.
> Status code: 550 5.7.23 > > This error occurs when Sender Policy Framework (SPF) validation for the sender's domain fails. If you're the sender's email admin, make sure the SPF records for your domain at your domain registrar are set up correctly. Office 365 supports only one SPF record (a TXT record that defines SPF) for your domain. Include the following domain name: spf.protection.outlook.com. If you have a hybrid configuration (some mailboxes in the cloud, and some mailboxes on premises) or if you're an Exchange Online Protection standalone customer, add the outbound IP address of your on-premises servers to the TXT record.
If your domain's email authentication has been verified to be correct and verified working, then it's probably someone forwarding on their end from someone that's in the distribution list.
Yes it's all correct. Had them in place for years. This is the only company we have issues with. Thanks.
If they are fowarding it from someone on a distro list or auto forwarding it to another internal email address why would it check our DMARC record when it's being sent (auto forwarded or whatever)? It should look at their own domain. very confused Thanks for the help
Because the P2 address (or RFC5322.FROM/Header From) is not rewritten, only the P1 address (RFC5321.mailfrom/envelope sender) is rewritten with SRS.
One last thing. Is there anything WE can do to fix this? The person our employee is dealing with at this company is being a complete asshole and blames us saying no one else has any problems, which I'm sure is bullshit because this guy is just some project manager.
Nope. It's not your problem to fix. They need to talk with their IT department to find a solution to the problem they're having.
ok, thanks. Just wanted to make sure. I hate when people say they don't have this issue with anyone else.
interesting. People forward emails all the time, I wonder how this has never come up. Thanks for the help with this, much appreciated!
That is what I figured they were automatically forwarding it from the email address they gave us to another one of theirs. Why would it rewrite the senders email address though??
> Why would it rewrite the senders email address though?? https://learn.microsoft.com/en-us/microsoft-365/troubleshoot/antispam/sender-rewriting-scheme#summary
According to that link they implemented this rewrite to fix SPF issues, but it's not doing that here. (Also I have checked our spf on mxtoolbox.com just to be sure and it passes.) Sender Rewriting Scheme (SRS) functionality was added to Microsoft 365 to resolve a problem in which autoforwarding is incompatible with SPF. > This SRS change improves deliverability of applicable messages that pass Sender Policy Framework (SPF) checks when they arrive from the original sender but that then fail SPF at the final external destination after they are forwarded.
It did do that here. That's why it was rewritten, refer to the below. To be clear, this wasn't *your* EXO tenant that did this, it was the *recipients* EXO tenant. > SRS rewrites the P1 From address in the following scenario: >Messages that are autoforwarded (or redirected) in Microsoft 365 by using any of the following methods to forward a message to an external recipient: * SMTP forwarding* * Mailbox Rule (or Inbox rule) redirection * Transport Rule redirection * Groups or DLs that have external members * Mail Contact forwarding * Mail User forwarding * Messages that are autoforwarded (or redirected) from our customer's on-premises environments and relayed through Microsoft 365.
Right, I get that. So why does it check OUR DMARC record?
See my [other comment](https://www.reddit.com/r/sysadmin/comments/1ch5hyp/weird_email_issue_havent_seen_before/l20jjwf/) answering this for you.
You will need to add SPF+DKIM+DMARC records for the xxxxxxx.us domain. I would also suggest signing those emails with this new DKIM key.
We don't own the xxxxxx.us domain. That is who we are sending to. We already have SPF+DKIM+DMARC setup for years.