Insights > Blog

Phishing Protection: SPF, DKIM, DMARC

There are ways to prevent spammers and phishers from spoofing your domain in the FROM: addresses of email they send: Sender Policy Framework (SPF), DomainKeys Identified Email (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). Optimally, all three should be used in concert for phishing protection. They are very easy to configure, and everyone should do so.

Phishing Protection-1.png

 

But here’s the thing: a recent report from phishing specialist Agari states that only 1/3 of the Fortune 500 have configured DMARC. Why is that? First, let’s explain what the three email anti-spoofing methods are.

Sender Policy Framework (SPF) 

SPF was first published as an experimental RFP in 2006 after about six years of discussion and debate.  It defines what email gateways (Mail Transport Agents, or MTA’s) are allowed to send email for a domain.  The definition for these resides in an external DNS, such as a Linux server running Berkeley Internet Name Daemon (BIND). BIND servers are configured with zone files that return either IP Addresses when queried with a server name (record types A or CNAME), Server Names when queried with an IP address (record type PTR), or in this case, information in the form of TXT records.

example.net. IN TXT “v=spf1 mx a:pluto.example.net include:aspmx.googlemail.com -all”

The DNS zone record above says that for email addresses from the example.net domain, MX (mail exchanges) that send email are named either pluto.example.net or aspmx.googlemail.com, with all other server names not authorized.  If an email with FROM address that includes example.net came from any other email gateway, it is not to be trusted – it could be spoofed. The receiving email gateway checks this by looking at the example.net’s SPF record in DNS. Many companies require SPF be configured for your domain in order for your email to be successfully delivered to them.

Interested in learning more about phishing protection? Download our latest whitepaper.

DomainKeys Identified Email (DKIM) 

DKIM dates back to 2004, a merger of Yahoo’s “enhanced DomainKeys” and Cisco’s “Identified Internet Email.” DKIM involves asymmetric public key cryptography, i.e., a generated public and private key.  The public key is included in a TXT record along with some other bits of information; the sending email gateway(s) are configured with the private key to include in headers of the email to be sent.  The keys are generated in a variety of ways, including free public sites.

Here’s an example of an email header containing DKIM information.  Based on this, the receiving gateway will check example.net’s DNS for the corresponding public key.

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=itverx.com.ve;    s=example; t=1342650894;    bh=pFo6ZYCLWFoBWmva8IlsxprN/QOinqGTGscl1MBI3sQ=; h=MIME-Version:Sender:In-Reply-To:References:Date:Message-ID:    Subject:From:To:Cc:Content-Type;    b=Fkcgti0ONF9w/F12LwqW1GQjecEZZgohQmQlkDENRQOdWJINF4DaowPc6LM5tAd5/    kM666teylglDIgJnF2ThGEUrnkmavZvPsHuecWc/ZEYl+3NT7/gb46568UWPjXqbFo    zQDzLozzqw+GABj+pXlC2fDBscesx++q5fBw5dPA=

Below is an example of a DNS TXT record for DKIM.

example._domainkey.itverx.com.ve.86400 IN TXT “v=DKIM1\; g=*\; k=rsa\; p=MIGfM
A0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDqFGebZAOHfSGy9CWtA4Uads0zaXAy8TWtW9uIFbyIkFNC67fQVFVjsxlmcEg1oFNp2CrTYF1YNh2gB144c+XY5GVM2fGEYAKx3iBxajWTzsx3SvpQtAZ2Bvf2mV+Te+JtlbpxVuiuiW2Alqwhk1ytTWspf/S3bM73XssV+/mh9wIDAQAB”

Domain-Based Message Authentication (DMARC) 

Domain-based Message Authentication, Reporting and Conformance and builds on SPF and DKIM.  DMARC contains instructions on what actions receiving gateways should take if a message fails the spoofing check. Like the others, it’s configured as a TXT record in DNS.

_dmarc.example.net IN TXT “v=DMARC1;p=none;sp=quarantine;pct=100;

rua=mailto:[email protected]

That states the version as DMARC1, no policy (both SPF and DKIM are to be checked), the recommended action is to quarantine (or send to spam folders), that 100% of emails from example.net are to be subjected to the check, and reports should be sent to [email protected].

And, here’s also the thing: only 7% of companies using DMARC have it configured for “quarantine” or “reject.” They use if for reporting purposes only, negating its value as an anti-spoofing mechanism.  That’s too bad, because in all three of these examples, they rely upon broad community/global adoption to realize any tangible benefit for those that deploy them. Configuring SPF, DKIM, and DMARC doesn’t prevent your receipt of spam and phishing, it prevents spammers and attackers from spoofing your email domain in sending spam and phishing to others. It’s part of being a good citizen. Lack of immediate tangible benefit for the effort could be a big reason why adoption is low. Maybe default rejection of email from domains that don’t use all three methods would be motivation to conform, but that’s very unlikely to happen.

For added phishing protection, there are hardened email gateways and providers that have superb anti-spam capabilities – if you get a lot of spam, look into them, or contact CIPHER. And of course, conduct regular Phishing Training campaigns and track your results over time.

Dave Rickard is the Technical Director for CIPHER US.

Did you enjoy this blog article? Comment below with your feedback.

0 Comments

Submit a Comment

Your email address will not be published.

GET EMAIL UPDATES

Information Security Maturity Self-Assessment Survey

Learn More

•  Whitepapers
•  E-books
•  Checklists
•  Self-Assessments
•  Webcasts
•  Infographics