DKIM signs each outgoing message with a private key. The matching public key is published in your DNS under a selector, so a receiving server can fetch it and verify the signature.
Two things follow from a valid signature: the message really was authorised by that domain, and the signed parts have not been modified since.
Selectors let you rotate keys
The DNS record lives at selector._domainkey.yourdomain.com. The selector is an
arbitrary label, which is what makes key rotation possible — publish a new key
under a new selector, switch signing over, then retire the old record once no
in-flight mail depends on it.
It also means several providers can sign for the same domain simultaneously, each under its own selector, without conflicting. That is genuinely useful when you route marketing and transactional mail through different providers.
Use a 2048-bit key
1024-bit keys are still widely accepted but are the weaker option, and some providers now treat them less favourably. Use 2048-bit wherever your provider and DNS host support it.
DKIM survives forwarding, SPF does not
This is the practical reason to have both. When a message is forwarded, the forwarding server is not listed in your SPF record, so SPF fails. The DKIM signature travels with the message and still validates, so DMARC can still pass on the DKIM side.
Mailing lists are the exception — many modify the subject or append a footer, which breaks the signature. That is a known limitation rather than something you have misconfigured.
Alignment still matters
A valid DKIM signature is not automatically enough for DMARC. The signing domain
has to align with the domain in the visible From: header. A message signed
with your provider’s key rather than your own will verify perfectly and still
fail DMARC — which is why signing on your own verified sending domain matters
more than merely having DKIM switched on.