Your email is already encrypted in transit. That is not the protection you are thinking of.
Microsoft 365 has three encryption layers that get confused with each other: TLS between mail servers (already on, protects nothing after delivery), Purview Message Encryption (per-message protection any recipient can read, including Gmail), and sensitivity labels with encryption (protection that travels with the file wherever it goes). Most organisations need the second, some need the third, and almost everyone believes the first is doing a job it is not. We configure the right layer for what you actually send.
- 3 layersTLS, message encryption, labels
- Gmail worksPortal or one-time passcode
- PAN, AadhaarAuto-encrypt on detection
- Remote-firstDelivered from Hyderabad
Which encryption layer answers which worry.
Almost every email encryption conversation we have in India starts with the layers confused. This is the fastest way to un-confuse them.
- TLS in transit is already on. It protects the message between mail servers, the way HTTPS protects a web page. It does nothing after the message lands, and it cannot restrict what a recipient does. If your worry is interception on the wire between two competently run mail systems, you likely already have the control.
- Purview Message Encryption protects an individual message and its reply, at rest and in transit, with optional Do Not Forward. Any recipient can read it, including Gmail, through native Outlook or the portal with a one-time passcode. If your worry is a salary letter or client statement sitting readable in somebody else's inbox, this is the layer.
- Sensitivity labels with encryption attach rights to the content itself: who can open it, view-only, no-print, expiry date. The protection follows the file after download or forwarding. If your worry is what happens to the document after it leaves the thread, this is the layer.
- A compromised mailbox defeats all three, because the attacker reads exactly what the legitimate user reads. Encryption is not the control for account takeover; multifactor authentication and conditional access are. We say this up front because it is the most common oversold claim in this market.
Eight parts of Microsoft 365 email encryption, and which layer each one lives in.
TLS in transit, what it covers and what it does not
Exchange Online negotiates TLS with the receiving mail server by default, so mail between well-run servers is already encrypted on the wire. What TLS does not do: protect the message at rest in the recipient mailbox, restrict forwarding or printing, survive delivery to a badly configured server, or prove anything to an auditor about a specific message. When TLS is enough, we say so. When it is not, the next two layers exist.
Purview Message Encryption for individual messages
Encrypt-only protects the message content in transit and at rest without restricting the recipient. Do Not Forward additionally blocks forwarding, and can block copy and print. Microsoft 365 recipients read both natively in Outlook on desktop, Mac, mobile and web with no extra step. This is the layer most Indian organisations actually need for salary letters, financial statements and client-confidential mail.
Gmail and other non-Microsoft recipients, honestly described
A Gmail, Yahoo or Rediffmail recipient receives a wrapper message directing them to the encrypted message portal, where they sign in with their existing Google or Microsoft credentials or request a one-time passcode by email. It works, and it is a portal experience, not a native inbox experience. We test it with your real counterparties before rollout so nobody discovers the difference from an annoyed client.
Mail flow rules that encrypt without anyone remembering
Exchange transport rules apply encryption automatically on conditions: a specific recipient domain, keywords in the subject, or detected sensitive information types. Purview ships built-in detectors for the India Permanent Account Number and Aadhaar number formats, so a rule can encrypt any outbound mail containing a PAN or Aadhaar pattern regardless of who sends it or whether they thought about it.
Sensitivity labels for protection that travels
A label with encryption settings applies persistent rights to the file or mail itself: named users or domains can open it, view-only, no-print, no-extract, and access that expires on a date you set. The protection travels with the content when it is downloaded, forwarded or copied to a USB drive, which is what per-message encryption alone does not give you. This is the third layer, for the material that matters most.
DLP integration, encryption as an automatic response
A Purview DLP policy can detect sensitive content leaving by email and apply encryption as the action, instead of only blocking or warning. Detection keyed on PAN, Aadhaar, bank account patterns or your own keyword dictionaries means the protection attaches to the content, not to training. We tune policies in audit-only mode first so false positives are found before enforcement annoys anyone.
Replies and attachments are covered
Replies to an encrypted message are encrypted too, which matters because the sensitive detail in a thread is usually in the answer, not the question. Office attachments inherit protection when sent with a protected message, and the supported file types are documented and finite, which we confirm against what your teams actually attach before promising anything.
Branding, revocation and expiry from the advanced tier
Advanced Message Encryption adds custom branding templates for the portal experience, message revocation, and access expiry. The honest caveat: revocation and expiry work only for external recipients who read through the portal, and forcing the portal route requires a branding template applied in a mail flow rule. We configure all of it, or tell you plainly which messages it will never apply to.
Four things that decide whether email encryption survives its first month.
Scoped narrowly, applied automatically
We key mail flow rules on genuinely sensitive conditions, PAN and Aadhaar patterns, defined recipient domains, specific sender groups, so encryption happens without anyone deciding and does not happen to everything. A narrow automatic rule gets used. A broad manual one gets worked around.
Recipient experience tested before go-live
We send test messages to the actual mailbox types your counterparties use, Gmail, company IMAP, Outlook mobile, and walk through the portal and one-time passcode flow ourselves. An afternoon of testing changes what we recommend applying and to whom.
Honest about limits, in writing
We document what the deployment does not cover: compromised mailboxes, screen photography, categories where revocation cannot apply. You get the limits in the handover pack, not discovered later. The credibility of the control depends on nobody overselling it.
Remote-first from Gachibowli, Hyderabad
Tenant configuration, mail flow rules, labels and DLP are all remote work, so we deliver this across India from our Hyderabad base without travel dependencies. Managed clients get the 30 minutes response SLA for issues after go-live.
Six Indian situations where sensitive mail is going out unprotected today.
CA firms and law practices
Chartered accountants send financial statements, tax filings and PAN-bearing documents to clients daily; law firms send privileged advice, often to clients on Gmail. Do Not Forward on the privileged categories, encrypt-only on the rest, and a tested portal experience is the configuration that works without client complaints.
HR teams sending salary and offer letters
Offer letters, salary revisions, Form 16 attachments and disciplinary correspondence are personal data going to individual, usually personal, mailboxes. The senders are few and the content predictable, which makes HR the best first mail flow rule in almost every deployment we run.
Healthcare providers and diagnostics
Reports, results and referrals move between hospitals, labs, insurers and patients by email constantly. Rules keyed on health-related patterns and sender departments encrypt the mail regardless of who is on shift, and the one-time passcode flow works for patients on any mailbox.
BFSI vendors and fintech processors
If an RBI-regulated bank or NBFC is your client, their outsourcing and vendor assessments increasingly ask how customer data is protected in transit and at rest with you. Configured message encryption with documented rules is an answer that closes the question; "we use email carefully" is not.
DPDP data fiduciaries and processors
The Digital Personal Data Protection Act, 2023 requires reasonable security safeguards for personal data. Where personal data leaves your organisation by email, and it does, automatic encryption keyed on content detection is a safeguard that is straightforward to evidence, with the rule itself as the artefact.
Anyone sending confidential material to non-Microsoft mailboxes
The most common objection, "our clients are on Gmail", is answered by the product: non-Microsoft recipients read through the portal with their existing credentials or a one-time passcode. It is worth experiencing that flow yourself before deciding it is unacceptable, and we set up that test in the first week.
A compromised mailbox reads encrypted mail perfectly.
Email encryption protects messages from parties who are not the mailbox owner. It does not protect anything from someone who has become the mailbox owner. Both problems are real, and they have different controls.
- An attacker who phishes a user's password and passes their weak MFA setup sees every encrypted message exactly as the user does, because the tenant decrypts for authenticated users. Encryption was never the control for this.
- The controls for account takeover are phishing-resistant multifactor authentication, conditional access policies, and sign-in risk detection. If those are weak, fix them first or alongside; encrypting mail into a compromised mailbox protects nothing.
- Encryption also does not stop an authorised insider photographing a screen, retyping content, or summarising it in a new mail. Do Not Forward raises the effort; it does not make disclosure impossible, and we never describe it as if it does.
- What encryption genuinely delivers: mail unreadable in transit and at rest to intermediaries, forwarding and printing restricted where you choose, rights that survive delivery, and evidence for auditors that a specific control was applied to a specific category of mail.
TLS, message encryption, and sensitivity labels, compared honestly.
| Feature | TLS in transit Already on | Message encryption Per message | Labels with encryption Travels with content |
|---|---|---|---|
Configuration needed | None, on by default | Mail flow rules or sender choice | Label schema and publishing policy |
Protects in transit | Yes, between servers | Yes | Yes |
Protects at rest after delivery | No | Yes | Yes |
Restricts forwarding, copy, print | No | Yes, with Do Not Forward | Yes, per label settings |
Protection survives download or re-share | No | Partly, message-scoped | Yes, rights travel with the file |
Readable by Gmail recipients | Yes, as plain mail | Yes, portal or one-time passcode | Yes, with supported apps or the portal |
Access expiry and revocation | No | With the advanced tier, under conditions | Yes, expiry per label, revocation per file |
Evidence for an auditor | Weak, connection-level only | Strong, per rule and per message | Strong, per label and per file |
Typical Indian use | Everything, silently | Salary letters, statements, client mail | Board papers, deal documents, designs |
The recipient experience by mailbox type, which decides adoption.
| Recipient | What happens | |
|---|---|---|
| Microsoft 365 user in Outlook desktop, Mac, mobile or web | Native reading experience, no extra step, no portal | |
| Microsoft 365 user in a different organisation | Still native, the tenants do not need any prior relationship | |
| Gmail recipient | Wrapper mail to the encrypted message portal, sign in with Google credentials or a one-time passcode | |
| Yahoo, Rediffmail or other consumer mailbox | Portal with a one-time passcode sent to the same address | |
| Recipient on a company IMAP or POP mailbox | Portal with a one-time passcode, works from any browser | |
| Recipient on a mobile phone | Native in Outlook mobile; portal opens in the phone browser for everyone else | |
| Any recipient replying to an encrypted message | The reply is encrypted automatically as well | |
| Recipient of a label-protected attachment | Opens in Office with the rights enforced: view-only, no-print, expiry as configured |
Five steps from confusion to configured, most engagements in two to four weeks.
- 1
Map what actually needs encrypting
Week 1
A working session on the specific mail categories, senders and counterparties, plus a licence check against your actual tenant. The output is a short scope: which categories get encrypt-only, which get Do Not Forward, which documents warrant a sensitivity label, and which mail TLS already covers adequately.
- 2
Test the recipient experience
Week 1-2
Test messages to the mailbox types your real counterparties use: Microsoft 365 tenants, Gmail, consumer mailboxes with the one-time passcode flow, and mobile. We record what each recipient type sees so your senders can answer questions with screenshots, not guesses.
- 3
Configure rules, labels and DLP
Week 2-3
Mail flow rules keyed on recipients, keywords and the India PAN and Aadhaar sensitive information types. Sensitivity labels with encryption for the persistent-rights categories, published to the right groups. DLP policies applying encryption on detection, started in audit-only mode to surface false positives safely.
- 4
Branding, revocation and enforcement
Week 3-4
Where the advanced tier is licensed and revocation or expiry is wanted, we configure the branding template and apply it in a mail flow rule, since that is a functional prerequisite, not decoration. DLP policies move from audit-only to enforce once the false-positive rate is acceptably low.
- 5
Brief senders and hand over
Week 4
A short internal note for the teams who send protected mail: what recipients see, what to tell a confused client, and how to request a change to the rules. Handover includes the documented scope, the configured rules, and the stated limits. Managed clients carry a 30 minutes response SLA from here.
Which plan family includes which capability, without the sales gloss.
| Capability | Where it starts | |
|---|---|---|
| TLS encryption in transit | Every Exchange Online plan, on by default, nothing to buy | |
| Purview Message Encryption (encrypt-only, Do Not Forward) | Microsoft 365 Business Premium and the E3 plan family upward | |
| Mail flow rules applying encryption automatically | Included wherever message encryption is licensed | |
| Sensitivity labels with encryption, manual application | Business Premium and the E3 family upward | |
| Automatic labelling based on content detection | The E5 family, or the equivalent compliance add-on | |
| Advanced Message Encryption (revocation, expiry, multiple branding templates) | The E5 family, or the equivalent compliance add-on | |
| DLP policies that apply encryption on detection | Business Premium and E3 for core email DLP; broader locations from E5 |
Email encryption in Microsoft 365, frequently asked in India.
Fifteen questions we work through with every Indian organisation.
What you are protecting
- Which mail categories genuinely need encryption?Encrypting everything is how a control gets bypassed.
- Do you send PAN, Aadhaar or bank account data by mail?All three have built-in detectors for automatic rules.
- Is the risk interception, or what the recipient does next?Encrypt-only and Do Not Forward answer different risks.
- Are you a DPDP data fiduciary or processor?Reasonable security safeguards are easier to evidence with this in place.
- Does an RBI-regulated client flow data through you?Vendor assessments increasingly ask this exact question.
Configuration
- Automatic by rule, or sender-initiated?Automatic is the only version that reliably happens.
- Which conditions trigger encryption?Recipient domain, subject keywords, or detected content patterns.
- Which categories warrant Do Not Forward?It also blocks copy and print where specified.
- Do any documents need rights after delivery?That is a sensitivity label, not a mail flow rule.
- Is revocation wanted, and are its conditions configured?External recipients, portal access, branding template in a rule.
The recipient experience
- Who receives your sensitive mail most often?Their mailbox type determines their experience.
- Are they on Microsoft 365, Gmail, or company IMAP?Native for the first, portal for the rest.
- Have you sent yourself a test to a Gmail account?Do it before your most important client does it for you.
- Do your senders know what recipients will see?They will be asked, and should not be guessing.
- Is there a support path for a confused recipient?A one-page note prevents most of the rollout noise.
The pages around this one.
Email Security Audit India
The inbound side: spoofing, phishing exposure, DMARC, and the mailbox takeover risks that encryption does not address.
Learn moreEndpoint DLP India
Loss prevention at the device level: USB, cloud uploads and printing, complementing the mail-level controls on this page.
Learn moreMicrosoft Purview
The wider governance platform this runs on: sensitivity labels, DLP, retention, audit and eDiscovery as one programme.
Learn moreFind out which encryption layer your mail actually needs.
A short review of what you send, to whom, and what your tenant already licenses. We will tell you where TLS is already enough, which categories warrant automatic encryption, and whether revocation would currently work on anything you have ever sent. Initial reply within 4 business hours.
Related Services
Explore more solutions that work great with this service