How to prevent email spoofing

Fake emails sent to your customer base at worst compromise their security and at best lead to a bad reputation for you. Whether it's a phishing attempt or a malicious download, SPF and DKIM are two techniques you can employ to prevent others from abusing your email sender addresses.

The problem with email

Email is one of the oldest communication protocols on the Internet. It originated in a time when the authors of this technology saw no need to verify the identity of the sender, as it was based on mutual trust.

By the time email became available for the general public and caught on as an important communication channel, the issue of identity spoofing became pretty obvious.

Unfortunately, because the success of email lies in its simplicity, it also is very difficult to repair. It would take a total rewrite of the email protocols and standards, which would be incompatible with existing email software and infrastructure.

Although the best way to verify identity (as well as added privacy benefits) would be to use some form of encryption and digital signatures, this would also need every end-user to join in the effort, something that doesn't sound very realistic.

So, instead of trying to convert the software at the level of the end-user, some technologies have been invented that tackle the problem at the level of the intermediaries: email services and internet service providers.

Email sender address

An email message conceptually consists of 2 parts: the envelope and the content. The envelope contains information about the origin and routing of the message and is mostly of concern for the intermediate servers that make sure the message arrives in the user's inbox.

The envelope has one important piece of information, the envelope sender address. It is this address that we want to protect from being used by just anyone.

Sender Policy Framework

In order to limit the origin of messages coming from this email address, we need to find a way to map the email sender domain to a specific set of servers. Since every email domain has its own DNS records, we can assume that whoever controls these records, is authorized to configure the sender domain.

This standard technology is called Sender Policy Framework, or SPF. It is configured by a special entry in the DNS, called a TXT record, which contains information about which servers are allowed to send email from this domain.

Whenever a mail service receives a message from a sender in a domain, it will check the SPF record for that domain to see if the sending IP address is allowed to send email on behalf of this sender domain.

An example of such a record is

example.com TXT "v=spf1 a mx include:spf.mailservice.org ~all"

Let's analyze what this means:

• the a means that any IP address which is listed for the server name example.com is allowed
• the mx means that any IP address that is designated as one of the destination mail servers for example.com is also allowed to send mail
• the include:mailservice.org means that any IP address that matches the SPF record for spf.mailservice.org is also allowed to send mail for example.com. This way, it is easy for organisations to use the SPF records of any mail service they use, like Microsoft Outlook or Gmail without the need to keep track of the exact IP addresses.
• the final ~all means that any message that comes from an IP address that doesn't match any of the criteria will fail the policy and should be marked as such.

Other possible types that can be used are ip4:x.x.x.x and ip6:xxxx:xxx:xxx:xxx but these are only useful if the domain has its own mail servers, which is hardly the case nowadays, except for email services themselves.

Sender Authentication

Now, while SPF prevents unauthorized IP addresses, it doesn't guarantee the actual sender is valid. It also won't survive any forwarding of emails, as this will most likely not comply with the SPF records.

For this, the DomainKeys Identified Mail, or DKIM, was invented. DKIM basically adds a signature to your email envelope that can be verified by the receiving party. This is done by signing with a private key which can then be cryptographically verified by a corresponding public key, which is published in a special DNS record:

email._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfCSqaodjVvZ0ohz...."

The message envelope contains a header referring to the email key and a signature. The receiving party looks up the corresponding public key (shown above) and verifies the signature.

You can check this yourself by viewing the message headers, for example in Gmail there is an action menu on a message:

The mail headers will contain something like

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=email;
        h=mime-version:date:reply-to:feedback-id:message-id:subject:from:to;
        bh=Arfes+E1HZN1hUGqTLgA+4fakE0NNQEPDypo;
        b=dk7in9QoemqGpxLydTe803nYY8oJ7cDAtiw48Yj

Which is verifiable by the public key belonging to s=email, i.e., the value of the email._domainkey.example.com record.

Usually, nowadays, these keys are maintained by your email service provider. In that case, multiple entries will need to be created that allow for key rotation and revocation, for example:

xxx._domainkey.example.com  CNAME    xxx.dkim.mailservice.org
yyy._domainkey.example.com  CNAME    yyy.dkim.mailservice.org
zzz._domainkey.example.com  CNAME    zzz.dkim.mailservice.org

This way, the mail service provider will take care of key management and your records don't need to be changed anymore over time. The receiving party will then simply look up the corresponding keys at mailservice.org.

