Email is flawed, and threat actors know this very well. Email was originally created over 50 years ago, and whilst it has evolved quite a lot during this time, email is still far from being as secure as other communication methods. On today’s threat landscape, up to 91% of all cyberattacks start with Spear Phishing emails. Unlike regular phishing emails, which are usually sent in bulk to thousands of email addresses at the same time, Spear Phishing are highly targeted phishing emails intended for a very specific individual or organization.

Often, when thinking of phishing emails, many people think of Nigerian prince scams and very poorly crafted emails, often in broken english and with obvious fake domains, thinking – “Sure, I would never fall for that!”.

And whilst lower sophistication phishing campaigns like those are and will probably be around until the end of time, threat actors and their tools of trade have greatly evolved over time, to the point where more tech-savvy actors are able to perfectly mirror websites,company branding and spoof domains in their emails, making their phishing emails look like they’re sent from a legit address or company. And while there are endless resources on how to protect yourself against these threats and how to identify and report suspicious looking emails, my idea for this blog is a bit different, as I wanted to focus on how to protect your own domain and email setup and make it as difficult as possible for malicious actors to spoof your own domain – That’s right, threat actors can and will try to impersonate your company or personal domain.

But it’s not all doom and gloom, as there are some steps we can take to ensure our domain is fully protected and that nobody will be able to send emails on our behalf. We’ll be able to achieve this through SPF, DKIM and DMARC, which are protocols that can be set in place in our domain DNS in order to authenticate emails and verify they’ve been sent from an authorized source.

Whether you are a business or an individual, if you have configured your email to use a custom domain, you’ve probably had to edit your domain’s DNS and added MX records in order to allow your email server to send and receive emails from that domain. And whilst MX (Mail Exchanger) records would connect your domain to the email server and allow email delivery, on today’s landscape that is definitely not enough. You would need to make sure to apply additional changes to your DNS in order to implement SPF, DKIM and DMARC to protect your email and ultimately, your identity.

SPF

SPF Stands for Sender Policy Framework, and is the most commonly used protocol in email security. SPF will verify that the sender of an email is indeed authorized to send that email, and it should be added as a TXT record in the domain DNS. Generally, SPF records are provided by your email provider, but there are some values that can be customised depending on your requirements. Here’s an example of my SPF (TXT) records for the domain prats.co, which I use with Proton Mail:

Type	Domain Name	TTL	Record
TXT	prats.co	5 min	“v=spf1 include:_spf.protonmail.ch mx -all”

(There are many tools you can use to look up DNS records, but I recommend MXToolbox.)

But what does it all mean?

• Type is the type of DNS record, in this case TXT (text)
• Domain Name – The domain we’re searching this DNS for
• TTL – Time To Live – How long the DNS record is stored in any server or resolver. That is for example, how long any email server will store (as cache) the above TXT record when sending or receiving an email from the domain prats.co. For security reasons, lower TTL such as 5 min (300 seconds) is recommended email-related DNS records, as it would require all email servers to check for any changes in your DNS and identify any changes quicker.
• Record – The value or content of that record, which generally points to different servers or URLs and, in the case of TXT records, can contain additional information as we can see here:

• v=spf1 – Specifies which version of SPF are we using, which in this case is the current standard, SPF 1.
• include:_spf.protonmail.ch – Allows my email provider (Proton Mail) to send emails through my domain.
• mx – Allows the servers specified in the MX records to send emails through this domain.
• -all – This bit describes how would we like any email server to process an email sent from our domain. There are few options:
  • -all (The most common option) – Tells the receiving server to reject any emails that don’t match the value in the SPF record
  • ~all – Allows the receiving server to accept the email, but flagging it as suspicious/spam
  • +all (Not recommended) – Allows the receiving server to accept any email from this address, even if it does not match the SPF record.

DKIM

DKIM stands for Domain Keys Identified Mail, and it is the way that email servers use to cryptographically sign any outgoing email. Receiving servers will then use the keys in this same DKIM record to verify the signature and confirm the email has indeed been sent from an authorized server and hasn’t been spoofed or modified during transit.

Generally, DKIM is a predefined value assigned by your email provider, and should be added as a CNAME record in your DNS settings.

DMARC

