Email Spoofing explained

How email spoofing works and how to protect from it.

Email spoofing is usually the first step (or a proven working step) into a network intrusion, data breach, ransomware, or any other cyber attack. Therefore, this is a very important topic to have a clear understanding of what it is, how and why it works, and how to be protected against it. In my experience, I have noticed this issue is usually disregarded or not taken as much as a serious problem by organizations. I will try to discuss this issue in the following post in more detail, by using analogies with real life postal mail processing and showing how it is compared to digital email delivery & spoofing.

How email sending works (SMTP)

The standard protocol that is used for sending emails on the Internet is the SMTP — (Simple Mail Transfer Protocol). Most email agents use this protocol to send emails through different servers. So, similar to other protocols, SMTP uses a specific way of communication and has its own message format. I will try to explain by trying to not oversimplify it and lose context, in the listed steps:

1. The email sender (client) has to connect on the specific TCP port (usually port 25 is well known port — encrypted version uses port 465) on the email server (the mail service which actually process & deliver the email).
2. The client can use a set of commands standardized by SMTP protocol to communicate with the server. Some of such commands relevant to this topic are: HELO, AUTH, MAIL FROM, RCPT TO, DATA, QUIT. The usual sequence of commands a client would use, would be the same order as they are written.
3. HELO command is used for identifying yourself to the server.
4. AUTH command is used to authenticate yourself (verify your identity) to the server by using any sort of credentials.
5. MAIL FROM command is used to tell the server from whom the email is sent.
6. RCPT TO command is used to tell the server to whom to send the email.
7. DATA command will define the whole email data which will contain the actual message the receiver will see.
8. QUIT command (as by its name) is used to terminate the connection with the server.

Now, for better understanding, I like using analogies how the same process and steps above would look in real life mail sending:

1. The person sending a mail letter (Bob), would go to the local post office, on the mail processing department (supposing there are no auto/mailboxes in the post office — as actually to some post offices), where it is an employee called Alice.
2. Bob can use human language to communicate with Alice and will tell her that he wants to send mail to a friend of his.
3. HELLO (or similar) would be the usual word to start the conversation.
4. ID Verification could in some cases be required by Alice depending on what Bob would like to send (eg. if he is a licensed gun dealer).
5. Bob will tell Alice who is sending the mail, so the post office could properly process and track the package.
6. Bob will tell Alice to whom to send the mail, so the post office could properly process and track the package.
7. Bob will hand-over to Alice the mail or package he wants to send.
8. Bob can say “Goodbye” or “Have a nice day”, and leave the post office.

As you can see, both processes are very similar to each other, without diving into much technical details. Now the steps 5, 6, 7 are most important to focus as they are related with the topic of this post. From step 5 & 6, the MAIL FROM and RCPT TO are part of the so called SMTP Envelope. This means that the SMTP server will check those data to know how to process the email. While from step 7, the DATA command specified the content of the message sent. This DATA is defined by Message Header and Message Body. The header part contains the From, To, and Subject fields. While the Body contains the actual email text (or HTML) message. The header and body should be separated by a new line (similar to HTML). Find below an example of the whole communication process of sending an email over SMTP where the lines starting with S (green) are from the server and those with C (black) are from the client.

Note: AUTH command is not used in the example below, yet that does not look anything different from the below process.

S: 220 smtp-server.com ESMTP Exim
C: HELO company.com
S: 250 Hello company.com
C: MAIL FROM: <sender@company.com>
S: 250 Ok
C: RCPT TO: <recipient@othercompany.com>
S: 250 Accepted
C: DATA
S: 354 Enter message, ending with “.” on a line by itself
C: Subject: sample message
C: From: sender@company.com
C: To: recipient@othercompany.com
C:
C: Greetings,
C: This is just a test message.
C: Bye
C: .
S: 250 OK
C: QUIT
S: 221 www.company.com closing connection

Again, following the same analogy of the real-life mail sending. As a mail sender, when you send a letter or postcard for any occasion, you usually would use a standardized format. The format would probably have the header information written on top of the letter, by saying from who, and to whom is dedicated. After that, an additional title as a subject, followed by a new line space with the actual text message. You would fold this letter into an envelope, where again you write from who it is and to whom to send it (required by the post office). Deliver the envelope to the post office to send your mail. As you may have noticed, the letter represents the DATA command (message header + message body) on SMTP protocol. While the Envelope information represents the SMTP Envelope (MAIL FROM + RCPT TO). Find below a visualized representation of Envelope and Letter in SMTP.

