Topping up your SPF protection with DMARC
When talking to customers about OnDMARC, we’re often asked: what if I’m only using SPF in my organization at the moment? Can I use DMARC, or do I have to start using DKIM as well? These are good questions, and I’ll aim to address them in this blog.
As you’ll know, DMARC uses both the SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) protocols to check if inbound emails are coming from where they say they’re coming from, and allows senders to report on this and define how email recipients deal with emails that fail the checks.
The good news is, these organizations can still gain strong benefits from using DMARC while only using SPF — but there are some important caveats that companies planning to do this should note.
Forward-thinking
SPF has the limitation that it only works for emails that haven’t been forwarded, because it needs to check the IP address of the server that originally sent the message against its authorized list of senders. When an email is forwarded, it essentially is being sent by an intermediary which has an IP address that does not match the DNS list that SPF works from.
If the system or device forwarding the message isn’t on the “approved” DNS list, the SPF check will fail. And if a DMARC blocking policy is published for this domain, the email message will not reach the intended target.
So the starting point for any organization that is using SPF and planning to deploy DMARC is to start collecting and analyzing DMARC aggregate reports for their email domain or domains. This provides in-depth visibility into the authorized senders using the email domain, as well as showing whether or not the domain is being impersonated. It can also enable you to establish how much of the email within your organization is being forwarded. Tools like OnDMARC can make the implementation and reporting of DMARC extremely easy and it is well worth checking out.
DMARC decisions
Then, based on the DMARC aggregate reports, you can start making decisions. If, for example you are currently only deploying SPF and your domain handles a large proportion of forwarded emails, then a ‘quarantine’ or ‘reject’ DMARC policy would not be appropriate, because it would block many of those forwarded emails.
It is also important to remember certain known and trusted forwarded emails will be accepted by some mailbox providers, such as Google and Microsoft. They use a ‘local override’ mechanism on the sender’s DMARC policy. But the exceptions are applied at different rates and different times, which means that for a consistent approach to email reliability and authenticity, you need to minimize the number of forwarded messages that are not verified.
If you have very little forwarding, then a DMARC blocking policy could work well — but it’s still vital to continue reviewing those forwarding reports for any changes. A simple change such as a business being acquired and implementing an email migration plan that involves forwarding could mean that customers or partners will stop receiving messages — so regular reviews are important to avoid this type of scenario.
Your unique context
Above all, it is important to remember that every organization’s email profile is different. There is, for example, a huge contrast between HMRC sending out tax return reminders and a local restaurant emailing out a special offer. Organizations have different sizes of mailing lists, different frequencies of emails and different calls to action. All this have an effect on how much of a percentage of blocked emails are acceptable.
Even if you have only deployed SPF, DMARC can still benefit for your business, and DMARC reporting is useful even if you don’t have anything in place to authenticate your email. Understanding the proportion of emails that are forwarded is a vital first step.
The video below explains how SPF, DKIM and DMARC work together to secure your email.
Why not contact us to find out more, or check the current status of your organization’s email domain for free?
