Email System

HighLevel already allows multiple dedicated sending domains inside one sub-account and lets us assign specific domains to workflows. However, when sending a manual 1:1 email from Conversations or a contact record, there is currently no option to choose which dedicated sending domain should be used. The email is sent through the primary domain of the sub-account. This creates a problem for agencies and businesses managing multiple brands, departments, or domains inside the same sub-account. It would be very useful to add a simple Sending Domain dropdown when composing a manual email, similar to the domain selection already available for workflows. This would allow users to: keep each brand sending from its correct domain; manage multiple brands without creating separate sub-accounts; maintain cleaner domain reputation and brand consistency; use HighLevel Conversations for manual replies without switching to external webmail. Since multi-domain support already exists for workflows, extending the same flexibility to manual emails would make the feature much more complete.

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.

Problem HighLevel currently treats Email DND as a global suppression state. If a contact unsubscribes from marketing email, Email DND also prevents transactional and operational workflow emails from being delivered. HighLevel Support confirmed this behavior under Ticket GHL-6446254 and confirmed there is currently no supported method to exempt transactional/operational workflow emails from Email DND. This makes it difficult to maintain separate consent states for marketing communications and transactional/operational communications. Example A customer submits an application or service request and separately opts out of marketing. The business should stop sending newsletters, promotions, nurture campaigns and other marketing email. However, the customer may still need to receive: Application/form submission confirmations Document requests Application or account status updates Appointment confirmations/reminders Transaction receipts Service-related notices Customer-requested communications Other non-promotional operational communications Under the current architecture, marketing unsubscribe can prevent these operational messages as well. Requested Enhancement Please add separate email consent/suppression states for: Marketing Email Transactional / Operational Email Workflow email actions should be configurable as Marketing or Transactional/Operational. If a contact unsubscribes from marketing, HighLevel should suppress marketing email while continuing to permit legitimate transactional/operational communications. Ideally, HighLevel should also maintain auditable consent information including consent/withdrawal status, date/time, source and communication classification. Transactional/operational email should also support appropriate footer behavior rather than automatically using the same marketing-unsubscribe mechanism. Business Impact Businesses need to respect marketing opt-outs without inadvertently terminating communications necessary to service an application, appointment, transaction, account or other existing customer relationship. The current global Email DND architecture can force businesses to move operational communications outside HighLevel in order to maintain separate marketing and operational communication controls. Purpose-based DND would improve compliance architecture, customer experience and workflow reliability across financial services, healthcare, professional services, SaaS, home services, appointment-based businesses, e-commerce and other industries. Reference: HighLevel Support Ticket GHL-6446254

