When I was a kid I played around with the SMTP protocol in telnet (I could also chat on IRC via telnet, but that's another story). Hotmail was all the craze at the time, and so that was my MX server of choice.
I incidentally discovered that you can send mail on behalf of pretty much anyone. Indeed, once you test the protocol manually, it's quite easy to discover mail spoofing.
I even wrote a small VB program to let the other kids in the neighborhood in on the fun.
The SMTP protocol looks like this:
HELO <introduce yourself>
MAIL FROM:<address you have mail from>
RCPT TO:<for this recipient>
DATA
<mail content>
.
Pretty simple. HELO is actually obsolete now and should be EHLO (extended HELO).
So long as the recipient is on the mail server you're connecting to, it will pretty much let you drop any mail there. So, how does it know that it actually came from the address you state?
SMTP doesn't actually care—email authentication is not part of the specification.
Email authentication standards are used to determine whether or not an email is legitimately from the designated sender or spoofed. There are three authentication standards in use today:
- SPF - Sender Policy Framework
- DKIM - DomainKeys Identified Mail
- DMARC - Domain-based Messaged Authentication, Reporting, and Conformance
Sender Policy Framework (SPF)
This is probably the most common of the lot. SPF is a method to let mail servers know that the sending server (connecting IP address) is authorized to send on behalf of a domain.
You add it to a domain via a DNS record, for example:
example.com. IN TXT "v=spf1 mx ~all"
The above will authorize the IP addresses of any MX servers (dig mx domain.com) listed on the domain to send on behalf of the domain example.com.
When mail addressed from someone@example.com is delivered, the receiving server may look up the SPF record for "example.com" to see if the connecting IP address is authorized. If not, the mail server may block it.
~all in the record suggests to soft-block, or put it in
the spam folder (soft fail for all other addresses),
rather than deleting it outright. Soft-fail is recommended
by many administrators to protect important mail from
accidents.
Pitfall #1
One thing many don't understand is that SPF does NOT validate the "From:" field in an email message.
Consider this example:
EHLO fungames.com
MAIL FROM:<bounce-250123508@fungames.com>
RCPT TO:<john.doe@gmail.com>
DATA
Date: 9 Jun 2021 7:55:00 -0600
Subject: dude!! check out these fun games!
Message-ID: <501283508@fungames.com>
From: Jane <jane.doe@gmail.com>
To: John <john.doe@gmail.com>
john! visit fungames.com LOL, it's so FUN
This email can pass the SPF check easily. In the inbox, it will look like it came from jane.doe@gmail.com and there may be a hint that another server sent it, such as "via fungames.com".
Jane certainly seems excited about fungames, so it would be easy to ignore the tip that another domain sent on her behalf. Maybe she just used a FUN thing to send the mail?? Most users are unaware of the implications of an intermediate server like that.
In case it isn't clear, the "envelope sender" is the "MAIL FROM:" address. The "MIME sender" (but there are many names for it) is the "From:" address. The MIME sender is typically more visible. Well-behaving mail servers also store the MAIL FROM address in a "Return-Path:" MIME header during delivery.
Pitfall #2
Just because a mail is "From:" someone@example.com, it doesn't necessarily mean that "example.com" will hold the SPF record. It's common, but not the case in many situations.
It's the same as above--the MAIL FROM domain is the one that holds the SPF record, not the "From:" field.
It is especially common to send under a subdomain. Some services will, for example, send under "mail.example.com". It's common to have a "bounce" address in this field, e.g.,
MAIL FROM:bounces-23085123@mail.example.com
mail.example.com is the domain that should hold the SPF record here. An SPF record under example.com will not affect this mail.
This can be convenient, too. If you use a third-party sender that employs a subdomain method for email authentication, you can just CNAME to their designated address and automatically get SPF set up without having to mess with SPF records.
Anyway, how do we make sure the mail is legit? DMARC is what provides authentication for the the "From:" field, but let's check out DKIM next.
DomainKeys Identified Mail (DKIM)
DKIM is a standard that describes employing public key cryptography to sign messages so they can be verified as authoritatively sent from a domain.
The process is this:
- An email service wants to send mail addressed from your domain.
- You, the domain owner, can add DNS records to the domain.
- The server provides a DNS record to add to your domain.
- This contains an cryptography public key and a "selector".
- You add the record to your domain, thereby authorizing the server to sign messages.
- The server adds a signature to outgoing mail, generated
with its private key.
- The signature header contains the signature and the signing domain.
- When mail arrives at another server, the server sees the signature header and may look up the signing domain's public key to verify the signature, thereby authorizing the mail.
DKIM records are added like this:
<selector>._domainkey.example.com. IN TXT "v=DKIM1; t=s; p=<public key>"
This will register the public key as authorized under example.com. t=s means that subdomains can't be used for the signature. There are a bunch of other options that you can play with, but you best read the DKIM spec to fully understand.
The main benefit here is that this is not reliant on the IP address of the sending server. That might not even be available if there are perimeter servers in the way (then you would have to trust the perimeter servers).
DKIM is a way to know that a mail is authentic (so long as the private key/server isn't leaked), even when the sending server is NOT authorized.
Still, DKIM, just like SPF, does not authorize the MIME "From:" field, so that is where DMARC comes in handy.
Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
I can see why they usually abbreviate it. This standard has a bunch to it.
- Message Authentication
- This is what we're interested in.
- Reporting
- DMARC will also let you tell other mail servers that you want to receive information about your mail flow and Conformance.
- For example, servers will tell you if you fail an SPF check so your administrators can act on that.
This is probably the least employed standard because it's newer and not obvious why it is needed in the first place.
You basically add it to your domain like so (and yes there are other options):
"v=DMARC1;p=quarantine"
This turns on the DMARC policy with "quarantine" as the action if "alignment" fails. Alignment is the term for making sure that the "From:" field matches one of the authenticated domains, leveraging SPF and DKIM.
Either method needs to have a sending domain that matches the "From:" domain in order for mail to DMARC to pass.
So, for example:
MAIL FROM:<legit@legit.com> -> SPF passes (not aligned)
<no DKIM signature> -> DKIM fails
From: user@example.com -> DMARC fails
MAIL FROM:<legit@legit.com> -> SPF passes (not aligned)
<DKIM signature from example.com> -> DKIM passes (aligned)
From: user@example.com -> DMARC passes
MAIL FROM:<legit@example.com> -> SPF passes (is aligned!)
<DKIM signature from example.com> -> DKIM passes (aligned too!)
From: user@example.com -> DMARC passes
No, DMARC doesn't say you passed extra-good if both SPF and DKIM align. Just pat yourself on the back.
One other note about DMARC is "strict" and "relaxed" mode. Many services will send email using a subdomain of your domain. For example, SendGrid might use these records:
CNAME em2350.example.com -> u555555.wl141.sendgrid.net
CNAME s1._domainkey.example.com -> s1.domainkey.u555555.wl141.sendgrid.net
CNAME s2._domainkey.example.com -> s2.domainkey.u555555.wl141.sendgrid.net
The MAIL FROM domain will be em2350.example.com, so the SPF lookup will use that and then be redirected to SendGrid's domain records. If you set "strict" mode in your DMARC record, then "em2350.example.com" will not align with the address "user@example.com", due to it being a subdomain. By default, both DKIM and SPF are checked in "relaxed" mode, which would allow the subdomain to pass alignment.
But note, even if both are set to strict mode, DMARC will pass, so long as the DKIM authenticated domain is example.com. There is no good reason for that to not be the case.
And in case you're curious, yes, there are two DKIM records in the previous example. In cases like this, the server alternates between the two, signing mail with one while updating the other and waiting 48+ hours for DNS propagation before switching. That way the key can continuously update so it can't be cracked.
Though, keep in mind, when you use keys that constantly update, you can no longer verify if previous email was authorized (e.g., if you forward it a year later).
Anyway, just keep in mind that blindly turning on DMARC will have a good chance to drop your mail if you don't understand your underlying mail authentication. This is so common that the "reporting" part of DMARC is an essential part of the design to help administrators deploy the policy:
- Enable reporting without an authentication policy action.
- Wait for email to bounce around the internet.
- Check the reports to make sure that your SPF and/or DKIM is aligning.
- Enable a policy action to enforce full authentication.
- Feel at ease knowing that your domain will never be spoofed.
Fun stuff, right? It is pretty simple to make sure everything is good, but some companies have messy mail networks, especially ones with extra layers of security and firewalls.
And, just keep in mind, even if you confirm perfect SPF, DKIM, and DMARC authentication on an email, it can still be spam. :)
Just very authentic spam.