Best Practices for Managing Emails with OX App Suite

Anti-Spam and Anti-Virus Filtering

Every OX App Suite mailbox routes incoming mail through a filtering layer before it reaches the inbox, scanning message headers, attachments, and sender reputation data against known threat signatures. The strength of this filtering is not uniform across all deployments because Hiya Digital operates as a reseller-managed licensing partner. The specific filtering tier, quarantine retention window, and false-positive tuning available to a given mailbox depend on the license bundle selected at signup, not on the base OX App Suite platform alone.

How Filtering Decisions Get Made

Spam scoring in this environment works on a weighted point system rather than a simple allow/block list. Each message accumulates a score based on factors such as sender IP reputation, SPF/DKIM pass/fail status, embedded link density, and known spam-signature matches. Messages that cross a defined threshold are quarantined instead of delivered, while messages just below it are typically flagged and delivered with a warning banner. Administrators can adjust these thresholds per domain rather than per mailbox in most reseller-provisioned environments, which matters for organizations running multiple departments with different risk tolerances. A finance team handling wire-transfer requests usually wants tighter thresholds than a marketing team receiving high volumes of legitimate promotional mail from partners.

The practical effect shows up during onboarding audits. A newly migrated domain often surfaces a backlog of borderline senders, vendors, newsletters, and automated systems that the previous provider handled differently. The first two weeks after cutover typically involve manually releasing or blacklisting a handful of senders until the filter’s learning model stabilizes to the domain’s actual mail patterns. This is normal and not a sign of misconfiguration; static filters built on decade-old blacklists don’t adapt this way, and it’s one of the tradeoffs of adaptive filtering versus a simpler rules-only approach.

Attachment Scanning and Malware Detection

Attachment handling operates independently of the spam-scoring engine described above. Every inbound and outbound attachment is scanned against a malware signature database before delivery, with executable file types (.exe, .scr, .bat) typically blocked outright regardless of scan results, since legitimate business correspondence rarely needs to send raw executables as email attachments. Archive files such as .zip and .rar are scanned after extraction, where technically feasible. However, password-protected archives can’t be inspected internally; they get flagged for manual review rather than automatically delivered or blocked.

This creates a specific edge case worth knowing about before it causes a support ticket: a client sending a password-protected ZIP file for legitimate reasons (protecting a client contract, for instance) may find that message held in quarantine longer than an unprotected attachment, because the filtering layer can’t verify its contents. Renewal reviews commonly surface a stale allowlist entry nobody remembers adding, usually from a one-time vendor interaction years earlier that was never removed. Building a habit of periodically auditing allowlisted senders, not just blocklisted ones, closes a security gap that’s easy to overlook because allowlisting feels like a one-time “fix it and forget it” action rather than an ongoing control.

Comparison: OX App Suite vs Google Workspace vs Microsoft 365

Transport Encryption: TLS and STARTTLS Enforcement

Mail moving between servers and between a mail client and the mail server gets wrapped in TLS wherever the receiving server supports it, which covers the overwhelming majority of legitimate mail infrastructure. STARTTLS negotiation occurs automatically during the SMTP handshake, upgrading an initially plaintext connection to an encrypted one before any message content is transferred, and this behavior is consistent regardless of which client software or device initiates the connection.

Where Encryption Enforcement Differs by Client

This is one area where mobile app vs. native client behavior genuinely diverges within the same OX App Suite deployment. The official OX Mail mobile app enforces TLS 1.2 or higher as a hard requirement and won’t fall back to an unencrypted connection under any configuration; there’s no toggle to disable it. Native desktop clients configured manually through IMAP/POP3/SMTP settings, by contrast, can technically be set up with STARTTLS disabled if a user manually selects an insecure port and authentication method during setup, which is a legacy compatibility option rather than a recommended path.

In practice, this matters most during migrations, when IT staff copying old server settings from a previous provider sometimes carry over outdated port numbers (like port 25 without encryption) instead of using the correct encrypted ports (587 for submission with STARTTLS, or 465 for implicit TLS). The mail still sends in these misconfigured cases, which is exactly why the problem goes unnoticed: nothing breaks outright; it just quietly transmits credentials and message content without encryption on that specific leg of the connection. A one-time audit of client configuration settings across a device fleet after any migration catches this before it becomes a standing exposure.

Certificate Validation and Downgrade Protection

TLS is only as trustworthy as the certificate validation behind it, and this is where downgrade attacks become relevant. A downgrade attack attempts to force a connection back to plaintext by interfering with the STARTTLS negotiation itself, and modern mail servers defend against this with strict transport security policies that refuse to complete a connection if the expected TLS upgrade doesn’t happen cleanly. OX App Suite’s server-side infrastructure applies certificate validation against a standard trust chain, rejecting self-signed or expired certificates from receiving servers rather than silently accepting them.

For outbound mail to domains that themselves have weak or missing TLS support, the connection typically still completes over an unencrypted channel as a fallback, since refusing to deliver mail entirely to under-configured recipient domains would break legitimate business correspondence more often than it would prevent interception. This is a tradeoff that every major provider makes in the same way. Universal TLS enforcement sounds appealing until it starts silently dropping mail to smaller organizations still running outdated mail servers, which remains more common than most administrators assume.

OX Guard and End-to-End Message Encryption

Transport encryption protects mail in transit between servers. Still, it doesn’t prevent the receiving mail provider from reading message content, which requires end-to-end encryption, a feature OX App Suite offers through OX Guard as an add-on rather than a default. OX Guard implements PGP-based encryption at the message level, meaning the message body and attachments are encrypted before they ever leave the sender’s device, and only the intended recipient’s private key can decrypt them.

What OX Guard Actually Encrypts

OX Guard’s core function centers on public-key cryptography, managed through OX App Suite’s key management interface, rather than requiring users to run separate PGP software. When two OX Guard users exchange mail, key exchange happens automatically in the background; when messaging an external recipient who doesn’t use OX Guard, the sender can choose password-based encryption instead, where the recipient receives a secure link and enters a shared password to decrypt the message rather than needing PGP infrastructure of their own. This dual-path design solves the single biggest historical obstacle to PGP adoption: the requirement that both parties manage keys correctly before encrypted mail worked at all.

It’s worth being precise about what this does and doesn’t protect. OX Guard encrypts the message body and attachment content; it does not encrypt the subject line, sender address, recipient address, or message metadata, since that information is needed for mail routing to function. Organizations evaluating OX Guard for regulatory reasons (handling health records or financial account details, for example) need to confirm with their compliance team whether metadata-level exposure is acceptable for their specific requirements, because “end-to-end encrypted email” gets used loosely enough in marketing contexts that the metadata gap catches people off guard during an actual audit.

Key Management and Recovery Tradeoffs

Because OX Guard’s encryption is genuinely end-to-end, the operator-side infrastructure lacks the technical ability to decrypt a user’s messages, even if legally compelled to do so; the private key never leaves the user’s control in a form anyone else can access. This is the entire point of end-to-end encryption. Still, it creates a real operational tradeoff: if a user loses their private key without a recovery backup in place, messages encrypted to that key become permanently unreadable. No support ticket fixes this after the fact.

OX Guard addresses this with an optional key backup feature that stores an encrypted copy of the private key, which is protected by a separate recovery password set independently by the user. Skipping this step during setup is one of the more common oversights in early OX Guard deployments, usually because it’s presented as optional in a setup flow people move through quickly. Enabling it during the initial rollout, rather than after the first lost-key incident, is the difference between a minor inconvenience and a permanent data-loss event for any mail encrypted in the interim.

DNS-Level Email Authentication: SPF, DKIM, and DMARC

Filtering and encryption protect content, but authentication protects identity, confirming that a message claiming to come from your domain actually originated from a server you’ve authorized. This happens through three DNS TXT records working together: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance), each defined by its own IETF standard.

SPF and the Ten-Lookup Limit

