Email to SMS ( is blocking our domain for spam.

Show first post
This topic has been closed for comments

153 replies

Userlevel 3
Badge +4

Reply message sent. Your domain is using a 3rd party service to send messages on your behalf and consequentially, the mail is rejecting because your domain is using Sender Policy Framework (SPF) DNS. SPF rightfully rejects other domains trying to send mail on your behalf that are not permitted to do so. SPF is solely controlled by the sending domain so T-Mobile cannot fix 3rd party SPF.

Kudos to whoever initially setup SPF in the first place, as this security feature protects you from spoofing.

Article explaining how SPF works.

Validation tool

Hi @srickar, I work for a 911 dispatch center and we are also started experiencing this issue this week. Is there anyway to assist us as well? Phone support has been not been helpful. suspects your message is spam and rejected it.

Status code: 550 5.7.350

Userlevel 3
Badge +4

Sure. I can see what I can do. 550 either means SPF or blocked for scoring of content. Sending you a follow back. Thanks.

Based on the sheer number of users running into this problem, it looks like T-Mobile needs to find a better way to block spam.  It appears that email to SMS has a lot more real world usage than they realized and a catch all blocking solution is not functional.  Having a single person dedicated to unlocking specific domains and sometimes not being able to do anything about it, as in my case, is very frustrating.

Maybe a better solution would be requesting the T-mobile end user accept the message the first time in order for the domain to be unlocked for future messages. (This was a functionality implemented by Yahoo mail over 15 years ago.)

I've been a mail adminstrator for several companies, many of which use a commercial email filtering service, since they have dedicated resources to keep up with the continually evolving battle with spammers, spear phishers, and other malicious senders.  Inbound email first flows through the filtering service before it is ever received by our own mailservers.  We generally do not globally "whitelist" entire domains based on a request by one user, and maintaining per-user whitelists in the filtering service is unscalable, if the service even provides that capability.  If user-based whitelists were supported, and users had to maintain them themselves, that would require us to write an application that interfaced both with the user as well as the filtering service on the back end.  With the right resources, that is certainly possible to implement, but the difficulty depends on whether the filtering service includes a programming interface, such as REST, to easily make updates with code, along with all the security implications of such an interface.  And even then, because senders can be easily spoofed, the origin of any message from a whitelisted domain should still be verified.  I imagine in T-Mobile's case, a lot more people would be screaming if they didn't filter out the spam.  But maybe they could look at providing a whitelist feature on the website that allowed users to manage their own whitelists, or even opt out of spam filtering altogether.

Hi there @srickar​.  Same problem here (Status code: 550 5.7.350).  We had problems yesterday between 13:00 and 13:10 ET with a short message we use for two-factor authentication.  A longer message (containing a URL) appears to have gone through at 13:32.  The Kitterman site shows "SPF record passed validation test with pySPF (Python SPF library)!"  Please help as this works with all the other mobile providers.

Userlevel 3
Badge +4

Please reverify traffic. There were changes made late yesterday afternoon to relax rules and from prior items I reviewed, they were passing correctly.

Sorry, missed your email. It is still being blocked.

Original Message Details

Created Date:

2/6/2020 9:15:10 PM

Sender Address:

Recipient Address:



Error Details

Reported error:

550 5.7.350 Remote server returned message detected as spam -> 550 permanent failure for one or more recipients (

DSN generated by:

Remote server:

Userlevel 3
Badge +4

Messages are failing because the content is being sent in ALL CAPS while discussing accounts/payments. Discussing account/money over email in brief blurb style, which is too similar to spam attacks for Netflix phishing activity I spoke about earlier in the thread. Also, the message-ID is being modified by the sending server which should be resolved by the sending domain.

A payment of $182.00 has been received for account number XXXXXX on 06-FEB-20.

The Prepaid balance for account XXXXXXX is 0.79. If needed make a payment by 9:30am.

Anti-spam is flagging the semantics of these messages because it is being sent from which has a poor reputation for webmail spamming combined with the issue of sending “account alerts”, using ALL CAPS. If the all caps issue could be resolved, the messages would likely pass based on the score evaluation.

Rule breakdown below

pts rule name description


I am also getting blocked as spam. The text of the message is very short: "StationMD code is 29842". Can you give me some guidelines on how to format the message as to avoid being caught in a spam filter? I can include a url, but I'd like to keep it short.

Update: Our company's IT person updated our domain's SPF record as you suggested and our e-mails to text are going through again. Thanks!

Verified as working.  Thank you.

I have this problem as well.  Been on hold with CS for about 13 min. Referenced the DOC-414999 to them.  Can someone please help?

Our company is getting the same error when trying to send to, 550 blocked error.  Can you assist?

Userlevel 3
Badge +4

Sure! Sending a follow request. 550 is either content or SPF related.

I finally got a CS Rep to open a ticket, it's 43823782.  I was told I would hear back today to see if our domain was blocked but I still have not heard anything.  Our domain is  Are you able to look at this ticket number to check the status?

Userlevel 3
Badge +4

I'll review the ticket and reply back shortly.

Userlevel 3
Badge +4

The email SMTP domain used to send these corporate messages is also shared amongst all spam sources from Microsoft (outlook webmail, hotmail,, etc), and the corporate email is intermixed into that same realm. When sharing ESP providers that have poor reputation, messages receive extra scrutiny based on the source of origination.

With that said, also the message body is too short in comparison to having a large HTML signature that contains excessive email address, phone number, and address with a long line break. Please remove the signature and any HTML hidden formatting when sending through email to MMS text.

Also having this in message body "our records indicates that you have not accepted your pre-appro=ved offer to reinstate..." reads like cash loan/finance/fraud spam.

Please test out some of these suggestions and refrain from using phrasing that is finance/enticement related. Thanks.

Thank you we will give your suggestions a try.

Sorry for delayed response,

I did as you suggested looking at the RULE BREAKDOWN you sent.
That gave me a X-BESS-Spam-Score: 3.87

Changed the Context to Text from HTML (which also took care of the HTML image only)
Avoided manually changing Message IDI think I removed the base64 encoding.
Not sure about the quoted printable line...

Could you send me a current X-BESS-Spam-Score?

The TXT msgs and Emails are now flowing.


srickar, can you please follow me on inbox? I'd like to get your help with an issue similar to this please!

Hi I need help as well,you guys are blocking the email to SMS from

Halloo said this;

"Can you "white list" emails from @halloo to @tmomail.  It's likely that in an effort to stop spam texts, they have clamped down on these kinds of email gateways."

Userlevel 3
Badge +4

Sorry cannot whitelist 3rd parties but I can give you guidance on how to improve presentation of certain items that are being flagged. The messages are sent in plain text content, with no subject, short message body with imbalanced ratio of numeric punctation to text, yet has URL in the message body. This is the same tactic employed by spamming to thwart detection. If the message were to include a subject, the message would likely pass.

Additionally, the "from" and "envelope from" addresses do not match.- mailer-daemon@ and admin@. Clean up the presentation consistency of the envelope to match both username and domain parts, so they consistently match the PTR record. Avoid the use of defaults like mailer-daemon all together because spammers also use the same tactics. Sender address should be unique. Thanks.

Hi @srickar​, One of our solution made use of the "Email to SMS" facility as well but stopped working and error looks as follows:

"delivery-status": {

"tls": true,

"mx-host": "",

"attempt-no": 1,

"description": "",

"session-seconds": 7.0337419509887695,

"code": 550,

"message": "permanent failure for one or more recipients (",

"certificate-verified": true


I have followed you and can share more details if required. Our message is simple "subject": "Confirmation code: 655985" but the sending domain seems is blacklisted. I had contacted support and opened several tickets 43547374, 27050534, 27081283 (they include more details) but all of them went unresolved. Could you please help resolve this case?


Userlevel 3
Badge +4

Hi @magenta10610698,

I reviewed the examples and the intent reads like cash loan spamming/fraud. I went ahead and resolved the block, but please note that automation traffic like pin code resets need to route through an automation short code channel.

Routing automation over email is not a valid long term solution and repetitive messages like this will trigger blocking. This is necessary to comply with TCPA CAN SPAM Act of 1993. Automation is classified as A2P traffic and can result in charges to consumers who do not have an unlimited messaging plan. The subscriber has to initiate opt-in to be contacted through wireless domains and even so, automation guidelines require certain traffic content to route over subscription based short code.

For more information please see Domain Name Downloads | Federal Communications Commission

and for short code traffic, please refer to section 4.2