Privacy Policy

How Hamanimail handles your mail and your personal information.

HAMANI PTY LTD · ACN 696 864 981 · ABN 48 696 864 981 · Sydney, New South Wales, Australia. Effective 1 August 2026 · Version 1.1, last updated 5 September 2026.

Every factual statement below about what the software does was checked against the source code; if the code changes, this policy changes with it. It describes what we do, and it is not a compliance certification.

In one paragraph

Hamanimail hosts business email on your own domain. To do that we receive, store and serve your mail. Your mail is yours. We store it in Sydney, Australia. We do not read it, sell it, mine it or use it to train anything. There is no lock-in, and you are never locked out of your own mailbox — not for a late invoice, not ever.

1. Who this covers

This policy covers the Hamanimail hosting service: mailboxes on your domain that send and receive mail, the webmail you read them in and the personal file drive inside that webmail.

Two different sets of people appear in the data:

• You and your staff — the people who own and use the mailboxes.
• Everyone who writes to you — third parties whose messages arrive in your mailbox. We hold their information because you received their mail. We handle it as we handle yours.

Sending mail through the Hamanimail sending API (bulk, transactional and marketing sends) is governed by the same principles; the specific Australian Spam Act obligations that attach to sending are set out in our Acceptable Use policy.

2. What we store, exactly

Each item in this list is a thing the software writes.

Your mail

Mail you send through the sending API

Mail sent through the API (not from webmail) is not kept. Once a message is handed to Amazon SES its body is gone from our systems; what we keep is a log record of the send — message id, event type (accepted, delivered, bounced, complained…), a timestamp, and a short detail string. No body, no subject, no template data.

Three exceptions:

• A scheduled send (one you asked us to send later) is stored — content and all — in DynamoDB, Sydney, until its release time. A message we will send at 9am tomorrow must live somewhere tonight. Once it has been sent (or you cancel it), the spent record — content included — is kept for 30 days so your workspace's recent history works, then erased automatically.
• Attachments on an API send are staged as objects in S3, Sydney, because they are too large to travel through the send queue. Staged objects are erased automatically after 30 days — 30 rather than fewer because a failing send can wait in the dead-letter queue for 14 days and still be retried, and a retried send must find its attachments waiting.
• A send that keeps failing waits in a dead-letter queue for up to 14 days (see §5) so we can retry or investigate it, then expires.

All three live in the same Sydney infrastructure, under the same protections in §4, and none is read for any purpose except sending your message.

Files you keep in your drive

Webmail includes a personal file drive: you can upload files, or save a received attachment into it. A file's bytes live in Amazon S3, Sydney (the same bucket, under a separate prefix), and its index entry — filename, content type, size, an automatic category such as Photos or PDFs, when it was saved, and whether it came from an upload or an attachment — lives in DynamoDB, Sydney. The drive is bounded by a per-account storage quota, and deleting a file from the drive deletes the stored bytes, not just the listing. Everything in §4 (encryption at rest, no public access) and §6 (who can access) applies to drive files exactly as it applies to mail.

If you import your old mail

"Bring your mail" migration, where offered, signs in to your previous provider with an app password you supply and copies your old mail into your Hamanimail mailbox. That password is encrypted the moment it arrives, is handed only to the dedicated import worker, is never written to a migration record and never logged, and is used for nothing except fetching your mail. On deployments where the import worker is not enabled, the request is refused outright rather than a credential being taken and parked.

Everything else

Sign-in security data (two-factor, recovery, sessions)

These are live: signing in creates a session, and you can enrol two-factor authentication and set a recovery address from your security settings. Here is exactly what each one stores.

Device fingerprints — what they are and, more importantly, what they are not. When you sign in we want to be able to tell you "this is a device we have not seen on this mailbox before". To do that without keeping the things that identify you:

