Configurable “On Behalf Of” From Address for Multi-Tenant Email Sending

Pamela 5 Reputation points
2026-08-29T14:26:17.13+00:00

We would like Microsoft/Azure email services to provide greater control over how the From field is displayed when an application sends email on behalf of a client or tenant.

Our platform, BizPlex, sends transactional emails on behalf of multiple businesses. We would like the ability to configure the email headers so recipients see a format similar to:

From: notifications=******@mg.businessname.com on behalf of Business Name (via BizPlex) ******@bizplex.com

This is similar to the behaviour used by platforms such as Cliniko, where the recipient can clearly see which business the email relates to while also seeing which platform actually sent the email.

 

We would like Microsoft to support configurable sender presentation that allows:

  • A client/business-specific From identity, including a tenant-specific sending address or domain.
  • An explicit “on behalf of” relationship in email clients such as Outlook.
  • A configurable display name such as “Business Name (via BizPlex)”.
  • BizPlex's authenticated sending address, e.g. ******@bizplex.com, to remain visible.
  • Support for this configuration through Azure/Microsoft email services and APIs, while maintaining SPF, DKIM and DMARC compliance.

Business Use Case

BizPlex is a multi-tenant platform where emails are generated for individual client businesses. Currently, using a single sender can make an email appear to come directly from BizPlex rather than from the business the customer is interacting with.

An explicit “Business on behalf of / via Platform” format would provide greater transparency and make it immediately clear that:

Business Name = organisation communicating with the customer

BizPlex = technology platform responsible for sending the email

This capability would be particularly valuable for CRM, booking, healthcare, professional-services and other multi-tenant SaaS platforms that send transactional communications on behalf of their customers.

Azure Communication Services
0 comments No comments

2 answers

Sort by: Oldest
  1. James Gamble 170 Reputation points
    2026-08-29T20:01:31.0833333+00:00

    Hola Pamela,

    I think what you’re trying to achieve makes sense, especially for a multi-tenant platform where the recipient needs to understand both who the message is for and which platform actually sent it.

    The tricky part is that there are a couple of different email concepts involved here.

    The From header identifies the apparent author of the message. A separate Sender header can identify the system or account that actually transmitted it when it differs from the From identity. Some mail clients, including Outlook, may display that relationship as “on behalf of” or “via,” but that presentation is controlled by the receiving client. It isn’t simply text that Azure Communication Services can force Outlook to display.

    ACS Email does support custom verified domains, multiple sender usernames, and configurable display names.

    So, for example, if mg.businessname.com is verified in ACS, you could send from: ******@mg.businessname.com

    Display name: Business Name (via BizPlex)

    That would give you the customer-specific branding you’re looking for.

    Where ACS appears to fall short is the exact dual-identity model you described. It doesn’t currently give you a per-message way to say “this business is the From identity, but BizPlex is the separate Sender identity” and then rely on Outlook to render that as a native “on behalf of” relationship.

    DMARC is also important here. DMARC evaluates alignment against the domain in the From address, so if the message says it is from mg.businessname.com, that domain needs to be properly authenticated with an aligned SPF and/or DKIM record. Simply authenticating bizplex.com while putting the customer’s domain in the From field would not give you the clean alignment you’re after.

    Microsoft explains the ACS authentication model here.

    Practically, I think you have two workable options today:

    Use a verified sending domain or subdomain for each customer. That gives you the strongest customer branding and proper authentication, but it adds some onboarding work.

    Or, send from a BizPlex-owned domain and use a display name such as “Business Name (via BizPlex),” with Reply-To set to the customer’s address. That’s much easier to operate at scale, but the actual From domain remains BizPlex.

    If your requirement is specifically for Outlook to show a true “Business Name on behalf of BizPlex” relationship with both identities represented separately, I believe that would need to be treated as a feature request for ACS rather than something that can be configured today.

    Thanks,

    James

    Was this answer helpful?

    0 comments No comments

  2. Minas Casiou 0 Reputation points
    2026-10-04T00:40:22.1733333+00:00

    Hi James, thanks for the thoughtful breakdown — genuinely appreciate the clarity around From, Sender, DMARC alignment and how Outlook chooses to render “on behalf of” relationships.

    That said, this still doesn’t address the core problem we’re raising.

    Our requirement isn’t unusual or niche. Many mainstream email providers that support SaaS platforms at scale — sending thousands or millions of messages on behalf of clients — already offer a configurable dual‑identity model where:

    the client’s domain is the From identity

    the platform’s domain is the authenticated Sender identity

    email clients display the native “on behalf of / via” relationship

    This is standard behaviour in other ecosystems, and it’s essential for multi‑tenant SaaS platforms like ours where transparency, branding clarity, and trust are critical.

    Your answer confirms that ACS currently cannot provide this dual‑identity configuration and instead suggests workarounds that either break the branding model or require heavy domain‑by‑domain onboarding that doesn’t scale for large SaaS environments.

    So while I appreciate the explanation, the reality is that ACS is missing a capability that other providers already support and that SaaS platforms rely on. This is why we’re asking Microsoft to consider native support for this pattern — not as a workaround, but as a first‑class feature.

    Thanks again for engaging with the question.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.