By David,
"Push, never intercept" is the four-word version of Atlas Ink's architecture, and it sounds like a slogan until you sit in a mail-privacy review and watch it change the length of the meeting. This article unpacks what the phrase means mechanically, why the alternative - interception - is the default in this product category, and what each choice puts in scope when compliance comes asking.
Two verbs, two architectures
Every signature platform has to get its HTML in front of a recipient somehow, and there are only two moments to do it: while the message is being composed, or while it's being delivered.
Intercept is the delivery-time answer, and it's how most of the category works. A connector or transport rule routes outbound mail to a service - the vendor's cloud, or Exchange's own transport pipeline - which stamps the signature onto the message body and hands it on. The mechanism is powerful: it catches every message from every client, including native mobile apps and system-generated mail. It is also, unavoidably, mail processing. Something other than Exchange's normal delivery path is opening your messages and rewriting them.
Push is the compose-time answer, and it's the one Atlas Ink is built on. Atlas resolves which template applies to each user (tenant default, group variant, or user exception - most specific wins), hydrates the tokens from that user's Entra ID profile, and writes the finished signature into the mailbox as the user's own Outlook compose signature, via the Exchange admin API. Then it's done. When the user sends a message, the signature is already part of what they composed - by default no rule fires, no service touches the message, and mail leaves Exchange Online exactly the way Microsoft sends it.
Push is built for what "signature management" usually means - people sending on-brand, current, correct signatures that they can see while they type - and it does the job without the baggage below. If you also keep a plain legal disclaimer on system-generated mail, Exchange's built-in transport rules run happily alongside pushed signatures.
What interception puts in scope
Compliance reviews don't score architectures on elegance; they trace data. Put an interception-based product in place and three findings appear on the diagram:
A third party processes outbound mail. While the stamping hop exists, message content - body, recipients, attachments - is being handled by infrastructure you don't operate. Your records of processing, your DPA inventory, and your incident-response plan all grow a node. Responsible vendors document this well, but documentation doesn't remove the node; it describes it.
The mail path gains a dependency. Delivery now involves a service whose availability and behavior you don't control. Most of the time this is invisible. The day it isn't - a latency incident, a malformed-HTML edge case, a certificate expiry on a connector - it's a mail-flow incident, which is the highest-severity category most IT teams have.
The blast radius widens. A multi-tenant stamping service holds, at minimum, transient access to every customer's outbound mail. Your review has to reason about that shared surface even though you only bought signatures.
Plenty of organizations accept these trades knowingly. The failure mode is accepting them unknowingly, because the product was sold as "signatures" and nobody asked where the HTML gets applied.
What push puts in scope
Run the same trace against the push model and the diagram stays almost empty:
- Mail: never routed through Atlas. There is no connector, and by default no transport rule; there's nothing to trace.
- Directory: read in place, read-only, via Microsoft Graph - from a service running inside your own Azure subscription. No synced copy of your people exists in a vendor database.
- Signature data: templates, assignments, and revision history live in a per-tenant PostgreSQL database in your subscription, encrypted with keys in your Key Vault.
- What leaves: one aggregate number - distinct active users per month - reported to Atlas for metered billing at $1 per active user, always.
That's the whole review - for the default push posture. There is one opt-in exception, and it's worth knowing before the meeting. Pushed signatures can't reach classic desktop Outlook or non-Outlook clients like Apple Mail, so Atlas Ink also offers server-side stamping for those users. An admin has to turn it on explicitly, with its own consent and the Exchange Administrator role, and it isn't available in GCC or GCC High. When it's on, Atlas creates one mail-flow (transport) rule, and a mail-enabled group of the users it applies to, in your own Exchange Online, and that rule appends the signature as those users' mail passes through Microsoft's pipeline. That is in-transit stamping, so for those users your review gains a rule to document. It still adds no connector and no third-party hop: mail never flows through Atlas on either tier.
The data-residency deep dive walks the same exercise across all three architectures in the market if you want the vendor-by-vendor version.
The questions that surface the difference
Whatever you evaluate, these five questions separate stamping from provisioning in one meeting:
- Does any outbound message ever transit the vendor's infrastructure? Under what conditions?
- If the vendor's service is down, does mail still flow - and does it flow signed?
- Is directory data copied to the vendor's environment, or read in place?
- What is the complete list of data that leaves our tenant in normal operation?
- Can the sender see the signature while composing, or only the recipient after delivery?
Question five looks like a UX nicety next to the compliance heavyweights, but it's the same architecture showing through: a stamped signature is invisible to the person sending, which is why stamped deployments sprout hand-made duplicate signatures and reply chains stack disclaimers. The mechanism that keeps you out of mail-flow review is the same mechanism that puts the signature where users can see it.
"Push, never intercept" isn't a feature toggle - it's the default shape of the product, chosen so that the answer to "what do you do with our mail?" is nothing unless you deliberately opt users into stamping. If that's the answer your next review needs, see how Atlas Ink deploys into your own tenant.