Page 23 - Cyber Defense eMagazine - October 2017

To implement SPF in the simplest way, domain administrators must create a DNS TXT record in
their domain that specifies which IP addresses or hostnames are allowed to send mail for that
domain. An example SPF record for the domain “example.com” might be “v=spf1 ip4:11.0.0.1
A:mail.example.com” which means the IP address 11.0.0.1 and the server located at
mail.example.com are allowed to send email for the domain.

When a recipient mail server with SPF record validation enabled receives a message, it uses a
DNS query to check the SPF records for the sender’s domain. If an SPF record is found, the
mail server will compare the allowed source addresses with the address of the actual server
which sent the email. The admin in charge of the recipient mail server is given control over what
to do when a message fails SPF checking. They can configure the mail server to drop the email
entirely, or they can configure it to tag the message as possibly spam, but accept it anyway.

A major drawback of SPF is that it only cares about the envelope MAIL FROM header, it doesn’t
check the message FROM header contained in the email itself. Because email clients typically
use the message FROM header to display the sender of an email, an attacker can still spoof
this header while providing valid address for the envelope header.

DKIM

Another technology available to combat spoofing is DomainKeys Identified Mail (DKIM). DKIM is
the combination of Enhanced DomainKeys from Yahoo and Identified Internet Mail from Cisco.
In a nutshell, DKIM uses cryptographic digital signatures to authenticate email messages,
allowing recipient mail servers to verify the authenticity of the message sender and even the
message contents. DKIM is similar to SPF in that it uses DNS TXT records to house important
information, in this case RSA public keys for digital signature verification.

DKIM works by first naming a few important parts of the message to protect, usually including
the FROM and TO headers, the subject header, the date header, and even the message body
itself. The sending mail server then computes a cryptographic hash of the chosen sections and
then encrypts it using a private key, creating a digital signature. The digital signature and a few
informational fields are added back to the message as a special DKIM-Signature message
header before he message is sent. Because the corresponding public key is published in a DNS
TXT record for the sending domain, recipient mail servers can decrypt the hash and verify it,
confirming the protected fields were not spoofed or modified in message transit.

DKIM unfortunately has its own limitations. While header fields protected by a DKIM signature
can be confirmed as valid, a message without any DKIM signature at all causes problems. The
DKIM standard does not provide a mechanism to confirm if a message should have a DKIM
header when no header is present. This means, without other protections in place, an attacker
can simple omit a DKIM header from their phishing email to bypass DKIM protections.

DMARC

Back in 2011, a group of organizations including AOL, Comcast, Google, and Yahoo, among
others, came together to create an even more comprehensive technology standard to address
email spoofing called Domain-based Message Authentication, Reporting and Conformance or

23 Cyber Defense eMagazine – October 2017 Edition
Copyright © Cyber Defense Magazine, All rights reserved worldwide.