System Help


You have a message saying Karmasphere's blocking your email? Please read this before you email us.

What's Going On Here?

Karmasphere does not block email. We provide a reputation service that is used by email servers to make decisions to block, accept or further process an email.

When your email arrives at a mail server for the user it's sent to, the mail server looks at identities in the email and uses Karmasphere to check the reputation of one or more of those identities. If there's a problem with the reputation of any of those identities, it may decide to block that incoming email. This is an efficient and common way that email providers deal with the massive problem with spam and phishing plaguing the Internet. In fact, it's highly probable that email sent to your organization has its reputation checked without you even knowing about it in order to help protect you from email abuse.

It's likely that previous behavior of the IP address or domain from which you're sending email has caused that identity to get a questionable reputation. An identity such as a URL in the email you're sending can also have a questionable reputation. It's possible that you're completely unaware of any problem and consider your mail practices to be perfect.

If the email that was blocked was sent by your marketing department or by an Email Service Provider (ESP) that you use, you should involve them in your attempts to resolve the problem. Note that if you are sending marketing emails from your company and encountering deliverability problems, you might want to consider using an Email Service Provider (ESP). There are many reputable ones that help you with your email marketing practices. One place to look for an ESP is the Email Service Provider Coalition.

What kind of problems might there be?

The cause of the problem usually falls into one of these categories:

  1. An identity in the email (such as IP address, domain name or even URL) is on a black list of some sort.
  2. Your organization, or an organization that sends email on your behalf, has a misconfigured mail server.

Karmasphere's reputation service allows mail recipients to query many data sources in a single look-up, using what we call a feedset. You may see a reference to that feedset in the block message you have received. It's an important piece of data.

How do I find the specific problem in my case?

To discover what is triggering the block decision, you can look up the reputation of the IP address and domain in your email here on the Karmasphere web site. That will give you a good clue as to what is happening. To do this, you need to know how to find the IP address and domain from which your email was sent. If you don't know how to do this already, look at the example below.

Different email recipients use different feedsets. You may have the name of the feedset they use in the email that informed you that your email had been blocked. Then again, you may not. A feedset identifier looks something like this: karmasphere.email-sender. If you can't determine the feedset that was being used, don't worry. The best thing in that case is to use the "Karmasphere All Feeds" feedset to query the reputation of your IP address and domain name.

Now that you've got the IP address and domain name from the email that was blocked, you can look them up.

How do I fix the problem?

Once you've found the specific reason for the block, we recommend that you contact the owner of that data source to request removal. We've tried to provide URLs for them in the detailed information for that source (which you can find by clicking on its name).

Other things to consider in a mail blocking situation are your reverse DNS (you should have it, and it should reflect your domain name and the fact that you're running a mail server) and your HELO string (this is a setting in your mail server that tells the receiving server what the machine that's connecting to it thinks it is -- this should probably match your reverse DNS entry). Failing to have these two things properly set up may cause you to be blocked in error because the receiving server is looking up an identity in your email that you didn't know you were providing.

If this advice has not helped you, you can write to us at for further help. Please include the error message you received and, if possible, the full headers of the email you sent that was blocked. Before you do that, we urge you to:

  1. Talk with your marketing department or email service provider. It's possible that your problem is symptomatic of a bigger problem within your organization that stems from email marketing communications.
  2. Talk to your email provider if you don't run email systems from within your own organization.
Thanks!

An Example

Here are some example mail headers (note that you may see other stuff in the headers, but these are the important ones), with the identities most recipients will be checking in bold:

NB: You may have to turn on a setting to be able to view these -- often it will be a "View" setting labeled "Headers" or "Long Headers." If you can't find it, consult the help function of your email client.

From:   XXX@gmail.com
Return-Path: 

Some receivers may check the domain of your "from" and/or "return-path" address, or even the whole address. You probably want to make sure that these are the same address, unless you really want replies to your email going somewhere else.

Received: from rv-out-0910.google.com (rv-out-0910.google.com
[209.85.198.188]) by XXX.XXX.pdti.net (8.13.8/8.13.8/Debian-3) with
ESMTP id l7MJWTsX030028 for ; Wed, 22 Aug 2007
14:32:30 -0500
Received: by rv-out-0910.google.com with SMTP id k20so293862rvb for
; Wed, 22 Aug 2007 12:32:26 -0700 (PDT)
Received: by 10.140.132.8 with SMTP id f8mr485164rvd.1187811145896;
Wed, 22 Aug 2007 12:32:25 -0700 (PDT)
Received: from ?192.168.0.4? ( [71.121.16.42]) by mx.google.com with
ESMTPS id c20sm2322509rvf.2007.08.22.12.32.24 (version=TLSv1/SSLv3
cipher=OTHER); Wed, 22 Aug 2007 12:32:25 -0700 (PDT)

These "received" headers trace the path of an email from the sending server (in this case, a google.com server) to the receiving server (in this case, pdti.net's server). Note that they appear in *reverse* chronological order -- the last hop the mail takes is at the top of this list. *Most* mail servers will only check identities in that header (since the path the mail takes to get to you isn't generally important).

The first thing you see here is the HELO string of the mail server. Note that it matches the next thing, which is the reverse DNS of the mail server. You're going to need to have both of these things set up, and you should use the same "fully qualified" domain name for both of them (i.e., a real domain name, as opposed to an IP address or "localhost" or something similar). The third thing is the IP address of the connecting server. Note that mail is commonly blocked if it has IP addresses instead of proper HELO or reverse DNS strings -- some mail servers will even use "forbidden" IP addresses in these spots. You can recognize such an IP address because it will start with 10. or 172.16 - 172.31 or 192.168. If you see these IP addresses in your headers anywhere but in the first received header (the one on the bottom), you should probably check to make sure that your mail server is properly configured.