Traditional SPF Simplified
When an email is sent, the receivers pull the SPF list and check if the IP is on the list. This is what causes lookup limits and size issues as large organizations can own large IP chunks.
Sample SPF record for Microsoft.com
v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:147.243.128.24 ip4:147.243.128.26 ip4:147.243.1.153 ip4:147.243.1.47 ip4:147.243.1.48 -all
The above is actually AT the 10 lookup limit.
Hosted SPF
Agari utilizes macros within our hosted SPF function. This uses variables within the record to limit the length/complexity, and it is up to the "backend" to make sure the record returns results. This also does provide some level of security, as it limits a malicious user from easily identifying your authorized email senders. It's still possible, but more time consuming since it will require multiple queries/tests guessing combinations of IPs/Domains/Hostnames as opposed to a single DNS query to see a list of IP addresses. They will usually look at other methods and means.
Below is agari.com's current SPF record (a Customer record would look very similar):
v=spf1 include:%{d}.01.spf-protect.agari.com exists:%{i}._i.%{d}._d.%{h}._h.espf.agari.com -allThere are a few things to notice:
- The exists as opposed to include. This means it checks to see if value returns for the query, and if it does then it passes.
- The variable strings: example: "%{d}" and "%{i}", These are rarely used part of the SPF standard, but can be powerful when used correctly. When an ISP/MTA receives a message, and they go to check the SPF record, they will input the values from that specific message into those variables.
The "d" = domain, and the "i"= IP address "h" is hostname/ptr/ehlo. If a value is returned, then it passes SPF.
This method is useful for bypassing the SPF limits since it only counts as 2 specific lookups for any single message, and is also obviously shorter. Organizations could also use this in conjunction with their own SPF record (i.e. put critical IP's before the macros if you really wanted to for initial roll-out). The downside to using macros is that at large scale it is difficult to manage all the backend DNS entries/records in order to pass if you were to attempt it yourself. And for 3rd parties, it is easier/simpler to just use standard include statements. You could do it yourself easily for a dozen IP's, however, this becomes increasingly difficult as organizations grow and more senders are added to the record.
Agari has built out the processes, infrastructure, and automation to handle this at scale and dynamically for our customers with multiple senders and complex environments. This automation/infrastructure means that you can easily approve/deny entire 3rd party well-known senders, as well as individual IP address/ranges with a few mouse clicks, instead of attempting to fiddle with your SPF record to get it undersize and look-up limits.
Example of how it works
If someone receives an Alert from Agari's notification server (198.2.132.180) for the domain agari.com, the receiver inputs the variables.
Example Query:
dig -t A +short 198.2.132.180._i.agari.com._d.espf.agari.comReturns:
127.0.0.2
Because there is an answer, this means it passes SPF. The RFC says it just has to have an answer, and it doesn't matter what it is.
But, let's say we receive a spoof from 1.1.1.1:
dig -t A +short 1.1.1.1._i.agari.com._d.espf.agari.comReturns a null/blank or "no answer" which fails the SPF lookup.
Agari also provides "future-proof" integrations
In the event that you would choose to move away from Agari and/or hosted SPF for a specific domain, we have our SPF builder which is a UI based tool that analyzes your existing SPF record, DMARC data, and assists in building out an SPF record easily within the portal, where you can save/download the value/instructions for updating your existing record. This means that you can choose a combination of Hosted-SPF and traditional SPF depending on the domain/requirements and are stuck with an all/none across all of your domains. Although moving away from hosted does take you back to the traditional lookup limits and complications that you may have moved away from.
While Agari's EasySPF will help you build DNS records, hosted SPF does fundamentally allow you to overcome basic SPF limitations that may require changes and the use of subdomains, or sending policies in order to meet the traditional lookup and size limitations, should you in the future chose to remove the simplicity factor of hosting SPF with Agari.
As the maco hides your includes and IPs in your record, you can use the following tool to look up your SPF record, and then do a reverse lookup to verify the IP is in the record.
Simply put your domain in the SPF field, and then click the SPF to the right. On the next page put the IP of the service in question to verify.
Comments
0 comments
Please sign in to leave a comment.