Dedicated Domain = Spam. SMTP = One User for 100 People?!
C
Charlie Stevenson
❌ The Glaring Problem:
HighLevel allows multiple SMTP servers at the sub-account level, but only one can be set as the default for outbound emails. This creates major limitations for companies where users each have their own email - which is 99.99% of companies - and is near enough completely redundant.
If a company has 100 employees (e.g. charlie@, rebekah@, joanne@) and several shared addresses (e.g. info@, billing@, sales@), all emails must be sent through one default SMTP or dedicated domain.
If the default SMTP is charlie@, why would Rebekah send through it?
If it’s info@, why would Charlie email the lead he's just spoken to on the phone through it?
Yes, we have dedicated domains. Dedicated domains are great for mass campaigns to protect the root domain’s sender rep - but terrible for personal outreach, and they almost always end up in spam.
If it’s a dedicated domain for bulk - why would Joanne send a 1:1 sales email that NEEDS to land, FROM HER, through it?
For SDRs or anyone doing 1:1, emails need to come from the actual user’s address to ensure deliverability, and appear professional and trustworthy.
SMTP is the only reliable option for this - but we can only use one SMTP across 100 employees... Why?!
✅ Suggested Solution:
Allow each user to connect their own SMTP/email service. Emails sent from that user should automatically route through their configured SMTP provider, offering full control and accountability - with the option to override if needed.
If no match is found, the system should fall back to the company’s default SMTP, or default sub-account email address through their dedicated sending domain.
Additionally, allow admins to assign access to specific shared addresses (e.g. sales@, support@) to certain users or teams. For example, sales team members could be granted access to send and receive from sales@ - without exposing it to the rest of the company.
This would solve so many issues with the current, deeply flawed email service. Having one SMTP per sub-account makes zero sense when every user has their own inbox, and using a dedicated domain for 1:1 SDR emails is deliverability and conversion suicide.
Log In
C
Campbell Haigh
We need major help from GHL for landing in the inbox with our emails.
S
Shaun Curry
I have noticed that if a GHL user's profile email address = the default email sending domain emails will go out from: that user's email address.
I just created a feedback idea so that inbound gets routed (via assigned to) to that user: https://ideas.gohighlevel.com/lcemailsystem/p/automation-trigger-for-to-email-address-incoming-emails-when-using-lc-email
C
Charlie Stevenson
Shaun Curry I believe it’s addressing a slightly different piece of the puzzle, and is more a workaround than a solution. The core issue here is that without true SMTP integration at the user level, GHL is effectively spoofing the user’s email - without authentication from the domain/server.
For instance, if the dedicated domain is mail.domain.com and the user’s email is email@domain.com, the email will appear to come from domain.com but be signed by mail.domain.com. That mismatch often causes deliverability issues, as the message technically isn’t coming from the user’s actual domain.
As an example: I can freely set a user’s email to elon.musk@spacex.com within GHL and send an email that looks like it’s from him - but email providers would flag it, because the sending server isn’t authorised by spacex.com. That’s a major red flag for spam filters and recipient trust. This is effectively what’s happening now, which explains many of the deliverability issues people are seeing.
The solution I suggested would resolve this and actually make your proposed routing functionality reliable, as it would be sending through properly authenticated user accounts - not just mimicking them.