With the growing risk of Business Email Compromise in the cyber space, it’s imperative to understand the email security controls of the times, they are what I like to call the holy trinity, namely, SPF, DKIM & DMARC
Ever received an email from a colleague but he swore it never came from him and apparently he wasn’t breached? Happens right? Maybe.
SPF
Sender Policy Framework is the verification system designed to state which mail server is allowed to send emails for your domain, when SPF enabled server receives a mail, it verifies the sending mail server’s identity against the publicly available SPF TXT DNS record.
Coming across an SPF record, the following parameters / placeholders are what to look out for:
- v= states the version of the implemented spf record
- ip4= specifies the ip address of the mail server allowed to send mails for your domain
- include= are the secondary mail servers that can send mails in place of the primary mail server
- all= this placeholder informs the receiving server what to do with the received mails, however this is where it gets tricky, all is usually preceded by a sign which tells all, namely:
+all — this means any domain can send emails even if they are not identified in the DNS TXT record. (BAD)
-all — this informs the receiving end that only the listed mail servers are allowed to send mails. (GOOD)
~all — this informs the receiving server that any mail server not listed should be accommodated but not as a valid email, probably spam. Like a bad guest. (NOT SO GOOD)
DKIM
Domain Keys Identified Mail is the trust handler, allows the sending mail server to prove it’s the legitimate mail server by signing outgoing mail with a generated private key, the receiving end verifies this using a published public key of the same pair.
DMARC
Domain based Message Authentication Reporting and Conformance, this is quite the enforcer. Informs the receiving mail server what to do with an illegitimate email when both SPF & DKIM verification failed, also gathers statistical data to report to domain owners.
What to look out for;
- v= version, check DMARC
- p= informs what to do if verification fails
p=none tells the receiving end to take no action if verificated fails (BAD huh?)
p=quarantine tells receiving end to move illegitimate mails to spam
p=reject (kind of obvious)
A misconfigured mail server leaves space for mail spoofing, remember that email you got from your friend asking for a gift card because he is stuck in bad traffic lol. Yea, it’s probably not from him and it’s likely his mail wasn’t compromised either.
This is why email spoofing is dangerous, this technique is being employed by BEC groups (ironic isn’t it) to fool victims.
One of my favorite opensource projects for looking susceptibility to mail spoofing is here and the these are what it looks out for;
- SPF records with ~all or +all item
- No DMARC record or set to none
Okay, so you found a mail server domain that can be spoofed, what now?
Cyber criminals take advantage of this by masquerading as a legitimate sender without having to set up similar looking email address, I put together php script for this, all hail stackoverflow!
Such mails appears as it came from a legitimate mail server.
It’s always DNS, ain’t it?
Implementing SPF, DKIM & DMARC doesn’t make you hacker proof but it’s a right step in a good direction in improving security for all parties involved.
The risk of ignoring this leaves a chance for spearphishing which could result in the penetration of your mail workspace.
If you appreciate this research and look forward to more content like this, you can buymeacoffee by following the link below, gracias.
