From RFC 7208:
8.5. Softfail
A "softfail" result ought to be treated as somewhere between "fail" and "neutral"/"none". The ADMD believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.
The ADMD wants to discourage the use of this host and thus desires limited feedback when a "softfail" result occurs. For example, the recipient's MUA could highlight the "softfail" status, or the receiving MTA could give the sender a message using greylisting [RFC6647], with a note the first time the message is received, but accept it on a later attempt based on receiver policy.
The key phrase here is "SHOULD NOT", thus the receiving server can enforce other policies and still be within the standard.
From RFC 7489:
reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction.
The key phrases here are "wishes" and "SHOULD", thus the receiving server can enforce other polices and do whatever they want during the SMTP transaction while still being within the policy.
My best guess is that if the receiver is enforcing DMARC, then p=reject will be the overriding policy.
Also from the same section in RFC 7489:
none: The Domain Owner requests no specific action be taken regarding delivery of messages.
The key phrase here is "requests". In practice, this is nearly always treated the same as having no DMARC policy, other than to send reports since this policy is used for testing.
As a side note, you appear to have a common misunderstanding of what DMARC is testing. DMARC tests alignment, which is not what DKIM or SPF are testing, so those tests can both pass while DMARC fails.
