Your login page,
on your own domain

Authentication that looks like you, not like us

Your users never see the word Maillog. The login lives on your domain, in your theme, with your terms.

Connect your software in three values

Maillog speaks standard OAuth 2.0 and OpenID Connect. If your framework has an OIDC library — and they all do — you are one configuration block away.

// NextAuth/Auth.js — any OIDC library works the same way
providers: [
  {
    id: "maillog",
    name: "Log in with your account",
    type: "oauth",
    issuer: "https://login.maillog.dev",       // or login.yourdomain.com
    clientId: MAILLOG_CLIENT_ID,
    clientSecret: MAILLOG_CLIENT_SECRET,
    authorization: { params: { scope: "openid profile email" } },
  },
]

Start free, grow when your user base does

The first 100 accounts are free, permanently. Paid plans add capacity, domains and support.

Extra accounts above your bundle are billed per account per month, with an optional monthly spending cap. Two-factor authentication is included on every plan, including Free.

Frequently asked questions

Can I put the login page on my own domain?

Yes. You set a login host like login.yourdomain.com, verify it with one DNS TXT record (the same check that verifies a sending domain), and Maillog serves the login screen on that name with your branding. Unverified hosts never serve a screen — they redirect to our own domain — so the address bar always matches the brand your users expect.

Can I style the login page to match my brand?

Yes. Each application gets a theme with your product name, logo (HTTPS) and two brand colors for the button and the background. The login, consent and two-factor screens all render in your theme. Values are strictly validated — only hex colors and HTTPS logo URLs — so nothing you enter can inject markup into the page.

How do I connect my own software?

Maillog is a standards-based OAuth 2.0 and OpenID Connect provider. Any library that speaks OIDC works: NextAuth/Auth.js, AppAuth, Spring Security, Ory, Passport, and the SDKs of most frameworks. You need three values from us: a client ID, a client secret, and our discovery URL (/.well-known/openid-configuration). PKCE is enforced for public clients, and access tokens are short-lived JWTs that your app validates locally against our published JWKS.

Is there a free plan?

Yes. Your first 100 accounts are free, permanently — not a trial that expires. That covers a small web app, an internal tool, or a pilot. Above 100 accounts, paid plans start at €19 per month, and every paid plan starts with a 14-day free trial, no credit card required.

What about security?

The identity provider is a separate application with its own security boundary. Password hashing uses scrypt with explicit, upgradeable parameters. Refresh tokens rotate with breach detection: a reused token revokes its whole family. Authorization codes are single-use and expire in sixty seconds. Redirect URIs are matched exactly, component by component. Tenants are separated by database constraints, not just application code. Two-factor authentication (TOTP, backup codes, passkeys) and magic links are included on every plan.

Where is the identity data hosted?

In the EU, like everything else at Maillog. Password hashes, signing keys (encrypted at rest) and audit logs stay in our European infrastructure. An audit log records events with hashed IP addresses — never raw values — and no tokens or passwords ever appear in logs.

Does it also work for customers who log in with Google or Microsoft?

Yes. Google, Microsoft, Apple and Facebook can be enabled as login methods. Accounts are linked by the provider's stable subject identifier, never by email address alone, and unlinking is refused if it would leave an account without any way to log in.

What happens to my users' data if I leave?

Accounts, consents and audit history belong to your team. You can export them via the API, disable applications at any moment (which revokes all their tokens), and delete accounts. When an account is deleted, any mailbox content remains with your team, not with the user — the mail is yours, not theirs.