Instructor: In this lesson,
we will learn about email security.
Email security protects email communications
from threats like phishing, spoofing,
and unauthorized access.
Email security concepts include sender policy framework
or SPF,
DomainKeys identified mail, or DKIM,
domain-based message authentication,
reporting and conformance or DMARC,
and secure/multipurpose internet mail extensions
or S/MIME.
SPF, the sender policy framework
is an email validation protocol
that allows domain owners
to specify which mail servers are permitted
to send emails on their behalf,
preventing email spoofing.
DKIM or DomainKeys Identified Mail
adds a digital signature to emails,
allowing recipients to verify
that the message has not been altered,
and that it truly comes from the legitimate sender.
Next DMARC, domain-based message authentication, reporting
and conformance,
provides a framework for email authentication
and policy enforcement
to protect against email based attacks
based on the results of SPF and DKIM checks.
Finally, S/MIME the Secure/Multipurpose
Internet Mail Extensions enhance email security
by enabling encryption
and digital signatures in email messages.
Let's learn more about SPF, DKIM, DMARC,
and S/MIME.
First, we have the Sender Policy framework or SPF.
SPF is a protocol
that helps prevent email spoofing.
SPF works by allowing the owner of a domain
to specify which mail servers are authorized
to send emails on their behalf.
When someone receives an email,
the receiving sender can check the SPF record
of the sender's domain
to verify if the email is from an authorized server.
This way, if an unauthorized server
tries to send an email pretending to be from that domain,
the email can be flagged or blocked.
Think about sender policy framework
like a guest list at a fancy event.
If you are hosting the fancy event,
you create a list of people who are allowed to get
into the event.
If someone shows up who is not on the list,
your security guard will not let them in.
Similarly, SPF creates a list of approved mail servers
that can send emails from your domain.
If an email comes from a server that is not on the list,
it is rejected or marked as suspicious,
helping to prevent email spoofing attacks.
SPF records are stored as text records
in the domain name system or a DNS,
and specify the domains
and IP address ranges
authorized to send emails on behalf of a domain.
These records identify which mail servers
are allowed to send emails for the domain,
helping to prevent email spoofing.
Each SPF record includes a policy symbol
such as the tilde, which is a soft fail,
or a dash, which is a hard fail.
These indicate how strictly the policy should be enforced.
Overall, SPF policy helps mail servers decide
whether to flag or reject emails from unauthorized sources.
However, SPF alone is not foolproof.
While it can block unauthorized servers from sending emails,
it does not prevent someone from forging the from address
in an email header.
This means that an email could still appear
to come from a trusted sender
even if the SPF check doesn't pass.
Additionally, if a legitimate organization
uses a third-party service to send emails on their behalf,
such as for surveys,
then those emails, though legitimate,
might fail an SPF check.
For this reason, SPF is often used
in combination with other protocols like DKIM,
the DomainKeys identified mail, and DMARC,
domain-based message authentication, reporting,
and conformance to provide stronger email security.
Second, we have DomainKeys identified mail or DKIM.
DKIM adds a layer of security
by attaching a digital signature to every outgoing email.
This signature is generated using a private key,
which only the owner of the sending domain possesses.
When the recipient's email server receives the email,
it uses the domain's public key,
which is stored in a text record in the DNS
or domain name system of the sender's domain
to verify that the signature matches.
If the signature is valid,
it confirms that the email has not been altered
during transmission,
and that it truly originated from the claimed sender.
This ensures the integrity of the message
and helps prevent email tampering.
So you can think of DKIM as a verification
of a fancy party guest's invitation at your fancy party.
Someone shows up with an invitation that looks suspicious,
you have a guest list, which is like SPF,
and a special stamp, which is like DKIM,
to confirm the invitation's authenticity.
So you take out your stamp
to check to see if it matches the one on the invitation.
If it does, you know the guest was truly invited
and the invitation hasn't been tampered with.
If it doesn't match, you know something is off
and they might not be who they claim to be.
Similarly, DKIM ensures that an email hasn't been altered
and that it comes from the legitimate sender.
So if the digital signature matches,
the email can be trusted.
Overall, the DKIM plays an important role
in email security
by preventing attackers from modifying emails
after they have been sent.
However, like SPF, DKIM is not perfect on its own.
While it does protect the integrity of the email,
it does not provide a full solution to email spoofing.
For example, while DKIM verifies that the content
of the email has not been altered,
it does not authenticate the from address
in the email header.
This means that an attacker could still forge
the from address to make an email appear
as though it is coming from a trusted sender,
even if the DKIM signature is invalid.
This is why DKIM is often combined
with domain-based message authentication, reporting
and conformance, or DMARC.
DMARC ensures that both SPF
and DKIM align with the from address,
allowing domain owners
to specify how emails should be handled
when authentication checks fail.
This combination provides a stronger defense
against emails spoofing by verifying both the sender
and the integrity of the message.
Third, we have domain-based message authentication,
reporting and conformance, or DMARC.
DMARC builds on SPF and DKIM
to provide a more comprehensive framework
for email authentication.
It allows domain owners to publish a policy
that tells receiving mail servers
what to do if an email fails SPF or DKIM checks.
For example, the policy could instruct a mail server
to reject the email, quarantine it,
or simply flag it as suspicious.
Think of DMARC as setting the rules
for handling guests at your fancy party.
If a guest shows up who isn't on the list,
which is like failing SPF,
or whose invitation is suspicious,
which is like failing DKIM,
then DMARC tells your security guard
how to handle the situation.
Should the guest be turned away, asked to wait outside
or let in with caution.
This policy-driven approach
helps ensure that only legitimate emails are delivered
and fraudulent ones are dealt with
according to the rules set by the domain owner.
DMARC also provides reporting features,
which allow domain owners to receive feedback
about how their emails are being handled
by receiving servers.
This reporting helps identify
potential email spoofing attempts
and allows administrators to fine tune their policies
to improve email security.
By using DMARC, organizations can take proactive steps
to protect their domain from being used in phishing
or spoofing attacks,
helping to maintain trust with their users and customers.
Fourth and last,
we have secure/multipurpose internet mail extensions
or S/MIME.
S/MIME is a standard that allows non-text based emails,
such as those containing graphics, videos,
or emojis to be sent securely over the internet.
So when we send emails with these elements, graphics,
videos, or emojis,
we use multipurpose internet mail extensions or MIME.
When we want to encrypt
or digitally sign these emails for security,
we use secure/multipurpose internet mail extensions
or S/MIME.
S/MIME relies on public key cryptography standards
to provide confidentiality, integrity, authentication,
and non-repudiation during an email transfer.
Protocols like secure socket layer
and transport layer security
do an excellent job of securing the connection
between a client and a server,
but they do not protect individual messages.
So once the connection is closed,
the messages are no longer secure.
This is where S/MIME comes in,
because it applies security measures such as encryption
and digital signatures to individual emails,
ensuring protection at the message level.
S/MIME is widely supported by most email clients,
including Microsoft Outlook, Apple Mail, and Gmail.
It secures emails by creating a unique session key
for every message sent or received.
So, if you and I wanted to exchange encrypted emails,
we would begin by exchanging public keys.
To do this, you would send me an email
that includes your public key
and sign the message with your private key
to confirm its integrity.
When I receive your email,
my email client would check your public key
with a certificate authority
to verify that it is legitimate.
I would also validate your signature
using the public key you sent me
to confirm that the email truly came from you.
Next, I would reply to your email with my public key
and sign my message with my private key,
allowing you to verify the authenticity of my message
just like I verified yours.
Once our public keys are exchanged and validated,
we can securely exchange confidential emails,
but instead of encrypting the entire email
with your public key,
my email client will generate a unique session key
for that specific message.
This session key is used to encrypt the email content
because symmetric session keys
are faster for encrypting bulk data.
So, I would encrypt the session key with your public key
and send both the encrypted message
and the encrypted session key to you.
When you receive the email,
your email client will use your private key
to decrypt the session key.
When the session key is decrypted,
you can then decrypt the message content that I sent.
Now, by signing each method
with our respective private keys,
we ensure that email maintains confidentiality,
integrity, authentication,
and non-repudiation throughout our entire communication.
While S/MIME provides excellent security,
it has a potential drawback.
For example, attackers could use S/MIME
as part of a social engineering attack
by sending encrypted malware in an email.
Since S/MIME encrypts the entire email,
including its contents,
the malware could go undetected
through boundary protection devices or email filters,
since they may not be configured
to decrypt and inspect email.
This is because without access
to the recipient's private key,
security devices cannot inspect, detect,
or block malicious content.
Therefore, when using S/MIME,
especially for external communications,
it's important to weigh the benefits of encryption
against potential risks.
So remember, email security protects communications
from threats like phishing, spoofing,
and unauthorized access.
Key email security concepts
include sender policy framework or SPF,
DomainKeys identified mail or DKIM,
domain-based message authentication, reporting,
and conformance or DMARC,
and secure/multipurpose internet mail extensions
or S/MIME.
SPF helps prevent email spoofing by allowing domain owners
to specify which mail servers can send emails
on their behalf.
DKIM adds a digital signature
to verify the email's integrity,
and to prove that it truly comes from the claimed sender.
Next, DMARC provides an overall framework
for enforcing email authentication
and handling fraudulent emails
based on SPF and DKIM results.
And finally, S/MIME provides encryption
and digital signatures to ensure the confidentiality
and integrity of individual email messages,
making sure that only the intended recipient
can read the content of an email,
and that the email has not been altered.