Most of us who have hosted or registered a domain, are familiar with the regular DNS record entries. The A, MX, NS and CNAME records are used on a daily basis and are familiar to most Systems Administrators. SOA records, while a bit less familiar, are also present in every DNS zone as they define the DNS authority for the zone. Extended DNS records are less known but equally useful. These are SPF, DKIM and DMARC records which are now in demand as one of the anti-spam tools. Then there are the exotic records hardly ever used such as SVR and DNAME which we will cover in a separate blog article.
From Wikipedia: Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain’s administrators.
In simple terms. the SPF record is a TXT record which defines who may or may not send email for a domain. It defines the sender, the domain and how strict the policy should be applied. This enables ISP’s to use the SPF to either block email that fails this check or to use it to increase the accuracy of their anti-spam measures. An SPF record has the following structure:
“v=spf1 a mx ip4:184.108.40.206/24 ip4:220.127.116.11 include:_spf.google.com -all”
The various elements are:
v= The SPF record always starts with the v= element. This indicates the SPF version that is used. Right now the version should always be spf1 as this is the most common version of SPF that is understood by mail exchanges.
a, mx, ip4, ip6 These define what IP addresses are allowed to send mail from the domain. Rarely used or discontinued records are not discussed here.
a – If the domain name has an address record (A or AAAA) that can be resolved to the sender’s address, it will match.
mx – If the domain name has an MX record resolving to the sender’s address, it will match (i.e. the mail comes from one of the domain’s incoming mail servers).
ip4 – If the sender is in a given IPv4 address range, match. Example: ip4:18.104.22.168
ip6 – If the sender is in a given IPv6 address range, match. Example: ip6:2001:0DB8:AC10:FE01::
include – Include spf records from other sub-domains os domains. This allows more complex spf records to be built.
The policy of enforcement:
Each mechanism can be combined with one of four qualifiers:
- + for a PASS result. This can be omitted; e.g., +mx is the same as mx.
- ? for a NEUTRAL result interpreted like NONE (no policy).
- ~ (tilde) for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
- - (minus) for FAIL, the mail should be rejected.
When deploying SPF records, it is recommended to start with the SOFTFAIL tilde (~) or NEUTRAL (?) modifiers. In well structured corporate email setups, the FAIL (-) may be used as these enterprise setups usually have strict usage policies around email and rarely have to route public email. SPF is now more commonly used as one component of a DMARC record.
DKIM (Domain Keys Identified Mail)
DKIM is another extended DNS record which is becoming more useful as an anti-spam tool.
This record serves as an email reputation authentication method. It allows the mail recipient that an email was actually allowed to be sent from the domain it says it comes from. This is done by adding a digital signature to the email. This signature is checked against the domain’s DNS DKIM record which will then confirm or deny the validity of the signature.
DKIM signatures and the verification usually occurs in the background by the email servers. The process s not usually visible to the end users. DKIM signatures are not a DENIAL or ACCEPTANCE switch. They are usually used to enhance the effectiveness of other anti-spam measures. Thus, they help combat spam and certain types of PHISHING but are not meant to be an absolute defence. DKIM makes it harder for a spammer to forge a source address. A DKIM record in DNS has the label containing “._domainkey” for example “default._domainkey” in the hostname section of the record. The record type is TXT and is constructed as follows: “v=DKIM1; p=yourPublicKey”
Constructing the key and integrating with your mail system is outside the scope of this post.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC counters the illegitimate usage of the exact domain name in the “From:” field of email message headers. It utilizes SPF and DKIM records to confirm the legitimacy of the email sender. The use of DMARC allows the recipient infrastructure to query the sender infrastructure to confirm the validity of the email.
DMARC entries in DNS do not have a host component as they usually refer to the domain root. The record is a TXT record and usually looks as follows:
The tags are as follows:
|pct||Percentage of messages subjected to filtering||pct=20|
|ruf||Reporting URI for forensic reports||ruf=mailto:firstname.lastname@example.org|
|rua||Reporting URI of aggregate reports||rua=mailto:email@example.com|
|p||Policy for organizational domain||p=quarantine|
|sp||Policy for subdomains of the OD||sp=reject|
|adkim||Alignment mode for DKIM||adkim=s|
|aspf||Alignment mode for SPF||aspf=r|
Using these records is strongly encourages as it can have a large impact on reduction of SPAM and acceptance of valid email.