Envelope & Letter on SMTP.

The importance here in relation to email spoofing, is to distinguish the “Mail From” and “From” values. The first, will be only used by the SMTP server (not visible to the email receiver on UI), while the second will be used to be displayed to the email receiver as From whom the email was sent. That would be the same as saying the Post office will only care about the information you put in the envelope, while it does not care with the actual letter content (otherwise it would be a privacy issue). And the mail receiver will usually care about the letter content and not the envelope itself.

What is email spoofing?

Email spoofing is sending emails with a forged senders address. Basically, sending an email to anyone, by claiming to be someone else. An example would be, an attacker being able to send emails to anyone, by spoofing the “Mail from:” or “From:” attributes, and the email would show up on victims inbox, appearing to be sent from the forged address for example: ceo@somecompany.com.

This feature has been and is actively exploited for different purposes. It can start with a simple reason for prank, spam, phishing etc.

• Pranksters use spoofing as it simply allows them a very convenient way of pranking others.
• Spoofing was used for SPAM (mostly unwanted advertising emails), because it was a good way for bypassing different filters that email servers might apply. When a spammer email is identified, it can be blacklisted so all emails sent would automatically go to SPAM (or JUNK) folder. Therefore, this was a good way to change the emails frequently by spoofing them (especially on domains with good reputation).
• Phishing usually goes along with spoofing emails. This allows attackers a very advantageous way of luring their victims into something they want. So then, posing as any sort of legitimate authority or persona, will request the victims for sensitive information. This form of attack was very common lately on different small businesses. In which the attacker posing as their cooperative (or 3rd party) business, used phishing to ask the business owner/finance person (victim) to make the next money transfer for the goods on a different bank account (an account operated by the attacker), thus stealing the money.

Sometimes you intentionally want the ability of spoofing! Really?

Email spoofing should not necessarily be related with criminal or malicious activities. Many times you may want to have spoofing enabled, or better to say, enabled for certain applications & servers only. In many modern applications, especially if they have more complex architecture & infrastructure, the project owner can decide to delegate certain services to other 3rd parties. That for many reasons like marketing, performance, or so the development focus would be concentrated on the main application features being built. Generally, the email sending services would be one of the features to be outsourced. Mostly, since there are many good and reliable, cloud email delivery services, which are very cost-effective. A few examples are: Amazon SES, SendGrid, Mailgun, Google Cloud etc.

Basically, you intentionally allow another 3rd party server to be able to deliver (sometimes also receiving) emails, using your domain, on your or other users behalf. And that, not just a few emails that are associated and belonging to no one (eg. info@company.com), but also spoofing someone else’s name (eg. john@company.com). So, this means, you intentionally want some other server or app to be able to spoof your emails. Of course not anyone out there — duh!

Surely, this process of giving others the authority of delivering emails on your behalf “should” be in a controlled and safe way. For example, not everyone having access to the 3rd party server will be able to send emails with your domain. Obviously, many other authentication & authorization controls are applied. Usually, that would start by the 3rd party service asking you to prove domain ownership (for more, research the documentation of the example services mentioned above).

Other than using 3rd party services, corporations may have different branches on different locations, sub-companies, sub-domains, that operate independently, but which still are interconnected. In these cases, the owner would want the ability on their apps & servers to send emails under different domains they possess. There can also be multiple email servers they own. On top of that, including the 3rd party services. Many times this process will be a hurdle for companies to manage, and it could end up by misconfigurations that enable spoofing on overall or not applying proper protection. Thus, this would pose a security vulnerability.

Should I care?

Short answer: YES!

This is usually the initial step to a cyber-attack on different types and motives. You can be a victim of email spoofing in two ways:

• The attacker spoofed your email and used your authority over someone else.
• The attacker spoofed the email of someone else and used their authority over you.

In both cases, it can affect one badly.

In my experience, I have mainly seen email spoofing to be used a lot for stealing credit cards, along with many other things. The scam goes like below:

