DNSSEC for mail

SPF, DKIM, DMARC and MTA-STS are all DNS records. Without DNSSEC there is nothing stopping someone on the path from answering a lookup with different records, and every one of those protections can be undone that way. Signing the zone is what makes the answers verifiable.

bash

# is the zone signed
dig example.com DNSKEY +short

# is the chain complete, ask a validating resolver
dig example.com +dnssec | grep -i "flags:.* ad"

Turning it on

Most registrars and DNS hosts do this with a switch now. The provider signs the zone and publishes a DS record at the registry for you. If yours does not support it, that is a reasonable argument for moving the domain somewhere else.

Do not sign a zone you cannot maintain

A broken chain is worse than no DNSSEC. If keys expire or a DS record is left behind pointing at a key that no longer exists, validating resolvers stop resolving your domain entirely, which takes your mail and your website with it. Automated signing from your DNS provider avoids this. Hand rolled signing you forget about does not.

What it does not do

DNSSEC proves the records came from the zone owner and were not tampered with. It does not encrypt anything, and it does not make a bad SPF record good. Treat it as the foundation the other checks stand on rather than as a fix by itself.

It also unlocks DANE, which lets you pin the certificate your MX presents. That is another way of forcing TLS, and it only works on a signed zone.