• No raw IP address is ever stored or logged. Your IP is reduced to a coarse prefix first — the first three parts of an IPv4 address, the first three groups of an IPv6 address — and only then hashed.
• No raw browser user-agent is ever stored or logged. It is hashed too.
• Both hashes are SHA-256 salted with your mailbox address. That salt is not decoration: without it, an IPv4 prefix has few enough possibilities to be brute-forced straight back out of its own hash, and the same device would produce the same hash on every mailbox in the system, which would let us correlate one person across mailboxes. Salted per mailbox, it cannot.
• What a person sees in their session list is the first 16 characters of that hash — enough to tell two entries apart, not enough to be useful for anything else.
• This is not geolocation. There is no geographic database in this system and none is consulted. A changed network prefix is not a place: a mobile carrier moves a phone between prefixes while it sits on a desk, and a VPN can hold one prefix in another country for months. So an alert says "a device or network we have not seen on this mailbox before" — it will never say a city or a country, because we do not know one.

What we do not collect

We do not run trackers, advertising pixels or analytics on the contents of your mail. We do not build a profile of you. Beyond the mailbox account above — an address, a display name and a password hash — we hold no personal profile of you: no date of birth, no address, no marketing attributes. At the account level we know an opaque owner id and the domains you verified.

3. Where it lives

Everything above is in AWS's Sydney region (ap-southeast-2): the mail storage, the message index, the send queue, the logs and Amazon SES itself. Australian mail, hosted in Australia.

Two qualifications:

• This is a statement of fact about where servers are, not a certification. There is no Australian law under which "stored in Sydney" is by itself a compliance guarantee, and we do not present it as one.
• Email crosses borders because email crosses borders. When you email someone overseas, or someone overseas emails you, that message travels through mail servers we do not run, in countries we do not choose. No email host can promise otherwise. What we control — where your mail is stored — is Australia.

If we ever configure a service outside Australia (for example a second sending region for failover), we will update this policy before doing it.

4. How it is protected

What is configured today:

• Encrypted at rest. The mail storage bucket uses S3-managed server-side encryption (SSE-S3). The database table uses DynamoDB encryption at rest with an AWS-managed key. The send queue uses SQS-managed server-side encryption.
• Encrypted in transit to us. The mail bucket and our notification topics require TLS — unencrypted requests are refused. The API is HTTPS only.
• Not public. The mail bucket blocks all public access.
• Backed up. Point-in-time recovery is enabled on the database table.
• Not deletable by accident. Both the mail bucket and the database table are set to be retained even if our infrastructure stack is torn down.
• Scanned. Amazon SES scans inbound mail for spam and viruses before it reaches you; a virus or spam failure is routed to a quarantine folder rather than your inbox.
• Least privilege. Each part of the system is granted access only to the specific resources it needs.
• Rate limited before authentication, so credentials cannot be attacked at speed.

Attachment scanning — what it does, and what leaves

The local layer below runs on your inbound mail today, in addition to Amazon SES's own spam and virus scan. The optional third-party engine is a slot that is not configured — see the second bullet.

There are two layers, and they are deliberately told apart:

• Local checks, which never send your file anywhere. These run inside our own system with no network call at all. They refuse the published EICAR anti-malware test file, files whose first bytes are a Windows, Linux or macOS executable, files whose declared type is executable or script content, and filenames with an executable extension — including the disguised invoice.pdf.exe pattern, which is reported as a type refusal, not a malware detection.
• A third-party scanning engine, which we do not have. Our system has a slot for a commercial scanning service. No such service is configured today. If we ever configure one, then for an attachment the local checks did not already refuse, the entire file is uploaded to that service, together with its filename, its declared content type and its size. If that ever happens, this policy will be updated to name the provider and the country it operates in before a single attachment is sent to it — and it would be an APP 8 cross-border question if that provider is overseas.

The verdict rule. A result is one of three things: clean, infected, or unscanned. unscanned exists because the failure that actually infects someone is a system reporting "clean" when nothing looked. With no engine configured, an attachment the local checks did not refuse comes back unscanned, never clean — and the same is true if a configured engine is slow, unreachable or returns something we cannot read, or if the file is over the size ceiling (10 MB by default), in which case it is not sent to the engine at all. Local checks are not antivirus.

