I think y'all have overlooked one small detail that was mentioned in the dramatization above, that is actually really easy to check:

Spoof emails do not come from an email address that legitimately belongs to the domain from which they claim to originate. Part of the SMTP protocol includes a set of full message headers that always includes the return path of the message, which is the email address that actually sent the message. Not only that, but IP addresses also have a definitive geographical region they're assigned to. So you can catch these discrepancies with a bit of digging.

Take, for example, said dramatization.

It mentions that the email is coming from whitehouse.gov. Here's its IP address:

calyodelphi@dragonpad:~ $ dig +short whitehouse.gov 173.223.0.110

Now, let's say that nastyhackerz.cn resolves to an IP address somewhere in the block 1.0.32.0-1.0.63.255 (for reference: http://www.nirsoft.net/countryip/cn.html first block in the list). That IP address is going to be in the full message headers. All you gotta do is take that IP online to track down its geolocation (you can use http://www.geoiptool.com/ for example)

The IP for whitehouse.gov (173.223.0.110) at the time of writing this post geolocates to Boston, Massachusetts (for some reason a spam prevention system won't let me post my search on geoiptool due to reputation points, so you can go do the search yourself) which is pretty close to home (District of Columbia)! Let's just assume that whitehouse.gov is hosted in a data center that's in Boston just to make this easier to explain.

As long as the IP and email address that the email was actually sent from does not match the IP and email address that the email claims to be sent from, it can be determined as spoof. You just need to look in the full message headers.

Let's look at the headers of an email I sent from one of my own domains (dragon-architect.com) to my own personal email address:

Delivered-To: dragon.architect@gmail.com Received: by 10.180.89.68 with SMTP id bm4csp105911wib; Tue, 29 Jan 2013 08:54:47 -0800 (PST) X-Received: by 10.60.30.38 with SMTP id p6mr1296792oeh.2.1359478487251; Tue, 29 Jan 2013 08:54:47 -0800 (PST) Return-Path: <calyodelphi@dragon-architect.com> Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35]) by mx.google.com with ESMTP id m7si14056914oee.29.2013.01.29.08.54.45; Tue, 29 Jan 2013 08:54:46 -0800 (PST) Received-SPF: neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of calyodelphi@dragon-architect.com) client-ip=69.93.154.35; Authentication-Results: mx.google.com; spf=neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of calyodelphi@dragon-architect.com) smtp.mail=calyodelphi@dragon-architect.com Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 0530E1DFDB334; Tue, 29 Jan 2013 10:54:43 -0600 (CST) Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) by gateway14.websitewelcome.com (Postfix) with ESMTP id EA7191DFDB314 for <dragon.architect@gmail.com>; Tue, 29 Jan 2013 10:54:42 -0600 (CST) Received: from [127.0.0.1] (port=43458 helo=dragon-architect.com) by bentley.websitewelcome.com with esmtpa (Exim 4.80) (envelope-from <calyodelphi@dragon-architect.com>) id 1U0ESK-0001KE-DP for dragon.architect@gmail.com; Tue, 29 Jan 2013 10:54:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 29 Jan 2013 10:54:44 -0600 From: calyodelphi@dragon-architect.com To: <dragon.architect@gmail.com> Subject: Headers Test Message-ID: <11c694cd1e07c66a404000008321d0c4@dragon-architect.com> X-Sender: calyodelphi@dragon-architect.com User-Agent: Roundcube Webmail/0.8.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bentley.websitewelcome.com X-AntiAbuse: Original Domain - gmail.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dragon-architect.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dragon-architect.com) [127.0.0.1]:43458 X-Source-Auth: calyodelphi@dragon-architect.com X-Email-Count: 1 X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20= Testing testing!

That's a lot of random data to sift through, but there are two lines that we are looking at here: return-path and from. Since I legitimately sent this email to myself, they both match. The return-path cannot be spoofed. Or if it can, it's incredibly difficult to effectively spoof and requires some deliberate configuration of the SMTP daemon used to send mail. Comparing the return-path and the from data fields in the full headers is one way that I and my coworkers where I work can identify spoof and determine if a support ticket needs to be submitted.

