sender rejected. AUP#CXSNDR

If the alias is a real address, yes, this could be a problem.  As far as it working intermittently, well, this would be inconsistency of the third-party administer for Cox.

To prevent spoofing, spamming, maliciousness, Cox needs to verify the IP of the sending client.  If your IP address is using a functional, non-Cox address to send email through their servers, Cox would probably block it because "somebody" is using your IP address.  However, if Cox did suspect maliciousness, I don't know why Cox would reply with an NDR.  Is Cox being polite to malcontents?

Why are you using an alias with Cox...to mask your email address?

Do you have 2 accounts or profiles in Outlook?  One for Cox and the other for ABC?

If you use the Cox profile, does the ABC account list as a choice under the From address?

Did you previously send the email via Cox address and then later attempt to reply via the ABC address?

curtb knows lots about email settings.  I'm curious about the Secondary address in webmail.  If I enter a non-Cox secondary SMTP, can this address send/receive email via Cox?  Or is the Secondary address only for receiving forgotten credentials?

Okay...a little long-winded but here it goes.

You subscribe to an Email Hosting Company.  With this subscription, the Email Hosting Company provided you an email domain, such as admin@Californian.com.  Your customers use this address to contact you and when they do, the email goes to a server at the Email Hosting Company.

You don't host an email server at home and you don't log into a server of the Email Hosting Company.  However, the Email Hosting Company needs to send the email to you, so you have the Email Hosting Company send the email to Cox, your ISP.

You receive said email but when you want to reply, you don't want to reply with your Cox address.  You want to reply with admin@Californian.com.

Ten years ago, you contacted Cox, Cox said it's doable but Cox needed to authenticate you with the Email Hosting Company.  The authentication included you having a valid account, valid credentials, valid subscription, valid trustworthiness, etc.

This actual authentication process is Cox creating an SPF text script.  Cox enters the script into their server and sends you a version to send to the Email Hosting Company.

After the Email Hosting Company enters the script and Cox later authenticates you, Cox will send your email as admin@Californian.com.

However, every couple years, the script stops working.

From what you have written, I'll assume these scripts expire after a few years.  I don't know why the scripts would expire because if the Email Hosting Company doesn't authenticate you...perhaps you cancelled your subscription...Cox could just remove the script.  You wouldn't care because the Email Hosting Company is no longer sending you email.

It probably still is doable.  I don't know.  However, you need to establish an internal process to avoid these interruptions.  If these scripts expire at 24 months, you need to start renewing at 23 months.

While renewing, most reps, however, will not understand so you need an accurate, brief, concise template to explain the background, its process, what you need and for the rep to open a trouble ticket and assign to whichever dept does it.

Again, if the script is still authenticating you, I don't know why it would expire.  Perhaps this is a Cox rule.  Something changes every couple years.  What do you do every couple years...renew your subscription with the Email Hosting Company?  If so, perhaps the Email Hosting Company changes your "certificate."  Maybe Cox had downloaded your original certificate and after this process fails, downloads another.