Step 1
Choose the masking domain
Use a company-owned domain or dedicated subdomain for protected client identities, based on branding, separation, and operational requirements.
Microsoft 365 email masking ✨
Protect client email addresses while your team keeps using Outlook
ProxiedMail can operate as a controlled routing and masking layer alongside Microsoft 365, so authorized employees continue working in Outlook instead of moving into another messaging application.
The exact deployment depends on your Microsoft 365 tenant, domains, desired external sender identity, and Exchange Online mail-flow configuration.
Microsoft 365 / Outlook
Employee workflow
Protected client address
Used internally
ProxiedMail
Controlled routing layer
Real client
Receives normal email
Return path
Real client
Replies normally
ProxiedMail
Routes return path
Microsoft 365 employee
Reads in Outlook
How Microsoft 365 email masking fits the mail flow
Use standard email infrastructure and deployment-specific routing to keep the employee experience familiar.
Step 2
Configure mail routing
Set the required DNS, SPF, DKIM, sender-domain, and Exchange Online or mail-flow configuration for the selected architecture.
Step 3
Authorize and revoke
Map protected contacts to approved employees or teams, then update or remove that access during offboarding and account reassignment.
Keep your company identity externally
Internal protection does not have to change the client's email workflow
An employee can work with a protected client address internally while the external client continues to see an authorized company sender identity when the deployment is configured for that workflow. Sender identity, return-path behavior, and routing are deployment-specific and should be validated for the customer's environment.
A design review determines whether a subdomain, connector, transport rule, or other mail-flow configuration is appropriate.
Employee in Outlook
Protected client identity
ProxiedMail routing
Company sender identity
Client inbox
Business benefits
Add control while keeping the Outlook workflow
Employees keep Outlook
Continue reading and sending email through the Microsoft 365 tools employees already know.
Protected internal contact
Use a controlled identity for routine work instead of distributing the underlying client address.
Company-owned domains
Use a suitable company domain or dedicated subdomain for the masking workflow.
Revocable routing
Remove or reassign communication access as employment and account ownership change.
Domain configuration support
Plan SPF, DKIM, DNS, and sender-domain configuration for the selected mail architecture.
Enterprise infrastructure
Dedicated infrastructure and deliverability or reputation monitoring can be scoped where included in an enterprise deployment.
Deployment choices
Match the routing layer to your Microsoft 365 environment
There is no single tenant configuration that fits every company. The right design depends on domains, identity, mailbox access, and mail-flow policy.
Dedicated masking subdomain
Separate protected contact identities from normal employee mailbox addresses.
Exchange Online mail flow
Coordinate the selected route with connectors, transport policy, or other tenant configuration where needed.
Account-team communication
Let authorized employees work from Outlook with controlled client addresses.
Offboarding and reassignment
Update access without asking the external client to adopt a new communication tool.
Microsoft 365 configuration
Use normal email infrastructure—not an assumed Graph dependency
A deployment may combine a custom masking domain, DNS records, SPF and DKIM, Exchange Online mail-flow configuration, dedicated mail infrastructure, and custom sender-domain configuration. Microsoft Graph is not automatically required, and this page does not claim a native Graph integration.
- Confirm which system owns the sender domain and signing configuration.
- Validate inbound, outbound, reply, and bounce behavior before rollout.
- Document the revocation path for Microsoft 365 user offboarding.
Outlook
Exchange Online mail flow
ProxiedMail
Protected client route
External client
Clear answers
Frequently asked questions
Do employees need another email application?
No. A deployment can keep employees in Outlook while ProxiedMail provides the controlled routing layer.
Can we use our existing Microsoft 365 domain?
Potentially. Whether to use the primary domain or a dedicated subdomain depends on your tenant, DNS, sender identity, and routing requirements.
Can the external client continue seeing our normal company email?
That can be configured for appropriate enterprise workflows, but the exact sender identity and reply behavior depend on the selected domain and mail-flow architecture. It should be validated during deployment.
Does ProxiedMail require mailbox access?
Not every deployment requires direct mailbox access. The required access depends on how messages are routed, signed, and sent in the chosen architecture.
Do we need Microsoft Graph?
Not necessarily. Standard DNS and email-routing configuration can support many workflows. A custom integration may use Microsoft APIs only when the customer's design calls for them.
Can we use a dedicated subdomain?
Yes. A dedicated masking subdomain is often useful for separating protected identities and their DNS or routing policy.
What DNS changes are required?
The exact records depend on the design and may include MX, SPF, DKIM, and verification records. ProxiedMail and Microsoft 365 settings must be planned together.
Can access be revoked when an employee leaves?
Yes. The protected route can be disabled or reassigned, and that step should be included in the company's Microsoft 365 offboarding workflow.
Add protected client routing to your Microsoft 365 workflow
Tell us about your domains, Exchange Online setup, sender identity, and offboarding process. We will help scope a deployment-specific design.
Book a call
Discuss your use case with ProxiedMail
Choose a convenient time for a 30-minute conversation about your workflow, integration, and infrastructure requirements.
Enterprise contact
Tell us about your client communication workflow
Enterprise deployments are scoped based on workflow, infrastructure, integration, and usage requirements.
- Which system stores the real client contact?
- Which teams need communication access?
- What should trigger assignment or revocation?
