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:

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:

-Reduced confidence in the business sending the message

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