Skip to content

Enterprise Email Solution — Non-PHI/PII Informative Notifications via Non-User ID (M365)

Document Version: 1.0 | Date: March 12, 2026 Classification: Internal — Non-PHI / Non-PII Only Scope: Alerting, Job Updates, and Operational Notifications

Table of Contents

  1. Executive Summary
  2. 1.1 Purpose
  3. 1.2 Scope
  4. 1.3 Goals, Objectives, Assumptions, Constraints and Risks
  5. 1.4 Related Documents
  6. Overall Design
  7. 2.1 Components
  8. 2.2 High-Level Design
  9. Solutions
  10. 3.1 Solution Overview
  11. 3.2 Solution Scope: PHI/PII vs. Informative
  12. 3.3 Implementation Options
  13. 3.4 Implementation Option Comparison
  14. Implementation
  15. 4.1 Team Responsibilities
  16. 4.2 Logic App Setup (Standard Plan, VNet)
  17. 4.3 Java Code Integration
  18. Warning — Security and External Sending Considerations
  19. Testing
  20. Appendices
  21. Appendix A — Acronyms
  22. Appendix B — Links

1. Executive Summary

1.1 Purpose

This document describes the enterprise solution for enabling automated, non-PHI/PII email notifications using Microsoft 365 (M365) via a Non-User ID account. It addresses the newly enforced throttling limits Microsoft has applied to .onmicrosoft.com (MOERA) domains and provides a compliant, scalable, and team-owned approach for sending internal operational alerts and job update notifications.

The solution has been validated and tested. This document serves as the reference architecture and implementation guide for all teams adopting this pattern.

1.2 Scope

In Scope:

  • Automated email notifications containing non-PHI / non-PII data only
  • Use cases include: job status alerts, pipeline failures, operational updates, scheduled report summaries
  • Internal distribution lists (DLs) and verified internal @optum.com recipients only
  • M365 Non-User ID-based sending via Logic Apps (Standard Plan) or Java code

Out of Scope:

  • PHI (Protected Health Information) and PII (Personally Identifiable Information) data in email body, subject, or attachments — this is explicitly not covered in this document
  • State-specific data sending
  • External recipient email sending (requires separate security architecture review — see Section 5)
  • Client-facing email communications

Note: A separate architecture document will address PHI/PII email paths. That path requires distinct security controls, encryption, and compliance reviews and is intentionally excluded here to maintain clear separation of concerns.

1.3 Goals, Objectives, Assumptions, Constraints and Risks

1.3.1 Goals

  • Provide a compliant, repeatable pattern for teams to send automated internal email notifications without using the .onmicrosoft.com domain in a manner that exceeds the new Microsoft enforced limits
  • Establish a Non-User ID-based identity as the sending principal so that email is not tied to any individual employee account
  • Ensure all teams are self-sufficient in setting up and maintaining their own email-sending infrastructure
  • Restrict all email sending to internal targets only (internal DLs and @optum.com)
  • Keep the solution lightweight, cost-effective, and maintainable

1.3.2 Requirements

ID Requirement Priority
R-01 Email must be sent only to internal distribution lists or verified @optum.com addresses Must Have
R-02 No PHI or PII data may be included in any email sent via this solution Must Have
R-03 The sending identity must be a Non-User ID (service/functional account) — not a personal employee account Must Have
R-04 Logic App must be deployed on the Standard Plan and placed inside a Virtual Network (VNet) Must Have
R-05 Each team must independently provision their own Non-User ID and Logic App or Java integration Must Have
R-06 All creation requests and support must go through the company portal Must Have
R-07 Java-based sending teams must implement their own SMTP/Graph API integration Should Have
R-08 External sending must not be enabled without explicit approval from the Security Architecture team Must Have

1.3.3 Assumptions

  • Teams have access to the company portal to raise requests for Non-User ID creation
  • Teams have Azure subscriptions with permissions to deploy Logic Apps on the Standard Plan
  • The Non-User ID will be provisioned under the organization's custom domain (not .onmicrosoft.com)
  • All recipients are internal — either @optum.com addresses or internal distribution lists
  • Teams are responsible for the content they send; governance controls (e.g., DLP policies) are assumed to be in place at the organization level
  • The Office 365 connector in Logic Apps has sufficient permissions granted to the Non-User ID

