Introduction to Email Authentication
The Department of Homeland Security seeks to incentivize the thoughtful deployment of email authentication technologies and generally increase the security of messages to and from government agencies. Email that fraudulently uses a Federal domain should be easy to detect.
This section is a recital and elaboration of key points in two recent Federal documents:
- Special Publication 800-177, Trustworthy Email, which the National Institute of Standards and Technology issued in September 2016
- Businesses Can Help Stop Phishing and Protect their Brands Using Email Authentication, issued in March 2017 by the Federal Trade Commission’s Bureau of Consumer Protection based on a study performed by the Office of Technology Research and Investigation
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 in 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 .gov address.
- internal government users who may rely on information that appears to come, e.g., from an important colleague.
- 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.
See SP 800-177, section 4 for a detailed technical description.
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
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
- place unauthenticated messages in the recipient’s junk email folder (
- 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=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
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.