Email Spoofing and Security

      

An electronic mail is the most common communication mode on the internet today.
Around 70 percent of the transactions, marketing and alerts system consume emails as the medium.
Emails can be easily spoofed if authentication protocols are not implemented and can impact your domain's reputation. The deliverability of your emails is an important criterion in-order to increase the traffic inflow to your websites and hence affect the conversion.

When an email is sent, the receiving mail-server authenticates an email first.

We will talk about  the three email authentication protocols:

1. SPF- Sender Policy Framework

2. DKIM- DomainKeys Identified Mail

3. DMARC- Domain-based Message Authentication, Reporting, and Conformance

Before we begin with, we will discuss various types of DNS records published on the DNS servers of a domain:
1. A record - It specifies what IP address to point to when a user clicks on a link or enters the URL in the browser. It provides with an IPv4 address.
2. AAA record - It is similar to an A type record but renders an IPv6 address.
3. MX record - It is used to specify what MX(email receivers) cater to replies to an email address.
For eq. request to nitinmuteja@abc.com should be routed to an MX server with an IP x.x.x.x.
4. CNAME record - It is used to point a subdomain or a secondary domain to A type or AAAA type records. For eg., if we have an A type record for nitinmuteja.com pointing to x.x.x.x and we purchase another domain mutejanitin.com. We can enter a CNAME record for the second website so that any migration of servers would affect both at the same time.
5. TXT record- A TXT record is used for storing text-based information and can be used to grab a variety of information. The most common uses are for storing SPF records or DKIM records for authorization purpose of email senders.

To know how a DNS works visit
https://www.verisign.com/en_US/website-presence/online/how-dns-works/index.xhtml

SPF- Sender Policy Framework

The intention of this email protocol is to publish a list of sender IPs or domain servers which are authorized to send an email for a particular domain. For eq. a mail server with IP x.x.x.x is allowed to send an email for all XYZ domain accounts. The messages received from any other servers will be marked as spam or will be rejected. This depends on the policies at the receiving end.

For eg.

v=spf1 a mx ip4:52.40.61.88 include:servers.mcsv.net ~all

"v=" defines the version of SPF used.The "a" defines: Match if sender IP has a DNS 'A' record in the sending domain.The "MX" defines: Match if sender IP is one of the MX hosts for given domain name.The "ip4" and "include" defines the other legit senders by the ipv4 address and the domain name for the sending domain.The "-all" at the end specifies that, if the previous mechanisms did not match, the message should be rejected.

  

DKIM- DomainKeys Identified Mail

This protocol was intended to overcome the limitations of the SPF protocol. SPF defines what will be the sender email's address, but it does not define if the rest of the contents delivered to the user are intact. DKIM overcomes this limitation and signs an email with a digital signature using its private key. The public key is published on the DNS in the form of a TXT record. An example of a DKIM signature in the email is 

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
     c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938;
     h=from:to:subject:date:keywords:keywords;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR

This header notifies the receiver to verify the TXT record brisbane._domainkey in the DNS of the sender example.net. A sample DKIM record in the DNS looks like this

v=DKIM1; k=rsa; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMLv2pmxrY4bwMGl+UCa60/LbbuvVKya7h4bvhKdQZHzXSvRUwziNt2GIc2av9ZaC64a2OYGyopZjQOpTDATEyZDKICbZ9zuQfFbZ1tM5KYdhvZiU1XUl61SdakcwyWMSKkqjLT2aVKWp+WXOnUO90xFPyB9Hyt9wO2HdxpcoRdQIDAQAB



where  k=rsa is the key exchange algorithm and h=sha256 is the hashing algorithm and
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMLv2pmxrY4bwMGl+UCa60/LbbuvVKya7h4bvhKdQZHzXSvRUwziNt2GIc2av9ZaC64a2OYGyopZjQOpTDATEyZDKICbZ9zuQfFbZ1tM5KYdhvZiU1XUl61SdakcwyWMSKkqjLT2aVKWp+WXOnUO90xFPyB9Hyt9wO2HdxpcoRdQIDAQAB
defines the public key to be used by the receivers to verify the authenticity of the email.

DMARC- Domain-based Message Authentication, Reporting, and Conformance

Although SPF and DKIM can identify whether an email is from the legit sender or not, the implementations don't seem to limit the spoofing of messages as the implementation is dependent entirely on the receiving side. Hence Paypal pioneered an approach in 2007 after discussions with ISPs like google and yahoo and is known as DMARC. It is implemented over SPF and DKIM as the base protocols and gives the entire control to the legit sender. A sender can publish a DMARC record on its DNS servers, stating the action to be followed by the receivers, in case of illegitimate emails having failed the SPF or DKIM validation. The record specifies whether to reject the emails or to quarantine them. It also specifies the aggregate report to be shared on a particular address for such illegal attempts.

For eg. 

v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;

This is an example of a DMARC record published by AOL.com stating

"p" policy=reject for "pct" percentage of forged emails=100 and share "rua" aggregate report to "d@rua.agari.com" and "ruf" forgery report to "d@ruf.agari.com".