Key size and algorithm

You can read a key’s size off its record without decoding anything, because the first bytes of a DER-encoded public key describe its own structure and base64 encodes them to a fixed prefix.

Reading the size from the prefix

Two live records, checked the same day, showing both RSA sizes still in service:

dkim.mcsv.net.
"k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDbNrX2cY/GUKIFx2G..."

fm1.fastmail.com.dkim.fmhosted.com.
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq2dC4DR0fSK..."

If you would rather confirm than trust a prefix, the base64 decodes to a DER key that OpenSSL will describe:

dig +short TXT fm1._domainkey.fastmail.com \
  | tr -d '" ' | grep -o 'p=[A-Za-z0-9+/=]*' | cut -c3- \
  | base64 -d | openssl rsa -pubin -inform DER -noout -text | head -1

Public-Key: (2048 bit)

Where the floor is

RFC 8301 sets the minimum at 1024 bits and the recommendation at 2048, and removes SHA-1 from the permitted hashes entirely. 1024-bit RSA has been factored under laboratory conditions; it is not broken for a casual attacker and it is not a size to choose in 2026.

• Do not go above 2048. A 4096-bit key produces a record that many DNS providers cannot store and some resolvers will not return over UDP. The failure mode is not weak security, it is no verification at all.
• 1024-bit is usually a vendor default from a decade ago rather than a decision. If a platform gives you a 1024-bit key, ask for a 2048-bit one; most will now issue it.

Ed25519

RFC 8463 added k=ed25519. The keys are 32 bytes — a DKIM record that fits comfortably in one TXT string — and the signatures are fast. The catch is deployment: a verifier that does not implement it treats the signature as unverifiable, not as valid.