Reply-To’ Header Being Stripped in Office 365 Emails
Hi everyone, we are experiencing an issue where the “Reply-To” header in emails sent to our Exchanged hosted email account is being stripped. This behaviour started on the 7th of August, seemingly for reasons we haven’t been able to isolate.
Our current set up is that we have one primary email address that we receive all of our customer enquiries, orders, and emails through for 15+ websites. This email address is hosted through Exchange and we have set up SMTP. Our website is a WordPress based website, and we use WP Mail SMTP to connect our Exchange account to this plugin. Then, we filter this email account through MailGuard so that we mitigate 99% of the spam sent to that address.
Originally, we thought the problem was to do with this plugin, so we rolled back a version of the plugin and the issue was still not rectified. We also reached out to MailGuard asking them if they would strip Reply-To headers before they sent the email(s) back to us, and their reply from support was:
“We will add details into the headers of an email, but that will be in regards to recording the Hops of the email, whether it has passed SPF/DKIM/DMARC checks and specific logging regarding tour processing of the email.
That all being said, MailGuard’s systems do not remove content from emails.
If the emails do not have a reply-to in them, that is how they are when we have received them.”
As mentioned, we have 15+ other websites, but only 2 of them run through an OAuth connection with Exchange through the WP Mail SMTP plugin. The other websites, use Brevo (SendInBlue) as their SMTP provider.
Thinking it was a plugin issue, we tested the enquiries being sent from those websites to our email address, to see if they were also getting their Reply-To headers stripped, however, none of them were having this issue. We use the free SMTP service through Brevo for these smaller sites, and would exceed their limit if we switched our main sites to Brevo in the meantime.
We believe we have isolated the issue down to Exchange/Office365, but admittedly, are finding it a bit of a challenge given the intricate settings and options available throughout the account.
Below is a screenshot of two enquiries sent through to our email address, but 24 hours apart. The left indicates the the Reply-To header is present as normal, but the right image, indicates a missing Reply-To header.
To add a note, it is interesting saying that the emails were not signed. We definitely have DMARC/DKIM DNS records present so I’m unsure why they would be being delivered as unsigned.
We have not changed any SMTP settings, any policy settings, mail rules or anything similar in our Exchange account. It seemingly appears to be an issue that randomly appeared overnight.
Has anyone experienced similar issues with “Reply-To” headers being stripped in Office 365? Could there be specific settings or policies in Exchange Online or Azure that might affect this behaviour? Any advice or troubleshooting tips would be greatly appreciated.
Thank you in advance for your help.
Hi everyone, we are experiencing an issue where the “Reply-To” header in emails sent to our Exchanged hosted email account is being stripped. This behaviour started on the 7th of August, seemingly for reasons we haven’t been able to isolate. Our current set up is that we have one primary email address that we receive all of our customer enquiries, orders, and emails through for 15+ websites. This email address is hosted through Exchange and we have set up SMTP. Our website is a WordPress based website, and we use WP Mail SMTP to connect our Exchange account to this plugin. Then, we filter this email account through MailGuard so that we mitigate 99% of the spam sent to that address. Originally, we thought the problem was to do with this plugin, so we rolled back a version of the plugin and the issue was still not rectified. We also reached out to MailGuard asking them if they would strip Reply-To headers before they sent the email(s) back to us, and their reply from support was: “We will add details into the headers of an email, but that will be in regards to recording the Hops of the email, whether it has passed SPF/DKIM/DMARC checks and specific logging regarding tour processing of the email. That all being said, MailGuard’s systems do not remove content from emails. If the emails do not have a reply-to in them, that is how they are when we have received them.” As mentioned, we have 15+ other websites, but only 2 of them run through an OAuth connection with Exchange through the WP Mail SMTP plugin. The other websites, use Brevo (SendInBlue) as their SMTP provider. Thinking it was a plugin issue, we tested the enquiries being sent from those websites to our email address, to see if they were also getting their Reply-To headers stripped, however, none of them were having this issue. We use the free SMTP service through Brevo for these smaller sites, and would exceed their limit if we switched our main sites to Brevo in the meantime. We believe we have isolated the issue down to Exchange/Office365, but admittedly, are finding it a bit of a challenge given the intricate settings and options available throughout the account. Below is a screenshot of two enquiries sent through to our email address, but 24 hours apart. The left indicates the the Reply-To header is present as normal, but the right image, indicates a missing Reply-To header. To add a note, it is interesting saying that the emails were not signed. We definitely have DMARC/DKIM DNS records present so I’m unsure why they would be being delivered as unsigned. We have not changed any SMTP settings, any policy settings, mail rules or anything similar in our Exchange account. It seemingly appears to be an issue that randomly appeared overnight. Has anyone experienced similar issues with “Reply-To” headers being stripped in Office 365? Could there be specific settings or policies in Exchange Online or Azure that might affect this behaviour? Any advice or troubleshooting tips would be greatly appreciated. Thank you in advance for your help. Read More