• The attacker craft a spoofed email supposedly originating from info@paypal.com (or any other large bank authority).
• The email would be “professionally” written (sometimes), and would use any sort of reason to cause panic on the users to verify their credit card information (eg. we had our data lost, please verify the information), and would include a link pointing to a scam page the attacker created themselves. The page would either contain a login form, or a form for “verifying” the credit card.
• The attacker sent that email to a large email list, which was crawled over websites (or other different techniques).
• A percentage of those emails were truly users or customers of Paypal (or any other bank).
• A percentage of those real users, would fall into the trap of the attacker and would actually provide the information asked.

Ironically, while writing this article, I just got a similar email spoofed as supposedly from Paypal (see screenshot below):

Spoofed Paypal email for stealing credentials.

I think everyone has seen some sort of such emails (especially, since you are reading this). Surely, there are many other scenarios on how email spoofing is used for malicious and criminal activities. Not always the attackers are necessarily looking for credit card information. Many times they are also looking for other personal (valid) information which they would use in other criminal activities (eg. identity theft). Thus, I truly believe that everyone should care about this phenomenon.

How email spoofing works?

Recalling from the previous section “How email sending (SMTP) works”, protocols can be abused if not properly protected or poorly designed and/or implemented. Similarly this can happen when sending emails. The SMTP protocol has two fields where the sender is specified, the “Mail From” & “From” values. One is in the SMTP Envelope and the other in DATA — SMTP Header. Both fields can be spoofed (or forged). For example, an attacker can spoof emails of company.com domain by using an SMTP server that they can access. In the best scenario the SMTP server is owned by an attacker, supposedly with domain attacker.com. The process would be similar to when sending emails as by the steps below:

1. The attacker will connect on their SMTP server attacker.com (or any other they have access) on port 25.
2. HELO command will be used for identifying to the server.
3. AUTH command might be used to authenticate to the server.
4. MAIL FROM command will be used to spoof the email sender by impersonating someone on the victims domain (eg. Mail From: ceo@company.com).
5. RCPT TO command will be used to tell the server the victims email (eg. bob@company.com).
6. DATA command will define the whole email data, and will also contain the “From” value in which the same email is spoofed again (as in step 4).
7. QUIT command is used to terminate the connection with the server.

Now, see the same steps applied in an actual server:

S: 220 attacker.com SMTP Exim
C: HELO attacker.com
S: 250 Hello attacker.com
C: MAIL FROM: <ceo@company.com>
S: 250 Ok
C: RCPT TO: <bob@company.com>
S: 250 Accepted
C: DATA
S: 354 Enter a message, ending with “.” on a line by itself
C: Subject: Download this urgently
C: From: ceo@company.com
C: To: bob@company.com
C:
C: Hi Bob,
C: Please download this urgently: https://some-malicious-link.com
C: Regards
C: .
S: 250 OK
C: QUIT
S: 221 attacker.com closing connection

As you can notice, the only difference from sending a legit email is actually changing the “From” and “Mail From” values to the email we want to impersonate (spoiler: spoofing will work with just misusing the “From” value as well). An obvious and rational question to this is:

Why does the SMTP server not have any mechanism to prevent sending forged email?

(Basically, the authentication process we have when we use our emails through the web on a daily basis.)

The answer is, it usually does have. For example you cannot do the same example above in a Gmail SMTP server! The SMTP server of Gmail (or any well known email server) will require authentication before you are able to send an email as someone else. And if you try spoofing it, you will get error messages and the email will fail to be sent. So Gmail will not allow you to send emails through their server by forging the senders email.

