I built a free DMARC/DKIM/SPF checker: https://dmarcchecker.app/. No usage limits, no ads—just a small footer link to one of my other projects. Made it for the exact reason you mentioned.
An easy way is to check the length of the p= value in the DKIM record. If it's around 216 characters, it's likely a 1024-bit key. A 2048-bit key usually has about 388 characters.
The DKIM verification failed with the result "dkim=policy (weak key)," as it should according to RFC 8301: "Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures."
I guess most of these keys are decades old and no longer in use. They're likely just sitting in the DNS because someone forgot to delete them. Now, no one's sure if they're still needed and is afraid to remove them in case it breaks something. Or maybe they're still used by a legacy system, and no one realizes the impact an old DKIM record could have.
I agree, but to be precise, it was 1,726 out of 476,617 DKIM keys found across those 1M domains, or about 0.36%. Since it's impossible to determine all DKIM records a domain might have from the outside, I used a list of commonly used selectors (e.g., "default' or 'key1") for the search. It's likely there are additional short keys under selectors I didn't check.
Shameless plug: My DMARC Checker at https://dmarcchecker.app/ displays a warning message if it encounters a DKIM signature header with an 'l=' tag:
"The 'l=' tag limits how many bytes of the email body are included in the body hash. This may allow an attacker to alter/expand the message in a way that it still passes DKIM validation."
Additionally, the tool alerts you to the use of weak RSA keys or SHA1.
By the way, less than 0.4% of all emails checked make use of the 'l=' tag.
You are correct, the mail server is currently configured to only receive emails via IPv4. This setup is not uncommon as most major email providers have IPv4-only MX records (with Gmail and Yandex Mail being rare exceptions that support IPv6).
It might be a good idea to provide a different email address whose mail server explicitly requires IPv6. I'll think about it. Thanks for bringing it up.
We've just launched the app this week. While white labeling is a possibility down the road, we're currently focused on refining it and gathering user feedback.
Thanks for the feedback, much appreciated! It looks like you've flattened your SPF record, causing a large number of log messages. I'll see what I can do to better highlight the line that produces the 'pass' result.
There was a small bug in our DMARC record parser (it didn't like the semicolon at the end of the record). Sorry for that. Your DMARC record is definitely correct. The issue should be fixed now.
Also, thanks for the idea about circumventing DNS caching. I'll look into adding that feature.