LC Email System

We’d like to request a feature enhancement for the LC Email System to support the creation of fully branded and professional email addresses. Currently, the system allows us to create email addresses in the format name@post.domain.com . We would love the ability to create and use email addresses in the standard professional format: name@domain.com .

We’re adding support for a native professional email inbox that lets users send and receive personal business emails (e.g., you@yourdomain.com ) —without needing third-party email services. Key Highlights: Users can create and assign custom email addresses from their domains. Messages will only be visible to the assigned user unless the email is inactive or deleted. Admins can manage address status, forward messages, or delete mailboxes with handling options. DNS and domain verification are handled automatically behind the scenes. This unlocks a full inbox experience natively within the platform—great for client-facing roles, internal teams, or personal business communication.

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.

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).

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

On a regular basis I have to contact support to ask them to fix or change the sending IP associated with my dedicated sending domains, because Microsoft is blocking the emails. This issue is that Microsoft black lists the Mailgun server IP for the shared server(s). It then takes days, sometimes longer for the issue to be temporarily resolved. Then a few weeks later or sometimes longer it happens again. And it doesn't just happen on one sub-account. Every time this happens my clients get very frustrated that their emails aren't sending and ultimately it is impacting their business. We need a permanent fix for this issue. And purchasing a dedicated IP for the sub account is another expense when they don't send 100,000+ emails per month.

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.

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.

I would like you to have this feature on highlevel to allow users to select a sending domain for each worflow. Sometimes client has multiple website and funnel domain. If we create workflow and email sequence we might need a different reply email address for each domain. You can just add a limitation of the active sending domain maybe at least 3 or 5, so users will not be abuse this feature.