SPF works by publishing a list of servers authorized to send mail on behalf of a domain, so a receiving server can check whether the originating IP address of an incoming message matches that list. RFC 7208 caps SPF evaluation at 10 DNS lookups per check, and this limit trips up more organizations than any other part of SPF configuration. Every included third-party sending service (a CRM, a marketing platform, a helpdesk tool) typically adds its own “include” mechanism to the SPF record, and each of those can trigger additional nested lookups. Cross a domain onto multiple platforms that each add SPF includes, and the 10-lookup ceiling gets hit faster than most administrators expect, causing SPF to fail evaluation entirely rather than partially, a permanent error result, which many receiving servers treat similarly to an outright SPF failure.

Fixing this typically means flattening some includes into static IP ranges or consolidating to fewer third-party senders, both of which require someone auditing the record’s actual lookup chain rather than just counting the visible include statements, since nested includes don’t show their lookup cost at a glance.

DKIM Signing and DMARC Policy Enforcement

DKIM works differently; instead of authorizing sending IPs, it attaches a cryptographic signature to each outgoing message, generated from a private key and verifiable against a public key published in DNS. OX App Suite handles DKIM per-domain key provisioning automatically for domains hosted under the platform, generating a unique key pair per domain rather than sharing a single signing key across all customers, which matters because a shared-key model means one customer’s reputation damage from spam complaints or a compromised account can affect deliverability for every other domain signing with that same key. Per-domain provisioning isolates that risk to the affected domain alone.

DMARC ties SPF and DKIM together into an enforceable policy, telling receiving servers what to do when a message fails both checks: quarantine it, reject it outright, or monitor and report without taking action. Most organizations should start with a monitor-only DMARC policy (p=none) for several weeks to review the aggregate reports it generates before moving to enforcement, because jumping straight to a reject policy on a domain with unaudited third-party senders (an old marketing tool, a forgotten transactional email service) can silently break legitimate mail delivery from those systems without any obvious error message pointing back to the DMARC record as the cause.

Two-Factor Authentication and Account Access Controls

Password-based authentication alone leaves mailboxes exposed to credential-stuffing attacks, in which attackers test leaked passwords from unrelated breaches against email logins, assuming people reuse passwords across services. Two-factor authentication (2FA) closes most of this exposure by requiring a second verification step, typically a time-based one-time code from an authenticator app, beyond the password itself.

How 2FA Enrollment Works at the Mailbox Level

Enabling 2FA in OX App Suite ties into the platform’s mailbox-level permission model, where the setting can be enforced organization-wide by an administrator or left as an individual opt-in, depending on how the domain’s admin console is configured. Organization-wide enforcement is the stronger posture for any business handling client financial data, health information, or legal correspondence, since opt-in 2FA consistently yields adoption rates well below 100%. The employees least likely to enable optional security features are often the same ones whose accounts represent the highest business risk if compromised, simply because risk awareness and security opt-in behavior tend to move together.

Enrollment itself uses standard TOTP (time-based one-time password) generation, compatible with common authenticator apps, rather than requiring a proprietary app tied specifically to OX App Suite. This matters for IT teams standardizing authenticator app usage across multiple business tools, since employees can consolidate work-related 2FA codes into a single authenticator app instead of needing a separate app for each platform.

What Happens When a Second Factor Is Lost

Losing access to a 2FA device, a lost phone, or a factory reset without backup codes saved is the scenario that determines whether an organization’s 2FA rollout was actually planned or just switched on. OX App Suite issues backup codes at enrollment time specifically for this scenario, and the recovery process without them requires administrator-level identity verification through the admin console rather than a fully automated self-service reset, which is intentional: an automated reset path would itself become the weakest link an attacker could target instead of attacking the 2FA directly.

The operational lesson here shows up during actual incidents rather than during planning conversations. Organizations that store backup codes in a location genuinely separate from the primary device, use a password manager, or keep a printed copy in a secure location can resolve lockouts in minutes. Organizations that don’t end up routing every lockout through administrator-assisted recovery, which is manageable for one or two incidents a year but becomes a real support burden at a headcount where lockouts happen weekly instead.

Ready to Lock Down Your Domain’s Email Security?

Getting SPF, DKIM, DMARC, and 2FA configured correctly the first time, rather than discovering gaps during an actual incident, is exactly the kind of setup work an Authorized Partner handles as standard onboarding, not a paid extra. Hiya Digital configures these settings correctly from day one and stays reachable when a filtering rule or DNS record needs adjusting later.

Talk to an Email Security Specialist →

Admin Console Controls and Delegated Access

Security isn’t only about what happens at the mailbox level; it’s also about who can see, modify, or delegate access to mailboxes across an organization, and this is governed through the OX App Suite admin console rather than through individual user settings. Administrators can grant delegated access to a mailbox (letting an assistant manage an executive’s calendar and inbox, for instance) without sharing the actual account password, which is the security-correct approach compared to the still-common practice of simply handing out login credentials.

Delegation Without Credential Sharing

Delegated access in this environment relies on shared calendar permission separation as its underlying mechanism: a model in which calendar, contact, and mailbox access can each be granted independently rather than as an all-or-nothing bundle. An administrator might grant an assistant full calendar edit rights while limiting mailbox access to read-only, or the reverse, depending on the actual working relationship. This granularity matters more than it initially sounds like it should, because the alternative, shared login credentials, eliminates any audit trail showing which person actually took a given action inside the account, which becomes a real problem the moment something needs to be investigated after the fact.

Setting delegation up correctly the first time avoids a common failure mode in which an assistant’s access outlives the working relationship that justified it, someone changes roles internally, and the delegated permission from eighteen months earlier is never revisited because nothing in the interface prompts a periodic review. A standing calendar reminder to audit delegated permissions quarterly closes this gap more reliably than relying on anyone remembering to do it unprompted.

Audit Logging and Administrator Visibility

The admin console also maintains a login and activity log per mailbox, showing authentication attempts, IP addresses, and, for delegated access, which underlying account performed a given action rather than just showing activity under the primary mailbox owner’s name. This logging is what actually makes the mailbox-level permission model discussed earlier enforceable in practice, rather than just a settings screen nobody checks; a permission structure with no visibility into how it’s being used isn’t meaningfully different from no permission structure at all.

Reviewing this log isn’t something most organizations do proactively without a reason to, which is understandable; nobody has time to read login logs for accounts that aren’t causing problems. The more realistic approach is to set up anomaly alerts (a login from an unfamiliar country, or several failed attempts followed by a successful one). Hence, the log becomes something the system surfaces automatically rather than something an administrator has to remember to check. Not every reseller-provisioned environment has alerting configured by default, which is worth confirming explicitly during setup rather than assuming it’s active.

Admin Control Availability

Calendar and Contact Sync Security

Calendar and contact data syncing across devices has its own security considerations, separate from mail itself, since this data typically syncs continuously in the background across phones, tablets, and desktop clients rather than being checked once at login, as mail authentication often is. OX App Suite handles this synchronization through open, standardized protocols rather than a fully proprietary system.

CalDAV, CardDAV, and What Gets Exposed in Transit

The CalDAV/CardDAV sync layer is the specific mechanism behind calendar and contact synchronization in OX App Suite, using the same open standards that many third-party calendar apps already support natively. This is a deliberate architectural choice with a real security tradeoff embedded in it: standardized protocols mean broader compatibility with third-party apps a user might already prefer over the native OX interface. Still, it also means the security posture of that sync connection depends partly on how securely the third-party client itself implements CalDAV/CardDAV, which OX App Suite’s own infrastructure has no control over once a user authorizes an external app.

In practice, this shows up when an employee connects their work calendar to a personal third-party app for convenience, a habit tracker, a scheduling assistant, and grants it CalDAV access without fully reading what permissions that grants. The sync connection itself is encrypted in transit, consistent with the TLS enforcement covered earlier. Still, the third-party app on the receiving end now holds a persistent, ongoing copy of calendar data that isn’t subject to any retention or deletion policy OX App Suite controls. Reviewing connected third-party app permissions periodically, the same discipline as reviewing delegated mailbox access, closes this exposure before it becomes an actual incident.

Meeting Invite Exploitation as an Attack Vector

Calendar invites themselves have become a more common phishing vector than most organizations account for in their security training, precisely because employees are trained to be suspicious of email links but not of calendar invitations, which often auto-populate into a calendar view without the same visual scrutiny a suspicious email gets. A malicious calendar invite can embed a link disguised as a video conferencing URL. Because it arrives through the calendar interface rather than the inbox, it frequently bypasses whatever mental spam-checking habit an employee has built up for email specifically.

OX App Suite’s spam filtering, discussed earlier, does extend some coverage to calendar invite content, but the detection signals available for a calendar invite are inherently narrower than for a full email message; there’s less text, fewer headers, and a more constrained format to analyze for red flags. Extending phishing-awareness training to cover calendar invites, not just email, closes a gap that technical filtering alone doesn’t fully address.

Document Collaboration Security

Real-time document collaboration introduces a different security surface than either mail or calendar sync, since it involves live, simultaneous editing access rather than a discrete, logged action like sending a message or accepting an invite. OX App Suite’s document collaboration runs through OX Documents, the platform’s integrated word processing, spreadsheet, and presentation suite.

Permission Scoping Within Shared Documents

OX Documents supports view-only, comment-only, and full-edit permission tiers on a per-document or per-folder basis, allowing an administrator or document owner to scope access more precisely than a simple shared/not-shared toggle would. This granularity matters most in scenarios involving external collaborators, sharing a contract draft with an outside vendor, for instance, where view-only or comment-only access lets the collaboration happen without giving that external party standing edit rights to a document that will eventually need internal sign-off before finalization.

Link-based sharing is where this permission scoping gets tested in practice, because a shared link’s security depends heavily on whether it’s scoped to specific named accounts or left open to anyone possessing the link. An open link shared internally for convenience, posted in a team chat channel, for example, can end up circulating further than intended if that chat channel itself has broader membership than the document’s original intended audience. Defaulting to named-account sharing rather than open-link sharing for anything containing sensitive business content is a habit worth establishing at the organizational level, rather than leaving it to individual judgment on a case-by-case basis.

Version History and Accidental Exposure Recovery

Every edit within OX Documents is versioned, which serves a security function beyond simple convenience. If a document is edited maliciously or a permission mistake exposes content that shouldn’t have been shared, version history provides a recovery path back to a known-good state, along with a record of exactly which account made which change and when. This audit trail matters in any scenario where a document dispute needs to be resolved after the fact, since it removes ambiguity about who changed what.

Version history has a practical limitation worth knowing before it matters: the retention length for version history is plan-tier-dependent, meaning very old versions may eventually age out and become unrecoverable rather than being preserved indefinitely by default. Organizations working with documents that carry long-term legal or compliance retention requirements should confirm the specific version retention window applicable to their plan rather than assuming unlimited history, since that assumption is one of the more common gaps discovered only after it’s already too late to matter.

Cloud Storage, Backup, and Data Residency

Mail and document security ultimately depend on where the underlying data is physically stored and how it’s backed up, which is a separate question from the access control and encryption topics covered so far. OX App Suite’s file storage layer runs through OX Drive, functioning as the platform’s integrated cloud storage component for attachments, documents, and general file sync.

How OX Drive Storage Is Structured and Backed Up

OX Drive storage typically operates on a pooled basis across an organization’s mailboxes rather than allocating a rigid, non-transferable quota to each account. This pooling model means storage-heavy users and light users within the same organization can effectively share capacity rather than one account hitting a hard ceiling while another sits mostly unused. Backup frequency and retention for OX Drive content are details that vary by hosting configuration and plan tier rather than being a single universal figure across every deployment, which is exactly the kind of variable-by-plan detail worth confirming explicitly with a reseller in writing before treating any assumed backup cadence as fact.

