Check whether senders can be forced to use TLS when delivering to your domain, or can be silently downgraded.
Encryption between mail servers is opportunistic by default. A sending server asks whether the receiver supports TLS and, if the answer is no, delivers the message in plain text anyway. That fallback is the weakness: an attacker positioned between the two only has to strip the STARTTLS offer out of the greeting, and every message is delivered unencrypted with neither end noticing.
MTA-STS closes it. You publish a policy saying that TLS is required for your domain and naming the hosts that should present certificates. A sender that has seen the policy caches it, and a stripped STARTTLS becomes a refusal to deliver rather than a silent downgrade.
It has two halves and both are required: a DNS record announcing the policy and its version, and a policy file served over HTTPS on a dedicated hostname. A record with no matching policy file achieves nothing. This check reads the DNS half; the policy file is fetched separately, and we say so rather than implying a completeness the check does not have.
It can, which is why the policy has a testing mode. Start there: senders report failures without acting on them, so you find a misconfigured MX before it costs you a message.
No, they are two halves of one decision. MTA-STS enforces TLS; TLS-RPT is how you find out when TLS delivery failed. Publishing one without the other means either enforcing blind or watching without protecting.