- In 18.3, we're gonna focus in on email security.
Now, secure email communications refers
to the use of various measures and protocols
to protect the confidentiality, the integrity,
and the authenticity of email messages exchanged
between parties.
Now, secure email communications
really require both server side
and client side configuration.
So what we're gonna be looking at here really
is server side.
Earlier when we looked at encryption and digital signatures,
we really looked at ways that we could secure our email.
We could use encryption
to make sure that we had confidentiality,
that if anyone else saw that message,
they wouldn't be able to read it, it would be encrypted.
And then we used digital signatures,
which had both hashing for integrity
and our digital signature
for authenticity and non-repudiation.
So here are three server side configuration options we have.
SPF, DKIM, and DMARC, DMARK,
The SPF stands for Sender Policy Framework.
Now it's an email authentication method designed
to prevent email spoofing and to protect against forged
or unauthorized use of domain names in an email address.
DKIM stands for DomainKeys Identified Mail,
is an email authentication method
designed to verify the authenticity
and the integrity of email messages.
And lastly, DMARC,
which stands for Domain-based Message Authentication,
Reporting and Conformance, that's a long name,
is an email authentication protocol that helps protect
against email spoofing and phishing attacks.
So we're gonna look at all three of these.
SPF, DKIM and DMARC, all these being server side
email configuration security options.
Now, SPF allows the domain owner
to specify which email servers are authorized
to send mail on behalf of their domain.
And that's accomplished by publishing a SPF record in DNS.
The SPF record specifies the mechanisms and the rules
for determining who the authorized email servers are.
Now, it can include an IP address, IP range,
or domain names of the authorized server.
Now, it also might have some additional information,
such as the policy for handling emails
that doesn't match the SPF record,
and that's known as an SPF policy.
But the goal here is that we wanna make sure
that the whole email domain knows
that only these particular servers, you know,
are authorized to send email from a specific domain name.
So here's the SPF workflow.
We're gonna have an SPF Record
and SPF Check and an SPF result.
The domain owner is gonna create an SPF record
and publishes it in the DNS settings of their domain.
Now the SPF record contains information
about the authorized email servers
that are allowed to send emails on behalf of that domain.
The receiving email server performs an SPF Check
by looking up the SPF record of the sender's domain.
It then compares the IP address of the server
that sent the email with the list of authorized servers
that have been specified in the SPF record.
Now, based on the SPF Check,
the receiving mail server determines
if the email is coming from an authorized server or not.
Now, it can take different actions based on the SPF results,
such as either accepting the email
or marking it as suspicious
or just like totally rejecting it altogether.
Our second option, DKIM, allows a recipient
to check if an email was sent by the claim sender,
and if it's been tampered with during transmission.
The DKIM works by adding a digital signature
to the header of the email.
Now, that's not the user's digital signature,
it's the DKIM signature.
Now, the signature is generated
using public key cryptography
and can be verified using the public key stored
in the sender domains, DNS record,
which is stored as a text record,
because remember that a key is just a string
so it's stored as a text record.
So let's go through a DKIM workflow.
We have an email digitally signed
by the email server using the DKIM private key.
The DKIM signature is added to the email header.
Next, we have DKIM verification
by the recipient email server
looking at the DNS text record.
And then we'll have the DKIM result.
And that will tell us, right,
whether the email is proven to be tamper free or not.
And our third option is DMARC.
DMARC allows domain owners to specify how email receivers
should handle emails that fail authentication checks,
and it allows them to also receive feedback
on the emails using reporting mechanisms.
Now, the primary goal of DMARC is to combat domain spoofing
and to protect the integrity of email communication
in the aggregate.
Now, DMARC does require either the implementation of SPF
or DKIM or both for email authentication.
SPF verifies the sending IP address
or DKIM verifies the integrity of the email content
and the sender's domain.
So here our DMARC components.
We have a DMARC policy, policy actions,
and then reporting mechanisms.
Now, the DMARC policy specifies
how the recipient's mail server should handle emails
that either fail an SPF and/or a DKIM check.
Now, the email domain owner publishes the DMARC policy
in their DNS record.
And the DMARC policy actions could include none,
meaning it's just in monitoring mode,
quarantine, which is marking the email
as potentially suspicious,
or reject, which is outright rejection of the email.
And the DMARC reporting mechanisms provide or email domain,
right, the original owners, feedback including details
about successful and failed authentication attempts.
So let's take a look at some encryption options.
You know, the goal of email encryption
is that only the intended recipient can read the email.
So we really have two approaches.
We have server-to-server encryption
and end-to-end encryption.
Server-to-server encryption establishes
an encrypted connection to protect the email data in transit
between the sender and the recipient's email servers.
Where end-to-end encryption ensures
that the email message is encrypted on the sender's device
and can only be de-encrypted by the intended recipient.
That means it not even the email service provider
has access to the decrypted content.
Let's take a look at some secure email protocols.
TLS.
Oh, that should sound familiar.
And S/MIME.
TLS or Transport Layer Security
is a cryptographic protocol that we can use
to encrypt communication between our email servers
during transmission.
Where S/MIME, Secure/Multipurpose Internet Mail Extensions
is a standard for securing email messages
that provide for encryption and digital signatures.
So server-to-server and end-to-end.
That, my friends, takes us to a three second challenge.
Five challenge questions, three seconds each.
Let's do it.
Email authentication method designed to protect
against forged use of a domain name in email messages.
One, two, three.
It's gonna be SPF or Sender Policy Framework.
Number two.
Allows email domain owners to specify how email receivers
should handle emails that fail authentication checks.
One, two, three.
That's gonna be DMARC
or domain-based message authentication, reporting,
and conformance.
Number three.
Allows the recipient to check
if an email was indeed sent by the claim sender.
One, two, three.
And that's gonna be DKIM,
which is DomainKeys Identified Mail.
Number four.
This record states the authorized email servers
that are allowed to send emails.
One, two, three.
That's the SPF record.
And lastly, number five, using this encryption approach,
the email message is encrypted on the sender's device
and can only be decrypted by the intended recipient.
One, two, three.
That's gonna be end-to-end encryption.
Right, that brings us to a security and action
so you can apply your knowledge.
And this one's about email security.
To enhance your organization's email security,
you are recommending TLS encryption
and the implementation of SPF records and DKIM.
The first question you're asked
is why do you need all three?
It's like, isn't just one of them enough?
So my question to you is, how are you gonna respond?
TLS encryption, SPF records, and DKIM,
why do you need them all?
Go ahead and put me on pause
and think about what your approach is gonna be.
Well, TLS, DKIM, and SPF each address different aspects
of security.
TLS provides encryption to enforce confidentiality.
DKIM allows the recipient to check
if an email was indeed sent by the claim sender
and if it's been tampered with during transmission
SPF provides a way to verify the authenticity
of the sender's domain by ensuring
that the email is actually sent from an authorized server,
that implementing SPF protects your domain's reputation
and reduces the chance of your domain being used
for spoofing or phishing.
So all really good things to use.
You can use them, you know, in concert with each other.
They all handle or address different aspects of security.
So understanding that, explaining that
being able to implement that,
that, my friends, is security and action.
There's your word cloud.
Not particularly big
but a lot of really important components,
a lot of important stuff here.
So make sure you understand all of it before you move on.
If not, go back in through the lesson.
And when you're ready,
know I'll be waiting for you our next lesson.