1

As I'm reading DMARC aggregate reports, I've come across a few records that have <auth_results><spf><domain> values that don't match the envelope from, header from, or source IP reverse DNS. My understanding was that SPF checks for an SPF record at the domain of the envelope MAIL FROM? Why are these other domains showing up in that field, and where are they from?

I've also noticed that most reports don't specify an envelope from in the indicators. Why? It seems to be required by the schema in the RFC:

<xs:complexType name="IdentifierType">
     <xs:all>
       <!-- The envelope recipient domain. -->
       <xs:element name="envelope_to" type="xs:string"
                   minOccurs="0"/>
       <!-- The RFC5321.MailFrom domain. -->
       <xs:element name="envelope_from" type="xs:string"
                   minOccurs="1"/>
       <!-- The RFC5322.From domain. -->
       <xs:element name="header_from" type="xs:string"
                   minOccurs="1"/>
     </xs:all>
   </xs:complexType>

1 Answer 1

1

Why are these other domains showing up in that field, and where are they from?

Within the <auth_results> section of the DMARC report all authentication results are listed, no matter if they get used to compute the DMARC result or not. From the DMARC FAQ: I need to implement aggregate reports, what do they look like?:

Please note that the SPF and DKIM results in the auth_results are raw results, regardless of Identifier Alignment; the results of the DMARC evaluation with Identifier Alignment are in the policy_evaluated section.

As for the envelope_from:

I've also noticed that most reports don't specify an envelope from in the indicators. Why? It seems to be required by the schema in the RFC ...

These reports do conform to an older draft only, like draft-dmarc-base-00 rev.02 from 2012. There is no envelope_from in this version yet. It was only added later in draft-kucherawy-dmarc-base-00 in 2013. I do not know why the reporting tools did not get updated but even Google is sending such older reports.

Even the example shown in the official DMARC Wiki uses the older report format although it acknowledges that the example "may be out of date by this time". Given that even the official examples on how to write a DMARC report are out of date one probably cannot expect from the vendors to be better than this.

6
  • Why are these other domains showing up in that field, and where are they from? Commented Jun 16, 2021 at 23:50
  • @AdamWinter: The domain given for the SPF part can be the domain from the envelope from (MAIL FROM SMTP command) or in case of an empty envelope from the domain given in HELO/EHLO command. Commented Jun 17, 2021 at 4:51
  • So if the envelope from is empty, then auth_results->spf->domain will be the EHLO value? I don't see how this explains why that value comes up as the receiving domain. I've had a few situations where the auth_results->spf->domain value seems to be the domain the mail was being sent TO not from. It's a known friendly domain. So, probably not fraud. Seems to be when someone violates SPF by using their Gmail client to send a company email to a recipient that also uses Gmail. That is, it's going from a Google server to a Google server. Commented Jun 17, 2021 at 16:06
  • @AdamWinter: The sender could put anything as domain in EHLO/HELO the same as they can put anything into MAIL FROM. This includes "friendly" domains. One simply cannot trust what is given there. As for discussing a specific example it would probably better to ask a new question with all the details of the example. Commented Jun 17, 2021 at 16:14
  • Certainly, the sender could put anything there, but in this case it's Google. So, I would expect it to be consistent, if not thought out. Commented Jun 17, 2021 at 16:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .