For corporate and government rollouts, SIP Shield onboarding is managed by our team by default, regardless of OS. This keeps deployments consistent across Linux, Windows Server, and cloud environments, reduces misconfiguration risk, and shortens time to protection. If your IT team prefers self-install, we can support that after the first deployment is stable.
Server OS and version, mail stack (Exim / Postfix / Exchange / other), control panel (Webuzo / cPanel / Plesk / none), admin access method (SSH / VPN / Bastion), root or sudo access for installation (temporary access is acceptable), maintenance window, and rollout scope. If you want, you can create a temporary SSH username using your SIP Shield Client ID to make handoff cleaner.
Install and configure the SIP Shield server app, discover mailboxes and confirm the protected list, enable quarantine and review flow, validate held-mail notices and release/delete actions, and deliver a clean upgrade path with a basic runbook for your IT team.
Managed onboarding usually takes 60–180 minutes depending on the mail stack and environment. Self-install by the client typically takes 2–6 hours (often longer due to environment differences and troubleshooting).
We keep access as limited and temporary as possible while still completing the install correctly.
The server app installs as a system service and integrates with the mail stack, so root or sudo access is required during installation. Temporary access is acceptable and recommended. We suggest using your SIP Shield Client ID as the temporary username (example: SS-00ABC1234) so access references are easy to track.
We only keep access for the duration of the setup and initial validation. After that, you can remove access immediately.
We do not ask for mailbox passwords for end users, and we do not take ownership of DNS, MX records, or external mail routing without explicit agreement.
We keep the footprint small and reversible so your team can understand what SIP Shield touched.
SIP Shield installs as its own service with a dedicated config and does not replace your mail server or rewrite your core mail stack.
We add a controlled mail filter hook so mail can be evaluated before delivery. If the hook is removed, normal mail flow resumes.
We enable logging and quarantine visibility so your team can audit what was held and why. Nothing is hidden or opaque.
We prefer a narrow scope first, then expand after a clean test run.
We usually start with a small set of mailboxes to confirm mail flow, quarantine, and notice delivery before widening coverage.
A 60–180 minute maintenance window is usually enough for install and validation. We schedule around your lowest email traffic hours.
If anything unexpected happens, we can disable the SIP Shield mail hook and restore the default mail flow immediately.
SIP Shield does not replace your mail server and does not delete original mail without explicit review. It installs as a service and uses standard mail-stack hooks.
We do not take a full server backup by default because it can be heavy and slow. If your policy requires it, we can coordinate a snapshot before changes. We can also stage the install in a limited test scope before full rollout.
SIP Shield is designed to be low-risk, but any mail-stack integration carries operational risk. The main risk is mail flow interruption if a mail stack hook is misconfigured. We mitigate this by testing a small mailbox subset first.
A catastrophic system crash is not expected. SIP Shield does not modify system packages outside its own install path. The realistic risk is temporary mail-flow disruption if environment details are wrong, which is why managed onboarding is the default.
We want your internal teams to have clarity after the first deployment.
We provide a clean upgrade path and a short runbook so your IT team can apply updates without redoing the rollout.
Held mail triggers a notice to the affected mailbox user, with the customer account email copied for visibility.
The portal shows mailbox counts, quarantine status, and the active deployment model so your team can track the rollout.
We try to be transparent so clients know the tradeoffs.
Faster time to protection, lower misconfiguration risk, cleaner deployment record, and less burden on your IT team.
Requires temporary admin access, needs a maintenance window, and some organizations prefer full internal control.
Self-install keeps full internal control but is slower and has a higher risk of misconfiguration. We recommend self-install only after the first deployment is stable.