1.3.4 Constraints

  • PHI and PII sending is not part of this solution — any team attempting to send PHI/PII via this path is violating the constraints of this architecture
  • State-specific data sending is not covered — regulatory constraints vary by state and are out of scope
  • External sending is restricted — emails must not be routed to external domains without explicit security architecture review and approval
  • This solution applies to informative / operational notifications only
  • Only Logic Apps on the Standard Plan are within scope for the VNet integration requirement; Consumption Plan Logic Apps must not be used for this pattern
  • Each team is limited to their own Non-User ID and may not share accounts across teams

1.3.5 Risks

Risk Likelihood Impact Mitigation
Team accidentally includes PHI/PII in email body or subject Medium High Enforce DLP policies at the M365 level; teams must review content classification before sending
Non-User ID credentials are mismanaged or shared Low High Follow company portal provisioning process; rotate secrets regularly via Key Vault
Logic App is deployed on Consumption Plan outside VNet Medium Medium Architecture review gate; enforce Standard Plan in deployment pipelines
External emails are sent without security review Low High Disable external routing by default on the Non-User ID mailbox; require explicit connector configuration for any external routing
Microsoft enforces further restrictions on licensed accounts Low Medium Monitor Microsoft 365 Message Center; maintain this document with updated limits
Document Description
Microsoft Tech Community — Limiting Onmicrosoft Domain Usage Source blog describing the new MOERA throttling limits — see Appendix B
Company Portal — How to Create a Non-User ID Step-by-step guide for provisioning the functional account — see Appendix B

2. Overall Design

2.1 Components

Component Description Owner
Non-User ID (Functional Account) A licensed M365 service/functional account (not tied to any individual) used as the sending identity. Created via the company portal. Each Team
Non-User ID Company Mailbox Company mailbox associated with the Non-User ID, provisioned via the company portal. Configured to send to internal targets only. Each Team (via Company Portal)
Logic App (Standard Plan) Azure Logic App deployed inside a VNet using the Office 365 connector to trigger and send emails. Recommended approach. Each Team
Java Code (Optional) Team-owned Java application that calls M365 Graph API or SMTP relay using the Non-User ID credentials. Each Team
Azure Virtual Network (VNet) Network boundary within which the Logic App resides. Ensures network-level isolation and compliance. Each Team / Platform Team
Azure Key Vault Secure storage for Non-User ID credentials and secrets used by Logic Apps or Java code. Each Team
Company Portal Internal portal for raising Non-User ID creation requests and support tickets. Organization / IT
Internal Distribution Lists (DLs) Target recipients of the automated notifications. Must be internal @optum.com DLs only. Each Team

2.2 High-Level Design

┌─────────────────────────────────────────────────────────────────────────┐
│                          Team-Owned Azure VNet                          │
│                                                                         │
│   ┌────────────────────────┐                                            │
│   │    Trigger Source      │                                            │
│   │  (Pipeline / Job /     │──────────────────┐                         │
│   │   Scheduler / Event)   │                  │                         │
│   └────────────────────────┘                  ▼                         │
│                                                                         │
│              ┌─────────────────────────────────────────┐                │
│              │     Team Implementation Choice          │                │
│              └──────────────┬──────────────────────────┘                │
│                    ┌────────┘           └────────┐                      │
│                    ▼                             ▼                      │
│   ┌─────────────────────────────┐  ┌─────────────────────────────────┐  │
│   │  Option 1: Logic App        │  │  Option 2: Java Code            │  │
│   │  (Standard Plan, VNet)      │  │  (Team-owned service)           │  │
│   │  Office 365 Connector       │  │  MS Graph API / SMTP            │  │
│   └──────────────┬──────────────┘  └──────────────┬──────────────────┘  │
│                  │                                │                     │
│                  └─────────────┬──────────────────┘                     │
│                                │ Authenticate as Non-User ID            │
│   ┌────────────────────────┐   │                                        │
│   │  Azure Key Vault       │◀──┘                                        │
│   │  (Secrets / Creds)     │   |                                        │
│   └────────────────────────┘   |                                        │
│                                │                                        │
│                                ▼                                        │
│                  Non-User ID Company Mailbox                            │
│                  (Non-PHI / Non-PII only)                               │
└──────────────────────────────────┬──────────────────────────────────────┘
                                   │
                     Internal Only │ (internal DL or @optum.com)
                                   ▼
                     ┌─────────────────────────┐
                     │  Internal Recipients    │
                     │  - @optum.com mailboxes │
                     │  - Internal DLs only    │
                     └─────────────────────────┘

