DKIM, MTA-STS, TLS-RPT and BIMI
The DNS records that complement SPF and DMARC for modern mail domains.
Definition and scope
The DNS records that complement SPF and DMARC for modern mail domains.
Use this reference to establish the meaning and limits of the result before changing production configuration.
How it works
DKIM publishes a public key under selector._domainkey. MTA-STS advertises a version in DNS and serves a policy over HTTPS. TLS-RPT names report destinations for transport encryption failures. BIMI points supporting receivers to a brand indicator.
How to read it
A DKIM selector comes from the sender configuration and cannot be discovered reliably. MTA-STS TXT presence does not prove that its HTTPS policy is reachable. TLS-RPT and BIMI syntax should be checked separately from provider-specific eligibility.
Correct and incorrect examples
Compare the normalized examples. Technical values are illustrative and use documentation ranges or reserved names.
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."unknown._domainkey.example.com → DKIM = ∅| Element | Role | Example |
|---|---|---|
| DKIM | selector._domainkey | v=DKIM1; p=… |
| MTA-STS | _mta-sts TXT only | v=STSv1; id=… |
| TLS-RPT | _smtp._tls | v=TLSRPTv1; rua=… |
| BIMI | selector._bimi | v=BIMI1; l=… |
Common problems
Empty DKIM keys revoke a selector; unknown selectors do not prove DKIM is absent. Mismatched MTA-STS IDs, stale policies, invalid report URIs and assuming BIMI replaces DMARC are common mistakes.
Practical checklist
Inventory every sending platform and selector, rotate keys without removing the old one too early, validate DMARC first, and monitor TLS reports before enforcing transport policy.
Standards and primary references
These primary specifications define the protocol behavior. Provider documentation may add operational requirements but cannot replace the standard.