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 .

LC emails ending up in junk and GHL support has no recommendations or solution

Currently users still have to login to their domain DNS host and manually add the DMARC TXT record after doing the domain auto config in HL. It would be great (like with the www toggle) if an option existed where users could choose to have the DMARC for an email subdomain also added at the time the other DNS records are being added

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

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.

Can you guys fix this please? I want my emails to land in normal inbox... Even non promotional emails go to the promotions part, this is the reason why i switched platforms and left gohighlevel for email purposes. please fix this

At this time, cold inbound email is delivered to the "universal inbox" only if addressed to the Default Dedicated Domain. If someone replies to an email sent from a Dedicated Sending Domain it is delivered to the Conversations tab. But if they save that email address to their contact list and write a new email using the address in their list the resulting email will be lost, it will not be delivered. This has a predictable lost revenue potential where people who reach out later (rather than replying to email marketing immediately) are lost to the CRM/automations/nurturing. Certainly if the email is forwarded from our Contact to another email address or a friend and a cold email is sent to us from that other address we will not receive the message. Our nurturing campaign worked, but we failed to capitalize on the opportunity. In my set up (see graphic) any email sent to {{addressee}} @ email.thebaldguymarketing.com will not be delivered while emails addressed to {{addressee}} @ thebaldguymarketing.com will arrive in the Conversations view. I would like to take advantage of the options provided by having separate Workflow, One-One, Campaign, and Bulk domains. We could have four different Dedicated Sending Domains if we could be sure that emails addressed to any of them would be delivered to Conversations. What is the point of having multiple Dedicated Sending Domain options if any cold inbound emails will be lost in cyperspace? The way it is now we should have only one (the burner for cold outbound bulk email) and keep all other email on the Default Dedicated Domain. The behavior I would like to see: any email addressed to anyone at any dedicated sending domain established with correct MX and TXT records (DMARC & SPF) for that subaccount/location should be delivered to the inbox.

Have the ability to have a profile picture when we send an email to make it stand out while using ghl as our inbox.

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.

We created a subdomain on Highlevel through lead connector. However, after adding our DNS records we lost incoming email deliverability to our main domain email (hosted by Google). Any suggestions on preventing this?