Flow Description:

  1. A trigger event (pipeline failure, scheduled job, operational alert) fires
  2. The team's chosen implementation (Logic App on Standard Plan, or Java code) is invoked
  3. Credentials for the Non-User ID are retrieved from Azure Key Vault
  4. The implementation authenticates as the Non-User ID and sends email via the Office 365 connector (Logic App) or Microsoft Graph API / SMTP (Java)
  5. Email is sent from the Non-User ID Company Mailbox to the internal distribution list or @optum.com recipient
  6. All content is non-PHI / non-PII informational data only

3. Solutions

3.1 Solution Overview

The core of the solution is the use of a Non-User ID (functional account) provisioned through the company portal. Once the Non-User ID is created and an M365 mailbox is associated with it, the account is used exclusively as a sending identity for automated, informative notifications.

Why this approach:

  • Avoids the .onmicrosoft.com MOERA domain throttling limit (100 external recipients per 24-hour rolling window — see Appendix B)
  • Decouples the sending identity from any individual employee — no dependency on personal accounts
  • Enables audit tracking at the functional account level
  • Works within existing M365 licensing without additional cost per team
  • Keeps each team in full control of their own sending pipeline

3.2 Solution Scope: PHI/PII vs. Informative

The organization's email strategy is deliberately split into two paths:

Path Description Covered in This Document
Informative / Operational Non-PHI, non-PII alerts, job notifications, pipeline statuses, operational updates sent to internal recipients Yes — this document
PHI / PII Communications containing protected health information or personally identifiable information No — separate document and architecture required

This document exclusively covers the Informative path. The PHI/PII path requires distinct encryption, compliance controls, and will be addressed in a separate architecture document.

3.3 Implementation Options

The solution is the company-provided Non-User ID (functional account) with an M365 mailbox, provisioned through the company portal. This is the authoritative sending identity for all automated informative notifications. See Appendix B — Company Portal: How To Create a Non-User ID for the official reference.

How a team integrates with that sending identity is an implementation choice left to each team. Two options are available:

3.3.1 Option 1: Logic App with Office 365 Connector

Teams can use an Azure Logic App (Standard Plan, inside a VNet) with the built-in Office 365 Outlook connector to send email via the Non-User ID. This is a no-code / low-code option suitable for most teams. Refer to Section 4.2 for setup steps.

3.3.2 Option 2: Java Code Integration

Teams with existing Java services can send email programmatically using the Microsoft Graph API or SMTP relay, authenticating as the Non-User ID. This option requires the team to own and maintain the integration. Refer to Section 4.3 for guidance.

The choice between Option 1 and Option 2 is entirely up to each team based on their existing stack and preferences. Both options use the same company-provided Non-User ID solution as the sending identity.

3.4 Implementation Option Comparison

Criteria Option 1: Logic App (Office 365 Connector) Option 2: Java Code
Setup Complexity Low — no-code/low-code Medium — requires Java development
VNet Integration Native (Standard Plan required) Depends on team's network setup
Attachment Support Yes — PDF, TXT, and others supported Yes — fully flexible
Credential Management Key Vault + Logic App managed identity Key Vault or env-based secrets
Cost Standard Plan (~$40+/month) No additional Azure cost (code only)
Maintenance Low Medium
Retry / Error Handling Built-in Must implement in code
Recommended For Most teams — quick adoption Teams with existing Java services
PHI/PII Risk Must be controlled by team Must be controlled in code
External Sending Must be disabled — restricted (see Section 5) Must be restricted in code

4. Implementation

4.1 Team Responsibilities

Each team is independently responsible for their own provisioning, deployment, and ongoing management. There is no shared service or centralized instance for this solution. This is intentional — each team's use case, recipients, triggers, and content are specific to their workload.

Responsibility Owner
Raise Non-User ID creation request via company portal Individual Team
Configure the Non-User ID mailbox for internal sending only Individual Team (with IT via Company Portal)
Deploy Logic App (Standard Plan) or implement Java code Individual Team
Place Logic App inside VNet Individual Team
Store credentials in Key Vault Individual Team
Configure Office 365 connector (Logic App teams) Individual Team
Test email flow (see Section 6) Individual Team
Raise support requests via company portal Individual Team

