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:
ameans that any IP address which is listed for the server name
mxmeans that any IP address that is designated as one of the destination mail servers for
example.comis also allowed to send mail
include:mailservice.orgmeans that any IP address that matches the SPF record for
spf.mailservice.orgis 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
~allmeans 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
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.
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
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
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
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:email@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
firstname.lastname@example.org, so the sending organisation is able to analyse any violations of SPF or DKIM policies.
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
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
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
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.
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.