550 High probability of spam on all Confirmation Email to purchaser with Siteground

v1.5.7d Worked fine until a couple of weeks ago. Now email_template_checkout.html doesn't send to purchaser. It comes back to me. Siteground is the host.
The file looks like this - html.
$EMAIL_LOGO_ALT_TEXT $EXTRA_HEADER_INFO
$ORDERS_ACCOUNT
$EMAIL_TEXT_HEADER

$EMAIL_FIRST_NAME $EMAIL_LAST_NAME,
$EMAIL_THANKS_FOR_SHOPPING
$EMAIL_DETAILS_FOLLOW

$INTRO_ORDER_NUM_TITLE $INTRO_ORDER_NUMBER
$INTRO_DATE_TITLE $INTRO_DATE_ORDERED
$PRODUCTS_TITLE
$PRODUCTS_DETAIL
$ORDER_TOTALS
$ORDER_COMMENTS
$HEADING_ADDRESS_INFORMATION
$ADDRESS_DELIVERY_TITLE
$ADDRESS_DELIVERY_DETAIL
$EMAIL_TEXT_TELEPHONE $EMAIL_CUSTOMER_PHONE
$SHIPPING_METHOD_TITLE
$SHIPPING_METHOD_DETAIL

$ADDRESS_BILLING_TITLE
$ADDRESS_BILLING_DETAIL
$PAYMENT_METHOD_TITLE
$PAYMENT_METHOD_DETAIL
$PAYMENT_METHOD_FOOTER
$EMAIL_ORDER_MESSAGE
$EMAIL_FOOTER_COPYRIGHT
$EMAIL_DISCLAIMER
$EXTRA_INFO

Siteground responded on help with:

- The email was sent using a PHP script, as indicated by the X-PHP-Originating-Script: 825:PHPMailer.php header. As my colleague previously explained - emails sent from scripts can be flagged as spam, especially if they lack proper authentication.

- The subject line uses quoted-printable encoding: =?us-ascii?Q?ABC_Real_Estate_School_Order_Confirmation_No:_1?= =?us-ascii?Q?0210?=. This encoding is often used to handle special characters, but excessive use can appear suspicious to spam filters, suggesting an attempt to obfuscate content.

- The email contains words and phrases commonly associated with spam, such as "Order Confirmation" and "Click Here for the Course Link." These trigger words are often found in marketing emails and can raise red flags for spam filters.

- The Message-ID includes "www" in its domain part: <4rAKY91SDCM8oHeTTMi8nDxc6zfN0J57v0pFK5bvE@www.abcrealestateschool.com> . This format can sometimes be associated with automatically generated emails, which are more likely to be flagged as spam.

By addressing these issues, such as reducing the use of encoded characters in the subject line, avoiding trigger words, and ensuring the email is sent with proper authentication, you can improve the email chances of being delivered successfully.

....still no guarantee that it will send, I guess.
Does this make sense? Can anyone give me hints how I can fix some of this? All of my confirmation emails are ending up in Webmail with:

Mail delivery failed: returning message to sender


To protect your privacy remote resources have been blocked.

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

wendy.integritypm######################
host submission.antispam.mailspamprotection.com [34.149.79.66]
SMTP error from remote mail server after end of data:
550 High probability of spam 1tbPeh-0000000H0Xt-1grx
Reporting-MTA: dns; gvam1241.siteground.biz

Action: failed
Final-Recipient: rfc822;student
Status: 5.0.0
Remote-MTA: dns; submission.antispam.mailspamprotection.com
Diagnostic-Code: smtp; 550 High probability of spam 1tbPeh-0000000H0Xt-1grx

Thank you!

Do you send via phpmailer or via SMTP?

Functions_email.php lists:

use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\Exception;
use PHPMailer\PHPMailer\SMTP;

What value is at configuration->email->E-Mail Transport Method ?

E-Mail Transport Method is PHP.

If you setup SMTP then this will match what your hoster claims with authentication at top of their answer.

Thank you Shop Suey. I don't see that as an option. It lists smtpauth as preferred. Which one do you think is preferred - and not flagged as spam?

MOST SITES WILL USE [SMTPAUTH].
PHP
sendmail
sendmail-f
smtp
smtpauth
Gmail

smtpauth is fine

smtp is in your list too

Thank you! OMG. It was right there.

You're welcome.
Set either smtp or smtpauth up (the one which works best with you hoster's specs)
That could (or should) make the other issues obsolete