I think it is probably the reason. A lookup with the uppercase version makes it get cached with the uppercase label if (and only if) it's not in your recursive nameserver's cache to start with.

So to test this, you either have to flush the resolver's cache first, or try a lookup of something that's not likely to be in the resolver's cache to start with, like this domain name I own:

dig _dmarc.newWAVErevisited.com TXT

When I try that one repeatedly, the first time I get this result, which is not from the resolver's cache (note the 60 second TTL):

;; ANSWER SECTION: _dmarc.newwaverevisited.com. 60

But subsequent times I get the uppercase "WAVE" from the cache:

;; ANSWER SECTION: _dmarc.newWAVErevisited.com. 57

(This is with BIND 9.10.3 as the recursive caching nameserver in my case.)

So it does seem like this problem would happen when someone "From: something@AOL.com" sends a message *and* the DMARC record isn't in the resolver's cache.

(I've seen aol.com DMARC mitigations fail on two separate occasions within the last month, but the first time I couldn't trace the root cause because the uppercase entry had already expired from the cache. I just happened to catch it quickly today by good luck.)

** Changed in: mailman Status: Triaged => Fix Committed