The problem HighLevel's LC Email service can generate outgoing messages with a separate RFC 5322 Sender: identity that differs from the customer's configured From: address. When businesses follow HighLevel's recommended practice of using a dedicated sending subdomain, some Outlook clients expose this additional sender identity and display an "on behalf of" message. For example: Intended visible sender: Jane Doe Jane@doe.com Actual presentation in affected Outlook clients: Jane=doe.com@mg.doe.com On behalf of Jane Doe The result is a confusing, unprofessional-looking sender identity that can make legitimate business communications appear suspicious. Gmail may display the same message correctly, while different Outlook clients and configurations expose the additional address. This is not simply an Outlook malfunction. Outlook is interpreting sender information supplied in the email headers. The sending platform controls which headers it generates. Confirmed customer configuration In our case, we have: A dedicated sending subdomain: mg.doe.com SPF verification completed DKIM verification completed DMARC verification completed Dedicated domain configured for relevant email-sending categories A configured From name and From email Successful delivery to Outlook inboxes We also tested different sender settings and worked through the domain configuration with support. Although completing DMARC configuration coincided with improved inbox placement, it did not resolve the visible sender issue. Changing the visible From address to the sending subdomain ( jane@mg.doe.com ) has been proposed as a workaround, but this compromises the professional email identity customers want to maintain. Technical explanation The suspected cause is an additional RFC 5322 Sender: header that differs from the visible From: header. A representative example would be: From: Jane Doe jane@doe.com Sender: jane=doe.com@mg.doe.com Return-Path: bounce-address@mg.doe.com When the Sender: and From: identities differ, some email clients display the additional sender identity as "on behalf of". The Return-Path serves a different purpose: handling delivery failures and bounces. It does not ordinarily need to be displayed as the sender identity. The precise header construction should be verified against a raw message from an affected recipient. Why this matters This creates a customer experience problem for businesses using HighLevel's recommended dedicated sending-domain configuration. The consequences include: Recipients potentially questioning whether the email is legitimate -Reduced confidence in the business sending the message Inconsistent presentation between Outlook and Gmail Additional customer-support enquiries Pressure to use less professional-looking addresses containing sending subdomains Potential negative effects on engagement and brand reputation The issue is particularly relevant to agencies and white-label partners like me, who recommend HighLevel to businesses as their communications platform. A customer should not have to choose between using the recommended authenticated sending infrastructure and maintaining a clean, recognisable sender identity. Proposed technical solution Where the visible From domain and authenticated sending domain are organisationally aligned, investigate whether LC Email can: Option 1 - Preferred Omit the separate RFC 5322 Sender: header when it is not technically required. Option 2 - Alternative Use a Sender: identity matching the configured From: identity, where permitted by the sending infrastructure and applicable standards. Option 3 - Configuration control Provide an account-level setting to control the inclusion of the Sender: header for authenticated dedicated sending domains. In all cases, preserve: SPF authentication DKIM signing DMARC alignment Bounce handling through the Return-Path Sending-domain reputation management Existing deliverability protections The objective is not to weaken authentication. It is to separate the technical bounce-handling identity from the visible sender identity wherever the architecture allows. LeadConnector and Mailgun responsibilities LC Email uses email delivery infrastructure associated with Mailgun. It is not yet established whether the additional Sender: header is introduced by LeadConnector's application layer or by the underlying delivery infrastructure. However, this distinction should be investigated internally rather than left to individual customers. HighLevel owns the customer-facing LC Email service and is therefore best positioned to coordinate a technical review with the relevant engineering or infrastructure teams. Current response from HighLevel support In support ticket #6478373, HighLevel confirmed: "Suppressing or modifying the RFC 5322 Sender header is not currently a supported feature within our system architecture." Support further explained that the behaviour is considered expected platform architecture rather than a recognised bug and recommended submission to the Ideas Board. We appreciate that this may be expected behaviour within the current implementation. However, expected behaviour can still represent a product limitation requiring improvement. Requested outcome We are asking HighLevel to: Confirm which system generates the additional RFC 5322 Sender: header. Explain whether that header is technically required when the From domain and authenticated sending subdomain are aligned. Investigate whether it can be omitted or modified without compromising authentication or deliverability. Provide a supported method for sending bulk emails from a root-domain address without triggering the long "on behalf of" presentation in affected Outlook clients. Publish clear guidance explaining the current limitation and any available workarounds. The desired outcome is simple: A business using jane@doe.com as its legitimate From address and mg.doe.com as its authenticated sending domain should be able to send professional emails without recipients seeing a confusing rewritten sender identity. This is a sender-identity and customer-trust issue affecting the core email-sending experience, not merely a request for cosmetic customisation. Related HighLevel support ticket: #6478373

Email is not Receiving in Inbox. I have done all good practices to send my Email having One CTA or link to receive in Gmail inbox but I am tired to receive in clients inbox

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

Appointment confirmations and reminders get the automatic "Reply STOP to unsubscribe" line and sender name, on the first text and again every 30 days. For a client who just booked, that reads like marketing, and if they reply STOP they also lose their reminders. We'd like to mark a workflow's SMS step (or a calendar's notifications) as transactional, so the automatic line isn't added there, while it stays on for marketing texts.

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.

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.

Whenever ANY malicious actor sends an email to your LC Email sending domain, that email will appear in the Conversations Tab. Whether that email contains malware or phishing links, it will still show in the Conversations Tab. If you have a Contact in your CRM which these malicious emails may come from, it will trigger a reply, seemingly making the email seem legit. If you have Email Forwarding enabled inside HL, these malicious emails get forwarded via your LC Email sending domain, and in the case of it going to your Gmail account, gets properly flagged as Spam or Malicious, but now your LC Email Domain is receiving these bad signals, giving it a bad Reputation and it hurts your Deliverability. In Gmail these emails properly get flagged as spam...they go straight to the junk folder. But not inside the CRM platform. Add proper Spam protection like Gmail has to ensure malicious actors do not piggyback off of our LC Email sending domains to get their email delivered. I'm told this should be a feature request, but LC Email which is Mailgun, should have this by default seeing as Mailgun has inbound spam filtering available as a setting.