How DKIM and DMARC can help prevent phishing
Phishing is a form of online scam. Criminals trick you with an email or website that looks real but is a fake. Often the sender of the mail or the website appears to be a reliable company. Phishing emails usually ask for your personal information.
SMTP – an aging and non-secure protocol
The e-mail protocol (SMTP, RFC5321) is one of the older internet protocols and lacks built-in security. One of the shortcomings of SMTP is that falsifying a ‘from’ address is child’s play. And, to an ordinary user, a falsified address looks just like a real one. Needless to say, therefore, spammers and phishers forge ‘from’ addresses all the time.
What’s the answer?
On its own, ordinary spam filtering isn’t enough to ensure that all undesirable mail is promptly identified and flagged up to alert the user.Over the years, however, a number of solutions have been developed, which can help to minimise the problem of forged mail. They are the (proposed) internet standards DKIM (RFC6376), SPF (RFC7208) and DMARC (RFC7489).ISPs are well advised to implement all those solutions in their mail environments (where possible, because it isn’t easy in some cases). Fortunately, that is what many ISPs already do, particularly the bigger ones. How do they work and why is it important to implement the three standards? Those questions are briefly considered below.
SPF, DKIM, DMARC
SPF
All three techniques are based on the Domain Name System (DNS). With SPF, a DNS record is created, specifying which systems are allowed to send mail for the domain in question. Let’s consider a simple example involving the domain ‘contoso.com’. Suppose that an SPF record (which is actually just a TXT record) is created for the domain, as follows:
contoso.com. IN TXT “v=spf1 include:spf.protection.outlook.com ip4:46.192.20.15 -all”
That SPF record means that only servers with IP addresses in the specified series are allowed to send mail for contoso.com. Any mail that claims to be from contoso.com, but isn’t sent from a valid IP address, will immediately be identified as suspect by the recipient’s mail system. In other words, SPF helps the recipient to tell whether incoming mail is legitimate. SPF isn’t entirely straightforward, though. Before enabling SPF for outgoing mail or filtering incoming mail on the basis of SPF, you need to consider the configuration carefully. However, once set up correctly (see also RFC7001), SPF is a useful tool for identifying fraudulent mail.
DKIM
The main advantage of DKIM email is its ability to protect against both spoofing and phishing attacks. The authentication appears in the message itself to prevent forgery and prevent users from responding to illegitimate emails. Both spoofing and phishing can damage your sending reputation and/or future deliverability.
How DKIM works. DKIM works by adding a digital signature to the headers of an email message. This signature can then be validated against a public cryptographic key located in the organization’s DNS record. The domain owner publishes a cryptographic key. After a message is sent by an outgoing mail server, the server generates the unique DKIM signature and appends it to the header of the message. The DKIM key is then used by incoming mail servers to detect and decrypt the message signature and compare it with a new version. If the values match, it can be proven that the message is authentic and unaltered in transit, and thus not falsified or altered.
DKIM offers other useful functionality. Your DKIM record can indicate that your system is in test mode, for example. By enabling test mode while DKIM is being configured, you can ensure that mail isn’t rejected while the settings are still being perfected. Below is a script with which DKIM can be set up in Exchange Online. The script indicates which DNS records should be created. In this case it is two CNAME records.
param
(
[Parameter(Mandatory = $false)]
[string]$DomainName
)
$MessageColor = "cyan"
$AssessmentColor = "magenta"
if($DomainName -eq $null -or $DomainName -eq ""){
Write-Host
$DomainName = Read-Host -Prompt "Please specify the domain name"
Write-Host
}
## This line will return the CNAME record values for the specified domain name (Points to):
Write-Host -ForegroundColor $MessageColor "Enter the (Points to) CNAME values in DNS for selector1._domainkey and selector2._domainkey:"
Write-Host
Get-DkimSigningConfig $DomainName | fl Domain,*cname
## Pause the script to allow time for entering DKIM records
Write-Host
Read-Host -Prompt "Enter the DKIM records, have a coffee and wait for several minutes while DNS propogates, and then press Enter to continue..."
Write-Host
## This line will attempt to activate the DKIM service (CNAME records must be already be populated in DNS)
##If DKIM exists but not already enabled, enable it
if (((get-dkimsigningconfig -identity $domainname -ErrorAction silent).enabled) -eq $False) {set-dkimsigningconfig -identity $domainname -enabled $true}
##If it doesn't exist - create new config
if (!(get-dkimsigningconfig -identity $domainname -erroraction silent)) {New-DkimSigningConfig -DomainName $DomainName -Enabled $true}
Write-Host
## End of script
DMARC
Unfortunately, as with SPF, the forwarding of e-mail can cause problems, because forwarding sometimes involves alterations to the forwarded message. Spammers can spoof your domain or organization to send fake messages that impersonate your domain. DMARC tells receiving mail servers what to do when they get a message that appears to be from your domain, but doesn’t pass authentication checks, or doesn’t meet the authentication requirements in your DMARC policy record. Messages that aren’t authenticated might be impersonating your organization, or might be sent from unauthorized servers. DMARC is always used with these two email authentication methods or checks:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
For example, you might include a record that effectively says ‘if the DKIM signature is invalid, or if a message fails the SPF check, treat it as spam’. That is what the following DMARC record does:
_dmarc.contoso.com. IN TXT ‘v=DMARC1; p=quarantine’
A receiving MTA looks up the sending domain’s DMARC record to see what should be done with a suspect message.Naturally, the value of DKIM, DMARC and SPF records in the DNS is enhanced when the domain is protected with DNSSEC
Summary
SPF, DKIM and DMARC are standards that you should definitely use. It’s therefore very easy for a receiving system that supports those technologies to filter out fraudulent e-mails claiming to come from contoso.com and with a ‘from’ address that ends ‘@contoso.com’. Via the DMARC mechanism you can also ask for so-called feedback reports, which is a handy feature. When something is not right, receiving parties will (as a rule) send such reports. This is therefore one of the ways through which you are quickly alerted to a phishing attack. So, if you want to reduce the problem of spam and phishing emails, you should definitely consider adopting these standards.
A good way to check how things are going with a particular domain name is to check it at MXtoolbox. This site offers an easy and fast way to check whether modern (and secure) standards are met.
This message contains pieces of text written on Sidn’s website (https://www.sidn.nl/nieuws-en-blogs/waar-dkim-en-dmarc-kansen-helpen-in-geval-van-phishing).