Feature: re-think alias functions

I love my Helm and have been impressed with how flawless it has been. One aspect has been a real pain to manage though- aliases.

1: One user with multiple domains. We have a few family domains, my last name, her last name, her last name - my last name and a common mis-spelling of my last name. When I hosted with a third party mail host we had a few mail boxes and aliased all the domains to end up in the appropriate boxes. At the moment I have no less than 6 mailboxes to accommodate all the domains. It doesn’t make any sense and needlessly complicates things when we send outgoing mail.

2: One alias to multiple mailboxes. Whenever we expect mail from some source that we both want to know; the Daycare mailing list, the homeowners association, emergency alerts from the power company… I previously used an alias that went to both of us. Here too I had to create another mailbox for this.


I use the add-on alias feature to separate my friends & family from everyone else. I create aliases for sensitive things like my alarm and security cameras. It seems useful this way, but others may have different priorities.

I uncovered a bug in the system. When I created a specific [unnamed] alias, I started receiving dmarc emails from google and yahoo to this specific alias. For further testing purposes, I created another [unnamed] alias to see if it really was a bug. I started receiving let’s encrypt emails to this other alias - confirming a bug.

I reported this to Helm support. They agreed it was a bug. Helm explained the messages coming from the two [unnamed] aliases were associated to my server, but not meant to be visible, because of how the server is setup.

Apparently, the proprietary info I was getting wasn’t supposed to arrive in my inbox. At least this is what Helm Support explained to me. I have no reason to doubt them.

I wanted to know if my servers security was in any way compromised. They assured me everything was good. Again, no reason to doubt them. They have been very thorough in their direction.

I did disagree with the protocol they have in place that limits what I can and cannot see on the server. I asked if I would be able to keep access to what I uncovered, as long as it didn’t compromise the security and integrity of my server, as well as Helm in general. They obliged.

I continue to receive reports on specific topics I otherwise wouldn’t have, had I not stumbled upon it. Now just waiting for the SSD expansion firmware to release. Hopefully they will roll this out soon.


@MZY I agree with you that a user should be able to receive DMARC and other reports if they so desire (which I definitely do!) Do you mind posting or DM’ing me the aliases you set up?

1 Like

You absolutely should be able to get those if you want. It would allow you to proactively address deliverability problems. At least on my Helm the dmarc record is defined to tell recipients to reject 100% of messages that fail spf and/or dkim verification (authentication?) and let you know at that address. You can see the address used by looking at your DNS records in the domain section in the helm app. This is not secret stuff. Google has a useful outline of dmarc in the documentation for G Suite.



If you’re NOT interested in getting into the guts of how email deliverability works, don’t look. It will only stress you out.

Hi @bananalaser,

I have exactly the first usecase where I manage multiple domains for the same email accounts.

This works fine in my current setup but for various reasons I need to change find a new solution and I was hoping that Helm could be it. It would appear that it isn’t… :-/

Does anybody know how to get this put on the backlog and prioritised?

It would appear fairly straightforward to implement.

1 Like