Email System

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

Hello there! I am requesting for the following endpoint ' https://backend.leadconnectorhq.com/reporting/emails/aggregate/status ' to be available on the V2 Public API. This API endpoint gives LC Email stats for a particular location, is there a possibility of making it available to users of the V2 Public API?

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

Formal Complaint: Unsubscribe Requirements, Customer Autonomy, and Inadequate Technical Support I find this response deeply disappointing and frankly unacceptable. I am a paying HighLevel client, not a volunteer product tester submitting ideas for features that may or may not be considered someday. I am raising a legitimate concern about how your platform treats businesses and their subscribers. I have invested considerable time and resources into building a professional email infrastructure, including dedicated sending domains, branded email templates, and a fully functioning custom unsubscribe system integrated with HighLevel's own DND functionality. My unsubscribe system works. My subscribers can unsubscribe. HighLevel correctly records their decision. Yet your platform continues to display a warning that my emails are missing an unsubscribe link. Your proposed solution is to add HighLevel's native unsubscribe link, which may expose my subscribers to an intrusive questionnaire that I find completely inappropriate for my brand. Why should HighLevel dictate the questions my subscribers encounter when they simply wish to unsubscribe? Subscribers should be able to withdraw their consent without being subjected to an experience designed by a third-party software provider that I have explicitly chosen not to use. I understand and support legitimate email compliance requirements. I expect HighLevel to meet those requirements and provide the technical infrastructure necessary to protect deliverability. But I strongly object to presenting HighLevel's own interface and questionnaire as though they were inseparable from industry compliance. Even more concerning, your support representative was unable to provide a definitive answer about whether the persistent warning affects my domain reputation, email warmup, or deliverability. These are fundamental technical questions about your own platform. They should not be redirected to an Ideas Board. I am asking HighLevel to take responsibility for a contradiction in its product: You officially support custom unsubscribe workflows. Your system successfully processes those workflows. Your email editor nevertheless fails to recognize them. Your suggested workaround undermines the very customization your platform claims to support. This is a product and customer-experience issue that deserves technical investigation and a clear resolution. I expect this concern to be escalated to the appropriate product and email deliverability teams, with a substantive explanation of how paying clients can maintain their own branded unsubscribe experience while satisfying HighLevel's validation and deliverability requirements. I am not requesting permission to customize my brand experience. I am asking HighLevel to support the functionality it already advertises and to stop treating a legitimate customer concern as an optional feature request. Please escalate this complaint and provide a meaningful response. Lana Elco

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.

After a month of troubleshooting I finally learned that the 2way sync with Outlook only supports the native version of Outlook, not the desktop version. This is a great disappointment and was a huge waste of hours of troubleshooting with the support team. (At least this limitation should be noted clearly where the sync settings are located.) This ability to sync was one of the key items I looked at before joining GHL and now is not able to function.

Most of the system generated emails (eg for new contact created or appointment scheduled) are ugly, not translated and I cannot find a way to turn them off. Please let us customise all the system generated emails.

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.

One click “Export statistics” that would export an XLSX with multiple sheets. Campaign Performance (table of stats) Opens Performance (list of open email addresses, contact names, company names, event timestamp) Clicks Performance (list of click email addresses, contact names, company names, link clicked, event timestamp) Or if Excel workbook is too fiddly, separate csv export button as you have now, but with the option to select the fields you want in your export.

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