LC Email System

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.

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 need a native "Export BIND Zone File" button inside the Email Services (Dedicated Domain) dashboard. When creating a dedicated email subdomain, instead of being forced into a looping third-party API handshake or being forced to manually copy and paste 5 to 6 individual records (MX, TXT, CNAME) one by one, GoHighLevel should generate a single, standard .txt or .zone BIND file. Agency owners can then download this single file and upload it directly into their DNS manager (Cloudflare, Namecheap, etc.) using native import tools, deploying all required infrastructure instantly in two clicks. The Problem It Solves (For New Agency Owners): When you set up a dedicated email subdomain for a client (like :// clientdomain.com ), GoHighLevel requires you to add several technical DNS records (typically 2 MX records, 2 TXT records for SPF/DKIM authentication, and 1 CNAME for tracking). Currently, GHL relies on "Domain Connect" to do this automatically. However, this API automation frequently fails, crashes, or loops, leaving you stuck. When it breaks, you have to do robotic, mind-numbing data entry—copying the "Type," the "Name," and the "Value" for 6 different records. If you are onboarding multiple clients or setting up multiple sending subdomains, you are copying and pasting dozens of times. This takes forever and makes it incredibly easy to make a small typo that breaks your client's email delivery entirely. Why This is a Game-Changer (The Use Case): Bypasses API Failure Loops: If the Cloudflare or GoDaddy Domain Connect integration experiences a service lag, handshake drop, or security block, agencies are not left stranded. A zone file bypasses the automated bridge entirely. Support for ALL Registrars (Not Just the Big Players): Domain Connect only works with a few major providers like Cloudflare and GoDaddy. If a client uses Namecheap, Hostinger, Squarespace, or a local regional registrar, you have always been forced to do manual entry. Almost every major registrar on earth supports standard BIND Zone File imports. This feature extends bulk-setup speed to 100% of registrars. Flawless Virtual Assistant (VA) Delegation: Instead of giving a VA or a client access to sensitive account configurations or risking copy-paste errors, an agency can simply hand them a single file to click "Import." Zero margin for human error. How to cast your vote: If you want to save hours of manual data entry, eliminate onboarding bottlenecks, and ensure your client email setups are 100% accurate every single time regardless of what DNS provider they use, please upvote this feature request!

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.

We have a dedicated domain for workflows. Anytime an email is sent via a workflow, it is sent through this domain and applies the default headers (name/email) assigned to that domain. I just created a new workflow with an email action. We would like that email to be sent from a different header than what is currently on the workflow domain. Unfortunately, the "From Name" and "From Email" fields in an email action do not override the workflow domain header. Currently, you can assign more than one domain as a workflow domain. This splits the frequency up of which domain a workflow chooses as its sending domain. For example: You're sending 100 emails through a workflow and you have a 50% frequency for both domains, each one will send 50 emails. It would be nice to override the default headers with the headers in email actions OR if you have multiple dedicated domains configured to be workflow domains, you have the choice of picking only a single one of those domains to use for a specific workflow.

I’ve already set up the dedicated domain, but the email used for sending emails is unable to receive replies, and those responses don’t appear under the conversation tab. And with the new Domain resell feature, this is a must. We don't have dedicated inbox for our main domains and official email adresses.

For transparency, can we display the email usage costs chargeable to that sub-account on the Settings > Email Services page based on Email provider in use.

They could change the Mailgum server, the emails fall to SPAM, they could enable the option of connecting multiple emails through SMPT, application password or Oath, I give an example of other platforms for mass mailing and campaigns They could change the Mailgum server, the emails fall into SPAM, they could enable the option to connect multiple emails through SMPT, application password or Oath I send an image from another platform that I use to send mass campaign emails, they connect to several email providers and even heat up the emails

We run multiple businesses within a single sub-account, and each business uses its own verified Email Sending Domain (ESD). Currently, when a team member sends an email from the CRM, the system often ignores that team member's domain and forces the email to be sent using the sub-account's primary/default domain. This looks unprofessional and creates technical delivery problems. Example Scenario The sub-account has two businesses with verified sending domains: Business A Domain: xyz.com Business B Domain: abc.com The Limitation: If a staff member named john@abc.com sends a customer email, the system incorrectly tries to send it using the xyz.com domain. Proposed Feature: Automatic Domain Routing We request a new feature that automatically checks the staff member's email address and uses the matching verified sending domain for the outbound email. Implementing this automatic domain routing will ensure every email is sent from the correct business's domain, maintaining brand consistency and improving email deliverability. Thank you for considering this essential feature.

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