A question people asked repeatedly in 2016 was whether or not their organization could deploy DMARC if they only used SPF at present. They knew the recommendation is to use both DKIM and SPF, and were concerned that their organizations couldn’t benefit from DMARC without DKIM. The short answer is that you can use DMARC with only SPF – and absolutely should, at least as far as enabling reporting – but there are some very important questions you have to answer before moving past that to a DMARC policy that would block unauthenticated messages. This article will try to explain those questions and how you can get some answers.
Start With Reporting
The first step for anybody sending email for business should be to start collecting and reviewing DMARC aggregate reports for their domain(s). The information these reports provide about all messages, legitimate or otherwise, that use your domain is very useful.
In addition to seeing whether or not somebody is impersonating your domain, these reports provide excellent visibility into all the authorized senders using your domain – even the ones nobody told you about. Every sizeable organization that has gone through this stage has discovered important, and sometimes shocking things about in-house servers or legitimate third-party senders using their domain.
No matter what your plans are for email authentication, and even if you aren’t using SPF or DKIM, you should start collecting and reviewing the aggregate reports for your domain.
Limitations of SPF – Forwarding
The first question to answer is why the use of both DKIM and SPF is recommended, and the reason is that they complement each other. SPF has a lower overhead when processing messages, and is easier to put into production. DKIM requires some computation to produce a cryptographic signature that gets attached to the message, so there’s a little more overhead on the sending and receiving side.
But SPF only works if the messages aren’t being forwarded. What is forwarding? Very briefly, it’s when a message is sent to one address, but the receiving system takes the message and sends it on to a different address. SPF works by checking the sending server’s IP address against a list in a DNS record that the sender publishes, and the system forwarding the message isn’t going to be in that list, so the SPF check will fail. And if a DMARC blocking policy were published for the sending domain, that message probably won’t reach the addressee.
In the diagram above, when the message was first sent from the Sender’s server with address 192.168.1.100, that address matched what was in the DNS record at the top of the diagram. But when the message was forwarded from the Intermediary, the Recipient system saw the message coming from the server with address 10.23.45.99, which does not match the address in the DNS record. Thus, the forwarded message cannot pass the SPF check.
This commonly happens with alumni (jdoe@alumni.university.edu) or affiliate (jdoe@professional.org) addresses, mailing lists, etc. It’s also seen when a customer switches service from one mobile phone or internet service provider to another, and just forwards all their messages to the new address rather than updating their contact information with all the companies they do business with.
How Much of Your Email Is Forwarded?
The first step anybody should take with DMARC is publishing a record with a p=none policy to request aggregate reports, and then analyzing the reports they receive for their domain. In addition to seeing if their domain is currently being abused, these reports can indicate how many messages are being forwarded from the address a customer provided to some other mailbox.
Analyzing the raw DMARC aggregate reports for forwarding can be difficult. This is where report processing services can be very helpful – they typically maintain databases of known forwarders across the Internet. They can provide clear counts of the number of forwarded messages when they compare your aggregate reports to those databases. Here’s a sample report showing a domain where a little over half the messages using the domain failed to authenticate because they were being forwarded:
Sample graph courtesy dmarcian.com
In an extreme situation like this, it would be unwise to adopt a quarantine or reject policy if only SPF is in use. Many senders will never see forwarding levels this high, but it is essential to collect the reports and find out what the situation is for your domain before proceeding.
You should know that some mailbox providers will make exceptions for forwarders they know about and have some level of trust in. AOL, Google, Microsoft and Yahoo are aware of many forwarders, and will frequently execute a “local override” to a sender’s DMARC policy rather than block legitimate messages. However, in all the cases we’ve reviewed over the years, those exceptions aren’t applied to 100% of the forwarded messages. It can vary widely between 10 and 90% of the forwarded messages being allowed through, depending on the forwarder, and these levels change over time – sometimes significantly, even from one day to the next.
So unless you want to see large swings in who receives your messages from week to week, you should do everything you can to minimize the number of messages being forwarded that don’t authenticate. Deploying DKIM is one approach, and it can help close the gap since DKIM will survive many cases of forwarding where SPF cannot. But be aware that DKIM can fail when forwarders change the message in specific ways, so it may not reduce forwarding failures to zero. We’ll address that situation in another article.
Asking your customers to provide addresses that aren’t forwarded is another approach that can eliminate this concern. The right solution for you will depend on many factors specific to your organization, vendors, and customers.
Deciding To Proceed
If your aggregate reports show no or very little forwarding, it should be safe to proceed with a DMARC blocking policy for your domain. But things can change quickly, and it’s important to continue to monitor your DMARC reports! All it would take is one ISP who gets acquired and implements a migration plan involving forwarding, and suddenly you could have a lot of customers not receiving their messages. Regularly reviewing your reports for changes can head off a surge in complaints in these situations.
Organizations that see some forwarding would ideally have a business case to deploy DKIM, and see if that closes the forwarding gap in authenticating their messages. But assuming they cannot do that, they will have to make a business decision about whether to proceed with a quarantine or reject policy while only using SPF. Each situation is different – if you’re just sending coupons to frequent buyers, a small percentage of blocked messages may not delay your plans. On the other hand, a bank may decide that even a small number of blocked messages containing legally required notifications is too many to proceed.
Only you know what you send, what your customers expect from you, and what level of commitment to delivering those messages is required to meet those expectations. This article is intended to help you understand the situation so you can make the best informed decision possible.
Summary
You can still benefit from DMARC even if you’ve only deployed SPF. You should definitely deploy DMARC reporting even if you aren’t using any email authentication measures. Those reports will tell you how much forwarding of your messages happens after you’ve sent them. Then you can make an informed decision about whether to proceed to a quarantine or reject policy, even if you’re only using SPF, based on a measurement of how many messages might be impacted rather than guesses or speculation.