How Does Email Work, Anyway? Part 2: Spam and Scams

How Does Email Work, Anyway? Part 2: Spam and Scams:from B2B Marketing and Lead Generation | Optify by Nathan Harkenrider

In my first post on this topic, "How Does Email Work, Anyway?", I described some of history and technology infrastructure underpinning modern-day email. As most marketers have learned, possibly the hard way, sending an email is one thing, ensuring it is delivered is another. In this post, I’ll explain SPF and DKIM, two measures used to prevent unsolicited email (spam), and help ensure legitimate email is delivered.

Sender Policy Framework (SPF)

One common tactic used by spammers is email spoofing. Spoofing involves modifying the sender address or other portions of an email header to make an email appear to originate from a different source. This is used by spammers to hide their identities and increase the difficulty of tracing an email back to its origin. It is also frequently used in phishing attempts, where a spammer will try to collect private information from users via email that appears to be from a bank or other trusted organization.
The Simple Mail Transfer Protocol (SMTP, the standard for email transmission), does not require authentication, which makes spoofing relatively straightforward. To combat this problem, Sender Policy Framework (SPF) was created to verify the IP address of email senders. SPF requires that email senders create a SPF record in the Domain Name System (DNS) that identifies senders who are sanctioned to send email from a particular domain.
Here’s a quick example of a SPF check in the headers of an email sent to my Gmail address from Starbucks. You’ll notice the sending server (mta864.e.starbucks.com) is identified along with its IP address (63.236.31.232).
Received: from mta864.e.starbucks.com (mta864.e.starbucks.com. [63.236.31.232])
by mx.google.com with ESMTP id gc3si1831302qeb.4.2013.04.10.17.18.44;
Wed, 10 Apr 2013 17:18:45 -0700 (PDT)
Received-SPF: pass (google.com: domain of bo-b7xmfu6a9wf27sau0meqmckgftuy24@b.e.starbucks.com designates 63.236.31.232 as permitted sender) client-ip=63.236.31.232;
The last line "Recieved-SPF:" indicates that Google determined that the IP address (63.235.31.232) is a permitted sender for the domain e.starbucks.com. So how did Google know? Starbucks’ domain administrators have added a SPF record to DNS identifying servers that are allowed to send mail as e.starbucks.com. The SPF record is as follows:

"spf2.0/pra ip4:63.236.31.232/31 ip4:8.30.201.110/31 ip4:207.251.96.0/24 ip4:65.125.54.0/24 ip4:66.165.100.120/29 ip4:208.49.63." "128/28 ip4:63.211.90.16/29 ip4:8.7.42.16/29 ip4:8.7.43.16/29 ip4:63.232.236.144/29 ip4:8.7.44.144/29 ip4:66.165.105.144/29 ip4:" "63.236.31.128/26 ip4:63.236.76.0/23 ip4:8.30.201.0/26 -all"

If you look carefully, you’ll notice that the IP address that sent the original email 63.236.31.232 is listed as one of the permitted senders. So here’s a counterexample. Since SMTP does not require authentication, I can easily send myself an email spoofing Starbucks CEO Howard Schultz from a server that is not associated with Starbucks. In this case the SPF check failed.

Received-SPF: softfail (google.com: domain of transitioning howard@starbucks.com does not designate XX.XXX.XXX.XXX as permitted sender) client-ip=XX.XXX.XXX.XXX;
Authentication-Results: mx.google.com;
spf=softfail (google.com: domain of transitioning howard@starbucks.com does not designate XX.XXX.XXX.XXX as permitted sender) smtp.mail=howard@starbucks.com

A failed SPF check will not necessarily guarantee that an email is blocked or ends up in a recipient’s spam folder but it is one factor used to gauge the legitimacy of an email.

Domain Keys Identified Email (DKIM)

Another method used to associate a domain name with an email message is DomainKeys Identified Mail (DKIM). This technique allows a sender to use public key encryption to digitally “sign” an email, claiming responsibility for its content. Returning to my example email from Starbucks, I’ve provided the DKIM signature contained in that email’s header. The signature is a series of “tag=value” pairs. Breaking this down, some of the key tags are: d, the signing domain, bh, a cryptographic hash generated from the email body, and s a selector that is used to look up the sender’s public key.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e.starbucks.com;
s=20111006; t=1365639524; x=1381450724;
bh=X3k5d+rId8PVZz5h0+cm7Vfy96fOcyG03EaszJ2FrrE=; h=From:Reply-To;
b=hJi6ssm1hwn84S+UmZetSjQEVwPugUyh8gOqPd4hum245GZHPwMgvAdRnmJ4P5ZTA
2Xc1anF6O/KANmDkZHxJU1Ft9c1j220nW790i1CAzDnoInyNQebrjqiGND9KUAK1MB
FvKo5Svu//8Uh1tQgLHPG0ETwYFhzN0umH+PmeSY=

So how does this all work? Like SPF, the sender’s public DKIM key is published as a TXT record in the Domain Name System (DNS). When an email is sent, the DKIM signature is generated based on the body and often the from name and from address. The receiving server can then use the signing domain and selector to look up the sender’s public key. In the example above, the key can be retrieved by looking up the text record for 20111006._domainkey.e.starbucks.com, leveraging the values we received in the DKIM signature. This public key can then be used to regenerate and compare the cryptographic hashes. If the hashes match, this indicates that the email was actually signed by the sending domain and was not tampered with in transit.
While this post has been quite technical, I hope it has helped highlight some of the difficulties and challenges with email deliverability.