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.
Your client keeps using email exactly as usual
In the standard employee-to-client configuration, the client receives the message from the authorized company employee identity and replies normally—as if the employee had emailed them directly. ProxiedMail keeps the protected identity and routing in the company’s internal workflow. The exact sender-domain configuration is confirmed during deployment.
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.
Will clients notice that ProxiedMail is routing the message?
In employee-to-client deployments configured to preserve the company sender identity, clients see the authorized company employee as the sender and continue reading and replying as usual. ProxiedMail handles the protected identity and routing behind the company’s workflow. The exact visible address depends on the sender-domain and mail-routing configuration selected for the deployment.
Who owns the client data and business communications?
Your company remains the owner of its client contact data, protected identity mappings, and business communications. ProxiedMail does not take ownership of that data; it processes the information required to provide the configured routing service. Access, retention, and infrastructure details are defined by the deployment and applicable agreement.
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?
