LC Email System

Please enable users to add root domains to the platform under email services. Currently, we have to add a sub domain to each client, warm the sub domain, and use that sub domain to send bulk emails. It's weird because single sent emails come directly from the root domain. The issue is when it's sent in bulk, it comes from the sub-domain which isn't helpful / professional. Really should be able to add from the agency level and enable users to send emails with the root domain.

PROBLEM: ----------- Domain warmup currently displays daily sending limits and shows messages saying "sending paused" when limits are reached, but it doesn't actually stop emails from sending. This creates a serious deliverability risk because users think they're protected when they're not. WHAT'S BROKEN: ----------- The UI misleads users: The Email Services page displays a message saying "sending was paused" after hitting the daily limit, but emails continue sending anyway Documentation contradicts itself: One section says "sending beyond the daily limit is allowed," while another says "the system pauses additional sending from that domain" Support gives wrong info: Both the AI chatbot and live support tell users that warmup will automatically pause sends at phase limits Users are set up to fail: We enable warmup thinking it's protecting our domains, then unknowingly blast thousands of emails on day one and destroy sender reputation WHY THIS MATTERS: ----------- Email deliverability isn't forgiving. One mistake can burn a domain permanently. If warmup is meant to protect sender reputation, it needs to actually stop sends at the phase limits, not just track them and hope users notice. SOLUTION: ----------- Either: * Make warmup actually enforce the daily limits (preferred), OR * Fix all documentation, support training, and UI messages to clearly state it's tracking-only and won't stop sends Right now, the feature actively misleads users into thinking they're protected when they're not. That's worse than not having the feature at all.

Currently, in LC emails, every email is a new email. Need to include the email trail when sending outbound emails. The recipient receives separate emails and has to go back to find the conversation in their email inbox. It populates in the conversations thread for us but for the receiver's end it does not.

Currently you can only send emails from one sending domain per sub-account. It would be great if we could set up a way to have different sending domains for different workflows. For example, internal email notifications in one workflow sent from Domain A and customer facing follow-ups in another workflow sent from Domain B. Currently, this isn't possible, even if Domain B is added to the account as a sending domain. Emails will only be sent from the default domain (Domain A, in this case).

We are introducing a new AUP Spam enforcement system to improve sender reputation and protect HighLevel’s email infrastructure. Currently, we only take AUP action for high hard-bounce rates (invalid emails, etc.). With this enhancement, we will also enforce AUP when emails are repeatedly blocked for spam-related reasons, even if Email Validation is enabled. Enforcement Logic: 3 spam strikes within a rolling 7-day window → Email sending will be permanently blocked for the sub-account. This block is independent of bounce/AUP hard bounce logic. The block persists even when Email Validation is enabled. Notifications: For every spam strike, we will send: In-app & email notifications to Agency Owner Notifications to sub-account users (same flow as current AUP bounce notifications) When permanently blocked (after 3 strikes), users receive a clear message explaining: Why they were blocked The spam violations detected Recommended next steps (improving content, domain setup, warmup, etc.) Why This Matters: This enhancement: Prevents continued sending of spammy content Protects domain & IP reputation for all HighLevel senders Reduces Microsoft/Gmail spam filtering Ensures higher inbox placement for compliant users Strengthens overall infrastructure integrity Rollout Notes: This will run alongside the existing AUP bounce enforcement. Spam detection will use full provider response messages. UI + notification updates will mirror AUP bounce experience.

Could we get the ability to place a monthly email-sending limit in the subaccounts? This would be a great way to add revenue for everyone as well - Sort of like the options that we add per sub-account - do like 500, 2500, 5k, 10k - something like this would allow us to offer tiers based on sending volume and slow down sub-accounts so they don't jam up their own sending domains too fast

Ever since moving off of another email platform to HighLevel, our deliverability hasn't been as good. We've had many people mention they weren't getting our emails, even though our domain (and MailGun IP) isn't blacklisted anywhere and we've historically had an impeccable sender reputation for many years. (We also design our email messaging to avoid being marked as spam.) We've come to realize it's because HighLevel seems to force us to send from a subdomain of our main email domain (probably for message tracking purposes within HighLevel) which is not common in most email platforms. Here's a literal response from one of our recipient's IT staff about why our emails (sent via HighLevel) weren't getting through to her: "The emails they sent were being blocked because the email header includes both domains – TheirDomain.com & email.TheirDomain.com – which throws a flag in the phishing AI. Our security checks include following all links in the email and looking for re-directs and mis-matches in header information which could indicate a spoofed email address." There could be various ways for HighLevel to address this issue, but right now it looks like the most direct way to address this outright would be to allow us to send from our actual mail domain vs being forced to setup and send from a subdomain. I have a feeling with the way security is going, this will only become more of an issue for all us HighLevel users who rely on the system to send emails. (Such a solution would also avoid another current issue where recipients replying to our emails aren't actually replying to the "from" address and instead are sending an email back to the subdomain, hence not making it to the actual inbox of the "from" sender address. We don't care about tracking these in HighLevel's CRM functionality anyway... and if we did, there are typically other viable solutions like email client plugins to handle that.)

Right now every time I send out a campaign there are 2 contacts that within seconds show that they clicked a link. However they didn't. It's more than likely a antivirus tool or something that has clicked the link. I haven't had this issue in other email marketing tools. So there must be a way you can filter out or detect only real clicks from real people. Otherwise the click reporting is just wrong.

One of the things I have seen in many email builders is an automatic spam scoring. As you write out the email (or template), it gives you a score for how likely that is to trigger a spam filter and gives ideas of what you can do to reduce the likelihood of being put in the spam box. This is huge for all of us since any spam warnings that our sub-accounts get also affect the entire account. It could help increase overall deliverability and help all users across the platform.

When I am using go high level and I try to send an email outlook says on the from " team=gentlebirth.com@emailparents.gentlebirth.com on behalf of Sara" instead of team@gentlebirth.com like it does for google. Hence, it is likely people will find it "suspicious". It would be interesting to consider the approach that sendgrid uses which is to "authenticate single senders" so that this does not happen. Any other way to solve the problem is also welcomed.