This article gives an overview of how DMARC, DKIM and SPF work together to protect your domain name from being spoofed by attackers. The audience is intended to be business owners curious about how the technology works. It is not intended to be a comprehensive technical explanation, and intentionally glosses over many details.
The problem
When an email is received, a mail server needs to decide if it's legitimate or not, before the email is delivered to the recipient's mailbox.
One aspect of legitimacy is if the domain name in the "From" address (e.g. "example.com" in the email address "john@example.com") was actually responsible for sending this email — or did a malicious person merely pretend to be that organisation?
This is called "spoofing".
There are 3 email authentication protocols that can work together to block spoofed email before it reaches a recipient's mailbox: DKIM, SPF and DMARC.
DKIM
DKIM is a mechanism by which a domain name explicitly lists a specific service (e.g. an email service provider like Microsoft 365; a website; or an email newsletter provider) that is permitted to send email using that domain name as the sender. The cryptographic mechanism by which it does this makes it nearly impossible to impersonate the service, and also prevents a middleman from being able to intercept and change the email. The service will have a unique key for your account, so even another user on that same service can't impersonate your domain.
A platform that sends email on your behalf should give you a DKIM key that you then add to your domain's DNS records (which Precedence can do for you). That will allow a receiving mail server to be confident that emails sent by that service have been approved to use your domain name.
A DKIM record for a domain name looks like this:
<selector>._domainkey.example.com 300 TXT "v=DKIM1; k=rsa; p=<long crytographic key>"
SPF
SPF is a mechanism by which a domain name explicitly lists an entire server or network that is permitted to send email using that domain name as the sender, by listing the servers' IP address(es). It is an older protocol than DKIM and less effective because it has a much broader scope (another user on the same server could spoof your domain), but it has a similar objective.
A platform that sends email on your behalf may give you an SPF record to add to your domain's DNS records, instead of a DKIM key. This is better than nothing, but DKIM should always be preferred.
(SPF is still an important part of the chain of authentication for email, but for mail servers themselves, rather than an end user's domain.)
An SPF record for a domain name looks like this:
example.com 300 TXT "v=spf1 include:spf.protection.outlook.com include:_spf.pre.net.au -all"
DMARC
Neither DKIM nor SPF by themselves explicitly look at the "From" address, and so cannot identify this type of spoofed email on their own.
Instead, a third protocol, DMARC, uses information from DKIM and/or SPF to perform this test.
If the "From" address is set to "john@example.com", DMARC will look at the DKIM and SPF records for the domain example.com, and determine if either a DKIM record permits the service sending the email to use that domain, or if an SPF record permits the server/network sending the email to use that domain. If neither matches, it instructs the receiving mail server to reject the email.
The term "alignment" is used here to indicate if the "From" address domain aligns with the domain used in the DKIM signature or the SPF-validated server address sending the email.
Without DMARC, it is possible for an email to be sent from an authorised network (such as Microsoft) but still forge the "From" email address that is shown to the receiver, for example, if both domains authorise the same network. With DMARC, the domain in the "From" email address is specifically checked.
A DMARC record for a domain name looks like this:
_dmarc.example.com 300 TXT "v=DMARC1;p=reject;sp=reject;adkim=r;aspf=r;pct=100;fo=0:d;rf=afrf;ri=86400;rua=mailto:dmarc@pre.net.au;ruf=mailto:dmarc@pre.net.au"
Recommendations
We recommend that every business has a DMARC record for their domain name, and that every service sending an email uses either DKIM or SPF to authenticate with the domain.
Whenever a service provider offers to send emails "from" your domain, be sure to follow any instructions relating to DKIM or SPF. Forward such instructions to Precedence (or whoever manages your domain's DNS settings) for implementation.
For DMARC, if you register a brand new domain name and set up web hosting with Precedence, our platform will automatically configure DMARC on it. But if you have an existing domain name, it is more complicated to set up DMARC, because you must be careful to not disrupt existing services that send email on your behalf.
Here's a checklist of how you can implement DMARC on an existing domain name in a controlled manner:
- Make a list of all services that send email on your behalf where the "From" address includes your domain name. Examples would include your email service provider (e.g. Microsoft 365), your website, email newsletter services, and CRM platforms.
- Check if each of these providers had you configure DKIM or SPF when setting them up. If in doubt, send the list to Precedence, who may be able to check or make an educated guess. Most of the time, these will already be in place in order for their emails to work correctly.
- For any that don't, reach out to them and ask them to supply "...the necessary DKIM and/or SPF records you need to add to your DNS to allow them to send emails from your domain name". Forward those to Precedence (or whoever manages your DNS) for implementation.
- Ask Precedence (or whoever manages your DNS) to then enable DMARC on your domain.
- Finally, send a test email from every single one of of those services to a test email account that is different to your domain (e.g. to a gmail.com address) to ensure they are all delivered correctly.
If you have an IT company or Managed Services Provider, engage them to oversee this, as they will likely have their own processes and checks they will follow to implement and test DMARC in a safe manner.
