Within Proofpoint you should be able to set up a manual mail route (to override DNS/MX) to some external domain so that it uses only SMTP rather than ESMTP. You do this by prefixing the destination with "SMTP:", e.g.
gmail.com → SMTP:gmail-smtp-in.l.google.com.
This will cause your side to issue an old SMTP "HELO" rather than a new "EHLO" and STARTTLS should not be possible. (This requires both sides to be protocol compliant, it is possible to attempt STARTTLS over plain SMTP in some cases.) If you have an enforced TLS rule for that domain, outbound email should fail.
Or, a network solution, you could use one of many TLS stripping/MITM tools (e.g.
striptls), this performs the
equivalent of the above by intercepting traffic to prevent STARTTLS being advertised/detected/enabled.
Otherwise, with any modern SMTP server supporting STARTTLS, if you configure only a set of ciphers that require RSA authentication (
openssl ciphers -v aRSA) but do not configure a key and certificate then STARTTLS will not be supported.
There's a subtle distinction between TLS and STARTTLS, the latter is performed as an in-protocol upgrade: within the SMTP exchange the "STARTTLS" verb is issued and then TLS is negotiated (which is why it has security limitations).
With "regular" TLS the TLS happens first, and can be used for any protocol without first extending it to support that type of upgrade. There
is was an old standard for SMTP with TLS, ssmtp subsequently smtps — it never caught on (just like HTTP with STARTTLS). SMTPS on TCP/465 has since been resurrected in RFC8314, but as Steffen notes this is not for MTA-to-MTA, it's only for MUA (client) submission.