Automated spam and phishing classification, and the AI tier

The offline classifier below runs on your inbound mail today and sends nothing anywhere. The AI tier is off unless an Anthropic API key is configured — and by default no key is set, so nothing about your mail leaves our systems. This section describes exactly what the AI tier would send if it were ever switched on.

Again two layers:

• The offline classifier, which sends nothing anywhere. No key, no network, no third party. It looks at sender display-name spoofing, a Reply-To that points somewhere other than the sender, link text that lies about where the link goes, punycode and mixed-alphabet lookalike domains, links to bare IP addresses, high-abuse domain suffixes and urgency / credential-request / advance-fee wording. It is what runs when no AI key is set.
• The AI tier, which is off unless a key is configured. With an Anthropic API key set, each inbound message produces one call to the Anthropic Messages API (api.anthropic.com). With no key set, nothing leaves.

Exactly what is sent to the Anthropic API when that tier is on. This is the complete list:

That excerpt is your correspondent's message content, sent to a third party outside Australia. Reducing URLs to hostnames does not change that: whatever else was written in the first 2,000 characters — names, figures, addresses — goes with it. That is why the tier is off unless a key is deliberately set, why the limit is settable to zero, and why a private mailbox (§4A) is never classified at all. If HAMANI ever enables this tier, this policy must be updated first, because sending message content to a US-based API is a cross-border disclosure question, not a configuration change.

No message is ever failed by a classifier. If the AI call times out, errors, is refused, is cut off or returns something that does not match the required shape, the offline verdict is used instead and it says so in its own reasons. The model is also never allowed to invent a suspicious link: only links genuinely present in the message survive into the result.

And what is not true, stated plainly:

• An ordinary mailbox is not end-to-end encrypted. We hold the encryption keys. That means HAMANI is technically capable of reading stored mail — see §6 for the rules we work to. There is now one exception, and exactly one: a mailbox you have deliberately put on the zero-knowledge private tier (§4A), where we hold ciphertext we cannot open. Unless you have done that, for the mailbox you did it to, this bullet stands.
• Mail in transit between mail servers is not guaranteed to be encrypted. SMTP encryption is opportunistic: it happens when the server at the other end supports it. That is true of all email everywhere, and we do not require TLS on inbound mail.
• We hold no security certifications. We are not ISO/IEC 27001 certified, we have no SOC 2 report, no IRAP assessment and no Essential Eight maturity assessment.

4A. The zero-knowledge private mailbox — optional, and irreversible

A mailbox can be put on a private tier. This is off by default, it is opted into per mailbox, and you must acknowledge the consequences below before it can be turned on — the software refuses the request otherwise.

What it does

