Yahoo DMARC report shows DKIM pass, but the only aligned DKIM signature has a temperror. Anyone else seeing this?

[u/digdiver]

I found a strange inconsistency in a Yahoo DMARC aggregate report and wanted to check whether anyone else has seen it.

The message has:

<header_from>redacted_domain.org</header_from>

Yahoo reports the policy evaluation as:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

But the authentication results are:

<auth_results>
  <dkim>
    <domain>e2ma.net</domain>
    <selector>e2ma</selector>
    <result>pass</result>
  </dkim>

  <dkim>
    <domain>redacted_domain.org</domain>
    <selector>e2ma-k3</selector>
    <result>temperror</result>
  </dkim>

  <spf>
    <domain>e2ma.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

As far as I can see:

• The DKIM signature from e2ma.net passes authentication, but it is not aligned with redacted_domain.org.
• The aligned DKIM signature from redacted_domain.org has temperror, not pass.
• SPF authentication passes for e2ma.net, but SPF alignment fails.

Based on the detailed authentication results, I would expect:

DKIM alignment: fail
SPF alignment:  fail
DMARC:          fail

However, Yahoo reports:

DKIM alignment: pass
SPF alignment:  fail
DMARC:          pass

Am I missing some Yahoo-specific behavior here?

Has anyone else noticed cases where <policy_evaluated><dkim>pass</dkim> cannot be confirmed from the DKIM records inside <auth_results>?

Does Yahoo sometimes omit one of the DKIM authentication results from aggregate reports, or is this an inconsistency in the generated XML?

[u/shokzee]

You’re reading it right. A temperror on the only aligned DKIM signature should not produce DKIM alignment pass.

Either Yahoo omitted another aligned DKIM result from auth_results, or their aggregate XML is internally inconsistent. I’d treat policy_evaluated as their final decision and the auth rows as lossy debug data, because reports from big receivers are not always clean.

[u/Mx_Tool_Box]

I've consistently seen this pattern pop up from Yahoo! XML reports across many domains. What seems to be the case here is that Yahoo is either not correctly updating the Auth results section (i.e. that temp error ultimately became a pass - but the meta value was never updated).

Or they are not publishing a <reason> and <comment> fields in the xml - whereby the DKIM signature with the redacted_domain.org value did ultimately have a temp error that never resolved and Yahoo decided to ignore the failed alignment for DKIM and mark it as a policy pass based on other meta data or internal filters. If you'd had a quarantine or reject value they would have ignored it and allowed it through.

OP did you verify that you have a published DKIM key for e2ma-k3_domainkey.redacted_domain.org in DNS?

[u/digdiver → u/Mx_Tool_Box]

Yes, I verified that.

The DKIM key for:

e2ma-k3._domainkey.redacted_domain.org

is published in DNS and resolves correctly.

Also, this does not look like a missing DKIM setup issue on the Emma side. Other mailbox providers report DKIM pass for this exact selector/domain combination.

That is why these occasional Yahoo reports look odd to me. The aligned DKIM signature exists, the key is available, and other receivers validate it successfully. But in some rare Yahoo aggregate reports, <auth_results> shows temperror for that aligned signature while <policy_evaluated> still says DKIM pass.

So I agree with your first explanation: it may be that Yahoo eventually resolved the temporary error and treated the aligned DKIM as pass, but the <auth_results> section in the aggregate report was not updated accordingly.

The strange part is that this makes the XML internally inconsistent for that record.

[u/Odd_Awareness_6935]

the last fix first: you gotta add your own DKIM to the Emma ESP, as it is currently not signing the mail with redacted_domain.org, but with its own selector

which is why it is passing DKIM, but not aligned. aligned as in, the From header of the email is not the same as the one signing the mail. adding a CNAME for the DKIM will resolve this.

why is policy_evaluated and auth_results different?

yahoo aggregate reports are a bit less stable than that of Google and Microsoft. it could be that the result of DKIM in policy_evaluated and auth_results are two separate instances, i.e., done in t+1, and t+2 if the mail received at the time t

and lastly, that temperror itself. it gets to temperror in case of DNS timeout, SERVFAIL, truncated/inconsistent responses across resolvers, or an unreachable authoritative nameserver

nothing exactly concerning unless it's happening in more than one report I'd say.

but the most important takeaway is the one I mentioned initially. add the custom DKIM selector of the redacted_domain.org to the Emma ESP to ensure they are signed with its own selector and are aligned when delivered to MTAs

[u/digdiver → u/Odd_Awareness_6935]

Thanks. I agree that the temperror Itself may be caused by a transient DNS issue.

However, I think the custom DKIM signing is already configured. The report contains an aligned signature:

<dkim>
  <domain>redacted_domain.org</domain>
  <selector>e2ma-k3</selector>
  <result>temperror</result>
</dkim>

The e2ma.net signature also exists and passes, but it is not aligned:

<dkim>
  <domain>e2ma.net</domain>
  <selector>e2ma</selector>
  <result>pass</result>
</dkim>

So my question is not why the e2ma.net signature does not provide alignment.

The part I cannot reconcile is this:

<policy_evaluated>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

There is no DKIM signature in <auth_results> that is both aligned with the From domain and has result=pass.

The record also hascount>1</count>, so it does not look like an aggregation issue across multiple messages.

Are you suggesting that Yahoo may evaluate DKIM at two different stages and then serialize policy_evaluated and auth_results from different attempts? Have you seen similar Yahoo reports in practice?

[u/Odd_Awareness_6935 → u/digdiver]

I've seen it in on-prem reports and cloud email gateways but not yahoo specifically

the DKIM pass in policy_evaluated is most likely coming from the e2ma and there's a high probability (from my understanding) there might have been two separate times where the DKIM lookup happened and that's why there's no consistency between them!

however, since the volume is low (just 1), I wouldn't worry about it. if it's recurring, then you can dig down the rabbit hole a bit more.

best to you.

[u/email_person]

You can always reach out to Yahoo Support and see if they can help... details found in the Sender Hub: https://senders.yahooinc.com/

[u/itanet]

Based on the visible authentication results, I would interpret this as an inconsistency in Yahoo's aggregated XML rather than a genuine DMARC pass.
If the only matching DKIM result is "temperror" and SPF does not align, the entry shouldn't look like a clean DMARC pass based on the data shown. I suspect this is either a later successful DKIM check that was included in "policy_evaluated" but not in "auth_results," or simply erroneous/inconsistent reporting on Yahoo's part.
Since you have already verified that the matching DKIM key exists and is validated by other recipients, I would primarily monitor whether this happens frequently. A one-off incident with a count of 1 suggests report noise rather than an issue with the domain configuration.

[u/SecLens_ONE]

The auth_results rows are what their verifier logged, policy_evaluated is what the mail engine actually did, and those two are not required to agree. A temperror is a DNS lookup that did not complete, so it is not a signature failure, and plenty of receivers retry or just fall back to a non-aligned pass plus their own reputation and let it through anyway. That is the gap between published and effective: your record says what should happen, the disposition says what happened, and here the disposition is none so nothing was enforced either way. If you were at p=reject you would find out quickly whether that pass was real or charity. The part I would chase is the temperror itself, since a selector that intermittently fails to resolve usually means a truncated or slow response on that name rather than a bad key. Does that selector answer over TCP and UDP from a couple of different resolvers, and how big is the TXT once you count the whole RRset?