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.
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.
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.
MX server records defined within the DNS zone are valid senders
The additional DNS hostname defined as A resource record is a valid sender as well
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 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.
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.
The public key encryption method
The DKIM public key
DMARC is configured as a TXT resource record as well. The DMARC resource record uses the fixed hostname _dmarc.
_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.
No DMARC policy defined (You should always start with None