So, what if they both match, but the email should still be spoof? I'll get to that in the next section...

Now, as mentioned before, there are other means of determining the spoofiness of an email. SPF records are one of those ways, but they're not always perfect. Take, for example, the SPF of whitehouse.gov, and compare it to the SPF of my own domain:

calyodelphi@dragonpad:~ $ dig +short txt whitehouse.gov "v=spf1 +mx ~all" calyodelphi@dragonpad:~ $ dig +short txt dragon-architect.com "v=spf1 +a +mx +ip4:70.84.243.130 ?all"

Usually, a good SPF record also includes the IP address of the server that sent the mail, so whoever made the SPF record for whitehouse.gov probably doesn't know this. I would consider whitehouse.gov's SPF record to be too generic to be effective at determining the actual origins of any messages claiming to be from whitehouse.gov. The SPF for my own domain, on the other hand, which was automatically generated by the server that hosts my domain (courtesy of my webhost), is very specific and includes the IP address of the server itself.

I will admit to not being intimately familiar with how SPF records are formatted and how they work, but I've learned enough on my job that I can at least identify generic and specific SPF records. Guess that's something I should probably dig into some weekend when I'm bored and want some technical reading material!

Anyways, back on track here. Look at the Received lines. One of them states thus: Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Guess what? That matches the IP address in my domain's SPF record.

If the IP in the SPF doesn't match the IP of the server that actually sent the email, that's another indication that you've got spoof on your hands. Therefore, a generic SPF record like "v=spf1 +mx ~all" just isn't going to cut the security mustard. I wouldn't even trust emails coming from a legitimate domain that has a generic SPF like this.

Perhaps we should file a petition on petitions.whitehouse.gov to demand that their security admins revisit the SPF record they made for the domain! (I kid, I kid.)

EDIT

I actually have to MASSIVELY correct myself about SPF records! I made some wrong assumptions and learned a few things today after asking a coworker who was more in-the-know than I am about SPF records. So, I'll use the two SPFs for whitehouse.gov and dragon-architect.com in my self-correction:

calyodelphi@dragonpad:~ $ dig +short txt whitehouse.gov "v=spf1 +mx ~all" calyodelphi@dragonpad:~ $ dig +short txt dragon-architect.com "v=spf1 +a +mx +ip4:70.84.243.130 ?all"

The SPF for my own domain is actually more lenient than the SPF for whitehouse.gov (something I plan to correct tonight after I finish this edit). I'll explain why:

"v=spf1 +mx ~all" basically says that emails from whitehouse.gov are supposed to come from the hostnames defined in the MX records for whitehouse.gov, and any emails that do not come from those hostnames are supposed to be spoof, but whether they're marked spoof or not is up to the recipient of the email.

calyodelphi@dragonpad:~ $ dig +short mx whitehouse.gov 110 mail6.eop.gov. 105 mail2.eop.gov. 110 mail5.eop.gov. 105 mail1.eop.gov. 105 mail4.eop.gov. 105 mail3.eop.gov.

"v=spf1 +a +mx +ip4:70.84.243.130 ?all" says that emails from dragon-architect.com are supposed to come from either the IP address for dragon-architect.com (67.18.28.78), the hostnames defined in the MX record(s) for dragon-architect.com, or the IP address of the server that hosts dragon-architect.com (70.84.243.130). Any emails that do not come from those, well, that ?all at the end just means that there's no advice on whether to pass or reject the emails.

So what's the meat and potatoes of an SPF record? The "all" at the very end. To quote this coworker about the "all":

+all basically means ALL pass -- the record is useless, sender domain doesn't care ?all indicates neutral and is advising to not pass or reject mail ~all indicates fail, and the server is considered invalid, but does not specifically suggest an action. -all is a hard fail, anything else is invalid, reject or flag it.

So that "all" is where you define just how strict your SPF record is. But whether or not the SPF record is actually used to determine the spoofiness of an email is completely up to the receiving email service.

So there you have it. SPF in a nutshell.

So yeah. TL;DR: check your full headers to see if the return-path and from fields match. Then double-check your SPF records if there are any to see if you get matching IP addresses.