554 Error - MTA Poor Reputation Fixes

Occasionally, if you're unable to deliver mail to a specific domain, or even send ANY email at all, you may see the following error in your delivery logs:

554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.
Basically, a 554 "bad reputation" error means that the IP address you're sending from is on a black list used by that receiving mail server. In a "worse case" scenario, your IP is blacklisted by several RBLs, which can impact your ability to send any email, to anyone.

IP reputation is tough as most email users have no control over the reputation of the IP they're sending from. This is especially true if email is provided by a hosting company or ISP, or if mail is being sent from a VPS or dedicated server that's rented from a hosting company or ISP. IN these situations, the hosting company or ISP controls the IP addresses being used, and assigns them to a customer based on need. In a shared hosting environment, a single IP address can be used for mail servers that service hundreds, if not thousands, of domains and accounts. In addition, hosting providers who offer VPS and/or dedicated server hosting recycle IPs, assigning new VPS instances to existing, and frequently-used, IP addresses. The can, obviously, cause problems if the IP was previously used and been blacklisted.


Pre-check your IP
Prior to taking delivery of a VPS or dedicated server, ask for the IPs that are going to be assigned (or that were assigned) and check them to see if they're already blacklisted. This can be done on sites such as MXToolbox.com.

Monitor your IP's reputation
Within SmarterMail, system administrators can check whether any of the IPs being used are listed by going to Server Blacklist. This page can show Blocks by IP as well as Blocks by RBL, giving system administrators the ability to manage IP reputation for their mail server. If an IP shows up, administrators can contact the listing RBL and have the IP removed.

Use System Events
System events give system administrators the ability to stay on top of issues as they occur. Some sample events that can be used are:

- IDS Rule Triggered (Security Event Category) 
This allows a system administrator to be notified if a specific Intrusion Detection rule was triggered, specifically the "Internal Spammer" rule. The Internal Spammer IDS Rule is set in a mail servers Security settings, and is based on a time frame and the number of messages sent IN that timeframe. The idea behind this is that if a user sends, for example, 500 messages in 1 minute, they may be sending out spam.

- Spool Count / Threads (System Event Category)
These allow a system administrator to know when their spool count gets high, or the number of threads used to process mail reach a certain level. These Events are good ones to have regardless to manage the mail server, because having a large number of messages in the Spool, or having a large number of Threads running, can point to various issues, one of which is potential spam.

- Throttling (Throttling Event Category)
These can be used at the User or Domain level. If Throttling is set up, having an event to alert a system administrator if a User or Domain have been throttled can lead to finding out if a user is sending more mail than they should, which could be spam. These are just some examples of how Events can be used to protect a mail server, much less the IP reputation OF that mail server. The Events system is a great way for system administrators to be aware of what's occurring on the mail servers they manage, well beyond simply protecting the IP reputation of the mail server.

Set Up IDS Rules
As mentioned above, having the Internal Spammer IDS Rule configured can help identify when a user is abusing a mail server, allowing system administrators the ability to be proactive in protecting the mail server, a domain and the overall IP reputation of the server.

Use Throttling
As mentioned above, system administrators can set up domains with throttling enabled, by default, if they suspect users of the domain are potentially spammers. Ideally, a domain like this would not be set up, but if it's unclear, setting up throttling rules for a domain, or individual users, can help prevent users from sending out bulk messages, whether or not they're spam.

If All Else Fails, Change IPs
If nothing else, changing the IP of the server may be a last resort. IPs can be given by hosting providers and ISPs, and changed within the SmarterMail interface. In addition, pools of IPs can be used, and rotated as needed. The only caveat with this is that, if IPs are changed, they need to be changed everywhere: on the server, on firewalls and gateways, at DNS providers, etc. Simply changing the sending IP may not be enough -- it needs to be changed wherever it's being used.

Regardless of what a system administrator does, users will spam. Using the methods above can help limit they potential for the actions of users to negatively impact the server, and harming other, non-abusive customers on that server.