Different technologies are used to verify the validity of email senders. Each technology by itself represents only one component of a holistic solution. It is currently recommended to implement all three technologies.
The technologies are:
- SPF – Sender Policy Framework
The SPF resource record of a DNS zone defines which servers (hostnames or IP addresses) are allowed to send emails on behalf of the domain. Each sender domain must have its own SPF resource record.
- DKIM – Domain Keys Identified Mail
DKIM pursues the same objective as SPF. With DKIM parts of an email, messages are encrypted using a private key. The public key is published as a DNS resource record. In most cases, the mail servers generate the key pair, as these encrypt the message anyway.
- DMARC – Domain-based Message Authentication, Reporting & Conformance
DMARC is placed on top of SPF and DKIM. DMARC executes a so-called alignment for SPF and DKIM. An alignment defines a policy that describes how strictly a receiving server (MTA) should validate and assess the sender address with SPF and DKIM. Stefan Cink of Net at Work has published a detailed post (DE) on this.
The following figure illustrates the protocol relations.
SPF, DKIM, and DMARC are no substitutes for email message encryption or transport encryption. These technologies are used to identify and asses valid senders and to protect against spam messages.
Remember that SPF, DKIM, and DMARC are offerings for other email servers. As a sending party, you do not control if and how the receiving server evaluates SPF, DKIM, and DMARC. But if evaluated, the configuration must be correct to avoid messages being rejected by receiving email servers.
The following sections focus on the DNS configuration for SPF, DKIM, and DMARC. This post is not intended to rate the technologies but to describe the implementation.
SPF
Each domain used for sending emails requires an SPF resource record (RR) in its DNS zone. An SPF record is always of the type TXT and does not use any hostname (or resource record name if you will). An SPF RR is always valid for the entire DNS zone.
Example
mcsmemail.de. 3600 IN TXT "v=spf1 mx a:mail.mcsmemail.de ?all"
The following screenshot illustrates adding a new SPF TXT record in an internet provider’s common DNS management interface (DE). The hostname textbox remains empty.
Example explained:
v=spf1
SPF Version
mx
MX server records defined within the DNS zone are valid senders
a:mail.mcsmemail.de
The additional DNS hostname defined as A resource record is a valid sender as well
?all
Neutral validation of non-listed servers that send emails for this domain
SPF records can be created by using one of the various online resources.
DKIM
DKIM resource records are configured as TXT resource records as well. In contrast to an SPF record, a hostname is mandatory. In this case, it’s called a selector.
A DKIM TXT record is always created as a record in the subdomain _domainkey.
Example
nsp._domainkey.mcsmemail.eu. 3600 IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChZM8yjegaKfd0ssKyezTW/7xbDSNc0uPd50xa5/ecerv1v3mHKM+T7mClzRmIEx+Ji6AisVeo2uvjTYPemHFMBlQpuS/4zc2QxWHqp62FSQ7lASBOzDfUrIwayPVqwSPD6NrnfVSWoUNrFGGSVeU5uLASecBzTfxPukqTHgYKhQIDAQAB"
The following screenshot illustrates adding a new DKIM TXT record in an internet provider’s common DNS management interface (DE). The hostname textbox contains the selector nsp followed by the subdomain _domainkey.
Example explained:
v=DKIM1
DKIM version
k=rsa
The public key encryption method
p=MIGfMA….
The DKIM public key
DMARC
DMARC is configured as a TXT resource record as well. The DMARC resource record uses the fixed hostname _dmarc.
Example
_dmarc.mcsmemail.de. 3600 IN TXT "v=DMARC1\; p=none\; rua=mailto:DMARCRUA@mcsmemail.de\; ruf=mailto:DMARCRUF@mcsmemail.de\; fo=1\; adkim=s\; aspf=s\; rf=afrf\"
The following screenshot illustrates adding a new DMARC TXT record in an internet provider’s common DNS management interface (DE). The hostname textbox always contains the value _dmarc.
Example explained:
v=DMARC1
DMARC version
p=none
No DMARC policy defined (You should always start with None