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.

This is awesome. Thanks! Sensible, easy to use, easy to understand the results.

I've been trying the google one, for example, and it doesn't even work. "request timed out." Fishy, because yours works great.

much appreciated!

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.

If you're going to do this you should also check for k=rsa since other key types will be different lengths. But I'd really recommend something like in the other comment where you base64 decode and parse it with something like openssl.

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."

thanks, that's also what I was not understanding from the article

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).

Was redfin aware you were trying to break their DKIM record?

It was already broken.

This comment also serves as a public notice that I'm going to factor all the 512-bit DKIM RSA keys out there from now on. Start migrating.

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.

Dmarcchecker is one of those great things on the internet that you never knew you needed it until you really needed it. Thank you so much for your work on this note project, it's really helpful to us in monitoring our mail security.

Cool, this is helpful. Thank you!

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.

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.

Thank you - and would you be open to white labeling?

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.

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.