Will a 1024-bit DKIM signature fail verification?

Not on key length alone. RFC 8301 requires verifiers to be able to validate keys from 1024 to 4096 bits, and says verifiers MUST NOT treat signatures using keys of less than 1024 bits as valid. At exactly 1024 the signature verifies.

How do I read my DKIM key length?

Query the selector TXT record with dig, strip everything before p=, base64-decode it and read it with openssl rsa -pubin -noout -text. The output line begins Public-Key:.

How do I move from 1024 to 2048 without breaking mail?

Publish the 2048-bit key under a new selector, switch signing to that selector, and leave the old record in DNS for about a week so mail already in transit still verifies against it.

Is a 1024-bit DKIM key still acceptable?

Q: Is a 1024-bit DKIM key still acceptable?

RFC 8301 section 3.2 says signers MUST use RSA keys of at least 1024 bits and SHOULD use at least 2048 bits. So 1024 is the floor the standard allows, not the size it tells you to use.

1024 bits is the smallest key RFC 8301 allows a signer to use. 2048 is what it tells signers to use.

Most domains we audit that still carry a 1024-bit key got it from a mail vendor's default years ago and never looked again.

What the standard says

RFC 8301, section 3.2, Key Sizes:

Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits. Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. Verifier policies can use the length of the signing key as one metric for determining whether a signature is acceptable. Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures.

Two things in that text matter. The keyword attached to 2048 is SHOULD, which in RFC 2119 language means do it unless you have a specific reason not to, and "the vendor set it up that way" is not a reason. The sentence about verifier policies uses can, not may: it is not an RFC 2119 keyword and it grants nothing. It records that weighing key length is a thing verifiers are able to do.

Note also the last sentence. Below 1024 bits a signature is not weak, it is invalid.

Check it yourself

Find your selector first. It is the s= value in the DKIM-Signature header of any message you send. Then:

dig +short TXT google._domainkey.example.com

Replace google with your selector and example.com with your domain. To read the key length:

dig +short TXT google._domainkey.example.com \
  | tr -d '" ' | sed 's/.*p=//; s/;.*//' | base64 -d 2>/dev/null \
  | openssl rsa -pubin -inform DER -noout -text 2>/dev/null | grep 'Public-Key'

It prints Public-Key: (1024 bit) or Public-Key: (2048 bit).

The fix

Rotate, do not resize. Generate a 2048-bit key under a new selector, publish it, switch signing to the new selector, and remove the old record after a week so mail already in transit still verifies.

If a vendor signs for you, their DNS setup page usually offers 2048 today even if it did not when you first set up. A 2048-bit key does not fit in one 255-character TXT string, so the record is published as two quoted strings. Every resolver joins them.

If you need to build the record from scratch, Sidemail's DKIM generator does it in a minute.

Run your domain audit at audit.humerly.com. No signup, no card.