> For DMARC to pass, DKIM and/or SPF checks need to pass and the domains must be in alignment.
AFAIK this is incorrect.
It is not "and/or" but rather "or" - only DKIM or SPF needs to pass. There is no method to require both.
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.
[1] https://blog.cloudflare.com/sending-email-from-workers-with-...
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.
Tech docs for the curious: https://support.mailchannels.com/hc/en-us/articles/456589835...
Appreciate all the questions and criticism here. reply
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"
The english language being ambigious or not making sense is not a new issue. All i know, is i almost always see "and/or" used to mean inclusive or.
Also the dictionary seems to agree it means inclusive or: https://en.m.wiktionary.org/wiki/and/or
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.
But that is common sense.
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.
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!
1. https://easydmarc.com/blog/spf-too-many-dns-lookups-error 2. https://easydmarc.com/tools/spf-lookup
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
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
I use it for sending reports to upper management, who just want to see big green ticks next to our domain names:
> 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.
[1] https://support.apple.com/en-us/HT210425
[2] dig +noall +answer -t TXT <EMAIL_DOMAIN> | grep -i SPF
[3] dig +noall +answer -t A <HOSTNAME>
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
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".
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.
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.
See how DMARC, SPF, and DKIM work interactively - https://news.ycombinator.com/item?id=29869266 - Jan 2022 (108 comments)
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.
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.