Data residency, the physical or jurisdictional location where mail and file data is stored, matters specifically for organizations subject to regulatory frameworks like GDPR that impose requirements on cross-border data transfer. Confirming data residency in writing before onboarding, rather than assuming a default location meets organizational compliance requirements, avoids a class of problems that’s expensive to fix retroactively once data has been provisioned and is in active use.

Recovering From Accidental Deletion

Accidental deletion, a user permanently removing a folder they didn’t realize was shared, or an admin script running incorrectly during a bulk operation, is one of the more common real-world incidents this backup and versioning infrastructure exists to solve, and it’s worth distinguishing from the ransomware or breach scenarios that dominate most security discussions. Most accidental data loss incidents in day-to-day operations are exactly this mundane: someone deleted the wrong thing, not an external attacker.

OX Drive maintains a recycle bin with a defined retention window before permanent deletion, providing a recovery path for straightforward accidental deletion scenarios without requiring a full backup restoration. For deletions older than that recycle bin window, recovery depends on whatever backup schedule applies to the specific plan tier in place, which is why establishing what that schedule actually is and testing a sample restoration at least once during onboarding rather than assuming it works is worth the relatively small time investment relative to the cost of discovering a gap during an actual emergency.

Mobile Device Security and Coverage Gaps

Mobile access to email, calendar, and documents introduces its own distinct set of security considerations, since mobile devices are more frequently lost, more often connected to untrusted public networks, and more commonly used with weaker device-level lock screen security than managed desktop hardware in a business environment.

Mobile App Security Behavior

The OX Mail mobile app enforces the TLS requirements covered earlier without exception, and it also supports remote wipe, allowing an administrator or the account owner to clear synced mail, calendar, and contact data from a lost or stolen device without requiring physical access. This depends on the device having had connectivity at some point after the wipe command is issued, since a device that’s been powered off or kept permanently offline can’t receive the command until it reconnects.

Mailbox storage pooling, covered in the previous section for OX Drive, has a secondary effect worth noting specifically for mobile: cached content on a mobile device typically reflects only a recent, size-limited subset of the full pooled storage rather than a complete local mirror, which is a deliberate design choice to keep mobile app storage footprint manageable. The practical security implication is that a lost device generally exposes less data than a full account compromise would, since older content beyond the mobile cache window was never actually stored on the device to begin with.

What Isn’t Covered by Default

This is the honest gap section, and it matters more than the feature list above it for anyone making a genuine security evaluation. OX App Suite’s out-of-the-box security does not include mobile device management (MDM), enforcing passcode policies, blocking jailbroken devices, or remotely managing app installations on employee phones; a separate MDM solution integrated with OX App Suite is required, rather than a built-in feature of the email platform itself. Organizations with a bring-your-own-device policy and no separate MDM tool in place rely entirely on individual employees to maintain reasonable device-level security on their own initiative.

Similarly, advanced threat simulation, sending controlled phishing test emails to employees to measure and train awareness, a feature increasingly standard in larger enterprise security suites, isn’t part of OX App Suite’s native toolset and would need to be sourced as a separate, complementary service if an organization wants that specific capability. Being clear about these gaps during the initial evaluation, rather than discovering them after an incident has occurred, is the difference between a security stack with known, accepted gaps and one with unknown gaps.

Frequently Asked Questions

Does OX Guard cost extra, and is it billed per mailbox or per domain?

OX Guard is typically an add-on rather than a default-included feature, and reseller-managed licensing generally bills it per mailbox rather than as a flat domain-wide charge, since not every mailbox in an organization needs end-to-end encryption, a general support inbox handling public inquiries has different requirements than an executive account handling contract negotiations. Before committing, ask specifically whether OX Guard licensing can be applied selectively to a subset of mailboxes or requires an all-or-nothing, organization-wide toggle, since pricing structures and technical enablement don’t always align across all reseller configurations. Get this specific detail confirmed in writing rather than assuming it based on how other add-ons in the same plan are billed, since add-on billing models aren’t always consistent even within the same provider.