Important: For every step in this process, teams must use the company portal for creation requests and any support. Direct requests to IT via chat or email for Non-User ID provisioning will not be prioritized. All steps are documented in the company portal. See Appendix B for the Non-User ID creation guide.

4.2 Logic App Setup (Standard Plan, VNet)

  1. Create Azure Logic App (Standard Plan)
  2. Navigate to Azure Portal > Logic Apps > + Create
  3. Select Standard as the plan type (not Consumption)
  4. Choose the appropriate subscription, resource group, and region
  5. Enable VNet Integration — select the team's existing VNet and subnet

  6. Click Review + Create

  7. Configure Key Vault Access

  8. Assign a system-assigned Managed Identity to the Logic App
  9. Grant the Logic App's managed identity Key Vault Secrets User role on the team's Key Vault

  10. Store the Non-User ID credentials (client ID, secret, or password) in Key Vault

  11. Add the Office 365 Outlook Connector

  12. In the Logic App designer, add a new action: Office 365 Outlook — Send an email (V2)
  13. Authenticate the connector using the Non-User ID credentials

  14. Set the From field to the Non-User ID's email address

  15. Configure the Email Action

  16. To: Internal distribution list or @optum.com address only
  17. Subject: Descriptive, non-sensitive subject line
  18. Body: Operational / informative content only — no PHI/PII
  19. Attachments (optional): PDF, TXT, or other non-sensitive files as needed

Note: The parameters above define the mandatory baseline. All other email action parameters — such as CC, BCC, importance level, reply-to address, sensitivity label, HTML vs. plain text body formatting, and dynamic content mappings — are team-dependent and must be configured based on each team's specific use case, recipient requirements, and workflow design. Teams are responsible for defining and validating these additional parameters as part of their own Logic App implementation.

  1. Define the Trigger
  2. Use an appropriate trigger: HTTP request, Azure Service Bus, scheduled recurrence, or Event Grid event

  3. Ensure the trigger source is reachable within the VNet

  4. Test the Logic App

  5. Run a manual trigger test
  6. Validate email receipt at the internal DL or @optum.com address

  7. Verify the sending address shows the Non-User ID (not .onmicrosoft.com)

  8. Enable Monitoring

  9. Connect Logic App diagnostics to Azure Monitor / Log Analytics
  10. Set up alerts for run failures

4.3 Java Code Integration

Teams with existing Java services can integrate directly with the Non-User ID sending identity. Teams are fully responsible for implementing, testing, and maintaining this integration.

  1. Retrieve credentials from Key Vault
  2. Use the Azure SDK for Java to retrieve Non-User ID credentials at runtime

  3. Do not hard-code credentials in source code or configuration files

  4. Authenticate as the Non-User ID

  5. Use MSAL4J to acquire an OAuth token with the appropriate Microsoft Graph mail scope

  6. Alternatively, use the Non-User ID's SMTP credentials if configuring via SMTP relay

  7. Send email via Microsoft Graph API or SMTP relay

  8. Graph API (recommended): Use the Microsoft Graph sendMail endpoint authenticated with the Non-User ID token

  9. SMTP relay: Configure Jakarta Mail / JavaMail with the M365 SMTP endpoint using the Non-User ID credentials

  10. Restrict recipients to internal addresses only

  11. Validate all recipient addresses are @optum.com or internal DLs before sending

  12. Do not enable external routing — see Section 5

  13. Implement error handling and retry logic

  14. Handle throttling responses with appropriate backoff

  15. Log all send failures to your team's monitoring platform

  16. Test the integration

  17. Follow the test scenarios in Section 6
  18. Verify the sending address shows the Non-User ID (not .onmicrosoft.com)

Important: All constraints from Section 4.1 Team Responsibilities apply. Teams are fully responsible for ensuring no PHI/PII is included in any email content.

5. Warning — Security and External Sending Considerations

⚠️ WARNING: External Email Sending

While the Non-User ID mailbox and the Office 365 connector are technically capable of sending to external recipients, this must not be enabled without explicit review and approval from the Security Architecture team.

Key considerations:

  • Per-state regulations differ: The same sending solution cannot be uniformly applied across all states or clients. Some states have specific regulations governing automated communications, data handling, and notification requirements.
  • Client-specific constraints: For client-facing implementations, the solution must be re-evaluated and re-architected in collaboration with the Architecture team. Do not repurpose this internal solution for client communications.
  • Security review required: Any team that needs to send emails to external recipients must raise a formal request with the Security Architecture team for review on a per-state, per-client basis.
  • PHI/PII risk: External sending dramatically increases the risk of PHI/PII data leaving the organization's control. Content classification and DLP policies must be verified before any external configuration is considered.

