My Mail-In-A-Box Domain Is Being Blacklisted By SpamHaus And I Cannot Even SEND From My Domain

I’ve had a Mail-In-A-Box instance installed at for a short time (couple months?)

The site is secure as far as I can tell, and it has only been used very little to send and receive a few emails.

Today I was trying to send FROM an email at and I could not send at all because of the SpamHaus listing (which appears to be new) blocking me from sending.

Here was the error message:

SMTP Error (554): Failed to add recipient “@.******)” (5.7.1 Service unavailable; Sender address [] blocked using;

I tried sending TO other email addresses and had the same problem.

The SpamHaus link says:

This listing may be caused by poor sending reputation, or the domain or website may have been hijacked by cybercriminals.

As a result, the domain is listed in the Domain Blocklist (DBL)

Click on Show Details to see if you can request a delisting from this blocklist. This will also display any further information we have relating to this listing.

I ran a malware check on my site and made sure the server could only be signed into with a public/private key combo.

I have seen ZERO sign that this server or site has been hacked in any way.

The other domains I have as sending domains on my setup appear to be working fine.

So… I went ahead and requested delisting at SpamHaus which created a ticket and I am waiting to hear back from them.

In the meantime…

  1. Anybody know what is going on? What would be causing this on a relatively new server and site with very little use?

  2. How do I turn OFF the spamhaus blocking function inside my mailinabox setup so I can use it in the meantime? Right now ALL sending from the main domain is being blocked.

I look forward to the help of this community which I have been grateful for before. :slightly_smiling_face:

Okay. So I sent in a removal request to SpamHaus, but they did not accept it because the email did not come from the domain.

The irony: I cannot send from the domain because MailInABox is refusing to send due to the SpamHaus blacklist.

So until I can figure out how to disable the functionality in MIAB that is using the SpamHaus list to prevent me from sending emails I cannot request to be delisted.

I found another article with ideas about how to turn off spamassasin and spamhaus altogether but none of those ideas are working.

Hi JonD,

There might be a little confusion here about how blocklists work. SpamHaus maintains a database of problematic IP addresses and domain names. Anyone can attempt to send emails from any computer - SpamHaus is used by the receiver as part of their accept/reject/quarantine decision.

(I’ve never heard of any sender checking itself against SpamHaus. That doesn’t make sense - if you’re a “good” sender, no need to check; if you’re a “bad” sender, you would deliberately not check!)

The pertinent thing is I will be very surprised that your MIAB install is refusing to send, that’s not how blocklists are used. I see you’ve had some issues with your provider and been working around them. It is possible that you’ve created an “interesting” email configuration (possibly involving relays) and an intermediate server somewhere is blocking you, but it won’t be your MIAB.

Howdy Andrew. Thanks for replying.

Although I am not able to reconcile or understand what you are saying in light of what I am actually experiencing.

When I try to send FROM inside my MIAB install i get the error message described above.

I don’t know anything about “relays” or an “interesting” email configuration. Could you explain more?

The way this is happening it sure looks like MIAB is checking the SpamHaus list and then refusing to send the email.

It very much looks like MIAB functionality is doing the blocking using the list.

I cannot see a different explanation.

(Regarding SpamHaus I have no idea how my domain is even on any list but there are a number of posts in this forum that seem to indicate it is a common problem MIABers are having.)

So I am still stuck and unable to use MIAB the way things are.

Hi JonD,

I could be wrong, but I believe the message you describe is not coming from your MIAB box, but from some other server which is receiving the email message, checking whether it should accept/reject/quarantine the message, and saying to your box “I don’t like your domain, I won’t deliver the message”.

If you’re going to diagnose and fix problems, it is important you understand the email process. Your server does not check SpamHaus when sending messages, only when receiving them.

On a plain, vanilla install of MIAB, messages are sent directly from your MIAB to the destination server (which then checks if it will accept the message). Sometimes peoples’ hosting services block direct email sending (block port 25), and those people might resort to “relaying” the message via an intermediate mail server. I don’t know if you’ve done that, but I did see lots of forum posts which indicated that you had trouble running a vanilla MIAB - and I wondered how your install differs from the vanilla.

Unless you have significant expertise, the easiest way to run MIAB is to choose a hosting service that provides clean addresses (not on SpamHaus etc), clean server images (exact copies of Ubuntu Server), and doesn’t block any ports (permits direct email sending). Also choose a DNS provider that does everything cleanly and doesn’t prevent you from doing normal DNS things.

If you have a good hosting service and DNS provider, the MIAB install is very simple and everything “just works”! The easiest solution to your problems might be to start again with good providers.

I can’t suggest a hosting service as I run the hardware myself - but there are various forum threads that discuss “good” providers. Nor can I recommend DNS providers, other than to say I use and have had no trouble with their service.


This is why I tested over and over and over trying to send to multiple email addresses at multiple domains.

As far as I can tell, this install can not send to ANY email address of any kind.

Based on what I am seeing, I do not believe this to be true. I am, however, VERY open to being wrong.

But by all appearances the emails are being stopped before ever leaving my MIAB install. It is very much looking like and behaving like MIAB is checking SpamHaus and refusing to send the message. I cannot think of another explanation to what I am seeing. Please show me how I am wrong. I would love to be wrong, but it sure looks in every way like I am not.

If the problem was that the RECEIVING email server or somewhere on the way were blocking my domain then the email should send and then I should get back an error message.

The error message (as stated in my original post) is popping up on the bottom right of the screen and the EMAIL NEVER EVEN SENDS.

Regarding the rest:

My hosting service is Vultr - I spun up a server and installed Ubuntu directly via Vultr.

Is there a problem with Vultr or it’s Ubuntu installs?

My DNS provider for this domain is Namecheap.

Is there a problem with Namecheaps DNS? (I am seriously asking).

The “glue records” are set properly, etc.

Regarding other posts I have made in this forum - I don’t believe they were generally about the install of MIAB, they were about OTHER domains that I was setting up to send with on my MIAB install.

But the problem domain here IS the one setup properly in the “Vanilla” way with MIAB. The main domain of the install.

Interestingly, the OTHER domains (the ones I was posting about trying to figure out in other places in this forum) are all working fine.

Looking at what I am actually experiencing, I still don’t see any other explanation other than MIAB is using the SpamHaus list to prevent me from sending emails.

I am very open to another explanation, but I’m not seeing one.

Unless Vultr and NameCheap suck (which has not been my experience and I haven’t heard any of the tech people that I follow say they are a problem). I avoid shared hosting. I either install directly at Vultr or I use ServerAvatar (a control panel for managing servers). In this case I did it all directly at Vultr.

An important note - the install was working fine from the start. The inability to send emails from the main domain of the install is a recent development.

I keep looking into this.

This topic seems to indicate that there IS a process whereby MIAB would block sending the email at all: Blocked But Not Blacklisted - I am referring to @openletter 's comment.

I found the following line in /etc/postfix/ :


I am not a coder. Is that a line of programming that will prevent MIAB from sending from a domain that is listed @ (which is where my problem domain has gotten listed).

If it is, how do I edit that line to turn that OFF? (and I’m guessing I would need to RE-edit that line every time I update MIAB).

The post I referred to says there are TWO places where sending can be blocked. Any of you wonderfully smart people know where the other one is?

Another post from way back in 2017 that appears to deal with this and offers a possible way to turn off the sending check/block: I want to disable spam check for outbound email - #3 by sammopagla

I am going to try it out.

Okay. I WAS able to turn OFF the functionality where MIAB refuses to send FROM a domain that is listed at

I went into this file: /etc/postfix/

I found this line:


It happened to be on line 80.

I deleted “,reject_rhsbl_sender” from that line.

I rebooted the server for good measure and now I CAN send from that domain.

I think this officially goes into an “unsupported” type of modification, but it has meet my temporary need to be able to send while I try and get SpamHaus to delist my domain.

If anybody has any tips or tricks as to why a very limited use sending domain that has never been used for bulk email and is probably not hacked got listed there I look forward to your input. :slightly_smiling_face:

Well I learnt something - didn’t think postfix would be doing that. Thanks. Glad you’ve got it fixed.

1 Like

Now that I was able to send from my email address I was also able to get my domain removed from the SpamHaus dbl list.

So this drama is over haha.

Well done for persevering

1 Like

Seems like we could improve this by adding permit_sasl_authenticated after reject_authenticated_sender_login_mismatch and before reject_rhsbl_sender.


I am not really a coder so I don’t know what that would do, but I am chronically curious - what would that do?

I’m glad this forum exists and the old posts were there or I may have never solved it haha.

JoshData - looks like a good idea :slight_smile:

This topic was automatically closed 40 days after the last reply. New replies are no longer allowed.