If I migrate from another provider, does spam filtering data (allowlists, blocklists) transfer automatically?

No, spam filtering configuration, including custom allowlists, blocklists, and threshold adjustments built up over time with a previous provider, does not migrate automatically as part of a standard mailbox migration, since that data lives in the previous provider’s filtering system rather than in the mail itself. This means the first several weeks after migration typically involve rebuilding those lists from scratch as legitimate senders get temporarily caught by default filtering thresholds. Exporting your existing allowlist and blocklist entries before migration, even as a simple spreadsheet, gives your new administrator a starting reference point to manually re-apply the most important entries rather than waiting for each one to surface as an individual support ticket after cutover.

Does OX App Suite support Outlook, or only its native webmail and app?

OX App Suite supports standard Outlook connectivity via IMAP, POP3, and SMTP protocols, rather than requiring users to abandon Outlook for the native OX Mail interface, so organizations with existing Outlook-based workflows and muscle memory don’t need to retrain staff on a new client. What doesn’t carry over automatically through this connection method is anything specific to OX’s native interface features; OX Guard encryption prompts, for instance, are designed around the OX Mail webmail and app experience and don’t have an equivalent plugin inside Outlook itself. Organizations planning to rely on OX Guard should confirm whether affected users are expected to use OX Mail directly for encrypted correspondence specifically, even if they use Outlook for general daily mail.

How does 2FA work if an employee’s phone is company-managed versus personally owned?

The TOTP-based 2FA mechanism functions identically regardless of whether the authenticator app is on a company-managed or personal device, since it’s tied to the authenticator app account rather than to device ownership. The practical difference shows up in offboarding: when an employee with 2FA enrolled on a personal phone leaves the organization, IT typically can’t remotely clear that authenticator enrollment the way they could wipe a company-managed device, which means offboarding checklists need an explicit step for administrator-assisted 2FA reset on the affected mailbox rather than assuming device wipe handles it. Building this into a standard offboarding checklist avoids a lingering access gap that’s easy to overlook since the account itself gets deactivated either way, masking the fact that the 2FA method specifically was never formally revoked.

What specifically should I ask my reseller about backup frequency before signing?

Ask for the specific backup interval (daily, hourly, continuous) and retention window in writing, along with whether backups apply uniformly to mail, calendar, contacts, and OX Drive content, or vary by data type, since these details are frequently plan-tier-dependent rather than universal across all accounts. Also ask whether restoration has ever actually been tested on a sample account during onboarding rather than only during the buildout of the backup system itself, since a backup process that’s never been tested for restoration carries meaningfully more risk than one that has, regardless of how confident the underlying infrastructure claims to be. A reseller unable to answer these specifics clearly and promptly is itself useful information about what to expect from post-sale support generally.

Can OX App Suite mailboxes use a custom domain, and does that affect DKIM setup?

Yes, custom domain email is standard for business OX App Suite deployments, not an advanced or unusual configuration, and DKIM per-domain key provisioning is specifically designed around this. Each custom domain gets its own unique signing key rather than inheriting a shared key from a default OX-provided domain. The setup process requires adding the generated DKIM TXT record to the custom domain’s DNS zone, typically alongside SPF and MX records during the same initial configuration session, since all three usually need to be in place together before mail starts flowing reliably through the new domain. Domains migrating from a previous provider need their old DKIM records explicitly removed or replaced rather than left in place alongside the new ones, since conflicting or duplicate DKIM selectors for the same domain can cause authentication failures that are genuinely confusing to diagnose without knowing to check for this specific leftover-record scenario.

Is OX App Suite security sufficient for a business handling health records or financial data under regulatory requirements?

