[Exim] "temporarily rejected after DATA"

This is partly a report, and partly a couple of open questions.
exim version 4.10

Both the mainlog and the rejectlog were reporting:

temporarily rejected after DATA

without any further detail - other than logging the mail's headers in
the rejectlog; and the sending MTA was retrying, and retrying, filling
up the rejectlog with copies of these headers.

With a little help from the usual local colleagues, it was worked out
that this was a consequence of our clause

    require verify = header_sender

in the DATA part of the configuration: the mails in question were
citing an address in their From: header whose domain persistently
could not be looked up in the DNS.

(So the first question is whether there shouldn't be more detail
logged in this situation as to why the "temporarily rejected after
DATA" situation is arising.)

Anyhow: what to do about it...

Well, we already maintain a small database of unreachable domains,
which we use for rejecting mails at RCPT TO time on the basis of
envelope sender, in order to break this kind of impasse where mails
get retried and "temporarily" failed for days before finally being
abandoned. I decided it would be handy to put the failing domain into
this database, and query it just before that verification of the
header sender which was causing the problem - well, not really a
_problem_, but a rather messy nuisance.

However, there doesn't seem to be an easy way to test the "header
sender". In the cases we had at hand, the failing "header senders"
were all in "From:" headers, but that wouldn't always be so.

Anyway, my first cut at this was

  deny hosts = ! +relay_hosts
       message = We are currently unable to accept mail from \
             $h_from: \n\
             because that mail domain is persistently unreachable or not\n\
             responding properly, for reasons that are outside our control.
       condition =  ${lookup {${domain:$h_from:}} \
         partial-dbm{CONFIG_DIR/unreach_domains.db}{1}{0}}

require verify = header_sender


and this does seem to do what's intended, though I make no claims
for beauty...

Any thoughts on a better way to handle this, or to code what I'm
getting at?

best regards