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.
Basically, yes. In practice, there's a bit more to it. The user code is wrapped into an "async function(input)" (so you can use async/await) and run inside a worker inside a sandboxed iframe (for security reasons and for being able to stop the execution). There's also some additional code for catching errors and parsing the error stack.
The main reason is ease of use. Of course, you can use JSFiddle to create an HTML page with a textarea field and a button that triggers your code and outputs the result to the console or somewhere else. But that's a lot of overhead for a simple text editing task.
TxtFiddle is specifically built for text manipulation tasks and reduces the amount of code you have to write to a minimum. There's also a (growing) list of templates that you can choose from (see the "New" menu). Another differentiating feature is the ability to abort a running script (i.e., in the case of an accidental infinite loop).
That's strange, your grep looks fine to me. Is it possible that you have configured nginx to use different log files for different locations (or maybe don't log at all)? Other than that, I don't have any good explanation.
This is a repost from about two weeks ago. Back then, I had to remove the link after a few minutes because my little server couldn't handle the traffic spike and ran out of memory.
During the last days I have added more server power and did some major changes to make the service more robust. I hope the work was worth it.