I’ve been running MIAB for a few years now, with almost zero problems. But I’ve encountered an interesting situation that I haven’t been able to work around.
I host email for my business and several small clients, and recently I had a client who needed a quick fix to get a registration form on a WordPress site sending email again (unrelated problem with their web server). I don’t host this client’s email, it’s running on Office 365.
I had little time to get their web form working again, so I quickly added a “noreply” address for their domain to my MIAB instance, hooked up their WordPress site to that account via an SMTP plugin, and voila! All is well.
Except now, any time I try to send email from my business address to any address on their domain, MIAB stops the message from going out and instead looks internally for the address, and because I don’t actually host their email, it rejects the message with the error “Recipient address rejected: User unknown in virtual mailbox table”.
And I know the issue is internal, because emailing them from any address not hosted on my MIAB instance works just fine.
I know this is a weird edge case and I probably shouldn’t be doing this on my production MIAB - but is there a way to tell MIAB to ignore this domain internally and route emails externally instead?
Correct - I don’t host example.com but I created a noreply mailbox for that domain (and added my MIAB IP to their SPF record) for the purpose of relaying email messages from their web server. So now, all email from my domains hosted in MIAB to example.com, no matter where they are hosted, are failing because MIAB is apparently looking internally for the address.
Just to be sure I’m on the right track, I just now tested again and sent a message successfully to noreply from my primary business email, both on MIAB. And then tried again to email the client’s project manager (email hosted externally), and it failed.
And interestingly, I logged in to webmail as the noreply user, and saw the test email I just sent. Which shouldn’t be there because my MIAB is not on their MX records. So MIAB is definitely catching and locally routing email. Which is a cool feature, but has unintended consequences if you’re doing something like this.
I don’t point domains to MIAB, only MX records, and I figured that deleting the account would solve the issue. I’m just wondering if there’s any way to tell MIAB to not route mail internally for that domain? And instead look to the authoritative server for that domain’s MX records?
If not, that’s okay - I know this is probably a very non-standard use case and I should probably be using something like Mailgun or SendGrid for this. But if I could accomplish it with MIAB that would be very cool.
Okay, so based on what you’re saying, even if I don’t point domains to MIAB, the system will still assume that it’s the nameserver for all domains that have mailboxes on the server, and it won’t bother to look externally for MX records for those domains. So changing the records on-server should fix that problem, despite the records not actually having any effect outside of the server.
My desired end state is to have the web form that’s sitting on another server, use MIAB as an SMTP relay via the noreply mailbox, while other mailboxes for other domains on the same MIAB server can still send email out to example.com addresses that don’t live on MIAB.
Web Form → MIAB (via noreply account) → rest of the Internet [this works]
MIAB users → example.com addresses outside of MIAB [this currently doesn’t work]
I’ll try tweaking the DNS records on-server and see what shakes out.
Oh, actually I like the subdomain option best, that’s simple and it doesn’t matter whether noreply exists at the domain root or not. Thanks for the idea!