Protect the account
The current work includes MFA, single-use recovery codes and reauthentication for sensitive actions. The installed version’s path still needs to be qualified.
SAFEGUARDS WITH A CLEAR SCOPE
Confidence.
With concrete checks.
An account, key or instruction should authorise only the intended actions. Here are the private foundation’s safeguards and the work still requiring qualification.
Explore this guidePrivate project · public opening in preparation
THE MAILIE APPROACH
One action, several checks
01
A verified account and role
02
Permission for the specific action
03
Additional confirmation when needed
Useful messages. Clear choices.
Information updated on 14 October 2026. These guides describe product choices and private integration work. They are not a certification, reviewed legal terms or a qualification of live providers.
ACCOUNTS AND PERMISSIONS
Grant useful access, then be able to revoke it.
The foundation distinguishes organisation roles from access limited to a workspace. Checks run on the server; hiding a button is insufficient. Permissions are revalidated to reflect member removal or a revoked key.
Scope a key
A service key has a scope and expiry. It is not a human owner and should not be shared in a web page, email or support ticket.
Bound support access
Content access for support is designed around temporary, limited and revocable authorisation. A customer administrator does not become a Mailie operator.
PROTECTING INFORMATION
Safeguards suited to the data.
Passwords are stored as hashes. Application mechanisms protect recoverable secrets and contact addresses; service keys and tokens use non-recoverable representations where appropriate to their use.
These safeguards do not mean every field, log or backup is encrypted or purged in the same way. Retention, key rotation and backups are part of operational qualification.
A key, recovery link, MFA code or export does not belong in an ordinary support attachment. Share an opaque reference and the steps needed to understand the issue instead.
BEFORE AND AFTER SUBMISSION
Check the intent, recognise uncertainty.
Before sending, the content, sender, capacity and recipient eligibility need to be checked. A prepared send retains its approved version; changes require fresh validation.
Commands and events are deduplicated. If a transport may have accepted an email without a known response, the message still needs reconciliation. Immediately resending could create a duplicate.
SMTP tests used local servers and fictional data. They do not establish production qualification of OVH SMTP or guaranteed deliverability.
A USEFUL REPORT
Explain the problem without exposing secrets.
For private accounts, the support path planned in the application allows an incident and its scope to be described. Include the time, affected page, observed steps and a non-sensitive reference.
Before public opening, the channel for reports without an account and support procedures must be published. This page invents neither a receiving address nor a guaranteed response time.
Mailie claims no security certification, completed external audit, guaranteed availability or general compliance here. These safeguards have the scope of the private foundation and its local tests.
FOR AUTHORISED PRIVATE ACCOUNTS