Preventing address spoofing with DMARC, DKIM and SPF

If you are not using global email security standards SPF, DKIM and DMARC, you should be. They’ve been around for many years and used and trusted by millions of people. They can only help.

Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM) and Domain-Based Message Authentication, Reporting and Conformance (DMARC) allow you to prevent malicious third parties from spoofing your email domain to others who use it. They don’t work perfectly, but when enabled will absolutely cut down on some forms of email maliciousness.

For these protocols to work, the sender’s email domain administrator enables them in DNS using TXT records. (TXT records are a particular type of DNS record, like an A record is), or by enabling it in their email host provider’s administrative console. When enabled, receivers (actually their email servers or clients on their behalf) of emails from activated domains can check additional information to verify whether a particular email  came from the email domain from which it claims to be sent.

It’s a little confusing. Sending domains enable the protocols so that receivers can verify that emails are really from the sender’s domain. Senders enable these protocols so other people can’t claim to be them. Receivers enable them so they can verify whether a particular email is from where it says it’s from. Both sides must be enabled. Enabling them can’t hurt anything, unless you decide to take the draconian step of rejecting all emails that fail any of the checks. Hint: This will cause far too many false positives, so choose to quarantine instead.

SPF works by preventing spoofing of a legitimate email real return address (i.e., the email address that you would be sending a reply to) domain. This email address is known as the 5321 address, because it is defined in RFC 5321, which defines Simple Mail Transfer Protocol (SMTP). Depending on the email client, the 5321 address may not always be displayed. This is especially true of small form-factor email clients such as the ones you see on smartphones.

DKIM works by preventing the spoofing of the “Display From” email address (from RFC 5322, Internet Message Form email standard) domain. The Display From address is almost always shown to an end-user when they preview or open an email, hence its name. The figure below shows the difference between the 5321 and 5322 email addresses.

Roger Grimes

Although these addresses can differ in legitimate email, they are more likely to differ in malicious emails. I’ve always considered it to be much like the difference between what a URL link looks like in an email and what it really is when hovering a mouse cursor above it. Whenever I see two different things, I get a little wary. In most emails, the two URL versions should agree, and hovering over one should just verify that it matches the more obvious display name (which can be spoofed).

SPF and DKIM allow receivers of emails to ensure that the domains (and domains only) of a received email are really from the email servers of those claimed domains. However, they do it quite differently. DMARC is an additional standard that essentially tells others relying on your SPF and DKIM records how they should treat failing or spoofed emails.

Note: SPF and DKIM only verify the legitimacy of the sending and claimed domains (e.g., @example.com). The email address name portion before the email domain (e.g., roger@ or rogerg@) could still be spoofed by a malicious sender.

How to use SPF

Senders enable SPF for their domain by creating at least one DNS TXT record. When creating the SPF DNS TXT record, you need to have a few pieces of information handy, including which email server(s) do you want handling each defined domain and their public IP addresses.

Useful SPF configuration links include Rackspace’s instructions on creating an SPF TXT record;  Proofpoint’s SPF Check, which lets you find out which servers are authorized to send email on behalf of a domain; and SPF Wizard, which helps you craft the necessary DNS record based on your query answers.

If still in doubt, contact your ISP or email domain provider. They should be able to tell you what you need to include in the DNS TXT record. Here’s some simple SPF example TXT records:

com. IN TXT "v=spf1 -all"

com. IN TXT “v=spf1 a ip4:192.168.1.1 ~all”

Microsoft Office 365 users should refer to the Microsoft knowledgebase to enable SPF for their domain.

Here’s what a verified SPF email header looks like once it gets to an email client:

Roger Grimes

Here’s what a verified failed SPF header looks like once it gets to an email client:

Roger Grimes

Remember, with all these technologies, the end-user is not usually examining headers or determining whether to look at a particular email. This is all done in the background by the receiving email server/service, although understanding what the headers look like in pass and fail modes can help those of us who care enough to examine the headers when we see a suspicious email.

How to use DKIM

DKIM takes a bit more knowledge than SPF to set up. It requires a modification to that sender’s email server/servicei. The sender has to create/get a cryptographic public/private key pair, install it on their email server/service, and then create a DNS TXT record that contains their public key. Each outgoing email is signed by the email server’s private key and receivers can verify the digitally signed email by using the sender’s public key.

Here’s an example of a DKIM DNS TXT record (p is the public key of email server in Base64 format):

selector._domainkey.example.com IN TXT “v=DKIM1;p=RAG…123”

This is an example DKIM email header:

Roger Grimes

This is an example of a DKIM email header successfully verified:

Roger Grimes

How to use DMARC

DMARC is simply an aggregator service to determine whether the sender uses SPF and DKIM, and how the sender recommends receivers should treat failed/spoofed emails claiming to be from the sender’s domain. Like SPF and DKIM, it is set up in DNS as a TXT record by the sender.

A DMARC DNS TXT record might look similar to this:

TXT IN "v=DMARC1;p=quarantine;pct=100;rua=mailto:dmarccheck@example.com;"

One of the most important fields is the p value, which indicates how the sender wants receivers to treat failed emails. P can be one of three values:

• None – take no special treatment for failed emails
• Quarantine – treat as suspicious
• Reject – reject email at server before it gets to client

Be aware that legitimate emails fail one or more SPF, DKIM and DMARC checks routinely. This is often because someone configured something wrong, the email is incorrectly manipulated, or other reasons. Anyone choosing the “reject” value will probably be killed by management or their end-users because they did not get legitimate emails. Be safe and go with “quarantine” instead. Even then, many email services will just act as if “none” was specified.

Protocols are not perfect

SPF, DKIM DMARC are not perfect, for many reasons including these:

• Hacker could be sending a malicious email from within a compromised domain environment
• Hacker could be using a domain that enables and uses SPF and DKIM
• Many commercial email hosts do not respect your settings or all settings. Many times, it’s due to the way large email hosts work using many servers over many changing IP addresses to send email on behalf of your domain

Even with the flaws, enabling SPF, DKIM and DMARC can only help you. It will cut down on some portion of your fraudulently received spoof emails, and that is only good.

Just be sure to never completely reject any email that fails one or more verification tests. Legitimate emails fail these checks all the time. You want to set SPF, DKIM and DMARC so that they will let any failed email be inspected by a human defender (i.e., quarantined). If you find that SPF, DKIM or DMARC causes too many problems, you can always choose less aggressive settings, or if a complete failure, disable them altogether (although I’ve not seen anyone who has had to do this yet).

One more note. Office 365 users frequently complain that Microsoft does not respect all their email defense settings. Many 0ffice 365 admins set up an Exchange rule to block emails that spoof the receiver’s own domain.