An important way to prevent spam and phishing is being able to prove that an email was sent by the address claiming to have sent.
SPF, DKIM, DMARC, and ARC are standards used to try to solve this problem.
- Why is sender authentication hard?
- SPF
- DKIM
- DMARC
- ARC
- Sender authentication at Fastmail: inbound mail
- Sender authentication at Fastmail: outbound mail
Why is sender authentication hard?
Consider email as if it were a traditional letter. The envelope has addressing information on it that informs the postal service where to deliver the envelope and its contents. The letter inside the envelope also tends to include a greeting to the recipient and information on who sent it.
These two things — the delivery instructions on the envelope, and the information inside the letter — do not have to match.
Email is the same. Within a message, there is information to tell delivery systems who sent the mail and where to deliver the mail to. This is usually not shown to end users and is hidden in email headers. There is also the payload of actual email content which is what mail clients show to their users. These two things do not have to match. This is by design, to support features like BCC (blind carbon copy).
In proving sender authenticity, we need to:
- Make sure that the address information in the email contents matches the addressing information in the delivery instructions.
- Check that the server sending the mail for that particular email address is allowed to do so.
- Make sure that nothing has changed the contents of the email along the way.
- Ask the authorized sender for a particular domain what to do with an email that fails authenticity checks.
SPF
SPF (Sender Policy Framework) lets a receiver check that the system that sent the email for a particular domain is authorized to do so. This ensures that the delivery information is correct.
Unfortunately, SPF breaks when emails are forwarded. If someone sends from Outlook.com to Fastmail, and the Fastmail account is set to forward all messages to Gmail, the SPF checks fails the forwarded mail, because Fastmail is not allowed to deliver mail for @outlook.com email addresses.
It also doesn't always help the reader detect a scammer: the message's content can still claim to be from a certain address or company, even if the message was actually sent from a completely different address.
DKIM
DKIM (DomainKeys Identified Mail) lets a sender crytographically sign the email, to prove that certain parts of the message haven't been tampered with.
DKIM-signed mail can at least be forwarded (unlike SPF-signed mail), as long as the process of forwarding doesn't alter any of the signed message headers. It does give an extra level of trust that the original message did genuinely originate from the domain.
DKIM-signed mail still can break under some forwarding clients or mailing lists, which are prone to adding their own footer and/or [list-id] tags to the message.
As with SPF, DKIM also doesn't help end users detect scammers: a message can be signed from a certain domain while claiming to be sent from another domain in the From header. There's also no way for a receiver to know if all email being sent from a certain domain should be DKIM-signed.
DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on DKIM and SPF. It lets the owner of a domain decide what should happen to an email should it fail both DKIM and SPF checks.
DMARC lets the receiver verify that the From header (the user-visible sender) aligns with the DKIM signed delivery header, or that the From header matches the SPF signed delivery domain and that it's sent from an address validated by SPF.
DMARC also provides more robustness for mail being forwarded: SPF will fail but DKIM should survive.
If either the DKIM or the SPF check fail, DMARC lets the domain owner specify if the mail should be quarantined or rejected (and sent to a reject address).
Fastmail users do not need to set a DMARC policy for their domain to work, but users who would like to set a DMARC policy on their domain are welcome to do so.
Unfortunately, many email clients and mailing lists don't preserve message integrity, which breaks DKIM and SPF. Mailing list software is being brought up to date to deal with this, by adjusting the "From" header and re-signing the message with updated DKIM information.
ARC
Authenticated Received Chain is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.
ARC allows us to check that mail sent via a trusted forwarding service was authenticated when it arrived at that service. We can then use this additional information to safely override any DMARC policies associated with that email should the DMARC checks fail.
With ARC, if a message is sent from outlook.com to Fastmail, and the Fastmail account is set to forward all mail to Gmail, Fastmail is able to sign the forwarded message to confirm that other standards such as SPF were intact when the message arrived, and the message will arrive successfully.
ARC is an experimental standard, and not all mail forwarders are using ARC yet. Until the list of ARC enabled forwarders grows we maintain lists of known good email forwarders and mailing lists, which we use to whitelist known-good mail forwarders, and apply this list when evaluating DMARC policies for inbound mail.
Sender authentication at Fastmail: inbound mail
Fastmail checks SPF, DKIM, DMARC, and ARC on all inbound mail. Passing or failing these checks only alters a message's spam score; we do not outright reject mail, only mark it as more or less suspicious. We add a standard Authentication Results header to all received mail explaining the results of the authentication checks.
Sender authentication at Fastmail: outbound mail
We publish a relaxed SPF policy and DKIM-sign all outbound mail from our domains.
If you have a custom domain, you can set your SPF, DKIM and DMARC policy on your DNS screens. We have instructions if you host your DNS with us. If you use another DNS provider, you need to publish the correct records at your DNS provider.
Fastmail domains have a DMARC policy of none, which means recipient mail servers should report whether the message passes or not, but not change deliverability. This allows users to send mail using our domains from anywhere, for legacy reasons.
Any mail which passes through our system on the way to another provider will be ARC sealed with the authentication results when the mail was received.
Want to know more?
There's a longer blog post about SPF, DKIM and DMARC which explains in more detail how email sender authentication came to be in this state, options for the future and why Fastmail uses the configuration it has.