Action Required: If your use case requires external email sending, stop and engage the Security Architecture team before proceeding. Do not enable external routing in the Logic App connector or Java code without written approval.

6. Testing

The solution has been validated end-to-end. The following test scenarios were executed:

Test 1 — High-Volume Email via Logic App

Attribute Details
Approach Used Logic App with Office 365 Connector (Standard Plan, VNet)
Volume 100+ emails sent
Time to Complete Less than 1 hour
Recipients Internal distribution list (@optum.com)
Content Non-PHI / non-PII operational notifications
Result All emails delivered successfully; no throttling errors
Sending Domain Organization custom domain via Non-User ID — not .onmicrosoft.com

100+ emails delivered successfully

Test 2 — Attachment Testing via Logic App

Attribute Details
Approach Used Logic App with Office 365 Connector (Standard Plan, VNet)
Attachment Types Tested PDF, TXT
Content Non-sensitive test files
Result Attachments delivered successfully to internal recipient

PDF attachment delivered

Text attachment delivered

Testing Notes

  • Testing was conducted with the Non-User ID account as the sender — validating the end-to-end provisioning and connection flow
  • The Logic App was confirmed to be operating within the VNet during testing
  • No PHI or PII data was used in any test scenario
  • For teams running their own tests, replicate these test cases before going to production

7. Appendices

Appendix A — Acronyms

Acronym Definition
ACS Azure Communication Services
DL Distribution List
DLP Data Loss Prevention
Graph API Microsoft Graph API
IRM Information Rights Management
MSAL Microsoft Authentication Library
MOERA Microsoft Online Email Routing Address
M365 Microsoft 365
NDR Non-Delivery Report
PHI Protected Health Information
PII Personally Identifiable Information
SMTP Simple Mail Transfer Protocol
SPF Sender Policy Framework
DKIM DomainKeys Identified Mail
DMARC Domain-based Message Authentication, Reporting and Conformance
TLS Transport Layer Security
VNet Azure Virtual Network
Resource URL
[1] Microsoft Tech Community — Limiting Onmicrosoft Domain Usage for Sending Emails https://techcommunity.microsoft.com/blog/exchange/limiting-onmicrosoft-domain-usage-for-sending-emails/4446167
[2] Company Portal — How To: Create a Non-User ID https://uhgazure.sharepoint.com/sites/PowerPlatformCoE/SitePages/HowTo_CreateNonUserID.aspx
[3] Microsoft — Manage Accepted Domains in Exchange Online https://learn.microsoft.com/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains
[4] Microsoft — AD FS Overview https://learn.microsoft.com/windows-server/identity/ad-fs/ad-fs-overview
---

Reference: MOERA Throttling Limits (from [1])

The following table summarizes the new .onmicrosoft.com (MOERA) email throttling enforcement introduced by Microsoft. Source: Microsoft Tech Community Blog [1].

New Throttling Rule:

100 external recipients per 24-hour rolling window per organization — applies to all outbound email sent from any .onmicrosoft.com domain. When exceeded, senders receive NDR: 550 5.7.236.

Rollout Timeline (by Exchange seat count):

Throttling Enforcement Start Date Exchange Seats in Tenant
October 15, 2025 Trial tenants
December 1, 2025 Fewer than 3 seats
January 7, 2026 3 – 10 seats
February 2, 2026 11 – 50 seats
March 2, 2026 51 – 200 seats
April 1, 2026 201 – 2,000 seats
May 4, 2026 2,001 – 10,000 seats
June 1, 2026 More than 10,001 seats

Impact for our organization: As of March 2, 2026, the throttling limit is in effect for tenants with 51–200 Exchange seats. Organizations with 201+ seats will be affected from April 1, 2026 onward. The 100-recipient cap is org-wide — not per user or per mailbox — meaning all automated and manual sends from .onmicrosoft.com addresses are counted against the same shared pool.

This is the primary driver for this solution. Even with valid M365 licenses, the MOERA domain throttle applies. The Non-User ID solution avoids this entirely by sending from the organization's custom domain (e.g., @optum.com).

Document maintained by the Architecture team. For questions, corrections, or updates, raise a request via the company portal or contact the Architecture team directly.