Secure email protects client documents through encrypted delivery, controlled access and a secured mailbox. For a client’s tax return, use the lender’s approved portal or configured message encryption. Ordinary email’s transport encryption does not stop the wrong recipient or someone who has taken over a mailbox from reading an attachment.
How Secure is Ordinary Email?
Ordinary email can protect a message while it travels between systems, but that protection does not control what happens inside either mailbox. The usual transport protection is Transport Layer Security, or TLS. It encrypts the connection between mail systems when both ends support it.
Google’s email encryption explanation distinguishes protection in transit from protection after delivery. A padlock for the connection does not establish that only the intended person can read the stored message.
The brokerage, its email provider and the recipient’s provider can each have copies of a message. A client can download an attachment to a shared computer. An attacker with mailbox access can read messages or set up forwarding rules.
Sending to the wrong address is a separate problem. TLS can deliver a tax return securely to the wrong person’s mailbox. Autocomplete, a convincing display name and an existing email thread do not confirm the recipient’s authority to receive that file.
The Office of the Australian Information Commissioner, or OAIC, recommends procedures for sending personal information by email. Its security guide covers recipient validation and secure channels, alongside encryption for sensitive information. Client permission to send a document does not remove the need to choose a suitable channel.
Encrypted Email in Outlook and Gmail
Outlook and Gmail have additional encryption options, but the available protection depends on the account’s plan and administrator setup. The recipient’s reading experience also depends on the method you choose.
Outlook and Microsoft Purview Message Encryption
Microsoft Purview Message Encryption lets a brokerage send protected messages to recipients inside or outside its organisation. Microsoft’s Message Encryption FAQ lists Microsoft 365 Business Premium and Microsoft 365 or Office 365 Enterprise E3 and E5 among the eligible plans. Each user benefiting from the feature needs the appropriate licence.
Business Basic or Business Standard alone does not provide the same entitlement. Microsoft lists an Azure Information Protection Plan 1 add-on route for those plans in its licensing guidance. Installing Outlook does not establish that your mailbox has Purview Message Encryption configured.
In new Outlook, Microsoft’s sending instructions use the message’s Options menu, then Encrypt. Choose the protection your brokerage has approved. Encrypt protects the message, while Do Not Forward adds restrictions on forwarding and copying.
A recipient using a supported Microsoft 365 account can usually open the protected message within Outlook. Other recipients can receive a link to read it in a browser. Microsoft’s recipient instructions explain sign-in with a supported account or a one-time passcode sent to the recipient’s email address.
That passcode proves access to the mailbox. It does not establish the person’s identity if an attacker controls that mailbox. Forwarding restrictions also cannot stop someone photographing a screen.
Attachment protection needs its own attention. Microsoft documents different behaviour by file type and settings, including a separate setting for PDF protection after download. A cloud file link keeps its own sharing permissions. Sending the link inside an encrypted message does not change those permissions.
Gmail Encryption Options
Gmail uses TLS for supported connections between email providers. Additional message encryption is an administrator-managed Google Workspace capability, with different requirements from a personal Gmail account.
| Gmail option | Availability and setup | Recipient experience and limit |
|---|---|---|
| Hosted S/MIME | Google’s business-edition list includes Enterprise Plus and Frontline Plus. An administrator enables it and manages certificates. | The sender and recipient need compatible certificate-based encryption. A recipient without the required certificate setup cannot simply read it as an ordinary attachment. |
| Client-side encryption | Available on Enterprise Plus and Frontline Plus among business editions. It needs administrator configuration and encryption-key services. | The message body and attachments receive additional encryption before entering Google’s cloud. Reading can require identity-provider sign-in. |
| Confidential mode | A Gmail sending feature, subject to organisation settings, with expiry and optional SMS passcodes. | Recipients read through the supported Gmail or linked viewing experience. Copying and forwarding controls cannot prevent screenshots or photos. |
S/MIME means Secure/Multipurpose Internet Mail Extensions, a standard for encrypting and digitally signing email. Google’s hosted S/MIME setup guide lists the supported editions and certificate requirements. Its separate Google’s client-side encryption guide explains control of encryption outside Google’s ordinary server-side protection.
For certificate-based external delivery, Gmail client-side encryption requires the parties to exchange digital signatures first. Google’s Assured Controls beta also supports an external invitation flow. That flow can require a Google guest account and another sign-in before the recipient reads the message.
The Gmail client-side encryption instructions explain those recipient paths. They also state that headers, including the subject and recipient details, do not receive the additional encryption. Keep account numbers and other confidential details out of subject lines.
Gmail’s confidential mode guide describes expiry, access removal and passcodes. These controls do not give the sender exclusive control over every copy the recipient can make. Treat confidential mode as a sharing control, rather than assuming it supplies client-side encryption.
Before using either platform for client files, have your administrator send a harmless sample to an authorised test mailbox. Confirm the recipient can authenticate, open the attachment and reply through the intended protected path. If access fails, fix the setup or use the approved portal. Removing encryption to meet a deadline defeats the chosen protection.
When to Use Encrypted Email
Use message encryption or an approved secure channel for documents that expose a client’s finances or identity. Make this a brokerage rule so staff do not have to decide from scratch for each attachment.
| Information being sent | Brokerage handling rule | Check before sending |
|---|---|---|
| Tax returns, payslips and bank statements | Use the lender’s approved upload channel or configured message encryption. Send only what the application needs. | Confirm the lender’s destination and the exact attachment. |
| Passports, licences and identity packs | Use an approved restricted-access channel. Use encrypted email only where the receiving process supports it. | Confirm the authorised recipient and any required redaction. |
| Credit reports or documents revealing health information | Restrict access to the staff and recipient who need the information. Use the approved protected channel. | Confirm the purpose and recipient before attaching the file. |
| Appointment times or a generic document checklist | Ordinary business email can fit when the message contains no confidential client details. | Check that quoted replies and old attachments do not expose a client file. |
The sensitivity of a file depends on its contents and context. A routine-looking spreadsheet can contain more identifying information than a single identity document.
For example, a broker needs to send a client’s tax return to a lender assessor. Confirm the assessor through an established lender contact route, then use the nominated portal or protected email method. Keep the subject general and record what was sent in the client file.
If the recipient cannot open an encrypted message, use a different approved channel. A password-protected attachment can be an option when your brokerage’s process permits it and the file uses encryption that protects its contents. Give the password through a separately verified channel, such as a call to an established number.
A new request to send files to a personal address needs confirmation through a known contact method. Do not treat an urgent reply in an existing thread as enough proof. Reduce the material sent when the task can be completed with a redacted document or a specific extract.
Protect the Mailbox Itself
Protecting the mailbox reduces the chance that an attacker can read client documents or impersonate the brokerage. Message encryption still relies on secure accounts and authorised recipients.
Turn on multi-factor authentication for every staff mailbox and administrator account. Two-factor authentication is a form of this protection that requires two different types of proof. Prefer phishing-resistant passkeys or security keys where the provider supports them. Keep recovery methods protected and give each staff member their own account.
Review forwarding rules and mailbox delegates regularly. An attacker can use a rule to copy messages elsewhere or hide replies. Include recovery addresses and connected applications in the review, because they can give someone another way into the account.
The Australian Government’s email-account recovery guidance includes multi-factor authentication and forwarding-rule checks. An unexpected rule or login needs prompt investigation by the brokerage’s IT provider. Removing one visible rule does not establish that the account is secure again.
Train staff to open the provider’s known sign-in page when a message unexpectedly asks them to authenticate. Encrypted-message notifications can be imitated in phishing emails. Confirm an unexpected document or payment request through an established contact route before acting.
A secure email gateway can filter harmful messages before they reach staff. Domain authentication also helps receiving systems identify forged mail. Have your IT provider configure those protections alongside mailbox access controls, then keep client documents within the approved sending process.
