We've had an influx of questions about Email Authentication and how it works following on from our last blog post. As such, we thought it appropriate to demystify how it all works and make it that bit easier to understand how it all ties together, here goes. Before we start, bear with us, there's going to be a bit of tech-speak to start with, but we'll simplify it shortly after.
We're going to talk through some of the key parts, that being
SPF
DNS
DKIM
DMARC
SPF
SPF stands for sender policy framework. If you’re the owner of a domain, SPF is a validation protocol to define a list of authorised email senders that are authorised, stressing the term authorised to send emails on behalf of your domain.
So take our domain that we use for emails that being @etg365.co.uk our SPF policy outlines that Microsoft 365 exchange online is our authorised email sender, and any affiliated third party platforms that we use. So our finance system, our email marketing platform etc.
Here's the key thing that every organisation needs to understand and why SPF is so important:
If you don’t define your SPF records, that means unauthorised sources could send on behalf of your domain
Therefore, step one to prevent unauthorised sources impersonating you and your colleagues is to define these records.
DNS
Then we move onto DNS, which stands for Domain Name System. Owners of a domain then need to publish their SPF records in their DNS. This is to specify which servers are legitimate senders of emails originating from their domain.
So when you receive an email in your inbox, your email server (whether that be hosted with Microsoft or another means) is checking the SPF record to ensure that this email has come from an authorised source.
DKIM
Now we move on to DKIM, which stands for DomainKeys Identified Mail. What DKIM does is to add a digital signature to outgoing emails.
It provides a further authenticity check as it allows the recipient of that email to verify that the email has come from a legitimate source and that it hasn’t been tampered with in transit.
So here’s where it all comes together, that being SPF, DNS and DKIM. What DKIM will do is use cryptographic keys to sign outgoing emails. When the recipients server receives that email, the email server/provider then verifies the signature made by DKIM. It searches for the public key that is published in the senders domain DNS records.
Now Let's Simplify
This all sounds like tech-speak, so let's demystify it somewhat. Let's think of this as an analogy, think about when you use your passport at customs when you go on holiday.
Think of this as
SPF = Passport
DNS = Passport Records Database
DKIM = Passport Encryption
So the SPF records are like your passport. Our passport highlights some key information on us as an individual that’s says only I can travel using this document. We have set criteria that we specify on our passport to prove it’s us to prevent someone else travelling under the guise of impersonating us.
But, a passport in isolation is pretty useless. On its own, it can easily be copied or mimicked if the document isn’t verified.
That’s why in real life we have an extra layer of protection with a centralised database. Every single persons passport details are stored in a passport database. This is used for further proof of authenticity, a level of scrutiny to assess a persons passport beyond the basic visual check.
This extra layer of protection is to prevent the legal document being easily copied and the person being impersonated. This Database acts as a means to verify the details and their legitimacy when you arrive at customs. This is just like publishing SPF records to your DNS. Where DNS is represented here by the passport database.
But then to take this one step further, greater protection is added to your passport with unique encryption. Something that you may not be aware of is that your passport has a printed image of the passport holder on page three which acts as an added protection layer. There lies invisible data which only becomes visible when observed using a decoding lens that is integrated into the Biographical Data page. This is just like DKIM, a digital signature to justify authenticity.
Hopefully the analogy helps to understand how SPF, DNS and DKIM all work with each other, just like the controls adopted for your passport. Now we'll jump to the compliancy standard that is DMARC. Again this part sounds a bit like tech-speak but you're now a master of SPF, DNS and DKIM so it should be easier to digest and understand.
DMARC
Now onto DMARC which stands for Domain-based Message Authentication Report and Conformance. So it’s an authentication standard where you comply with the standard to a certain degree or you don’t.
What we should say is that DMRAC is a really good thing, DMARC compliance acts as an extra protection layer for organisations. To explain this protection, if you are a domain owner, when you’re DMARC complaint, you’re instructing email receivers as to how they should handle unauthenticated emails sent from their domain.
So, let's say you’re compliant with DMARC. Then if someone attempts to impersonate your domain, when that impersonation email is received it’ll be blocked. DMARC protects you, it outlines that this email hasn’t come from an authentic and authorised source, and therefore that email would fail authentication.
When an email fails authentication, the domain owner can specify three possible outcomes for that email, those being:
p=none - none policy - email is delivered as usual without additional action
p=quarantine - Quarantine policy - email is marked as potentially suspicious - sent to spam or junk
p=reject - Reject policy - the email is rejected outright and not delivered to the recipients outbox
So it’s great if you’re DMARC compliant as you’re protecting your domain and brand from being spoofed. If you’re not, it can be a risky gamble to take. Threat actors can be impersonating anyone in your organisation without you even knowing, without even accessing your email server. It’s a sophisticated attack with minimal effort, you don’t even need to be hacked to be a victim, you just need to be non compliant with DMARC.
Call to Action
Many organisations don't have a lot of time to act on this. If you'd like to assess your domain score in line with DMARC standards, or look at remediation steps to become compliant then speak to one of our consultants at EquiTech Group:
Phone - 01604 346 444
Email - info@etg365.co.uk
コメント