Enterprise DMARC: Scale & Subdomains
The SPF 10 lookup limit is not a problem
Almost the entire US federal government has adopted it at this point as well as half of the Fortune 100. We've already established how easy this is in smaller organizations too.
Scale does come with it's own implementation challenges, so let's start with the most well known.
Overcome the SPF 10 Lookup Limit
When a mail server tries to verify that a message passes SPF, it contacts the domain DNS to look for the SPF record and checks to see if the IP address of the server that sent the message exists within the record. This could mean directly listed IP addresses, ranges of IP address or include: entries which list another domain name that contains another list of IPs.
Every time another DNS query must be performed, it adds to the "lookup count". If you're using Google Workspace and included _spf.google.com in your top level SPF record you may think that's only 1 lookup. By querying that record though, we will see that it contains 3 additional lookups.
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
These all consist of IP address ranges without any additional look ups. Here's _netblocks3.google.com as an example.
_netblocks3.google.com. 300 IN TXT "v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"
That means that by including _spf.google.com we've added 4 lookups to our SPF record and that's only for our corporate email account! What happens when we start adding all of those other services?
Exactly. You'll quickly go over the 10 lookup limit if everything gets added to a single SPF record. Which is why you aren't supposed to have a single SPF record. Each subdomain can and should have it's own SPF record. If a record isn't present at the subdomain then the lookup will bubble up to the root domain.
The easiest way to think about this problem is in terms of what services are being performed. Let's use our pirate gym, Slimmer Ye Timbers as an example.
newsletter.slimmeryetimbers.com- Marketing newslettersinvoice.slimmeryetimbers.com- Invoicing systemsclasses.slimmeryetimbers.com- Class schedules and remindersreceipt.slimmeryetimbers.com- Transaction receiptsit.slimmeryetimbers.com- IT department systemshr.slimmeryetimbers.com- HR department and tooling systemssales.slimmeryetimbers.com- Sales tools like CRM systemsmail.slimmeryetimbers.com- General website emails
Any of these could be further broken down if needed. The point is that there's no need to try to cram everything into a single top level SPF record. As a bonus, you gain a number of benefits by using subdomains.
SPF Isolation and Error Containment
One thing many people don't realize is that a broken SPF record will invalidate your entire DMARC policy. If mail servers see you have an enforced DMARC policy setup, but also see that your SPF record is broken the error will force them to act as if you have no DMARC policy at all.
By isolating each SPF record on its own subdomain, you contain the damage from a broken record to only that subdomain.
You may be wondering how an SPF record could break after it's been setup correctly? One of the dangers of include: is the potential for change by the vendor.
Just as an example from 2012, we were using a vendor to manage sales channel communications. Not knowing any better, we added their include: record to our top level SPF and everything was working great. We had a fully implemented p=reject; policy and our phishing complaints had basically stopped at that point.
One day, all the phishing complaints started back again suddenly. And worse yet, the phishing emails were using our domain again. We hadn't touched anything with the email system so we couldn't understand what happened.
After inspecting all of our records, the Kitterman SPF Testing Tool helped us discover that our SPF record was broken. The sales channel communication company switched which domain they were using for include records and the old domain was no longer valid! This change invalidated our entire SPF record and the rest of our email policy along with it.
If the CRM tool had been on its own subdomain, only that tool would have been affected by a change outside of our control. We didn't know about the change because the email notification about the change only went to the person at the company who signed up for it in the first place. And they didn't pass it along.
The above scenario also underscores the benefit of long term monitoring for changes in your SPF records.
You don't need "SPF Flattening"
There are tools out there which provide a service called "SPF Flattening", which monitors your SPF record for changes and compresses it into the minimum possible number of SPF lookups. You have to pay for the service and it can still outgrow the 10 SPF lookup limit.
You don't need these services. You need subdomains.
No single service can function if it alone would outgrow the SPF lookup limit. By simply isolating each service on its own subdomain, you have "limit proofed" it against this problem.
The only potential benefit to an SPF flattening service is error insulation from 3rd party changes. If the flattening service does error detection against changes in the SPF record and refuses to publish any change that would cause an error, your tooling would be insulated against those 3rd party errors. That's a good thing.
However, it's only a short lived protection. Eventually the error has to be resolved or the flattened records may no longer be valid. A decent flattening service should notify you of these types of errors so that you can correct them.
If an error preventing cache buffer sounds worth the cost to you, then maybe it's worth it. Don't depend on the SPF flattener to prevent your longer term lookup limit issues. You're still better off with subdomains even when using a flattening service.
Return-Path and Subdomains
Both SPF and DKIM have an option in your DMARC configuration to allow both "strict" and "relaxed" (default) mode. In relaxed mode, the Return-Path used to send email bounces can use a subdomain while still showing the visible From: domain as only the primary root domain. There are examples included in the DMARC specification.
Most servers will configure themselves in the Return-Path by default, so if you have 1,000 servers like web1.slimmeryetimbers.com or api3. or mail7. or staging3. they can also still send DMARC aligned emails for the root domain, @slimmeryetimbers.com while using subdomains. An SPF entry referencing that server IP on the web1. subdomain will allow messages from that domain to pass an aligned SPF check without actually having to send email From:name@web1.slimmeryetimbers.com which might not be visibly appealing.
This illustrates why, no matter how big your organization may be, no matter how many servers you have, subdomains will scale with you without growing your total lookup limit.
You could certainly reorganize the above example for simpler management by publishing them under a grouped subdomain, like web1.it.slimmeryetimbers.com. Then an SPF record could be posted on it.slimmeryetimbers.com with an IP range including the scope of the servers underneath it rather than adding and removing individual IP addresses.
Subdomains for Project Scope
One thing that people often forget is that subdomains themselves are just like the primary domain. Each subdomain can have it's own _dmarc. entry if you want. It can have it's own set of DKIM keys under _domainkey. as well.
Which means you can have a different email address to collect aggregate reports from DMARC report providers on each subdomain, just as if another domain entirely was being used.
And that means that your organization can have multiple DMARC deployment projects if needed. You can let HR roll out DMARC on it's own schedule while the rest of the company gets setup for p=reject; on the main project, for example.
This article was originally published on as part of a 3 part DMARC Guide at Brightball.