Email Security through DMARC DKIM and SPF
What is email authentication?
“Email authentication” refers to a set of technologies that enable:
- a domain owner to assert control over its domains, making them harder to successfully spoof an email.
- the recipient of an email to have reasonable confidence that a message which purports to be from a given domain is genuine or not.
Email authentication can impede the delivery of phishing emails that attempt to play off an organization’s domain names. This protects:
- the sender’s reputation and keeps likely-harmful emails out of recipient mailboxes.
- the public who might receive authoritative-sounding emails claiming to be from a trusted domain.
- employees who may rely on information that appears to come, e.g., from an important colleague.
There are three predominant forms of email authentication technology: SPF, DKIM, and DMARC. Conceptually, each operates similarly:
- When an email arrives at a recipient mail server, it queries the sending domain’s DNS to check for relevant email authentication records.
- If email authentication records are found, the server evaluates the email it received against the email authentication records and makes a determination: deliver it, deliver it but mark it as questionable, or discard it altogether.
What are the standards that enable email authentication?
SPF & DKIM
- SPF, or Sender Policy Framework, enables a mail sender to detail the canonical source(s) (IP addresses, or domains to find those IP addresses) authorized to send email on a domain’s behalf.
Once set, a receiver authenticates a piece of mail by comparing the IP address of the sending email server against the addresses listed on the SPF record. The SPF record is found by querying at the domain used in the email address asserted at the initial SMTP transaction, called the RFC5321.From address, or envelope From: address (among other names). If the IP address of the sender is listed in the SPF record, the message is considered authentic.
- DKIM, or DomainKeys Identified Mail, involves the cryptographic signing of individual email messages. A receiver authenticates a piece of DKIM-signed mail by using the public key posted at the domain given in the DKIM header and comparing the signature embedded in the header with one the receiver calculates. If the signatures match, the message is considered authentic.
In effect, both these techniques allow a sending domain to “watermark” emails from their domain, making spoofed emails easier to detect.
However, there is no inherent or widely-implemented mechanism in either standard to signal what a recipient should do with messages that fail SPF/DKIM validation. DMARC serves this role.
Domain-based Message Authentication, Reporting and Conformance, or DMARC, serves three primary functions:
- Authentication: It verifies alignment between the domain listed in the email address that gets displayed to an email recipient and the outcome of SPF and DKIM authentication checks.
- Reporting: It enables a reporting mechanism so an email sender can validate their email authentication setup is working as expected.
- Conformance: It allows a domain owner to establish what the final disposition of email that fails email authentication checks should be.
Alignment and Conformance
Different than the RFC5321.From address that is sent in the initial SMTP transaction, the RFC5322.From address (also known as the message-From address) is typically the email address that is represented as the sender in email clients. DMARC requires “alignment” between the domain in this very visible address and the domains that are authenticated in SPF and DKIM. This alignment can be “strict” (an exact match) or “relaxed” (must be a subdomain of the parent domain). Alignment is fully tunable in DMARC, with different options for SPF and DKIM alignment. DMARC’s default for alignment is “relaxed”.
In order to satisfy DMARC filtering, at least one of either SPF or DKIM must “pass” their authentication checks and be in alignment with the domain in the message-From address.
If not, DMARC allows a sender to set one of three separate policy states for email disposition:
- block delivery of unauthenticated messages (noted in the DMARC record as p=reject),
- place unauthenticated messages in the recipient’s junk email folder (p=quarantine), or
- specify no guidance on how to treat unauthenticated messages (p=none). This setting should be viewed as a temporary policy setting before getting to p=quarantine and p=reject, and is only meaningful when coupled with reporting.
In other words, by using DMARC, a sending domain can instruct receiving email servers to block delivery of all unauthenticated messages – such as phishing messages – that claim to be from the sending domain.
DMARC also enables a sending domain to request that participating email providers send it automatically generated reports about authentication results, thereby enabling the sending domain to monitor whether its SPF and DKIM policies are working properly.
In addition to monitoring proper configuration, this is valuable information one would not normally receive: if an attacker spoofs your domain, they are not likely to copy you on the spoofed email.
What are DMARC reports?
DMARC reports are summaries of email authentication results that are automatically sent by participating email providers. They detail what the email provider saw from your domain over a given period of time, and facilitate the process of graduating to p=reject.
There are two kinds of reports:
- aggregate reports
- failure reports (sometimes called forensic reports)
Both reports provide information like the sending and receiving email domains, the DMARC policy that the email recipient discovered and applied, the identifier that was evaluated by SPF and/or DKIM and whether it was in alignment, the number of successful authentications, and the totals for all messages received. Aggregate reports are normally delivered once daily from mail receivers, whereas failure reports are sent immediately after an authentication failure. Failure reports include additional information about identity alignment, and can even include much of the body of the email and email headers; this can lead to an unintended exposure of private information. Failure reports are only sent by a handful of ISPs, none of which are US-based.
Select a DMARC Report Aggregator
Your DMARC policy is more valuable when you use an aggregator to help filter the content of the reports that are returned. Without an aggregator, the reports are in an XML format and are virtually unreadable. An aggregator formats this information and sends out weekly reports to the email address specified. The weekly report contains the sending source (domain or IP address) and information about whether the message passed or failed SPF and DKIM. This information enables you to monitor your domain’s activity and helps to prevent spoofing and domain abuse.
Following are some top reporting aggregators, based on suggestions from https://dmarc.org/resources/products-and-services/: