awulf

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 published the article today, though it was written a few months ago (when the DKIM record was still online).

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.

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.