Forum Discussion

MMike's avatar
New Contributor
3 years ago

AUP#CXSNDR -- error trigger depends upon message content

The AUP#CXSNDR with 550 - 550 coding report claims that the sending email has problems with email configuration:

Cox requires that all sender domains resolve to a valid MX or A-record within DNS. Ensure that your domain has a valid MX or A-record within DNS.

The AUP#CXSNDR only shows up in CXSNDR form as a sender configuration error:

There was a problem with the sender's domain. Your email failed authentication checks against your sending domain's SPF, DomainKeys, or DKIM policy.

The AUP shows up only in an Authorization in conjunction with CXMJ error code:

Email sending blocked due to suspicious account activity on primary Cox account. To secure your account, please reset all Cox account passwords at Contact Cox at to remove block and reference error code AUP#CXMJ. Reset your password at or visit to sign in to your primary Cox account and go to the My Profile page. Then, contact Cox at to remove the block referenced by error code AUP#CXMJ.

These all point back to Cox.  Various "plaintiffs" (I suspect this is the proper word, but not used here regarding legal proceedings) have complained about this AUP ("authorization"?) and CXSNDR (comm. SeNDeRf?) error.  I have had to work around it a few times in the past and again today.  Those previous questions have had their discussions locked out.  You can check.  At least two entries exist as of this writing.  I tried to send two sentences of text accompanied by a political cartoon to my bro-in-law.  Boom! 550-550 AUP#SNDR error, "see error code page"  Then I deleted the http prefix and got the same error.  I deleted the link entirely and the message succeeded, no error.  Then I broke the link into text bits on multiple lines, and voila! no error.  Then I copied the image file directly into the email inline.  Voila! no error.

It seems clear that the content is what was generating the error, not the sender configuration or authorization.  Other questions include:

This second one, by the way, includes a notice that 550 error is a "spam detection" indication.  This customer noted that his unsuccessfully forwarded email had the word "SPAM" in the Subj: line.  That was a trigger I ran into, but did not find an explanation at that time.  One respondent recommended that the customer forward the message to a "" address:

"....forward the [item] that was marked as Spam to this email address: . That will make sure that our system does not flag these messages as spam. The Error Code 550 That you received is saying that our system viewed the message as spam."

The same buried "considered as spam" hint is buried in responses to this question:

This information is not clearly pointed to in the link supplied by COX.  In my case, I found it sufficient to de-link the URL and break it up onto multiple lines.  That should not be necessary, and indicates (to me) a certain laziness on the part of s.p.a.m filter writers and a deficiency of some sort in the error code dictionary writers.  In my most recent case, the image could be sent in-line but not via link.

One of the above customers noted with disgust that the COX's question respondents "would not believe" that the error trigger was content-based in spite of his seemingly clear demonstration of this.  My experience agrees with his.  But other content-based triggers exist than this simple word.  I do not know exactly what the trigger is, but it clearly has a content component and is not solely account configuration based.

Please fix the issue or improve the descriptions in the error-codes.html file, preferably with hints about avoiding these problems.

2 Replies

Replies have been turned off for this discussion
  • JonathanJ's avatar
    Former Moderator

    Are you receiving this error message using webmail or a 3rd party email client?

    Jonathan J
    Cox Moderator
  • Bruce's avatar
    Honored Contributor III
    These all point back to Cox

    Yes, these are bounceback messages from Cox servers.  An admin creates the rules, sometimes using well-known abbreviations, sometimes not.  NDR is well-known; however, MJ is local to Cox and not well-known..

    I don't know the Cox URL-policy for email because I always find an innocuous email from our HOA in my Spam folder.  Perhaps Cox flags 'em as spam because the HOA includes lots of SMTP addresses as contact info within the text.

    However, this wouldn't be the same problem because Cox still delivered the email to my account, albeit my Spam folder.  I'm just implying Cox spam-rules for links is unclear.  We'd need to see your intended URL to decipher.

    AUP = Acceptable Use Policy
    CXS = Cox
    NDR = Non-Delivery Receipt
    MJ = (A Cox admin must have created this code but means suspicious account blocked)

    You shouldn't have to do this because it's ridiculous to camouflage a URL, but how about a URL Shortener tool?  I'd probably be quicker than breaking up and testing deliveries.