According to RFC 6376:
6.3. Interpret Results/Apply Local Policy
It is beyond the scope of this specification to describe what actions
an Identity Assessor can make, but mail carrying a validated SDID
presents an opportunity to an Identity Assessor that unauthenticated
email does not. Specifically, an authenticated email creates a
predictable identifier by which other decisions can reliably be
managed, such as trust and reputation. Conversely, unauthenticated
email lacks a reliable identifier that can be used to assign trust
and reputation. It is reasonable to treat unauthenticated email as
lacking any trust and having no positive reputation.
In general, modules that consume DKIM verification output SHOULD NOT
determine message acceptability based solely on a lack of any
signature or on an unverifiable signature; such rejection would cause
severe interoperability problems. If an MTA does wish to reject such
messages during an SMTP session (for example, when communicating with
a peer who, by prior agreement, agrees to only send signed messages),
and a signature is missing or does not verify, the handling MTA
SHOULD use a 550/5.7.x reply code.
Where the Verifier is integrated within the MTA and it is not
possible to fetch the public key, perhaps because the key server is
not available, a temporary failure message MAY be generated using a
451/4.7.5 reply code, such as:
451 4.7.5 Unable to verify signature - key server unavailable
Temporary failures such as inability to access the key server or
other external service are the only conditions that SHOULD use a 4xx
SMTP reply code. In particular, cryptographic signature verification
failures MUST NOT provoke 4xx SMTP replies.
Once the signature has been verified, that information MUST be
conveyed to the Identity Assessor (such as an explicit allow/
whitelist and reputation system) and/or to the end user. If the SDID
is not the same as the address in the From: header field, the mail
system SHOULD take pains to ensure that the actual SDID is clear to
the reader.
While the symptoms of a failed verification are obvious -- the
signature doesn't verify -- establishing the exact cause can be more
difficult. If a selector cannot be found, is that because the
selector has been removed, or was the value changed somehow in
transit? If the signature line is missing, is that because it was
never there, or was it removed by an overzealous filter? For
diagnostic purposes, the exact reason why the verification fails
SHOULD be made available and possibly recorded in the system logs.
So it may vary based on receiving server configuration, but probably most will not mark as spam, especially if there is otherwise valid SPF and DMARC records and other indicators of a valid sender (IP address reputation, domain reputation, etc.).
