Sending mail from another domain

So I mostly have things working however this one edge case seems to be problematic for me.

@domain.tld is hosted with another provider. I setup mx.domain.tld with mail-in-a-box to provide mail service for several domains and outbound for domain.tld. All other domains are working A-OK.

The part that I can’t get working is outbound for domain.tld. When I create a catch-all alias as such:

Attempts to send mail to anything@domain.tld from hostmaster@mx.mdomain.tld fail as User unknown in virtual mailbox table. Noticing this persists even after deleting the rule until I restart postfix, which may be a bug.

So my questions are:

  1. How can I allow really anything @mx.domain.tld to send mail on behalf of @domain.tld?
  2. Is this indeed a bug where deleting that rule requires restarting postfix? Or am I missing something else in the process/workflow entirely?


If domain.tld is hosted on a different mail server, what is purpose of this alias?

domain.tld’s mx record points to a different mail server. The purpose of this alias is so that mail-in-a-box can send email on behalf of this domain without having to relay through the other mail service and/or have to pay for extra mail accounts.

The only way I can think of to accomplish this with MiaB is to create an email account with domain.tld and MiaB will then configure everything to support sending (and receiving) with that domain. MiaB will complain that the records are not correctly configured, but the only things you would need to configure for this purpose is the sending-related records, especially SPF and DKIM.

Correct me if I’m wrong, but that would make MiaB think domain.tld is receiving mail in MiaB and then reject mail due the inbox not existing on MiaB. Unless you’re suggesting I recreate every email address on MiaB and forward each one individually which would be tedious.

I really just want to authorize the subdomain’s email addresses to be able to send mail as the domain.

You asked about sending on behalf of, but when domain.tld is a recipient address, MiaB probably just delivers to the local account without checking DNS, although I’m actually not quite sure.

I think MiaB (or really Postfix) checks against it’s own table of domains/addresses. Which is why I originally encountered the issues in my first post. Once the alias is created domain.tld is in the table, and Postfix doesn’t have enough information to continue.

At least that’s my interpretation. Though I’m a crummy Postfix admin, hence looking at MiaB.

It seems like there are better alternatives, but I’m not clear on your needs. For example, what is generating the messages? Is it required that they are from email accounts that don’t receive mail? Why can’t the existing mail server send the messages instead of some other server? Or why can’t MiaB be the server for the domain.tld? Not saying you haven’t figured this stuff out, just not clear because the way you are trying to use MiaB for this is not very common.

I’m migrating off of Gmail (like millions it seems) which currently handles the domain, and likely going to Microsoft 365.

I don’t want to be provisioning paid accounts just for SMTP for the webserver to send some email @domain.tld for example for various things. Especially when MiaB is already up and running for other domains.

I’m already having the webserver relay email for some things, and that works just fine. I just have to use a subdomain. For the rest of the migration process, I need to get some domain level things moved over.

This is really the only mail caveat that I’ve found. Otherwise it’s handled my legacy setup splendidly.

Why does the web server require a relay?

Not all datacenters allow email these days. And having less IP’s to keep whitelisted on DNSBL’s is always a good thing.

This is hardly a rare these days. Lots of applications have SMTP configuration in their configs and don’t even assume sendmail is assumed like they did years ago.

You can also configure an MTA to use the domain’s mail server for sending mail.

Right… but several dollars a month per account when i’ve got a mostly idle server running postfix defeats the point.

Hi, let’s look at this through a separate set of eyes. I am still not clear on what exactly you’re wanting to accomplish. Is it to send emails from a website using a subdomain as the authenticated sender and the main domain as the sender? Or is it to be able to send mails from the MiaB as though you were sending from the real mail server?

Draw me a map please … I think that there may be an easy postfix entry – which would be an unsupported modification, so you’d be on your own, but it should still work.

Let me try to explain it differently:

Use the following domains/setup: -> mail through 3rd party provider. -> mail through MiaB,net,org -> mail through MiaB

With this setup, everyone can email everyone just fine. Since domain. com isn’t in MiaB’s configs, it’s sent externally. Everyone else is routed internally.

You can setup a catchall and authorize to be able to send email on behalf of foobar .com as well using the directions here (step 3, second bullet point).

All of the above works perfectly.

Now say I want admin@foo.domain. com to be able to send email as admin@domain. com. However I don’t want to set the mx records to MiaB. I just want to add MiaB to send email, not receive. If I follow the directions I linked above, you end up in a bad state because MiaB tries to route the email internally and it fails because the mailbox doesn’t exist in MiaB.

One option I believe is to setup domain .com as a relay domain IIRC (it’s been years since I’ve done the whole postfix setup thing, and I loath it, hence MiaB caught my eye). I could be wrong about this.

This isn’t that crazy of a setup, especially with GSuite going away. Pay for one hosted email address, and setup some forwards to another address(es). Then allow them to send as your primary domain.

(apologies for the rogue spaces in email addresses, discorse wouldn’t let me post with more than 2 “links”).

No worries. Let me sleep on it. I’ll circle back within the next 2 days.

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