Header Envelope Fields And Tracking

[Justin814]

In short, when and where does Exchange add the Envelope From fields in the mail flow?  Can I use EMS to find emails missing the Envelope From field or if the field is null / empty?  In other words, can I track the Envelope From field to pinpoint when emails are sent without the Envelope From field?

We are working to clean up our sender authentication focusing on what we can fix quickly here internally.  However, the DMARC reports are not clear enough to explain why we are failing SPF. Even using a DMARC subscription tool.

We have our Exchange server (on prem) which sends to an encryption gateway (on prem and DKIM signer) and that sends to a security gateway (cloud).  The DMARC reports show Domain1 and Domain2 as our and we see the DKIM signature, thus proving it is coming from our internal email server. 

What I do not understand is how ~10% of the time Domain3 changes to our security gateway which uses the allowed IP netblock that we include in our SPF record, but it fails SPF.  Looking into the SPF records of that sending domain (Domain3), there are no existing SPF records which may explain the failing.  One DMARC report includes enough information that shows when Domain3 is the security gateway, the "envelope_from" field is empty.  When the "envelope_from" field contains our address, Domain3 maintains our domain and it passes SPF.

To reiterate, when in the mail flow does Exchange add the Envelope From field?  Can that be tracked?  What addresses would not add / include the envelope from field, e.g. distribution groups, shared mailboxes, or unauthenticated senders?  Any information on this would be grateful, even if it is argumentative as that would lead me to a better direction hopefully.

I am trying "New-TransportRule -Name "Find Empty Envelope From" -HeaderContainsMessageHeader "envelope" -HeaderContainsWords "envelope","envelope from","envelope_from" -ExceptIfRecipientDomainIs "workdomain.com" -BlindCopyTo my work address" to just track any email that may contain envelope to or from field to get more specific later.  Zero hits in a few hours of having it in place.

Justin

[#2]

Not sure if I am asking this on the proper site, but I learned a little more about what we are seeing from the DMARC reports. I would like to thank outlook[.]com for the details they include.

We had dozens of messages sent to domains being hosted on outlook[.]com, which had Domain3 reflecting our security gateway and the "scope" reporting as HELO. Many of these domains, we have not sent an email for at least a month. Fortunately, I did find a couple that we sent emails to and one domain an email was sent on the same day as this DMARC report.

So, this DMARC report had three entries for this recipient domain, two HELO's and one that seems to match the actual email sent. Now, it seems to me that our Exchange Server is, at some interval, sending HELO connections to domains that we emailed in the past, even if it is beyond 30-days. Since these are not regular email messages or connections with an Envelope From, the sending domain or Domain3 is changed to the last server in the connection.

This theory should be tested. So, my new question is how can I find, track, and/or discover these HELO connections? I reviewed Event Viewer to no avail. I cannot find a suitable Exchange Management Shell cmdlet to do this.

Does anyone have a suggestion to locate and review these HELO connections?  Thanks in advance.

Justin

[#3]

Alright. I have not figure out how to review or track HELO/EHLO message within Exchange 2019. Nor was I able to connect the failed SPF verification HELO checks to ones that occurred in Exchange. However, I believe my interpretation of the DMARC aggregate reports does in fact show our HELO connections are failing SPF. We started to forward Syslog events from out email gateway to our SIEM and can confirm this for a handful of mailing domains.

We adjusted our HELO DNS A records and PTR records. We also created a macro SPF lookup specifically for the HELO connections. I will continue to track our DMARC results in hopes that the above with fix our SPF failures.

Justin