Then how do attackers still go through? That is because the internet is open and allows anyone to be an SMTP server (or whatever other server). So, an attacker can implement their own server, or find another server without authentication mechanisms in place (or poorly implemented), and use it to spoof emails. There are even free & public servers which intentionally allow you to send emails by spoofing the sender (eg. https://emkei.cz).

Therefore, the issue of email spoofing should be treated as an issue of trust of “who the email sender/courier is”. The responsibility for checking & deciding that, should be on the Email Receiver server. Surely, there exist mechanisms that can be implemented for applying such trust checks in a safe manner, which we will discuss later.

There are two ways to deliver spoofed emails:

• Using your own SMTP server
• Using others SMTP server

When the attacker implements its own SMTP server, it has full control over it. It means that the attacker can configure any parameters in such a way that it will send spoofed emails appearing to be as legit as possible (tampering the SPF, DKIM, DMARC values). Also, a drawback for this is that when implementing your own server, there is some effort required for building a good reputation so other email receivers will recognize emails coming from your server as legit.

On the contrary, when using other SMTP servers, you may lack control over specific configuration of the server. Also, they should be aware of not leaving any footprints as they might be traced back. However, usually an attacker would use others SMTP servers when they are misconfigured, so it would take advantage over that (no authentication and SPF protection or “allow all” rule). In addition, the attacker does not have to put effort into building a good reputation for the server as it might already have.

There are two ways of spoofing emails:

• Spoofing the “From” value.
• Spoofing both the “From” and “Mail from” value.

When spoofing the “From” value, this means the attacker is only tampering with the Message Header from the email DATA (the actual email content), and not touching the “SMTP Envelope”. However, this would be quite enough as the “From” value is reflected on the receivers UI screen on email Inbox. While the SMTP Envelope information is not visible on UI almost always. Therefore, the victim might see the spoofed “From” email sender, as a legit one. Anyway, having a different email sender on the SMTP envelope from the one in message DATA, might raise suspicions in some email providers. Gmail for example, in these cases, will also add a short text next to the “From” value on UI saying the domain origin. For example see the screenshot below:

Made up email (not real) for demo — UI of Gmail showing the domain origin.

The other option is spoofing both the “From” and “Mail from” values. This means the attacker is tampering with both values, the SMTP Envelope and Message Header data. In such an attack, the email will be received by claiming the origin to be from the spoofed domain both in UI screen and the email source (envelope). Therefore, this would be an even better method of spoofing a legitimate sender as the email providers will not consider it as suspicious. That would work though just in case the spoofed domain does not implement any protection like SPF or DMARC (will explain later).

Using the postal mail analogy, spoofing the sender when sending a mail letter would be similar to spoofing the email.

There are two options to deliver spoofed sender mails by post:

• Sending the mail yourself or your own “postal service” (or hiring someone to send it).
• Using a legit postal service to send the mail.

Can you spot the fake postman? — story behind

If the attacker decides to deliver the mail themselves, they can decide on all the sending parameters, like when, where and how (drop it, person on the door etc.) to send the mail. The downside of this is that the attacker would lack the official stamps used by the legit postal office and mailman (unless being forged). So this might raise suspicions on the mail receiver in regards to trusting the mail.

The other option is for the attacker to use a legit postal service to deliver the mail. This would not give full control in terms of the parameters to delivering the mail as the post office would decide for them (at least some of them). Additionally, the post office (sometimes) might require some sort of identification or personal information. Also, just by going to the post office to send the mail, the attacker would probably be caught on any surveillance cameras which can be used to trace them back. Yet, delivering the mail by a trusted organization would be more trustful by the receiver. And an attacker can pick some local mailing service which would not ask many questions.

There are two ways of spoofing the mail sender:

• Spoofing only the mail letter details (sender information on letterhead)
• Spoofing both the mail letter details and envelope return address details.

When spoofing only the mail letter details, this means the attacker is only tampering with the letter content, and is forging the message by claiming to be someone else. Usually, the attacker would add some fake logo, signature, and address details of the person/company claiming to be. This could be pretty effective to the victim if it is crafted well enough. Still, if the envelope information (return address) belongs to the attacker for real, it would pose a high risk of being caught.

The other option is spoofing both the mail letter details and the return-address information (or data on the envelope). This means the attacker is forging both data content, in the letter itself, and the data required by the post office (return address) when sending the letter. In such an attack, the mail letter will be sent by claiming the origin to be from the spoofed persona as well the address in the envelope and the letter. Therefore, this would seem more truthful in the perspective of the victim.

How to protect my domain from email spoofing

Email spoofing is a historical problem. As soon as the email protocol started, soon after the email spoofing technique began to be exploited in the wild. Until some years ago, there was no complete solution to this problem. Specifically, there was no standard protocol defined to be more protected from spoofed emails. Rather, each email provider implemented their own security defense mechanisms, internally, and many times closed source. Even though today’s standard protocols exist, there are still additional unique internal mechanisms applied by each email vendor.

As of today, we have three main mechanisms that we can use to be protected from email spoofing. They are the SPF — Sender Policy Framework, DKIM — DomainKeys Identified Mail, and finally DMARC — Domain-based Message Authentication, Reporting and Conformance. DMARC is the latest and most important one as this will close the loose end of this problem. In the subchapters below, we will discuss each of them how it works and compare it with the supposedly real postal mail system process.

SPF — Sender Policy Framework

SPF is an email authentication mechanism that is specifically designed to detect and prevent email spam & spoofing. It was first publicly mentioned in 2000, but for some reason it was ignored. Until finally in April 2014 it was proposed as a standard on RFC 7208.

This works by allowing any domain to specify a list of legitimate email senders (servers) by their domain or IP. The list is defined as a TXT record type on the DNS server for that domain. So then, the email receiver, will check the SPF record list by doing an nslookup query, and compare it against the IP address (or domain) from where the email was received (origin). If the IP from the origin is also listed on the SPF list as a legitimate sender, then the email is valid and will be allowed on Inbox. Otherwise, it will be rejected or received in the junk/spam folder (depending on the SPF configuration).

An example scenario would be, company.com domain has configured an SPF list, in which the only allowed email sender is this IP — 40.50.60.70. Now, supposedly a spammer tried to send a malicious email by spoofing that domain since it has a good reputation. The spammer will send an email to bob@gmail.com, from their own server with IP — 50.50.50.50 (attacker.com) and will set the “Mail From” parameter in SMTP Envelope as ceo@company.com. When Gmail (Bob’s email provider) receives this email, it will check the SPF list of company.com and will see the IP 40.50.60.70 as the only legitimate sender. While the email on Gmail was received from a connection with an IP — 50.50.50.50 (attackers IP). Gmail will compare these IP’s and will notice that the IP address from where the email came from is not a legitimate sender of this domain. As such, it will either reject the email completely (skip the users mailbox), or will show it on the junk/spam folder (depending how SPF was configured on company.com).

SPF protocol workflow.

However, an important fact is that, as specified by RFC 7208, the SPF will only check the SMTP Envelope “Mail From” domain value to validate the email authenticity and it does not check the “From” value on the mail content. This means that the SPF will prevent spammers to misuse your domain reputation as the attackers cannot claim to be legitimate email senders of your domain. Yet still, they can implement and use their own email delivery server, with their own SPF record, and send legitimate emails with the “Mail From” value of their domain, EXCEPT spoofing the “From” value of the email content (see previous chapter of how spoofing works).

Therefore, the SPF mechanism is not the full-proof solution against email spoofing as it will only protect the server from being misused as an email deliverer, but it does not protect the victim from receiving emails with fraudulent “From” email value.

SPF protocol bypass workflow.

If you are not aware in case you have set proper SPF records on your domain, or rather you want to check someone else’s domain, you can simply get them on terminal by using the command below:

nslookup -type=txt [DOMAIN TO TEST]

Lookup SPF records for a domain with “nslookup” command.

Otherwise, if you prefer a GUI version, you can look that up by using this great online tool:
https://mxtoolbox.com/spf.aspx

Additionally, you can use this other GUI online tool, to generate proper SPF records in case you still did not add any for your domain:
https://mxtoolbox.com/SPFRecordGenerator.aspx

Now, going back to our analogy comparison! Each postal service has their own ways of delivering the mail. Either it being by mailman, motorbikes, cars, trucks, trains, ships, or airplanes, depending on the location where the mail has to be delivered. However, every one of them has their delivery transportation tagged and labeled with stickers and logos, and no other party can deliver their mail except with some sort of agreement. A well known mail postal service, can be spoofed by a malicious by imitating the same mail delivery transportation, the mailman wearing a similar official uniform, and/or adding the same labels and logos to their mail delivery vehicle. So when the other party receives the mail it will trust it just by seeing the visual similarities.

However, if a mechanism like SPF is implemented, it could add a layer of protection. That would work for example, when the postal services would publicly announce a list of vehicles with specific license plates as the only authorized vehicles to deliver the mail (similar to SPF list). When the mail receiver would get the mail, it will check the license plates of the vehicle they received the mail from, and will compare it with the publicly announced list of the postal service. If that license plate number is in the list, the mail would be considered as valid otherwise, it would be probably malicious. This would make way more sense on the mail delivery from one post office to another rather directly to a mail recipient.

But a malicious person can also forge the license plate, then what?!
That would be similar to saying that someone can also spoof the IP address when sending an email. I am not going down that rabbit hole 😄.

The SPF bypass mentioned earlier, in this analogy would be the same as the attacker would start up their own legitimate postal company and then misuse it by spoofing mails.

DKIM — DomainKeys Identified Mail

Similar to SPF, DKIM is another email authentication mechanism that is specifically designed to detect and prevent email spam & spoofing. It is defined as an internet standard in RFC 6376, in September 2011 with some additional updates later.

DKIM mainly works by taking advantage of cryptography. Specifically, it uses digital signatures. Digital Signature is a cryptographic method which guarantees that the contents of a message have not been altered in transit. In other words, it preserves message integrity as a protection against Man-in-the-Middle attacks. You can read more about how Digital Signatures work in my previous blog about Public-Key cryptography.

In addition to that, using digital signatures can help against spamming & spoofing as well. DKIM works by enabling a domain to specify a public-key as a TXT record type on their DNS server. While using the private key (counterpart of the public key) to digitally sign (hash + encrypt) the content of all emails that are sent. So then, the email receiver, will note the public key by an “nslookup” query, and validate the integrity of the email received, by using that public key. This way, if the message was tampered in transit it will get easily caught. That is because the attackers would not be able to generate the same email signature, since they do not have the private key (unless the private key is stolen, of course). You can see below, a visual workflow of DKIM for better understanding.

DKIM protocol workflow.

Similar to SPF, any email receiver will check the SMTP Envelope “Mail From” domain to validate the authenticity of the email by checking the public key listed on DNS records for that domain. DKIM will prevent any man in the middle attackers from tampering emails in transit and/or spoof emails using the “Mail From” header, as the attacker cannot digitally sign the email content as supposed to, by using the private key of the domain. Yet still, they can implement and use their own email delivery server, with their own DKIM record, and send legitimate emails with “Mail From” value of their own (attackers) domain, EXCEPT spoofing the “From” value of the email content (see previous chapter of how spoofing works).

Therefore, the DKIM mechanism is not the full-proof solution against email spoofing as it will only protect against email manipulation on transit, but it does not protect the victim from receiving emails with fraudulent “From” email values.

DKIM protocol bypass workflow.

If you are not aware in case you have set proper DKIM records on your domain, or rather you want to check someone else’s domain, you can simply get them on terminal by using the command below:

nslookup -type=txt [SELECTOR]._domainkey.[DOMAIN TO TEST]

Lookup DKIM records for a domain with “nslookup” command.

The selector is a specific keyword defined by each domain owner. You can get the selector word from the email source of the email you received. You can try that on any email you have received with DKIM on Gmail, by clicking on “Show Original” (email source), and look up the “s” parameter (written as “s=[keyword]”), under the “Authentication-Results” for DKIM. See an example of this in the screenshot below.

The “selector” keyword of DKIM in email source.

Otherwise, if you prefer a GUI version, you can look that up by using this great online tool:
https://mxtoolbox.com/dkim.aspx

Comparing DKIM with the postal mail services, it would be quite similar to the comparison with SPF (see previous subchapter). However, here the DKIM would be represented with stamping and signing from the postal office on each mail letter/box. In particular, the post office would be using signatures/stamps (which they actually do) to put integrity on the mail. Similarly to SPF, stamps/signatures can be forged of course. However, the same technique would still work, the attacker can start their own postal company and misuse it to spoof mail, by using legitimate stamps/signatures, and legitimate license plates for their vehicles to deliver the mail.

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC is yet another authentication mechanism for emails to protect against email spoofing. It is built upon the two previous protocols, the SPF and DKIM. A draft specification started in January 2012, while gradually started to get adopted widely by more corporations including the well known email providers. In March 2015, it was classified as informational non-standard RFC 7489.

This protocol is designed to work by specially checking the author “From” email message header. Similar to the previous mechanisms, the DMARC configuration is set in DNS as a TXT record. Then the email receivers will read its configuration accordingly. The main difference of DMARC with the other mechanisms is that it will apply the verification of the domain used in the “From” message header as opposed to the “Mail From” field on SMTP envelope.

First the email receiver will extract the domain from the email address used in the “From” header. Compare that domain with the origin domain (from which the email was received — technically will check the DKIM domain & Envelope “Mail From” domain). If both domains match, then the mail server will potentially continue checking against standard SPF and DKIM (depending if the origin domain is configured to use them). Otherwise, if DMARC fails (email in “From” header is spoofed), depending how DMARC was configured, it can either reject the email completely, accept it in quarantine (spam/junk), or accept the email regardless of that. In addition to fraudulent email detection, DMARC also has reporting capabilities. This means that for any detected spoofed email, it can be configured to report back to the original email sender (or any configured email) for any non conformance email message.

For example, supposing that company.com has the DMARC mechanism setup. Now, an attacker will spoof an email by using that domain as a sender. But for better results of not being detected, the attacker is using their own SMTP server to deliver emails, which is running under the domain attacker.com. Additionally, it is spoofing only the domain in “From” email header field, and not spoofing the “Mail From” domain in the email envelope for better results. This way the attacker was able to properly bypass the SPF or DKIM mechanisms before, since they do not check the domain in “From” email header (see earlier explanations). By using their own server, the attacker will send an email to victim@gmail.com, with “Mail From” set to server@attacker.com (not spoofed), and the “From” email header to ceo@company.com (spoofed email).

When Gmail receives this email, it will check the DMARC configuration of company.com because it was used in the “From” header. Then will notice the policy set to “reject” — not accept spoofed emails. After that, it will get the origin domain (domain used in “Mail From” SMTP envelope), which is attacker.com and will compare that with the domain used in “From” email header, which is company.com. Since the domains differ, the DMARC results will fail, so Gmail will reject to accept this email, and the victim will never see the spoofed email in their inbox. In addition, Gmail will also report back with these results to the email which was configured in DMARC configurations for reporting.

In case the attacker decided to spoof the “Mail From” email domain as well, the DMARC check might pass, but the SPF and/or DKIM will fail, which again would result with email rejection (as explained in the workflow diagram below).

DMARC protocol workflow

As visible from the diagram above, DMARC works pretty well in conjunction with SPF and DKIM. That is because it was built to work along with them with two additional features of checking the “From” domain on message header and reporting back for non-conformances.

If you are not aware in case you have set proper DMARC records on your domain, or rather you want to check someone else’s domain, you can simply get them on terminal by using the command below:

nslookup -type=txt _dmarc.[DOMAIN TO TEST]

Lookup DMARC records for a domain with “nslookup” command.

Otherwise, if you prefer a GUI version, you can look that up by using this great online tool:
https://mxtoolbox.com/DMARC.aspx

Additionally, you can use this other GUI online tool, to generate proper DMARC records in case you still did not add any for your domain:
https://mxtoolbox.com/DMARCRecordGenerator.aspx

However, if you decide to apply DMARC protocol on your domain, please make sure to integrate it in a progressive way. That means to set it up progressively, with a reporting feature only at first. Then gradually introduce the “quarantine” policy. And finally move it to “reject”. It is suggested to apply it in this way in order to identify all legitimate and 3rd party servers that are allowed to send emails for that particular domain on their behalf. Otherwise, you would get a lot of false-positives for fraudulent emails.

Since we keep up with the postal service analogy comparison with email protocols, we will do the same with DMARC. In the postal service, a protocol as DMARC would introduce a new verification process. The postal service agent will inspect the letter content of all received mails. It will check the header of the mail where the attacker writes their name or whom they pretend to be. Then it will compare that with the name/address that the attacker put on the Envelope (return address), by tracing it back from where it came from. If both identities match, it will pass the mail to the receiver. Otherwise, it will throw it in the garbage and will report back to the person the attacker pretended to be.

What is the best way to protect my domain from email spoofing? SPF, DKIM, or DMARC? All together.. or none?

As explained in the previous chapters, each of the protocols was using different methods for protection against slightly different things. Although they all are authentication mechanisms, they apply it on different levels. As a summary, the SPF protocol will disable emails from being sent by other non-authorized servers. The DKIM protocol will digitally sign emails by disabling someone from spoofing or tampering with the email in transit. DMARC will be used in conjunction with the previously mentioned protocols, by adding an additional check on the originating domain on the message header (“From”).

As you can assume, for now using all three together is the best security mechanism to protect your domain emails from being forged or spoofed or misused in any way by an attacker.

Are my emails now 100% secure?
There is no such thing as a 100% secure. Cyber security is an ongoing process and not a product. You can never assume that a system is bulletproof — 100% secure. Things constantly change over time, and new attack vectors are introduced along with new methods to protect. There surely could be many other ways to spoof or forge emails. However, in the protocols level, implementing all three mentioned would be a good start to protect your domain.