RFC 8463 — Ed25519 for DKIM

RFC 8463 adds Ed25519 to DKIM, alongside the RSA signatures RFC 6376 defined. It introduces the k=ed25519 key type and the ed25519-sha256 signing algorithm.

Why a second algorithm

RSA keys are large, and DNS makes that awkward. A 2048-bit RSA public key does not fit in a single 255-character TXT string, so it has to be split into multiple quoted strings — a step DNS control panels handle inconsistently and a common cause of a key that looks published and does not resolve correctly.

An Ed25519 public key is 32 bytes. Base64-encoded it is 44 characters. The entire record fits comfortably:

v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=

It is also faster to verify and considered at least as strong as 2048-bit RSA.

Why you should not switch to it alone

Verifier support is not universal. A receiver that does not implement RFC 8463 sees an algorithm it does not recognise and treats the signature as unverifiable — which, if that is your only signature, means no DKIM pass and a DMARC result resting entirely on SPF.

The intended deployment is dual signing: sign each message twice, once with RSA and once with Ed25519, under different selectors. Verifiers use whichever they support. RFC 6376 already allows multiple signatures, so nothing new is needed to do this.

What it means in practice

For most people, nothing — your provider chooses the algorithm and almost all of them still use RSA. If you sign your own mail and control the selectors, dual signing is a reasonable thing to do and costs one extra DNS record.

If you see k=ed25519 in a report or a record you inherited, it is legitimate and modern, not a misconfiguration.

Read it: rfc-editor.org/rfc/rfc8463