dane-required: a sender required DANE and yours was not usable
By Jose Pollman · Published · Updated
dane-required means the sending server insisted on DANE for your domain and could not use it: your TLSA records were missing, unusable or not backed by valid DNSSEC. The sender chose to require DANE, but the trigger is usually yours, such as TLSA records broken or left stale after a migration or certificate change.
How it appears in a report
"result-type": "dane-required"What it means
The sending server was configured to insist on DANE for your domain, and could not use it — your TLSA records were missing, unusable, or not backed by valid DNSSEC at the moment they tried.
Could be either end. This can originate at either end, so the failure reason and your own configuration are both worth checking.
Worth being clear about the direction, because it is easy to get backwards: you publish TLS-RPT for your own domain, and senders report the failures they hit while delivering to you. So policy-domain and receiving-mx-hostname in your reports are yours, and sending-mta-ip belongs to whoever sent the report.
Why it happens
This is the one type where the sender’s own policy is part of the story: they chose to require DANE. But the usual trigger is at your end — TLSA records withdrawn or broken while senders still expect them, often mid-migration or after a certificate change.
How to fix it
- Confirm your MX hosts publish usable TLSA records and that DNSSEC validates, since DANE is unusable without it.
- If you deliberately withdrew DANE, expect these until senders stop expecting it; the records should be removed cleanly rather than left broken.
- If you never intended to run DANE, check whether stale TLSA records exist for your MX hostnames.
Related
tlsa-invalid— your DANE TLSA record does not match your certificatednssec-invalid— your DNSSEC validation is failing- Setting up TLS-RPT — the record that makes senders send these reports