Preventing Mail Spoofing with SPF, DKIM, and DMARC
How can the misuse of your company's email address for phishing attacks be prevented? SPF, DKIM, and DMARC can help. But what are they?
Ing. Philipp Doblhofer
Phishing mail scam attempts occur repeatedly, where it is pretended that a mail comes from a company, which is not the case. The problem is that the sender can be freely assigned in mails. This fundamentally opens the door to fraudulent schemes.
To address the problem, there are various solutions. Here we would like to explain a few examples:
SPF – Sender Policy Framework
In this method, the domain owner makes an entry for the respective domain, from which servers emails may be sent on behalf of the domain. When an email is received, the receiving server checks the domain’s entries – is the server from which the mail comes allowed to send a mail in this name?
An example SPF entry could look like this (this is stored as a TXT entry for the domain):
„v=spf1 a mx ip4:123.45.67.89 -all”
This specifically means the following: Emails may be sent from servers listed in the A or MX record, and additionally from the IP 123.45.67.89. With -all, it is indicated that no other server should accept the mail. If ~all is used instead of -all, then emails from other servers should only be marked (Spam).
DKIM – DomainKeys Identified Mail
As with SPF, the goal of DKIM is to prevent spam and phishing. The basis for this method is asymmetric encryption or signature. The special thing about asymmetric encryption is that there is one key for encryption and a separate key for decryption. If you possess one of the keys, you cannot deduce the other key.
For DKIM, the public key is stored as a DNS entry. When a mail server sends an email, the message to be sent is signed with the private key. A receiving server can then check with the public key (from the DNS entry) whether the content has been modified – or even belongs to the respective domain.
DMARC – Domain-based Message Authentication, Reporting, and Conformance
This specification builds on SPF and DKIM. Here it can be defined how emails are to be checked and how to proceed in case of errors. As with SPF and DKIM, the desired settings are defined via a DNS entry.
An example DMARC entry is the following:
„v=DMARC1;p=quarantine;pct=100;ruf=mailto:postmaster@example.com;rua=mailto:postmaster2@example.com;sp=reject“
p=quarantine means that policy violations of the main domain should be quarantined (Spam). sp=reject instructs to reject policy violations of sub-domains. pct=100 means that the DMARC settings should be applied to all emails. The purpose of this option is to apply new settings to only a part of the mails to avoid bringing the entire domain’s mail traffic to a standstill in case of misconfiguration. Usually, the pct setting is gradually increased from 0 to 100 over several days or weeks. Through ruf or rua, it can be specified to which email error reports should be sent. Aggregate Reports – summaries – are delivered to rua. ruf-Reports send more detailed information.
In conclusion, it should be noted that all settings should never be “blindly” tried out in production systems, as a misconfiguration can bring the mail traffic of the entire domain to a standstill.