Walkthrough guide on SPF, DKIM and DMARC

In this article we’ll go through how SPF, DKIM and DMARC work and how they help to protect your business domains reputation.

Since the release of SMTP (the protocol used for sending emails) there are very few in-built protection / verification measures to “prove” the person sending the email is that sender / domain. This is why systems such as Mimecast, ProofPoint, Microsoft Defender for O365, And mechanisms such as SPF and DKIM have been introduced to protect against this type of abuse.

If you’re familiar with Dmarc, SPF and MX then you may find DNSTools handy. These are Powershell tools written by me which add Get-SPF, Get-MX, Get-Dmarc commands to Powershell

Basic SMTP has no mechanism by default for confirming either the IP address of the sending server is allowed to send From / To your email server, or that the From / To address are legitimate, With the exception of accepted domains and preventing openrelays.

In order to send an email, the sending server must first resolve the IP address of the server to send through. I’ll demonstrate how the process works using NSLookup to resolve the DNS records. I’ll then demonstrate the basic SMTP protocol to show sending an email.

Here we have done an NSLookup, Set the type of record we’re interested in to MX and queried talkingbytes.co.uk which resolves to the Outlook.com (Office365) DNS Record.

We can then change the type of record we’re interested in to All and resolve the Outlook.com address in order to get the IP’s of the Microsoft 365 recieving addresses for my tenant.

Here we can see Microsoft have four IP addresses against this record.

Using Putty, we’ll connect on TCP port 25 (SMTP) and demonstate sending an email.

Here we can see at the bottom “Queued mail for delivery”. This means the server accepted this message.

The “Helo hotmail.com” is the sending server (In this case, My Telnet Session) announced itself as.

The Envelope Addresses are the addresses the “Postman” uses to deliver the letter so these do matter. However as we can see from the Header address, And it’s important to know these are what Scam / Phishing senders use, Do not need to exist and can be (at first glance) used to hide important information from the recipient.

Now whilst this email was caught in my Defender for Office365 policies, This email was accepted and without these in place would have appeared in the users mailbox appearing to have come from admin@talkingbytes.co.uk.

If we look at the quarantine details, We can see that this email failed SPF, Shows a Permanent error for DMARC and DKIM shows as none. Lets now discuss how these work and how they can help prevent these types of emails.

SPF has been around since the early 2000’s and I first became aware of it when I started working in IT around 2004 although hasn’t been taken as seriously as it probably should be until recently. Following the above example lets look at SPF for hotmail.com and see why it failed.

So when recieving my telnet email, My Office 365 tenant would have resolved through DNS the SPF record for Hotmail.com

Here we’ve opened NSLookup, used “Set Type=txt” to only resolve TXT records and then entered Hotmail.com

Looking at the SPF record we can see an IPV4 address block (157.55.9.128/25) and numerous Include further TXT records, Crucially my home IP is not permitted through any of these blocks to send emails for hotmail.com (no surprise here)

Also note at the end of the record is -all, This is important as it tells the recieving server “This is a full list of every IP permitted to send emails from this domain”. Unfortunatly a lot of email servers and mail filters do not take this as seriously as they probably should.

When looking at TXT records you will see some records with a tilda ~all instead. This would tell the recieving server that all servers listed here should be trusted, However there may be some sending servers not listed here. This means that emails shouldn’t be getting dropped / blocked exclusivley just because it hasn’t matched on IP.

Either way, we have seen that Microsoft Defender has picked up the SPF failure correctly, And using this, The policies set in your mail filter, And the DMARC policy set by the hotmail.com domain owner (in this example) to determine handling of these failings. So now lets discuss DMARC.

So DMARC As the abbrieviation suggests, doesn’t actually control who can send emails from your domain. It is purely a reporting mechanism and gives you the option to reccomend to the recipients email servers, how it should handle emails that fall outside of conformance. The email addresses given in the DMARC records below advise the recipient where to send failure reports to so we can confirm if we’ve missed any senders from our SPF or DKIM Setups.

The reports given to these email addresses aren’t particulally easy to read so we can use tools such as Valimail to make our lives easier here.

As for checking DMARC, Once again, DMARC is managed through DNS records so we’ll start by checking NSLookup

Once again we’ve opened NSLookup, Set the record type to txt and then entered “_dmarc.hotmail.com” to get their DMARC record.

The first part of the record is crucial which is the p= policy. Hotmail.com domain does not have DMARC enabled as their action is set to none (Other options are Quarantine and Reject). As the hotmail.com domain owner is not suggesting an action be performed on the emails, All will come down to the recieving server how it chooses to handle emails that don’t match on SPF/DKIM.

The email addresses are advising the recieving server where to send DMARC email reports.

the FO=1 advising the recieving server to send a report if either SPF or DKIM have failed.

If enabled, DKIM adds an encrypted key to outbound emails which the recieving server can use to verify the message has not been tampered with and that it has come from a legitimate source. If the content of the email has been tampered with then the keys won’t verify and the policy will fail the sending domains DMARC policy, and the recieving server should apply the policies.

It’s always best here to ensure any services sending from your domain such as Sendgrid pass through your email security so DKIM can be processed however emails recieved without any DKIM keys in them should not be dropped by the recieving server. Only DKIM keys that are out of alignment (tampered with emails, Different organisations keys).

Back in February 2024 Google and Yahoo have been requiring senders that send over 5000 emails per day through their servers to have an active DMARC policy, and to have SPF and DKIM records per domain and ensure alignment.

This can only be a good thing as it means that SPF and other measures are taken more seriously and organisations will have to configure DMARC and go through the Report / Quarantine / Reject policies ensuring that all legitimate sources are included in SPF records and DMARC policies are aligned.

It’s generally recommended that SPF and DMARC are set on all domains, both ones your organisation uses for legitimate emails, but also for parked domains as it will prevent spammers from sending emails masking themselves as coming from your domains.

You can read the article from Google over at blog.google

As always if you have any comments or feel anything is missing please leave a comment below.