Great way of pushing the critical email services we all need to reduce spam. While I have always wanted SPF, DKIM and DMARC to be enough of an incentive for the businesses i work with, reputation is often not enough of a driver to prioritise the investment.
But fret not! For when you are dealing with companies which want to communicate with customers in a trusted way, there is a marketer's dream standard - Brand Indicators for Message Identification (BIMI) - now security isnt the only outcome, you get a pretty logo too! https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
I have used BIMI at multiple companies now which talk about Customer Experience to drive the proper (P=Reject) implementation of DMARC.
> Unfortunately, neither SPF nor DKIM provides a complete solution for preventing email spoofing. SPF authenticates the HELO/MAIL FROM identifier and DKIM authenticates the d= field in DKIM-signature header: neither of them authenticates the From header displayed to the end-user, which means that even if an email passes SPF and DKIM validation, its From address can still be forged.
A lack of DMARC+ on an email domain is definitely a problem, but DMARC+ alone still doesn't solve the "is this the real sender" problem.
We literally just ran into another issue with SPF: the SPF Lookup Limit [1] , which could cause receiver servers to bounce your email back with an "SPF PermError".
If your SPF record causes receiving mail servers to lookup too many domains, some receiving mail servers will reject your email, even when the email itself passes all SPF/DKIM/DMARC checks.
The tricky part of that to diagnose - which [1] talks about, and links to a tool to diagnose it [2] - is that there may be additional lookups that the servers you list in your SPF cause to happen.
So you could have an SPF record with only 4 servers, but if one of those servers causes 7 additional lookups, you might have over 10 SPF lookups. 10 seems to be a growing-in-popularity limit on SPF lookups.
So even if you have SPF, DKIM, and DMARC setup, make sure you don't have too many lookups caused by your SPF record!
As a practical example -- it's pretty common for companies to delegate email to a provider like Gmail. Some infosec folks consider this best practice, and Google will allow you to configure DMARC to say that only messages originating from their servers are legit.
However, this does mean that anyone who can suborn Google's mail servers can use them to spend spoof emails that DMARC will rate as legitimate -- and last month, there was announcement of vulnerabilities (since fixed) which allowed a third party to abuse email-forwarding features to do exactly that. See https://arxiv.org/pdf/2302.07287.pdf
It inst perfect, but it doesn't need to be unless your risk is disproportional to the market. Risk will always be there, you just need to manage it inline with your corporate risk tolerance - and implementing DMARC to P=Reject is most likely going to (very likely exceed) that approach.
Yes, some companies have elevated risk here (Banks, Payment Processors, Social Media companies) - but honestly most don't.
Btw - this is as much an acceptance as a survival strategy - nothing will ever be perfect, not without significant cost & impact elsewhere. Survival of the fittest these days is managing (and please the understanding of) risk better than others
Does anybody know open-source or, at least, free way to process DMARC reports?
I have several e-mail domains with SPF, DKIM and DMARC enabled, and it works, but I have two annoying problems with DMARC:
(1) Some sites like to send DMARC reports which says "you send us 3 messages, everything is OK, all checks are passed, you are clear".
(2) Sometimes my domains are used to (try to) send spam via other servers and I got DMARC reports like "this <IP> tired to spam with your domain in HELO/FROM and we killed it, as checks failed".
Both reports are of no use for me: I don't want to know, that my users send mail to @gmail.com and @mail.ru (first reports) and I can do nothing about second case, as these <IP>s are not <IP>s of my server, so what should I do?
Some filter or dashboard will be very useful, as unpacking & checking XMLs by hands are very cumbersome.
Here's a script I wrote for myself:
https://github.com/hannob/rpter
It gives a summary of reports, and details for failures. Not super sophisticated, but should be simple enough to extend. Also parses SMTP-TLS reporting.
This was a recent problem with Cloudflares partnership with MailChannels[1] that allowed email spoofing which was related to this.
The basic problem being that mailchannel did not require authentication - cloudflare workers could just hit an API endpoint on mailchannel to send email. Mailchannel required you to add an include: record to your SPF policy. This allowed anyone to impersonate anyone else due to mailchannel being a valid sender for all domains.
Only ~400 domains of the 2M hosted had DKIM set up but even if they did the passing SPF caused DMARC to pass.
Appreciate the skepticism; it keeps us on our toes. Let's cut to the chase:
Domain Lockdown: We added this to our Cloudflare Workers integration. It mandates a DNS TXT record to authorize a Worker to send emails from a specific domain. You can't forge the CF-Worker header, so impersonation is off the table.
Pre-Lockdown Vulnerability: Yes, we were more exposed before. Thanks to the researchers who pointed it out, we've patched this up with Domain Lockdown.
SMTP Relay & Web Hosting: Domain Lockdown isn’t mandatory yet in the rest of our service for the web hosting industry. But we’re developing updates for our cPanel WHM plugin and other integrations to make this scalable for millions of domains. Note that our service has to work for applications like public mailing lists where locking the sender domain down breaks stuff.
Scale & Standardization: We service a broad range of configurations. Rolling out universal changes takes time. We're also working with industry groups like M3AAWG to push for improvements to DMARC and other standards to help everyone be more secure.
I didn't mean anything negative towards MailChannels - I know this is a weak link in the chain for many people. I did know it was resolved and I should have mentioned that but I couldn't figure out the search query to find that post.
I mean i dont think requiring dkim would stop attacks based on totally broken authentication. In that scenario, mailchimp might as well be signing the emails for the incorrect domain as well.
I think its unambiguous. If they want "and/or" to just mean inclusive or why not just use "or". Its shorter, simpler, easier to understand. I also feel "and/or" in general usually means either option are possible/acceptable.
The point I was making is that "DMARC passes if DKIM _and_ SPF passes" and "DMARC passes if DKIM _or_ SPF passes" are both true - you can't specify "DMARC passes if, and only if, DKIM _and_ SPF passes"
I agree the statement "DMARC passes if SPF (inclusive or) DKIM passes"
I was only trying to point out that "and/or" is ambiguous (which we agree, and Wikipedia even agrees - 2 paragraphs for a defintion, 5 paragraphs of criticism) and one of those ambiguities is thinking it means logical AND - which is something DMARC does not do.
Using just "or" would have been fine and conveyed the same meaning as it does now.
And if you use IP address literals instead of paying for a domain, you get a free SPF:
If the "From:"/"Reply-To:" fields contains only the email address with the IP address literal, you get your "SPF" and it gets a much better score in order to avoid grey listing for the first transaction. And if there are no URLs in the content, even better.
I really appreciate the iterative way it goes through the process. It's been a few years but this would have been a godsend at a previous company when we were trying to move to self-hosted email sending with all the proper security measures.
I sent an email via Apple’s “Hide My Email” service [1].
> Unhandled Promise Rejection:
> TypeError: a.from.replace(/[<]/gi," is not a function. (In 'a.from.replace(/[<]/gi,"(")', 'a.from.replace(/[<]/gi,"' is undefined)
> dist.min.js:3:32767
This error occurred after the interface began displaying the following information:
> Here are the message headers and message body:
> DKIM-Signature: d=icloud.com s=1a1hai
It’s been over a year since the website was featured on Hacker News (January 10, 2022), so I suspect that the JavaScript code may have become outdated and non-functional. It’s possible that it never supported Safari browsers in the first place, or perhaps it’s a combination of both issues. Nevertheless, I’ve learned a lot from the initial [2] and second [3] parts of the DMARC test, which gives me some insight into what might be happening in the subsequent steps.
I also get the same error (in Chrome) when testing a forged email:
telnet learndmarc.com 25
Trying 87.239.13.42...
Connected to learndmarc.com.
Escape character is '^]'.
220 allspark.uriports.com ESMTP URIports Mail Portal 1.03.2 Sun, 01 Oct 2023 21:55:40 +0000
HELO there
250 allspark.uriports.com Hello <my host> [<ip address>]
MAIL From: me@example.com
250 OK
RCPT To: ld-49101f55f6@learndmarc.com
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
.
250 OK id=1qn4QF-00CUhd-5j
It's funny because while I was typing this, it's like "you don't have to write a love letter". Maybe not, but you do have to repeat the From: and To: header in the data segment, I guess.
I remain amused at how much email I've sent over the years with "HELO there" instead of my hostname in there. I also wonder what % of internet traffic is "Enter message, ending with . on a line by itself".
You sent an email without a "from" field and it broke. Programmer didn't think to test for bad users doing bad things. Nothing special here, no big conspiracy.
If this is true and Apple's service does leave out a "from" header (it may just as well be a parse error somewhere on the website's side) that would definitely be on the mail forwarding service, not on this particular website.
RFC 5322 and RFC 2822 specify that at least and at most one From: header must be present. Mail services that don't add at least some kind of fake From header aren't spec compliant and should probably expect error and delivery problems. RFC 2822 is over 20 years old now.
In theory Apple's service could only be RFC 822 compliant, but this does pose a big interoperability problem for its customers.
As DMARC relies on the RFC5322.From address, omitting it will lead to errors. To avoid these errors, emails lacking this address are currently being ignored.
It is absolutely astonishing that we rely on layers and layers of shims/compatibilities/hacks to keep a technology that was well-meaning and ideal 30ish+ years ago running in the 21st century.
Same thing in the VOIP/telecom space.
Microsoft recently had issues with mail deliverability - most of our O365 tenants had a notice reminding us to check SPF, DKIM, DMARC (we're configured properly already) - some of our tenants were having issues mailing smaller mail providers (ISP-level) because the small provider is outright blocking IPs and IP ranges due to spam coming from the same IP address/mail server we're trying to send from.
Fun fact: sns.amazonaws.com still has no DMARC record. This is where AWS SNS messages originate from unless you use a custom domain, and it's where all CloudWatch alerts come from (no-reply@sns.amazonaws.com)
Whitelists for what? Having a pre-determined whitelist for domains allowed to send to your domain is not common. That would defeat the purpose of e-mail.
People, don't forget to properly set all these checks for DNS failover.
I saw companies got scammed, because they used default settings in Exchange Online.
And attacker just made the DNS "unavailable" for brief moment and all phishing emails passed. Because MS server responded with DNS "temp error" and pass all emails as not a spam.
(detailed: received-spf: TempError (protection.outlook.com: error in processing during
lookup of <phished domain>: DNS Timeout)
and DKIM is checked on domain of sender's SMTP server, in this case attacker's server used for phishing
)
Then I had the great experience with MS IT/security support, people there can't even understand how emails works, very funny and sad experience. I hope outsourcing works for them.
DMARC is and has always been...fine, save for the fact that most phishing / exploits are sent using cousin domains. Is a DMARC policy necessary and a great security measure? Sure. Is it a domain identity security game changer?... no way.
But fret not! For when you are dealing with companies which want to communicate with customers in a trusted way, there is a marketer's dream standard - Brand Indicators for Message Identification (BIMI) - now security isnt the only outcome, you get a pretty logo too! https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
I have used BIMI at multiple companies now which talk about Customer Experience to drive the proper (P=Reject) implementation of DMARC.