SPF

“SPF Flattening” was invented by dmarcian as part of the initial release of the SPF Surveyor. For many years the functionality was flagged as “experimental.” Today, we’re concluding the experiment and sharing what we’ve learned. Sender Policy Framework (SPF) Background Email operators use SPF to identify themselves and their infrastructure when sending email across the internet. SPF was originally created by email operators around 2000 in response to Joe Job Attacks. At that time, spammers were making victims out of legitimate email operators by pretending to be them while sending spam. Legitimate operators were blamed for sending spam simply because there was no easy way to identify email operators and their infrastructure. Email operators publish SPF records to describe their email infrastructure. These records are specially formatted strings of text that live in the DNS. When receiving email, an email server looks at the domain of the sending operator’s email

Why Is SPF Flattening Relevant? SPF has a limit of 10 DNS Lookups; any mechanism (entry) requiring a lookup after the lookup limit will not be evaluated and will fail authentication. In some cases, people turn to SPF flattening tools to work around the 10 DNS lookup limit. When you add a new mechanism in your record, you require a new DNS lookup. The more services and third-parties that send on your behalf, the more complicated and bloated your record can become. SPF record flattening can be an easy answer, but is not the safest route. How Does SPF Flattening Work? In SPF Flattening, hostnames are converted to IP addresses, which don’t count in the DNS lookup tally. Then you create your SPF records using the IP addresses instead of the hostnames. dmarcian developed SPF flattening as an experiment to work around the DNS lookup limit. In IETF’s RFC 7208

The other day, I ran across a complaint on Linkedin. “Just saw another email go to the Promotions Folder with DKIM, SPF, and DMARC set up perfectly. Stop telling people this will fix their e-mail problems!” It’s not the first time I’ve heard this, and I can understand why the author is frustrated. But, it’s important not to miss the true point — email authentication will help to improve inbox delivery. Because it does! But there’s a nuanced explanation to go along with that. The devil truly is in the details.Email authentication is fantastic. SPF and DKIM both allow you to set yourself up as YOU in the eyes of mailbox providers — as opposed to just being one of the many clients of ESP or CRM platform X, based on a shared IP address or shared DKIM domain. This is a good thing, but it’s just the start.Setting yourself

SPF allows a domain owner to publish a list of servers that are allowed to send on behalf of a domain. When processing a domain’s DMARC data, dmarcian uses the domain’s SPF record to identify IPs that are authorized by the domain. The post SPF-Identified Servers—What is this Source? appeared first on dmarcian.

Rene Holt writing for We Live Security has shared a recent tale that gives me pause: What can go wrong if you get your SPF record wrong. Usually the risk here is that you make your SPF record too restrictive, resulting in the rejection of legitimate mail. But here’s an alternate case — what if your SPF record is so wide, so broad, that bad guys can easily send spam from certain IPs and pass authentication checks, successfully pretending to be you (or at least, successfully sending from your domain).I think the moral of the story is that you’ve got to get SPF right, both in how tight and how loose your SPF record should be. Don’t just blindly add a zillion IP addresses because somebody told you to; investigate and question and review.Rene Holt: How a spoofed email passed the SPF check and landed in my inbox

Sender Policy Framework (SPF) is one of two primary types of email authentication mechanisms used by email senders today (the other being DKIM). SPF is a “simpler” protocol than DKIM, in that SPF is based around a text record for your domain name that contains the IP addresses of the mail servers that are allowed to send mail on your behalf.You can lookup the SPF record for Spam Resource here, using my XNND DNS Tools website. As of this writing, that SPF record looks like this:ip4:213.138.100.131 ip6:2607:f2f8:a760::2 ip4:206.125.175.2 include:_spf.google.com -allIt contains two regular IPv4 IP addresses, one IPv6 IP address, and an “include” mechanism that references Google’s SPF record. Decoding this tells us that I want those three servers (with those three IP addresses) to be able to send mail using my domain name spamresource.com, and the “include” for Google is because I am a user of GSuite/Google for Business

SPF has been around for a long time and enjoys a rich history. But there are some challenges with the way SPF works. In this article we take a look at these issues and at the barriers that are keeping SPF from being better. The post Why SPF Is so Funky in Today’s Modern World appeared first on dmarcian.

Another day, another ESP telling a client to publish a SPF include for the wrong domain. It shouldn’t annoy me, really. It’s mostly harmless and it’s just an extra DNS look up for most companies. Heck, we followed Mailchimp’s advice and added their include to our bare root domain and it’s not really a huge deal for companies with only a couple SaaS providers. Still, it’s an incorrect recommendation and it does cause problems for some senders who are using multiple SaaS providers and Google. Both Steve and I have written different posts about SPF over the years. In fact, the Authenticating with SPF: -all or ~all post is the most visited post on the blog. I’ve even written almost this same post, pointing out that a lot of ESPs have bad recommendations for SPF records. Steve’s written about the technical ins and outs of SPF records in DNS and…

Jennifer Nespola Lantz does it again! Last time it was a deep dive into the topic of IP warming, this time around it is everything you need to know about email authentication technology (and related bits), covering SPF, DKIM, DMARC and BIMI!Click on through for the first in the series (An Introduction to Email Authentication), and you’ll find links right there that can take you to the rest of the posts in the series. Or, if you’re looking to jump directly to a specific article, here you go:Part 1: Why Email Authentication Matters to Your Email ProgramPart 2: Understanding SPF AuthenticationPart 3: Understanding DKIM AuthenticationPart 4: Understanding DMARC AuthenticationPart 5: Understanding BIMI

There are several causes for DMARC failure. To ensure your emails are properly authenticated and your domain is protected from cybercrime such as spoofing, it’s critical to understand what caused DMARC to fail authentication. When it comes to cyber-attacks, 2021 has shown how unprepared businesses all over the world are. Although Google tries its best to block over 100 million spam messages every day, companies have lost millions of dollars in financial losses due to cybercrime. Spam comes in all shapes and sizes, so why are we so concerned about DMARC email authentication? 94% of all malware is downloaded to a computer via email, and the majority of people are not able to distinguish between a well-crafted phishing email and legitimate messages. DMARC, along with SPF and DKIM, helps you monitor who is sending messages from your email domain and protects your customers from phishing, spoofing, and other email scams. As