Why did this email fail Domain-based Message Authentication, Reporting and Conformance (DMARC)?

When you send an email, machines are looking at it, and reporting back information. When culling through data it's often to just search for the word "fail"... which is what I did on the header information from the Wikileaks-Podesta-probablynotScalia email.

In the authentication-Results section you can see "dmarc=fail". Why did that happen?

Authentication-Results

mx.google.com; spf=pass (google.com: domain of podesta@law.georgetown.edu designates 157.56.111.54 as permitted sender) smtp.mailfrom=podesta@law.georgetown.edu; dmarc=fail (p=NONE dis=NONE) header.from=outlook.com

Up until today I didn't know DMARC existed, but here's a page that explains it:

https://blog.returnpath.com/how-to-explain-dmarc-in-plain-english/

And here's the actual site for the organization that governs DMARC, which, if I'm lucky, I'll get to study when I feel better (not feeling good today - head cold, but better than this weekend):

https://dmarc.org/

First off, what is DMARC? According to our link,

"DMARC ensures that legitimate email is properly authenticating against established DKIM and SPF standards, and that fraudulent activity appearing to come from domains under the organization’s control (active sending domains, non-sending domains, and defensively registered domains) is blocked. Two key values of DMARC are domain alignment and reporting."

And how does it work?

"DMARC’s alignment feature prevents spoofing of the “header from” address by:

1. Matching the “header from” domain name with the “envelope from” domain name used during an SPF check, and
2. Matching the “header from” domain name with the “d= domain name” in the DKIM signature."

Well, that's good. Even I know what spoofing is - it's when somebody sends an email in the name of somebody else. I'm glad somebody's checking emails to see if that happens!

So why would an email fail DMARC?

Back to our link:

"To pass DMARC, a message must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. A message will fail DMARC if the message fails both (1) SPF or SPF alignment and (2) DKIM or DKIM alignment."

Man, don't you love tech talk? That's, like, the easiest thing in the world to understand, right?

Instead of getting bogged down, let me just show you a couple things. 

1) Our message appears to have passed SPF testing at at least one of its hops:

Received-SPF

pass (google.com: domain of podesta@law.georgetown.edu designates 157.56.111.54 as permitted sender) client-ip=157.56.111.54;

and you can see spf=pass in the Authentication rhttps://db-ip.com/141.161.191.75esults above

but then it fails at another hop:

Authentication-Results: spf=fail (sender IP is 141.161.191.75)

Why did it fail?

Received-SPF: Fail (protection.outlook.com: domain of law.georgetown.edu does

 not designate 141.161.191.75 as permitted sender)

It appears that some sort of security device had blacklisted the 141.161.191.75 IP - hence it's not a "permitted sender".

So where is that server (141.161.191.75)?

According to https://db-ip.com/all/141.161.191 that IP belongs to Ch2m Hill

and where does that specific IP live? Washington, D.C.

https://db-ip.com/141.161.191.75

Looking at Google Earth, the coordinates put you in the middle of a park that's surrounded by hotels and embassies Google Earth for that IP address:

Tired yet? Buckle up, because that only gets us halfway to failing the DMARC test. In order to fail DMARC, something had to be wrong with DKIM as well. So what was the problem with DKIM? Actually, what the heck is DKIM? 

According to DKIM.org

"DomainKeys Identified Mail (DKIM) lets an organization take responsibility for a message that is in transit.  The organization is a handler of the message, either as its originator or as an intermediary. Their reputation is the basis for evaluating whether to trust the message for further handling, such as delivery. Technically DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication."

Riiiiigth. Translation? It's like a secret handshake. If you don't know it, you fail. And that's what appears to have happened with this particular email. Somebody asked for the secret handshake, and the email didn't know it - bummer. 

In the header information DKIM shows up twice, and in both cases it says:

dkim=none (message not signed)

So apparently no organization was willing to take responsibility for this message in transit, either as its originator or as an intermediary. Does this mean that the From: field was spoofed? Answer:

I don't know, and neither do you (unless you're an expert in this stuff, which if you are, please feel free to correct the record)

What's important at the moment is that the data is there waiting to be interpreted by an expert, so I'm pretty sure the answer to this question is knowable.

I'll keep researching and update this post if I learn more.

Conclusion: This email failed DMARC testing. In order to fail that test there had to be an issue with

1) SPF, which there was. Looks like the domain of law.georgetown.edu didn't like the IP of 141.161.191.75... 

(On a side note, this error shows up over and over in the Wikileaks emails, so this isn't unique to this email. Just Google "domain of law.georgetown.edu does not designate 141.161.191.75 as permitted sender" to see what I mean... there's tons of emails that say the same thing.)

AND

2) DKIM, which there was, due to the message not being signed

See how easy that was? :)