OX App Suite’s core security features, transport encryption, DKIM per-domain signing, and optional OX Guard end-to-end encryption, meet the technical baseline many regulatory frameworks require, but “sufficient” ultimately depends on the specific framework in question (HIPAA, for example, has requirements around business associate agreements that are a contractual matter, not purely a technical one) and on configuration choices made during setup rather than being automatically satisfied by the platform alone. Organizations in regulated industries should treat security configuration as a compliance conversation involving their actual compliance officer or legal counsel, not solely an IT setup task, and should get specific written confirmation from their reseller about which regulatory frameworks the current configuration has actually been validated against rather than assuming general security features imply full regulatory compliance automatically.

How are shared calendars handled when an employee with delegated access leaves the company?

Delegated calendar access tied to shared calendar permission separation doesn’t automatically revoke when an employee’s account is deactivated if the delegation was granted to their account by someone else managing a different calendar, resulting in the departing employee’s mailbox closing. Still, any delegated access they’d been granted into someone else’s calendar needs to be manually reviewed and revoked as a separate offboarding step. This is a commonly missed step precisely because deactivating the departing employee’s primary account feels like it should handle everything related to their access, when in fact delegated permissions on other people’s calendars are a separate permission grant that doesn’t automatically follow account deactivation. Adding an explicit delegated-access audit to the standard offboarding checklist, not just primary account deactivation, closes this specific gap.

Does storage pooling across mailboxes create a security risk if one account is compromised?

Storage pooling itself is a capacity-sharing mechanism rather than an access-sharing one, so a compromised individual mailbox doesn’t automatically grant an attacker access to other mailboxes’ content just because they share a storage pool. Access permissions and storage allocation operate as separate systems within the platform. What pooling does affect is the blast radius of a storage-based denial-of-service scenario: if a compromised account is used to rapidly fill available storage (through automated large-file uploads, for instance), that consumption draws from the shared pool and can affect available capacity for other mailboxes in the organization, even though it doesn’t expose their actual data. Monitoring for unusual storage consumption spikes, not just unusual login activity, is a detection signal worth including in an incident response plan specifically because of this shared-pool dynamic.

What happens to encrypted OX Guard messages if the recipient’s mailbox is later migrated to a different email provider?

OX Guard-encrypted messages already delivered to a recipient’s mailbox remain readable after a future provider migration as long as the recipient retains access to their private key or key backup, since decryption happens client-side using that key rather than depending on the message staying within OX App Suite’s infrastructure specifically. What doesn’t transfer automatically during a typical migration is the key management setup itself. A recipient moving to a different email platform needs to explicitly export and securely retain their OX Guard private key and backup password before migration, since a standard mailbox migration process focused on moving message content doesn’t necessarily account for exporting encryption key material as a distinct, separate step. Confirming this explicitly with whoever handles the migration prevents old encrypted mail from becoming permanently unreadable simply because the key export step was assumed to be automatic, when it wasn’t.

Glossary

SPF (Sender Policy Framework): A DNS TXT record listing which mail servers are authorized to send mail on behalf of a domain.

DKIM (DomainKeys Identified Mail): A cryptographic signing method that attaches a verifiable signature to outgoing mail, validated against a public key published in DNS.

DMARC (Domain-based Message Authentication, Reporting and Conformance): A policy layer built on SPF and DKIM that tells receiving servers how to handle messages that fail authentication.

TLS/STARTTLS: Transport Layer Security; STARTTLS is the mechanism that upgrades a plaintext mail connection to an encrypted one during the initial handshake.

OX Guard: OX App Suite’s optional end-to-end message encryption feature, based on PGP public-key cryptography.

CalDAV/CardDAV: Open standard protocols used for syncing calendar and contact data across devices and applications.

TOTP (Time-based One-Time Password): The standard mechanism behind most authenticator-app-based two-factor authentication codes.

Data residency: The physical or jurisdictional location where an organization’s stored data resides, relevant to regulatory compliance.

MDM (Mobile Device Management): Software used to enforce security policies (passcodes, remote wipe, app restrictions) on employee mobile devices, separate from email platform security itself.

Reseller-managed licensing: A licensing model where a partner (rather than the underlying platform developer) manages plan tiers, billing, and support for a customer’s deployment.