Most email-signature tools are SaaS: you create a vendor account, sync your directory into their cloud, and use a service you visit. Atlas Ink is a different supply chain. What you deploy lands in your own Azure subscription - App Service, a per-tenant database, keys in your Key Vault - provisioned from a scoped setup link, and what you pay is a small prepaid unit charge billed via Stripe. This walkthrough shows that path end to end, from trial signup to the first verified push, so you know what to expect - and what to check at each step.
Why deploy-into-your-own-subscription changes the buying motion
Three practical differences before the first click:
- Procurement is light. The platform deploys into your own subscription - no signature content leaves your tenant (only usage counts and, for any clickable banners, the banner links and their click counts reach Atlas) - and units are billed as a small prepaid charge via Stripe, with no seat commitment and no annual renewal to track. The approval conversation is "add a metered, usage-billed service in our own subscription," not "onboard a seat-licensed SaaS vendor."
- Deployment is provisioning, not enrollment. The platform's runtime - App Service, per-tenant PostgreSQL database, Key Vault-held keys - is created in your subscription, inside the boundary you already govern. You're not being granted a login to someone else's environment.
- The meter follows usage, not seats. $1 per active user, per month, always - and a user only counts in a calendar month where a managed signature was actually applied to their mailbox. Deploy today, pilot with ten people, and that's what the meter reads. Full details on the pricing page.
The deployment, step by step
1. Start a trial and get your setup link. Begin at the deploy page, pick your cloud, and sign up - the trial mints a setup link and hands you straight to it. There's no Marketplace listing and no vendor storefront to transact through; the setup link is the front door. (An operator can also start the trial for you and send you the same link.)
2. Open the setup link and consent, explicitly and scoped. The link opens the setup page, where you approve Atlas once in your own Entra directory. Atlas Ink needs two Microsoft integrations, both admin-consented and both worth reading rather than clicking through: Microsoft Graph access to read directory profiles - read-only, for hydrating signature tokens - and Exchange admin API access to write each user's Outlook compose signature. What's absent from that consent screen is the point: no mail-read scopes, no transport-rule permissions, no mail-flow anything, because pushing a compose signature never touches messages. (Optional server-side stamping is a separate, later decision: an admin turns it on explicitly with its own consent and the Exchange Administrator role, it creates one mail-flow rule in your own Exchange Online, and it isn't available in GCC or GCC High.)
3. Deploy into your subscription. From that same setup page, choose the subscription and resource group the deployment should live in, and kick off the install. Treat the resource-group choice as a real decision - it's where your tagging, cost views, and access policies will see the platform from now on. (A Cloud Shell installer stays as a manual fallback if you'd rather script it.)
4. Fold the resources into your standards. Post-deploy, the new resource group is ordinary Azure estate: apply your tags, wire diagnostics to your Log Analytics, add it to backup and access-review scope. Ten minutes now; it's what makes the platform's logs your logs at audit time.
5. Author the first template. Brand block, legal footer, and merge tokens for the per-person facts - name, title, department, phone, office. Resist hand-typing anything a token can carry; if the directory data is patchy, this is the moment you find out cheaply.
6. Assign by scope, pilot first. Set the tenant default, add group variants only where a block genuinely differs, and scope a pilot group that includes your awkward cases - a shared mailbox, a recent joiner, a heavy mobile user. (The precedence guide covers the scoping model properly.)
7. Push, then verify per user. Run the push and read the rollout status - applied, pending, failed - to green before widening. Failures are usually boring (unlicensed accounts, holds) and the per-user view is what turns "we deployed" into a checkable claim. From there, the daily reconcile keeps managed signatures enforced, and the meter starts counting exactly the users you've actually covered.
What you didn't do
Worth the contrast, because this list is the architecture: you didn't stand up a SaaS vendor tenant to log into; you didn't install connectors, or transport rules unless you later opt into stamping; you didn't sync your directory into anyone else's database; and you didn't add a processor to your outbound mail path for reviews to trace. The Azure-native deep-dive explains why those absences are structural rather than lucky - and if you're comparing against products where those steps are required, the field guide and CodeTwo comparison show the other side.
One link, one consent, one deploy, one template, one push - and signature management is a resource in your own subscription rather than a service you visit. That's Azure-native deployment done the structural way, and you can start it today.