DMARC Fail: 7 Causes and How to Fix Each(dmarcguard.io) |
DMARC Fail: 7 Causes and How to Fix Each(dmarcguard.io) |
One of those is mine (I have SPF records but no DKIM or DMARC). I don't seem to have any issues. I'm not a "bulk sender" though, and my domain has existed since 2002.
Meanwhile a whole lot of the spam I'm seeing comes either through gmail/outlook.com, or from domains with valid DKIM setups (either because the domain got owned, or because it was just 'correctly' set up... for spamming)
Most times I have to deal with issues are companies sending email enquiries from their website to their Office 365 hosted address when the sender is their own email address. Usually requires all 3 to avoid SPF/DMARC fails or mail going to Junk/Quarantine.
Many do, but not all. One of the hats I wear at work is mail server administrator, and it's astonishing the number of spam and phish attempts using our company domains that I see from all over the world, all of which bounce off due to SPF.
I've noticed too in recent years that some phishing spammers seek out established domains with liberal SPF (either no SPF or ~all) and use those for their phishing attempts. Some of the most common I've seen, ones that stuck in my mind, were secure.net, yale.edu, and servermail.com.
A point I have to reiterate to colleagues over and over is that SPF and DKIM are a form of identity management for domains. They're designed for phishing prevention, not general spam prevention. If you register a domain for any purpose, the first thing you should do, in my opinion, is stick a "v=spf1 -all" in DNS for it. Otherwise, phishing spammers may ruin its reputation before you get a chance to use it.
We configured a new email sending service and kept the DNS TTLs low on the TXT records for SPF, DKIM, and DMARC, in case we needed to change them. We saw a lot of mystery failures for emails going to Microsoft inboxes (M365 and Outlook.com). Changing the TTLs to be very long (86400 or more) caused a large improvement within a day to two.
The only way I can think to explain this is that some of their DNS lookups would time out if they had to follow recursion back to our DNS provider. Lengthening the TTL increased the chance the records would be cached locally to Microsoft’s systems and therefore served faster.
The only other explanation I can think of is that MS prefers longer TTLs as a matter of policy and downgrades based on that. But usually they publish policy preferences like that and I could not find one.