DMARC stands for Domain-based Message Authentication, Reporting and Conformance, and it is complementary to the previous protocols. DMARC will instruct mail servers how to process emails that do not match SPF or DKIM, and what to do if somebody is trying to spoof your domain. Additionally, DMARC will also verify what is called Identifier allignment, comparing that the “mail from” field in the message envelope matches the one in the email header. Lastly, DMARC also allows for extra features such as receiving reports on suspicious email activity, both for passed and failed DNS verification.

I will use my own domain (prats.co) and the MXToolbox tool again for this example. MXToolbox will show additional values and definitions for DMARC Lookups:

v=DMARC1; p=quarantine; fo=1; rua=mailto:[email protected]; ruf=mailto:[email protected]

Let’s break that down:

• v=DMARC1 – Specifies the version of DMARC we are using, in this case, the default DMARC1.
• p=quarantine – Similar to SPF, we can control how would we like any emails to be processed in case they fail validation. There are three possible configurations:
  • p=none – Don’t take any special action. This is generally used for reporting only.
  • p=quarantine – This allows the email to go through, but it sends the email directly to the spam/junk folder, also flagging the email as suspicious.
  • p=reject – This asks the server to drop the email directly, not completing the delivery.
• fo=1 – This is the failure reporting option (fo) . There are 4 possible options to choose from:
  • fo=0 – Generates a DMARC failure report if both SPF and DKIM fail validation
  • fo=1 – Generates a DMARC failure report if either SPF or DKIM fail validation
  • fo=s – Generates a SPF failure report if SPF fails validation
  • fo=d – Generates a DKIM failure report if DKIM fails validation
• rua=mailto:[email protected] – Used to specify which email address(es) to send DMARC aggregated reports to. These reports can be very useful, as it will help understand the security health of your domain and provide some insights into domain spoofing or phishing attacks impersonating your domain, which can impact your business and/or reputation. rua will also provide aggregate reports of successfully signed deliveries (As seen in the example below).
• ruf=mailto:[email protected] – Similar to rua, this ruf tag is used to specify which email address(es) should receive DMARC forensic reports. These forensic reports are much more detailed than rua/DMARC aggregated reports, as they represent a sample of an email that failed SPF, DKIM or DMARC validation.

Note that it is possible to receive multiple types of reports through the failure reporting option (fo). You can specify them by using a colon between each type. For example, if you would like to receive reports for 0,1 and S, you can use fo=0:1:s;. It is also possible to send reports to multiple email addresses by sepparating them with a comma. For example: ruf=mailto:[email protected], mailto:[email protected];

Not all email providers support ruf, so this value is completely optional and it would depend on your own email configuration. Additionally, it is also recommended to use a dedicated email inbox to receive these reports, as depending on your mail volume, there could potentially be thousands of reports being sent to these email addresses.

The DMARC aggregated reports (rua) will be generated by the receiver email server, and they are generally sent in .xml format, providing detailed information on the processed emails sent from your domain, what IP address were they sent from, as well as whether they’ve failed any of the specified verifications on SPF, DKIM and/or DMARC. Here’s an example of a rua report of a successful delivered email:

Update: I’ve recently received some spoofed domain reports. Here’s an example:

From here, it is possible to obtain some additional details such as checking the origin of that IP, which can provide some additional info on the adversary who may be trying to spoof your domain for spam or phishing campaigns.

As I mentioned, depending on your mail volume and your organization size, it is possible you may receive hundreds or even thousands of DMARC reports daily, which can overwhelm your resources. Thankfully, there are some services that can process these for you automatically, helping you unclog your inbox and providing you with an easier, readable formatted report with actionable insights. I’d highly recommend the services of Mailhardener or ReportURI.

Finally, once you have fully configured SPF, DKIM and DMARC on your custom domain, you can test everything is correctly set up by using Mail Tester. This service will provide you with the spammyness score and confirm that your email is correctly configured and all security protocols are correctly authenticating you as the authorised email sender for that domain.

Unfortunately, as there is no general consensus among all email providers on how to process and enforce these security protocols, this wouldn’t be a 100% bulletproof method (No cybersecurity solution really is) as all it takes is for an email provider to be lax when scrutinizing their incoming emails for their users to receive spoofed emails. In case of doubt or if an email still looks suspicious, you can also manually review the email headers as these would also contain additional information on whether the emaill has been sent from an unauthorized server or that it has failed any of the verification mechanisms in place. And of course, always use common sense.