When it comes to securing your outgoing email domains from those who want to impersonate you or your business. There are various technologies you can implement to add protection and build customer trust.
In this post we will cover SFP, DKIM and DMARC. What are they? How can help you? How do they work together? and How are they enabled?
Jump to
- SPF or Sender Policy Framework
- DKIM or DomainKeys Identified Mail
- DMARC or Domain-based Message Authentication Reporting & Conformance
- Need More?
SPF or Sender Policy Framework
Sender Policy Framework (SPF) is a security mechanism created to prevent those who would like to impersonate your domain from potentially being able to. I will cover why I use the work potentially in a moment.
First off, we need to understand that when sending an email is it simple to define what the from address will display as for the recipient.
As example let’s assume your domain name is mysupercoolcompany.com. An unauthorized person could send an email to one of your customers, say [email protected]. This person can define they’re from address as [email protected].
When the customer receives the email, how do they know the mail didn’t come from you?
What does an SFP record do?
SFP works by adding a DNS record to your domain, in this record you list all the servers or sources that are permitted to send from you domain. If someone attempts to impersonate your domain from a source not on the list the email will fail to match the SPF record.
SPF is not 100%
The reason I previously said that SPF potentially stops people being able to impersonate your domain is for a couple of reasons.
- An SPF mismatch needs to be picked up and handled correctly by the recipient’s email system. If your customers mail system is not configured to check and hold/block mails that fail an SPF check the mails will still get through.
- SPF records have been around a long time and used to make far more sense in the days of on-premises email servers, where you mail server would have its own public IP. However, in this era of Office365, GMail and our cloud-based email platforms. You can create an SPF record to say our emails are only allowed to originate from Office 365. But what is to stop someone looking up your SPF record and sending a mail impersonating your domain from another Office 365 tenant.
You absolutely should be using SPF records as they add a layer of protection and build customer trust. However, on their own, they are not enough these days.
How is SPF enabled for a domain?
SPF is enabled by adding a TXT DNS record to your domain, the process of how you do this will vary depending on who is providing your public name servers. You can use services such as MX Toolbox to check if you already have an SPF record in place and to test if you are configured correctly.
The TXT DNS record needs to be structed in a certain way, there are many tools online to help you generate the record such as this one from MX Toolbox https://mxtoolbox.com/SPFRecordGenerator.aspx
For example, if you only use Office 365 your SPF DNS TXT record would look like this
v=spf1 include:spf.protection.outlook.com ~all
- v=spf1 – Identifies the record as an SPF
- include:spf.protection.outlook.com – Includes the mail servers that are authorized servers to send from the domain. If you have multiple sources that mails can originate from, you can add multiple includes for example v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all
- ~all – Indicates or recommends the action to take if the SPF check fails because the mail has originated for an authorised source. In this case Not Passed, Soft Fail. The recipient will normally hold or mark as spam.
DKIM or DomainKeys Identified Mail
DKIM performs the same role as SPF, in stopping unauthorised people spoofing you domain. However, it does it in a different way.
Should I use SPF or DKIM?
Short answer, both! While SPF and DKIM attempt to solve the same problem, it is recommended to use both methods to build a layered approach and plug the gaps in both technologies. SPF and DKIM on their own are not 100% but together they create a strong mechanism to protect your domain and build trust and boost the reputation of your domain.
What’s the difference between SPF and DKIM?
With SPF we are defining a list of originating servers that are allowed to send from the domain.
With DKIM we are signing the message as if leaves our email system. On receipt the recipient can verify that the signature is correct. Proving the message was not altered in transit and that the message originated from a valid/trusted source.
How is DKIM enabled for a domain?
Firstly, you will need your email provider to generate a private key and start signing your outgoing messages. This step will of cause depend on who your email provider it, for example
- Microsoft – How to use DKIM for email in your custom domain – Office 365 | Microsoft Learn
- Google – Help prevent spoofing and spam with DKIM – Google Workspace Admin Help
Next you will need to add a CNAME DNS records to you domain containing the matching public key. You email provider will have detailed steps on what the name and value of the DNS record should be
DMARC or Domain-based Message Authentication Reporting & Conformance
DMARC required SPF or DKIM to be in place, while only SPF or DKIM is required. It is recommended having both.
DMARC adds a couple missing pieces to round off the protection of you domain.
- Improved Security – It allows you to specify what you would like the recipients mails server to do if the mail fails SPF or DKIM (None, Quarantine or Reject). Setting a consistent policy that recipients can follow.
- Improved Visibility – Recipient mail servers will send XML based reports to URIs / email boxes you specify. Giving you visibility of your mails and failing SPF or DKIM checks, this could either because of a misconfiguration or because someone is attempting to abuse your domain.
In some cases, publishing a DMARC record can boost a domains reputation helping to ensure that genuine mails are not wrongly held/rejected as spam.
DMARC Polices
DMARC allows you define one of three policies to tell recipients ail servers what to do if a mail from your domain fails the SPF and/or DKIM check.
- None – There is no impact if the mail fails the check, the alternative name for this policy is Monitor only. When first setting up DMARC it is recommended using the None policy initially, until you are happy there is no configuration issues with your SFP of DKIM records.
- Quarantine – Suggests that the recipients mail server should be suspicious about the mail flow. Marking as spam, holding for review, or alering the recipient to be cautious
- Reject – Advises the recipient mail server to reject the message. You should be completely confident with your SPF and DKIM configuration before going to this level. However, this is where you should get to
If you have parked domains or domains, you will never be sending emails from you can set the DMARC policy to Quarantine or Reject, even if you haven configured SFP or DKIM. This will ensure that no one else can spoof these domains. This is gap that many organizations miss, for example you may be sending from a .com address but you own the .co.uk or other TLD’s for brand protection. What is stopping people spoofing those non email domain, they are close enough to your primary domain name that you customers may not notice!
How is DMARC enabled on a domain?
You have two options when enabling DMARC. Depending on how you want to handle and analyse the XLM reports DMARC will be sending you.
- You can either sign up with a DMARC service such as https://www.dmarcanalyzer.com/ or there are many others out there.
- You can setup a mailbox or other service to receive the raw XML files and periodically analyses them, either manually or uploading them to a tool such as the one over at MX Toolbox DMARC Report Analyzer – DMARC Email XML Parser – MxToolbox
Once you have decided how you are going to handle the reports, you simple just need to setup up a TXT DNS record on the domain. for example
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1;
- v – The version i.e. DMARC1
- p – The policy to apply (see above)
- rua – The URI to send aggregate reports to (can be comma seperated)
- ruf – The URI to send forensic reports to (can be comma separated)
- fo – The type of failure report
Need More?
If you would like to learn more on the subject Pluralsight who I highly recommend have a great course covering the above topics. You can get a 7 day free trial too!