• Your browser generates a key pair and a passphrase-derived key on your own device. The passphrase never leaves that device and never reaches our servers.
• We keep your public key in the clear, and your private key only as an opaque blob that your passphrase locks. We never open that blob, and we could not use it if we did.
• When mail arrives for that mailbox, our server encrypts each body and each attachment to your public key and stores only the ciphertext. Nothing readable is written to disk.
• The subject line and the message preview are withheld too — stored empty rather than stored readable.
• Drafts and copies of mail you send are encrypted the same way, with their subjects and previews withheld the same way.
• Attachment filenames and content types are encrypted too, and the storage key is opaque.
• What is NOT encrypted, and what we can therefore read on a private mailbox: who sent each message, who it was addressed to, when it arrived, how large it is, and Amazon SES's spam and authentication verdicts. We need those to accept, route and list your mail. If a sender puts something revealing in their own Message-ID header, that is theirs and we leave it as they sent it. Everything in this bullet is readable by us; nothing above it is.
• There is no decryption function anywhere in our server code: an operator with complete access to our production systems has nothing to decrypt with.
• The cryptography is standard and comes from audited implementations (the browser's own Web Crypto, OpenSSL underneath in our server): RSA-OAEP with SHA-256, AES-256-GCM and PBKDF2-HMAC-SHA256 at 600,000 iterations to turn your passphrase into a key.

What it costs you — read this before opting in

The software shows you these before you can turn it on:

• If you lose your passphrase, your mail is permanently unreadable. There is no reset, no recovery, no support ticket, no court order and no backup that helps. We cannot open it.
• Search does not work on a private mailbox. The server refuses the search outright and tells you why, rather than returning an empty list that looks like "no matches". We cannot search what we cannot read. Searching a private mailbox has to happen in your browser, after you have unlocked it.
• Spam and phishing filtering does not run on a private mailbox — neither the AI tier nor the offline one, because even an offline verdict is a fact about content we said we would not inspect. You will receive spam unfiltered.
• Enabling it does not encrypt mail you already received. Anything already in the mailbox stays exactly as it was.
• A vault cannot be replaced. Publishing a second one would orphan every message encrypted to the first, so the software refuses it. A new vault means a new mailbox.
• It does not protect you from your own device. If the computer or browser you unlock the mailbox on is compromised, none of this holds. What it protects you from is us: our operators, our database, our backups and a subpoena served on us.

The instant of arrival

Mail arrives from the internet in plaintext. That is how email works: the sending server hands the message to Amazon SES, SES hands it to our engine, and our engine must hold the message in memory in order to encrypt it. So for the instant between arrival and encryption, your message exists unencrypted on our infrastructure.

What the private tier buys is everything after that instant: nothing readable is written to disk, nothing is searchable, nothing is readable by an operator, a backup, a database breach or a subpoena served on us. It is not "your message never touches our servers unencrypted"; any provider of zero-knowledge mail over ordinary email has this same property.

4B. Voice typing, writing polish and scenes — what leaves your device

• Voice typing (the Speak button). Dictation uses your browser's own speech service, not ours. Depending on your browser, that recognition may run on your device (e.g. Safari can) or the browser may send the audio to its maker's servers to transcribe (e.g. Chrome does). We never receive, process or store your audio — only the text that appears in your draft reaches us, and only when you polish, save or send it.
• Writing polish (the ✨ Magic button). Today the polish runs entirely on our own servers using deterministic grammar rules: your draft is processed in memory to produce the suggestion shown to you and is not kept. An optional AI tier exists in the software but is switched off; if we enable it, pressing ✨ would send your draft text (bounded in size) to our AI provider to produce the correction, and we will update this section before that switch is turned on. The same before-we-enable-it promise applies to optional AI screening of inbound mail.
• Scenes, Plain mode and the postman. A scene is the look of your personal inbox — its background and colours; Plain mode turns that off; the postman is the animated character in the personal inbox. Your choice is stored on your device only, in your browser's local storage. We do not record or receive it.

5. How long we keep it

Read this before you rely on "Trash". Moving a message to Trash moves it, it does not delete it — it stays in our storage until you erase it.

Permanent erasure exists at three levels, all of which delete the stored bodies and attachments from S3, not just the listing: "Delete forever" on a message in Trash, "Empty Trash" on the whole folder and deleting a mailbox (from your admin console), which walks every message in it and then removes the account — recreating the same address later starts empty and inherits nothing. Closing your account ("Close account" on your account page, behind a typed confirmation) is the everything-at-once version: it cancels your plan with the same refund cancelling gives, then erases every mailbox, every message and every file drive the account holds, and revokes your API keys. None of these can be undone by you.

The mail store keeps a short internal recovery buffer (S3 versioning) so that an accident or an attack on our side cannot destroy your mail. An erased message leaves every screen, every search and every export immediately, and its underlying bytes are purged from that buffer automatically within 35 days. Retaining is the default; the actions above are how to erase.

6. Who can access your mail, and when

• You, through webmail, using your mailbox credentials.
• The HAMANI hub, on your behalf. Webmail lives in the HAMANI hub, and the hub is what talks to the mail service. The mail service only answers requests that are cryptographically signed with a shared secret held by the hub — a signature older than five minutes is rejected — and it checks that the mailbox being read belongs to the account making the request. Without that secret, the mail endpoints are closed entirely.
• HAMANI personnel with production access, technically. We hold the keys, so we are capable of reading stored mail. Our rule is that we do not — mail is accessed only where it is genuinely necessary to operate the service (for example, investigating a fault you have reported), and never for marketing, profiling, model training or curiosity.
• Nobody else. We do not sell your data. We do not share it with advertisers. We do not give it to other customers.

If we are compelled by a valid Australian legal process to disclose data, we will comply with the law, and we will tell you unless we are legally prohibited from doing so.

On the last two points: the technical guarantee here is that access requires production credentials and a signed request. The rest is a policy commitment by a small Australian business — a promise backed by our word and our contract, not by a control that makes it impossible.

The one place that is different. For a mailbox on the zero-knowledge private tier (§4A), the third bullet above does not apply to the stored contents of that mailbox: we hold ciphertext and no key, so "HAMANI personnel, technically" is not true of it. We can still see that the mailbox exists, who sent to it and when, and how large the messages are — that routing information is what the internet used to deliver the mail and we cannot encrypt it away. If we are compelled to disclose data from a private-tier mailbox, we can hand over what we hold, and what we hold is unreadable to us and to whoever receives it.

7. Your data is yours

• You own your mail and your data. Hosting it does not give us any rights over it.
• You can get it out. If you leave, we will give you your mail. How that works today: the account API has a self-service export (GET /v1/billing/export) that returns a complete manifest of every message in every mailbox and folder you hold — Trash and quarantine included — with the storage location of each message's full original. It keeps working even if your bill is unpaid. A one-click export button in webmail is still on the roadmap; until then you can also ask us and we will run it for you. Export is free either way.
• No lock-in. Paid plans are billed monthly in Australian dollars with no minimum term, and the Personal plan is free. You can stop whenever you want. Ending the service does not cost you your mail — see our Terms of Service.
• Non-payment never locks you out of your mailbox. Sending may pause. Your mail stays yours and stays readable.

8. Access, correction and complaints

• Access. Ask us and we will tell you what personal information we hold about you and give you a copy.
• Correction. If something we hold about you is wrong, tell us and we will correct it. There is no charge for a correction.
• Complaints. Tell us first. Write to [email protected] — we aim to acknowledge within two business days — and we will investigate and respond within 30 days. If you are not satisfied with our response, or we do not respond within 30 days, you may complain to the Office of the Australian Information Commissioner (OAIC) — the OAIC asks that you complain to the organisation first and give it 30 days before bringing the complaint to them. The OAIC's complaint pathway is at https://www.oaic.gov.au/privacy/privacy-complaints.

This policy is deliberately written to describe what we do and to offer access, correction and a complaint pathway as commitments, so it holds regardless of how any small-business threshold under the Privacy Act 1988 (Cth) applies to us.

9. Data breaches

If personal information we hold is accessed, disclosed or lost without authorisation, we will assess what happened promptly, contain it and tell the people affected where the breach is likely to cause them serious harm. Where the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act 1988 (Cth) applies to us, we will also notify the Australian Information Commissioner as that scheme requires.

10. Changes to this policy

We will keep this current. If we change something that materially affects your data — where it is stored, how long we keep it, who can see it — we will tell customers before the change takes effect, not after. If we ever configure an overseas attachment-scanning engine, or switch on the AI classification tier (which would send bounded message content to an API outside Australia), we will update §4 to name it before the first message is sent, because that is a cross-border disclosure decision, not a configuration change.

HAMANI PTY LTD · ACN 696 864 981 · ABN 48 696 864 981 · Sydney, New South Wales, Australia. © 2026 HAMANI PTY LTD. Hamanimail Privacy Policy, version 1.1, effective 1 August 2026, last updated 5 September 2026. Privacy contact: [email protected].