DMARC

So now you have your SPF sender verification and DKIM sender authentication set up, you need to tell the receiving end what to do with non-compliant messages. This is done via Domain-based Message Authentication Reporting and Conformance, or DMARC.

DMARC has 3 policies

• none, i.e., just monitor your email traffic
• quarantine, i.e., put unauthorized emails in the Spam / Junk Mail folder
• reject, i.e., make sure unauthorized email is not delivered at all

The policy and other fine-tuning is published, again, in a specific DMARC record in DNS:

_dmarc.example.com  TXT "v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com;"

This entry tells receiving mail services what to do with email that does not comply to either SPF or DKIM. In the example above, it tells receiving mail servers to quarantine messages from non-compliant senders, i.e., put the message in the Spam or Junk Mail folder. It also tells services to send reports on DMARC to postmaster@example.com, so the sending organisation is able to analyse any violations of SPF or DKIM policies.

Caveats

The information above is, of course, pretty technical and configuring DNS entries is not for the faint of heart. Incorrect settings can prevent email from being delivered or, the other way around, from a message being regarded as valid even if it isn't.

Some common mistakes and things to look for:

Multiple TXT records

There can only be a single TXT record for SPF per domain. Multiple records will need to be merged into one record, so for example:

example.com TXT "v=spf1 a mx include:spf.mailservice.org ~all"
example.com TXT "v=spf1 a mx include:spf.mailprovider.com ~all"

will need to be merged into a single record:

example.com TXT "v=spf1 a mx include:spf.mailservice.org include:spf.mailprovider.com ~all"

Relative vs. fully qualified record values

Be careful in what your DNS provider expects you to put into values that refer to another record entry, such as CNAME records.

Let's say you want the following situation:

xxx._domainkey.example.com CNAME   xxx.dkim.mailservice.org

If the interface of the DNS provider expects the value to be a fully qualified name, you would enter xxx.dkim.mailservice.org. If, however, the interface just expects a relative name in the domain, if you would enter xxx.dkim.mailservice.org in this situation, you would end up with a record like this:

xxx._domainkey.example.com CNAME   xxx.dkim.mailservice.org.example.com

In those cases, the interface probably expects you to end the full name with a ., so you would enter xxx.dkim.mailservice.org.

Please take care in verifying if what you're entering is already expected to be relative to your domain.

Command line check

There are a number of online tools, for example MToolbox, to check your records. However, in some cases it might come in handy to check your records from your local machine, as if you were performing the DNS lookups that a mail server would do.

There are 2 tools commonly used, nslookup for Windows. Look up your SPF record:

C:\>nslookup -type txt example.com 

example.com	text = "v=spf1 a mx include:spf.mailservice.org ~all"

Look up your DKIM key for the email selector:

C:\>nslookup -type txt email._domainkey.example.com

email._domainkey.example.com text = "v=DKIM1; k=rsa; p=MIGfCSqaodjVvZ0ohz...."

Look up the value of a mail service-managed DKIM key:

C:\>nslookup xxx._domainkey.example.com

xxx._domainkey.example.com canonical name = xxx.dkim.mailservice.org

and dig for MacOS/Linux

Look up your SPF record:

MacBook:~ me$ dig txt example.com

example.com.		86400	IN	TXT	"v=spf1 a mx include:spf.mailservice.org ~all"

Look up your DKIM key for the email selector:

MacBook:~ me$ dig email._domainkey.example.com

email._domainkey.example.com.		86400	IN	TXT	"v=DKIM1; k=rsa; p=MIGfCSqaodjVvZ0ohz...."

Look up the value of a mail service-managed DKIM key:

MacBook:~ me$ dig xxx._domainkey.example.com

xxx._domainkey.example.com.		86400	IN	CNAME	xxx.dkim.mailservice.org

This way, you can be sure your DNS records are correct and approachable from the internet for all mail servers to see.

Conclusion

Although this may all sound a bit too technical and needs meticulous attention to get it right, it is of the utmost importance in these days of phishing and ransomware attacks to make sure that at least your email is correctly configured against simple abuse.

Needless to say, when you set up your email channel in Notificare, it will provide you with instructions on how to set up these email configurations in your DNS.

As always, we hope you liked this article and if you have anything to add, questions or suggestions to this post, we are available via our Support Channel.