In Part I, we talked about a few of the possible reasons that your email might be blocked. Today, we’ll talk about things that an individual end-user can do when they receive one of those dreaded bounce messages. Several of the tips here will also be relevant for small businesses.
One thing to take from Part I is the idea that you, as an individual, are probably not being blocked because anyone thinks that you’re a spammer. As a result of their efforts to get as much of their email delivered as possible, spammers have caused ISPs to tighten their restrictions on various characteristics of email they’re willing to accept, to the detriment of other senders. However, if you’re not actively trying to abuse a receiver, there are many steps you can take to help make sure that your future email gets through.
Take a close look at the bounces that you’ve received. There should be some information included in them to help point you to the reason why your mail was rejected. Some of the useful things you might see:
- links to DNSbl listings, like “550-[xx.xx.xx.xx listed in dnsbl.sorbs.net]”
- links to the receiver’s policy page, perhaps with a code, like “554-: (HVU:B1) http://postmaster.info.aol.com/errors/554hvub1.html”
Visit any web pages listed in the email bounce; to get a much clearer idea why your mail was blocked.Click to tweet
Unfortunately, you may not have all this information immediately available to you. Several email clients (some versions of Microsoft Exchange, for example) will hide those error messages from the end user in the name of ‘being friendly’. If the bounce you see doesn’t clearly spell out a reason, you’ll need to dig a little deeper. Enlist the aid of your postmaster – forward the bounce message to postmaster@ your ISP and ask them to check their maillogs for a more complete error message. You might also try directly contacting the postmaster at the receiving ISP. Laura Atkins at Word to the Wise has a collection of links to many ISPs’ postmaster pages. If all else fails, you may find yourself doing some detective work. Check the reputation of your outbound mail server’s IP address at the MXTools website – if your mail server is on a DNSbl, you’ll get immediate feedback, along with a link to the listing DNSbl’s homepage.
Whomever you end up contacting, be it an ISP’s postmaster, your own postmaster, or a DNSbl operator, keep a few things in mind:
- ISPs, for the most part, don’t want to block person-to-person mail. They may have some requirements for you (like, ‘send your mail through your ISP’s primary mail server’), but they want you to be able to get your mail through. Blocking person-to-person mail is usually considered a ‘false positive’.
- Having said that, ISPs are not required to accept your mail. In the US, the CAN-SPAM act specifically mentions that it does not “have any effect on the lawfulness or unlawfulness, under any other provision of law, of the adoption, implementation, or enforcement by a provider of Internet access service of a policy of declining to transmit, route, relay, handle, or store certain types of electronic mail messages”.
- DNSbl operators are just as concerned about false positives as ISPs, but they define them differently – a false positive is a listing that does not match the stated listing criteria for the DNSbl. Be sure that your IP doesn’t meet their criteria before requesting a delisting.
- Emotional appeals are not going to assist you when requesting a delisting. To the receiving ISPs, your email is no more or less important than the millions of other emails they handle everyday. “You’re ruining my business” is not a compelling reason to change a policy.
- Neither ISPs or DNSbls have any reason to be dishonest with you about the cause of a block. If a DNSbl says that they’ve had reports of email from your IP address that appears to be coming from a Waledac-infested host, there’s likely to be a Waledac-infested host on your network somewhere.
- Spoofing your IP address is hard, especially in the context of an email transaction. The chances that your IP address has a poor reputation because someone spoofed it are astronomical.
- Sometimes, the evidence you want to see of an issue can’t be given to you. Spam and virus messages are often sent to “spamtraps”, addresses that are not made public. On the other hand, evidence shouldn’t be necessary for you to resolve an issue (if one exists). If you suspect a bot- or virus-infected machine on your network, there are plenty of free tools that will assist you in sniffing your network traffic and finding the culprit.