A thought by Jeff Stein
When it comes to addressing email security, message integrity should be a main focus to mitigate spoofing attempts on your domain. While message integrity is not build into the SMTP protocol from a design standpoint there are a few frameworks to address the deficiencies. The three email authentication standards I recommending focusing on are SPF, DKIM and DMARC.
Sender Policy Framework (SPF) can be used for senders to define the IP addresses that are allowed to send mail on behalf of an email domain. In essence it serves as a whitelist for you domain. The framework is used in conjunction with DNS as a TXT record type to contain the whitelist of approved mail senders. Alternatively the record may contain of blacklist of mail senders or the ability to block all mail from being sent on behalf of a domain. The tailored SPF record can be added to your existing TXT record for your domain or a new TXT record can be created for the SPF record if a TXT record, for your domain, does not exists today. A list of some helpful options for the record can be seen below.
Option | Description |
---|---|
all | Represents all addresses. Think of this as an allow or deny all rule found on a firewall. |
ip4: | Lists IPv4 addresses associated with the SPF record. The syntax can include either a list of single IP addressees or network ranges. |
ip6: | Lists IPv6 addresses associated with the SPF record. The syntax can include either a list of single IP addressees or network ranges. |
ptr | Uses a pointer domain instead of an IP address to associate with the SPF record. |
exists | Refers to the A record for the domain listed. If the lookup of the A record is found it is considered a match. If no A record is found for the domain referenced, the match fails. |
include | Specifics a domain to search for. If found it is considered a match, otherwise an error will occur. |
Additionally, qualifiers are used in the SPF record to determine the action taken by the options discussed above. Here are three different qualifiers that can be added to the record to control the action taken.
Qualifier | Description |
---|---|
+ | Pass - Allows the addresses contained in the record to send on behalf of the domain. |
- | Fail - Blocks the addresses contained in the record from sending on behalf of the domain. |
~ | Softfail - Allows the message through but marks it as not passing the SPF check. |
Taking the options and qualifiers into account the syntax of the SPF record is as follows:
[spf version] [qualifier action (optional)][domains/IP addresses to check against] [qualifier action][include all other mail not listed in check]
Here are some examples of the SPF syntax you can input into your domain TXT file:
v=spf1 include:securityinobscurity.com ~all
Include messages found from securityinobscurity.com and softfail all others
v=spf1 ip4:x.x.x.x ip4:x.x.x.x/24 -all
Allow messages from either the certain IP listed or the network range listed. Block all other addresses.
v=spf1 -all
Deny all messages being sent on behalf of the domain.
One limitation of SPF to consider is that it only allows for up to 10 addresses to be included in the DNS record. If more than 10 addresses or network ranges are required hosted solutions for message authentication, such as Valimail, should be looked at.
DomainKeys Identified Mail or DKIM allows a mail recipient to validate that the message originated from the authentic domain name. To validate the domain, public key cryptography is used. A digital signature is generated and is appended to the message header. The validity of this DKIM signature can then be completed by looking up the public key in the DNS records of the domain. These DNS records are configured as CNAME records. The value of each will contain the public key of the digital signature.
DMARC is a framework that complements both SPF and DKIM. The framework allows you to better control how mail passing or failing your SPF and DKIM checks is handled. You can use it as a vector to give specific guidance to recipient MTAs to reject a message outright, quarantine the message or do nothing at all. Like SPF and DKIM, DMARC is stored as a DNS record. A list of some helpful options for the record can be seen below.
Option | Description |
---|---|
p | Sets the policy disposition for DMARC. You can set a policy to either reject a message failing SPF/DKIM, Quarantine a message or do nothing at all. |
fo | Allows you to request MTAs to sent you a report of message samples. There are two potential dispositions to leverage with fo. 0 will send a report when all checks fail: 1 will send a report if any checks fail. |
rua | Using this option will tell the MTA where to send a message failure report. The address domain must match the domain the DMARC policy is configured for. |
pct | Specifics the percent of messages that DMARC applies to other than a policy of none in which case this does not apply. |
Using the options, the syntax for the DMARC record is as follows:
v=DMARC1;p=reject;pct=100;fo=1;rua=mailto:contact@securityinobscurity.com
Uses a reject policy on 100% of messages and sends a message sample report to the domain email address specified if any combination of SPF or DKIM are not passed.
v=DMARC1;p=none
A DMARC policy is not leveraged.
Leveraging message authentication frameworks with email help to provide for message integrity and reduce security risks associated with email domain spoofing. By focusing not only on SPF and DKIM to provide message integrity, layering DMARC on top of them will provide for a holistic approach to message authentication. It will give you granular control of your message security posture including better insights into who is targeting your domain.
[1] SPF Record Syntax (n.d.). Retrieved from Article Link.
[2] Pollard, John. What are the different tags of a DMARC record (n.d.). Retrieved from Article Link.
Security Vulnerabilities IDS/IPS Malware Ethical Hacking Policies PowerShell Python Splunk Email Script PKI Firewall Router Vulnerability Management