In today’s post, I’ll try to cover one of the methods that spammers and malicious actors use to entice people into clicking links in their emails.
I’ll also describe a couple of extra steps that mail administrators can take to protect their users from this method.
If you’re not an email administrator, as soon as you have the gist of what I’m talking about, it’ll make it easier to ask your admin if they’re utilising these protective features!
So, lets get right into it, shall we?
“I’ve got an email that says it’s from you, but it doesn’t sound like it’s from you!”
Most people reading this post will have, at some point in their life, received an email claiming to be from a colleague, family member, or even Bill Gates himself! These messages almost always direct the reader to click a link, to send somebody money, or to open an attachment.
Most people who receive one of these messages will contact the supposed sender, telling them:
“Your email is hacked.”
“I think you have a virus.”
“I think you’re sending out dodgy messages!”
In most cases the poor spoofed sender will change passwords, check sent items, and generally assume they’ve been compromised. But they haven’t! They’ve had their email address spoofed!
“What is spoofing?”
Spoofing is the act of faking the From: address of an email. Its similar to sending notes or memos to a recipient, but signing someone else’s name instad of yours.
Most recipients will have no way of knowing that the message has a fake sender, and will happily believe that yes, their technophobic grandparent HAS just sent them a link to a crypo-coin ponzi scheme.
“Surely there’s a way to detect spoofing?!?”
There is, and don’t call me Shirley. Numerous technologies have been bolted onto the venerable email protocols to prevent this sort of abuse. SPF provides a method of identifying mail that has been spoofed, while DMARC provides mail servers with instructions on how to handle these spoofed messages. I’ll go into more details on each of these below.
SPF - Sender Policy Framework
The name is a mouthful, but the protocol boils down to: “What server can send messages saying they’re me?”
In order to get this working, administrators for a particular domain (like seantodd.co.uk) can specify the mail server/servers that are allowed to send email on behalf of that domain (<username>@seantodd.co.uk). This is done using DNS records.
For example, the SPF entry for my domain is here:
v=spf1 mx -all
For those that can’t read SPF record fluently, this means:
v=spf1: This is an SPF record.mx: This matches any IP listed within the domain’s MX (mail exchanger) records.-all: If the sending IP hasn’t matched any of the previous listed IP’s, the check fails.
As a whole, the record means that unless the email was sent from an IP address listed as a mailserver for my domain, the SPF check will fail.
Larger domains, such as hotmail or gmail, will have many servers listed, as they have a much larger infrastructure.
Example SPF interactions
“So what does an SPF check look like?”
Let <Sender> be the mail server sending a message, and <Recipient> be the server receiving said message.
Authorised mail sender
- <Recipient> gets an email saying it’s from sean@seantodd.co.uk.
- The headers of the message state that the message came from <Sender>, who has the IP address:
81.136.128.181 - <Recipient> looks at the SPF record for seantodd.co.uk:
v=spf1 mx -all. - <Recipient> then checks the IP addresses listed in the MX records of seantodd.co.uk, returning an IP address of:
81.136.128.181. - As this matches the IP address of <Sender>, the SPF check passes. This IP is authorised to send mail on behalf of seantodd.co.uk.
Unauthorised sender, spoofing messages
- <Recipient> gets an email from billgates@microsoft.com.
- The headers of the message state that the message came from <Sender>, who has the IP address:
83.146.58.22 - <Recipient> looks at the SPF record for microsoft.com:
v=spf1 ip4:147.243.1.48 -all. - This does not match the IP address of <Sender>, and the SPF check fails. This IP is not authorised to send mail on behalf of microsoft.com.
“So what?”
Well, we can now check if an IP address is allowed to send mail on behalf of a domain.
“But how does that help?”
A mail server can do this check for you, but without any guidance it may just deliver a spoofed message anyway.
This is where we implement DMARC.
DMARC - Domain-based Message Authentication, Reporting and Conformance
“Yet another long acronym, but what exactly does it do?”
DMARC is a DNS record that ensures that legitimate mail (that passes SPF) is delivered correctly, and that illegitimate mail (that fails SPF) is treated the way the owner of the spoofed domain wants. To further explain this, lets look at the DMARC record for seantodd.co.uk.
Explaining DMARC Entries
As of writing, the DMARC entry for seantodd.co.uk is:
v=DMARC1; p=reject; sp=reject; rua=mailto:o9oksxwk@ag.dmarcian-eu.com; ruf=mailto:postmaster@seantodd.co.uk; rf=afrf; pct=100; ri=86400
As before, we’ll break it into smaller chunks:
v=DMARC1: This is a DMARC record.p=reject: The policy to apply to mail that fails the DMARC test. Possible values are:- None : Do nothing to the message.
- Quarantine : Send the message to the user’s Spam/Junk folder.
- Reject : Drop the message entirely.
sp=reject: Subdomain policy. This has the same options as the previous policy.rua=mailto:o9oksxwk@ag.dmarcian-eu.com: Where to send DMARC test feedback to. We’ll touch on this later.ruf=mailto:postmaster@seantodd.co.uk: Where to send forensic reports to. Again, I’ll come to this further down.rf=afrf: Report Format. This is the format I want my forensic reports in.pct=100: The percentage of the time I want the policy to apply against mail that fails the DMARC check.ri=86400: Reporting interval. How often I’d like to receive the feedback reports in seconds.
“All that is great, but again, what does it DO?”
The short answer:
It tells a recipient server what to do with emails that have been spoofed.
The longer answer:
Any mail server that identifies a spoofed message checks the spoofed domain’s DMARC record.
If the policy says to Reject or Quarantine the message, the recieving server will do just that. It will either drop the message or send it to the user’s spam folder.
If set to None, the receiving server will happily accept the message.
“Is that all?”
Nope. The magic of DMARC doesn’t stop there!
If a receiving server has been set up correctly, it can send special reports to the addresses listed within the rua and ruf sections of the record.
These reports can tell the admin of a spoofed domain:
- The IP address of a server sending email marked as being from their domain.
and
- What the receiving servers did with that mail.
This is a great way for an email administrator to identify any undocumented mail servers that should be allowed to send mail for their domain.
It also lets administrators report those IP addresses used in mail spoofing, so that they can be added to blocklist worldwide, warning other servers that messages from this malicious one cannot be trusted.
“I’m not an email administrator, why should I care?”
For an end user, it means that you don’t get an email from your_grandma@domain.com asking you if you want to make billions of dollars with this new bitcoin scheme.
So if you often get messages that claim to be from someone you know, and they’re none the wiser about who sent it, get them to approach their email administrator and ask:
“People are getting messages that are supposedly from me, but I never sent them. Do we use SPF and DMARC?”
If the response is negative, then point them this way.