Common OX App Suite Mistakes and How to Avoid Them

DNS Record Misconfiguration During OX App Suite Setup

DNS errors cause more OX App Suite deliverability complaints than any other setup step, because a single mistyped MX priority or missing TXT record can silently fail mail delivery for days before anyone notices. Domain administrators moving from another host often copy old records forward rather than provisioning new ones for the new mail environment.

MX Priority and SPF Include Chains

MX records tell receiving servers where to route inbound mail, and priority values determine failover order when multiple records exist. A common error is leaving a legacy provider’s MX record active alongside the new OX App Suite record, which splits inbound mail between two systems and causes messages to bounce or arrive inconsistently depending on which server answers first. Administrators should remove old MX entries entirely rather than lowering their priority, since even a low-priority record can still receive mail during outages.

SPF (Sender Policy Framework) records list which servers are authorized to send mail for a domain, and they cap out at ten DNS lookups per RFC 7208, a limit that trips up domains carrying old includes from previous marketing tools or CRMs. Reseller-provisioned DKIM keys are generated per domain rather than shared across a platform-wide key, which means each domain added under an OX App Suite account needs its own DKIM TXT record published before outbound mail from that domain will pass authentication checks at scale. Skipping this step is one of the most frequent causes of mail landing in spam folders within the first month.

DMARC Policy Rollout Sequencing

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving mail servers what to do when SPF or DKIM checks fail, and publishing a strict policy too early is a frequent setup mistake. Domains that jump straight to p=reject before confirming every legitimate sending source, including third-party tools like invoicing platforms or helpdesk software, often find their own transactional mail rejected, sometimes without anyone noticing until a customer complains about a missing invoice.

The safer sequence starts with p=none, which collects only aggregate reports without blocking anything, followed by a review period of two to four weeks before tightening to p=quarantine and eventually to p=reject. Renewal reviews often reveal a stale SPF that nobody remembers adding, usually from a marketing tool retired years earlier, and DMARC reporting is often the only thing that flags it before it causes a rejection. Skipping the observation phase removes the one diagnostic window that catches these leftover senders before they break.

Mailbox Provisioning and User Account Setup Errors

Provisioning mistakes usually surface weeks after go-live, when a new hire cannot access shared folders or a departing employee’s mailbox gets deleted before its contents are archived. OX App Suite’s permission model is granular by design, which is exactly why rushed provisioning tends to under-configure it rather than over-configure it.

Role Assignment and Permission Scope

OX App Suite assigns access through a mailbox-level permission model that separates administrative rights, folder-level sharing, and application access into distinct layers rather than a single on/off toggle, and setup teams frequently grant broad admin rights to accounts that only need mailbox access. This shortcut saves a few minutes during onboarding. Still, it creates an audit problem later, since every admin-level account becomes a potential point of failure for domain-wide settings, not just personal mail.

A cleaner approach assigns the narrowest role that satisfies the job function, then escalates permissions individually as specific needs arise, which keeps the audit trail traceable to a named request rather than a blanket rollout decision. Agencies managing multiple client domains under a single reseller account are especially exposed here, since a single over-permissioned account can technically access settings across unrelated domains if role boundaries were not correctly scoped during initial provisioning. Reviewing role assignments quarterly catches drift before it becomes a compliance question.

OX App Suite vs. Microsoft 365 vs. Google Workspace

Offboarding and Mailbox Retention Gaps

Deleting a departing employee’s mailbox immediately after their last day is a common shortcut that causes real business damage because attached calendar invites, shared documents, and historical correspondence often disappear with it. A better pattern converts the account to a shared or archived mailbox for a defined retention window, commonly 90 days for SMBs and longer for regulated industries, before final deletion, giving managers time to redirect ongoing threads.

Startups running lean IT teams tend to skip this step entirely because no one owns the offboarding checklist, and the mailbox gets removed the same day access is revoked in other systems. Building offboarding into the same ticket that handles account deactivation elsewhere, payroll, Slack, and single sign-on closes that gap without adding a separate process for IT to remember. Enterprises with formal HR handoffs rarely encounter this problem. Still, SMBs without a documented offboarding flow often lose mailbox history, making it a default configuration step rather than an afterthought.

Migration Mistakes When Moving to OX App Suite

Migrating an existing mailbox into OX App Suite is where setup mistakes cause the most visible damage, because failures show up as missing email, duplicated folders, or broken calendar invites in front of the whole team rather than quietly in a DNS panel. Migration risk concentrates around three points: timing, folder mapping, and the cutover window itself.

Pre-Migration Data Auditing

Skipping a pre-migration inventory is the single most avoidable mistake in any move to OX App Suite, because it means nobody actually confirmed how much mail, how many calendar entries, and how many contacts exist before the transfer started, so there’s no baseline to check the migration against afterward. A quick export count from the source platform, compared with what lands in OX App Suite post-migration, is the only reliable way to confirm that nothing silently failed during the transfer.

Reseller-managed licensing under an Authorized Partner account typically provisions mailbox capacity ahead of migration day. Still, teams sometimes schedule the data transfer before confirming that every mailbox has been created and sized correctly on the receiving end, which causes partial transfers that appear complete in the status log but are missing folders subfolder-deep. Running the audit against actual mailbox contents, not just a migration tool’s success message, catches this before users start reporting missing mail. Migration risk compounds when audits are skipped because the same gaps that go undetected in the inventory stage tend to resurface later as support tickets.

Common Setup Mistakes, Detection Method, and Typical Time to Discover

Cutover Timing and DNS Propagation Overlap

Scheduling the DNS cutover at the same time as the mailbox data migration is a mistake that creates a window during which mail can bounce or be routed to the wrong server, because DNS changes propagate at different speeds across the internet. Some senders will still reach the old server for hours after the switch. The safer approach is to run the mailbox migration first. At the same time, DNS still points to the old system, confirms data integrity, and updates the MX records only after mail is verified in the new environment.

A 24- to 48-hour propagation buffer after the DNS change, with both old and new systems monitored for inbound mail, catches messages that arrive at the wrong destination during the transition. Agencies migrating several client domains in the same week sometimes stagger cutovers to spread support load, which also limits how many domains are simultaneously exposed to propagation-window bounces if something goes wrong with one domain’s records. Rushing every domain through cutover on the same day multiplies the blast radius of a single misconfigured record.

IMAP, POP3, and SMTP Client Configuration Problems

Desktop and third-party email clients connect to OX App Suite through standard protocols. Still, incorrect port numbers, missing TLS settings, or the wrong authentication method are a recurring source of “email not syncing” tickets that have nothing to do with the mailbox itself.

Protocol and Port Mismatches

IMAP synchronizes the mail state across all connected devices. At the same time, POP3 downloads messages to a single client and can leave other devices out of sync, a distinction setup guides often skip, leading teams to configure POP3 out of habit from an older mail system without realizing why their phone and desktop show different inboxes. OX App Suite’s client access layer supports both, but IMAP is the correct default for anyone checking mail from more than one device, which describes most business users today.

Port and encryption mismatches cause a second wave of tickets: IMAP over TLS uses port 993, SMTP submission uses port 587 with STARTTLS rather than the older port 25, and entering the wrong combination produces authentication failures that look identical to a wrong password from the user’s perspective. Support teams that verify protocol and port settings before resetting a password resolve these tickets in minutes rather than escalating them as account issues. Consultants managing multiple client mailboxes on personal devices are especially prone to carrying over stale port settings from a previous employer’s mail system.

Third-Party App Password Requirements

Client applications that don’t support modern authentication flows require an app-specific password rather than the account’s main login, and setup teams frequently skip generating one and then troubleshoot a “connection refused” error as if it were a server problem. This mistake is common with older desktop clients, some CRM email integrations, and IoT-adjacent devices like networked scanners that email documents directly to a mailbox.

Generating an app password takes under a minute in the account security panel. Still, it needs to happen before the third-party tool is configured, not after repeated failed login attempts. Enough failed attempts can trigger a temporary lockout that adds unnecessary delay to setup. Teams integrating several third-party tools with the same mailbox, such as a shared support inbox connected to both a helpdesk platform and a backup client, should generate a distinct app password per integration, so that a single compromised tool doesn’t require rotating credentials across every connected system.

Mobile Device Sync Setup Mistakes

Mobile sync issues generate a disproportionate number of support tickets given how simple the fix usually is, largely because the mobile app and a device’s native mail client behave differently even when connected to the same OX App Suite account.

Native Client vs. Dedicated App Behavior

OX App Suite’s dedicated mobile app and a phone’s built-in native mail client don’t sync identically; the native client typically relies on standard IMAP/CalDAV/CardDAV protocols and may not surface every collaboration feature. In contrast, the dedicated app is built to expose OX-specific functionality, such as document co-editing links and shared folder structures, directly in the mobile interface. Setup teams that configure the native client by default, because it’s faster, sometimes leave users without access to features they assumed came standard.

For users who only need mail, calendar, and contacts, the native client configured through the account’s mobile setup profile is sufficient and often loads faster than a dedicated app. For users active in document collaboration or shared team folders, the dedicated app is the better default, and setup documentation should specify which one a given role needs rather than defaulting everyone to whichever option installs faster. Enterprises standardizing device provisioning across a fleet see fewer support tickets when this distinction is documented once and applied consistently.

Push Notification and Battery Optimization Conflicts

Aggressive battery optimization settings on Android devices are a frequent, invisible cause of delayed mail notifications, because the operating system suspends background sync for apps it hasn’t been told to exempt, and OX App Suite’s mobile app needs that exemption explicitly granted, not assumed. Users report “email arriving late” when the real cause is the device silently pausing the app’s background activity to save power.

The fix is a device-level setting rather than anything inside OX App Suite: exempting the mail app from battery optimization in the phone’s system settings, and confirming that push notifications are enabled at both the OS and app levels. iOS devices rarely have this problem because background app refresh is handled differently, which is why the same complaint shows up almost exclusively from Android users during rollout. Documenting this as a standard onboarding step for Android devices prevents a wave of “is the server down” tickets that are actually a phone setting.

Get Your OX App Suite Setup Reviewed Before Small Mistakes Become Support Tickets

If DNS sequencing and domain verification order are already starting to feel like more than a one-person job, Hiya Digital’s team can review your OX App Suite configuration as an Authorized Partner and flag gaps before they affect mail delivery. Buying and setting up through a partner adds a knowledgeable second set of eyes to every step.

Request a Setup Review →

Security and Anti-Spam Configuration Gaps

Security gaps in OX App Suite setups are rarely about the platform lacking a feature; they’re almost always about a feature that exists but was never enabled during the initial rollout because default settings favor ease of onboarding over maximum restrictions.

Encryption Defaults and OX Guard Activation

OX Guard adds end-to-end encryption and digital signing to individual messages using PGP-based key management. It isn’t active by default; it must be enabled per user, and users need to generate or import their own key pair before it works. Teams that assume encryption is automatic because their provider is “secure” often discover during a compliance review that OX Guard was never switched on for anyone, meaning sensitive messages went out over standard TLS-in-transit protection only, not end-to-end encrypted.

Standard TLS protects mail in transit between servers, but not from the mailbox provider itself reading message content. At the same time, OX Guard’s encryption keeps message content unreadable to anyone without the recipient’s private key, including the hosting layer. Organizations handling regulated data, health records, financial details, and legal correspondence should treat OX Guard activation as a rollout checklist item, not an optional add-on discovered later. Rolling it out to a pilot group first, before mandating it organization-wide, surfaces key management questions while the stakes are still low.

Anti-Spam Filter Sensitivity Tuning

Leaving anti-spam and anti-virus filtering at default sensitivity is a mistake in both directions: being too permissive lets phishing attempts through, and being too aggressive quarantines legitimate vendor invoices and client replies. Most setup teams never revisit the default after initial configuration. A support team fielding “I never got that email” complaints should check the spam quarantine before assuming a deliverability problem elsewhere, since a surprising number of “lost” emails are sitting in quarantine rather than actually missing.

Tuning filter sensitivity works best as an iterative process: start with the provider’s recommended default, review quarantined mail weekly for the first month, and adjust thresholds based on actual false-positive and false-negative patterns rather than guessing at the right setting up front. Domains that send a high volume of client-facing transactional mail, invoices, appointment confirmations, and password resets benefit from allowing their own frequent senders explicitly rather than relying on filter learning alone. Skipping this tuning period is why some businesses report inconsistent spam filtering months into using the same settings that worked fine at launch.

Shared Calendar and Contacts Permission Errors

Calendar and contact-sharing mistakes tend to surface during onboarding of a second or third team member, when the permission structure that worked fine for one person suddenly needs to differentiate between who can view, who can edit, and who can manage on someone else’s behalf.

CalDAV/CardDAV Sync Layer Misconfiguration

OX App Suite syncs calendars and contacts with external clients via the CalDAV and CardDAV standards, so calendar entries created in OX should appear correctly in any properly configured CalDAV-compatible client. Still, incomplete server URL entries or missing authentication during manual client setup are common sources of one-way sync: changes flow from OX outward but never sync back. This shows up as a calendar that looks correct on desktop but is days out of date in a synced third-party app.

Manually configuring CalDAV/CardDAV in a third-party client requires the full server path, not just the domain, and skipping the specific subpath is the single most common setup error reported for this integration. Testing sync in both directions immediately after setup: create a test event in OX and confirm it appears externally, then reverse. This catches a broken sync configuration before a real meeting gets missed because of it. Teams relying on multiple calendar clients across a mixed device fleet should standardize on one confirmed CalDAV configuration rather than letting each person configure their own from memory.

Shared Calendar Visibility and Edit Rights

OX App Suite separates calendar sharing into distinct visibility and edit permission layers; a colleague can be granted “view free/busy only,” “view full details,” or “edit” independently, and defaulting everyone to full edit access when only visibility was needed is a common oversight that leads to accidental event changes on someone else’s calendar. This granularity is more detailed than a simple shared/not-shared toggle, and setup teams unfamiliar with the distinction often grant more access than intended to make sharing “work.”

The safer default grants free/busy visibility broadly across a team, since that’s usually all scheduling requires, and reserves full edit rights for assistants or shared team calendars specifically designated for collaborative use. Enterprises with executive assistants managing multiple calendars need explicit edit rights, but extending that same access to an entire department as a shortcut creates an unnecessary risk of accidental deletions or double-bookings. Reviewing calendar sharing settings alongside mailbox permission reviews keeps both systems auditable on the same schedule.

Storage Quota and Mailbox Sizing Mistakes

Storage misconfiguration doesn’t cause immediate failures the way DNS or migration mistakes do; it builds quietly until a mailbox hits its limit and starts bouncing inbound mail, often without any warning, reaching the user in time to act.

OX Drive Storage Pooling and Quota Allocation

OX App Suite pools storage across the mailbox and OX Drive file storage under most reseller-provisioned plans, rather than allocating them as entirely separate quotas. This means a user storing large files in Drive can unexpectedly reduce the space available for mail, and vice versa. Setup teams that configure quotas assuming mail and file storage are independent often size mailboxes too tightly once Drive usage grows.

Sizing storage correctly means accounting for both use cases together from the start, not retrofitting a quota increase after someone hits a wall mid-project. Teams that use OX Drive heavily for document collaboration should be sized closer to the upper end of their plan’s available range. At the same time, mail-only users can run comfortably on smaller allocations, and treating every account identically, regardless of actual usage patterns, is a common source of unnecessary requests for quota increases later. Reviewing storage pooling behavior during initial account sizing avoids most of these support tickets before they start.

Bounce-Back Warnings and Quota Monitoring

Mailboxes approaching their storage limit typically trigger a warning threshold before mail starts bouncing. Still, if quota alerts were never configured to notify an administrator, not just the individual user, who may ignore or miss the notice, a full mailbox can silently reject inbound mail for days before anyone with visibility notices the pattern. This is especially common with shared department mailboxes where no single person checks storage warnings as part of their role.

Configuring admin-level quota alerts as part of the initial setup, rather than relying solely on end-user notifications, specifically closes this gap for shared and high-volume mailboxes. A quarterly storage review across all mailboxes, checking which accounts are trending toward their limit rather than waiting for a bounce complaint, catches growth patterns early enough to right-size quotas proactively. Enterprises running large mailbox counts benefit most from this kind of scheduled review, since manual per-user monitoring doesn’t scale past a small team.

Custom Domain and Branding Setup Oversights

Custom domain setup extends beyond the DNS records covered earlier; it also touches admin-level configuration choices that affect how consistently the domain behaves across every mailbox created under it.

Domain Verification Before Mailbox Creation

Creating mailboxes on a custom domain before completing domain verification is a sequencing error that causes mail from those accounts to fail authentication checks, even after DNS records are eventually published correctly, because some verification and provisioning steps must complete in a specific order under the reseller-managed licensing model. Rolling back and re-provisioning mailboxes after the fact takes longer than simply verifying the domain first.

The correct sequence verifies domain ownership, confirms MX and authentication records are live and propagated, and only then begins creating individual mailboxes. This process typically takes under an hour when done in order, but can stretch into days of troubleshooting when mailboxes are created prematurely, and authentication has to be untangled retroactively. Agencies onboarding new client domains under a partner account should treat this sequencing as a fixed checklist step rather than something a technician can reorder for convenience.

Domain-Level Admin Control Consistency

Managing multiple custom domains under a single mailbox-level permission structure without clearly separating domain-level admin rights is a mistake that can lead to an admin scoped to one client’s domain unintentionally viewing or modifying settings on another domain under the same reseller account. This risk is concentrated in agency environments that manage multiple clients, where domain boundaries need to be deliberately enforced rather than assumed.

Assigning domain-specific admin roles rather than account-wide admin access for anyone managing a single client’s domain limits the blast radius if that account is ever compromised or misconfigured. Documenting which admin accounts have cross-domain visibility and auditing that lists them alongside the mailbox permission reviews covered earlier help keep agency-managed multi-domain accounts from drifting into an unintentionally broad access structure over time.

Renewal, Licensing, and Admin Role Misconfiguration

Setup mistakes aren’t limited to the technical rollout; how licensing, renewal terms, and administrative roles are configured at account creation determines how much friction shows up a year later at renewal.

Renewal Pricing and Grace Period Confirmation

Introductory pricing on OX App Suite plans typically differs from renewal pricing, and exact grace period terms for a lapsed or expiring subscription vary by reseller agreement, which is why this detail deserves direct confirmation in writing rather than assumption based on a first-year quote. Businesses that don’t ask about renewal terms up front are sometimes surprised by a price change or a shorter-than-expected grace period when the first renewal cycle arrives.

Getting renewal pricing, proration rules, and grace period length confirmed in writing before signing, not after the first invoice, is the single most effective way to avoid this surprise, and any Authorized Partner should be able to provide these terms clearly on request. Multi-year commitments sometimes lock in renewal pricing more favorably than year-to-year plans. Still, that trade-off only makes sense once the actual numbers are confirmed rather than estimated from marketing pricing pages.

Default Admin Role Over-Assignment at Account Creation

New OX App Suite accounts are frequently set up with a single admin login shared across the whole IT team, or with every early user granted admin rights “to keep things simple” during initial rollout. That shortcut becomes a real liability once the account has been running for months and nobody remembers who has what access or why. Untangling over-assigned admin roles after the fact takes longer than assigning them narrowly from day one.

The better pattern creates individually named admin accounts from the start, even if only one or two people initially need elevated access, so that role assignments remain auditable as the team grows. Reseller-managed licensing accounts that plan to add domains or mailboxes over time should build the admin structure to scale from day one, rather than retrofitting named accounts and permission boundaries after the environment has already grown unwieldy.

Frequently Asked Questions

What should I ask my reseller before signing an OX App Suite contract?

Beyond the headline price, ask for the exact renewal price after the introductory period, the grace period length if payment lapses, whether proration applies when adding mailboxes mid-cycle, and whether pricing is locked for multi-year terms. Ask specifically whether these terms are documented in the contract itself or only quoted verbally, since written confirmation is what protects you at renewal time. Also ask what happens to mailbox data if the account is canceled, how long it’s retained, and whether export tools are provided. A reseller that answers these questions clearly and in writing, without hedging, is generally a safer long-term partner than one that only discusses first-year pricing.

Can I migrate from Microsoft 365 or Google Workspace to OX App Suite without losing calendar invites?

Calendar invites are among the more fragile items in any migration because recurring events, meeting responses, and attendee lists don’t always map cleanly across platforms. The safest approach is to export calendar data in a standard format before migration, verify recurring events specifically after import, since they’re the most common failure point, and manually resend any critical upcoming invites that show signs of incomplete attendee data. Testing the migration with a single non-critical calendar first, before moving executive or shared team calendars, catches formatting issues. At the same time, the stakes are lower than during a live cutover affecting the whole team’s schedule.

Does OX App Suite support Outlook, and are there limitations compared to native use?

OX App Suite connects to Outlook via standard IMAP, POP3, and SMTP protocols, and calendar/contact sync is available through CalDAV/CardDAV connectors. However, Outlook doesn’t natively support CalDAV in some versions without a third-party plugin, a detail often missed during setup. Users expecting the same collaboration features available in OX’s native webmail interface, such as real-time document co-editing links, may find those features less integrated in Outlook specifically. For teams standardized on Outlook, confirming CalDAV plugin compatibility with the specific Outlook version in use before rollout avoids a mid-project surprise about calendar sync.

How many devices can sync to one OX App Suite mailbox at once, and does that affect setup?

There’s no hard device limit tied to protocol design itself, but each connected device or client using IMAP maintains its own sync session, and heavily fragmented setups, a phone, a tablet, a desktop client, and a webmail session all active simultaneously, can occasionally show brief sync delays under high mail volume rather than any actual restriction. For most business users, three to five connected devices sync without noticeable issues. Shared or department mailboxes accessed by many people simultaneously benefit from clearly assigned “owner” access for administrative changes, since simultaneous folder restructuring by multiple users on the same shared mailbox is a more common cause of confusion than the device count itself.

What happens to encrypted OX Guard messages if I switch email providers later?

OX Guard encryption is tied to the PGP key pair generated for that specific account, so messages encrypted under it remain readable only with access to the private key used to encrypt them, regardless of which provider hosts the mailbox afterward. If you migrate away from OX App Suite, exporting your private key beforehand, not just the encrypted messages, is required to retain access to historical encrypted mail on a new platform. Businesses under compliance obligations to retain readable historical correspondence should treat key export as a mandatory step in any offboarding or provider-switch plan, not an optional backup.

Are OX App Suite backups included, or do I need a separate backup solution?

Backup provisions vary by reseller plan, and confirming exactly what’s included, retention length, whether backups cover mailbox data only or also Drive files and calendars, and how restoration requests are handled should happen during initial setup rather than being assumed. Some plans include baseline retention sufficient to recover from accidental deletion within a short window. In contrast, businesses with longer compliance-driven retention requirements often need a supplemental third-party backup solution regardless of what’s built into the hosting plan. Asking your reseller for the specific retention window in writing avoids relying on an assumption that turns out to be shorter than your actual business need.

Can I use OX App Suite with a custom domain I already own, or do I need a new one?

Existing domains work with OX App Suite without needing to purchase a new one. The setup process verifies ownership of your existing domain and then updates its DNS records to point mail to the new environment, rather than requiring domain re-registration. The main consideration is DNS access: you need administrative control over your domain’s DNS zone, whether it’s managed through your domain registrar or a separate DNS provider, because MX, SPF, and DKIM records must be added or updated there. If your domain’s DNS is managed by a previous host who is uncooperative about access, that access issue, not OX App Suite itself, is typically the actual blocker to a smooth setup.

How long does a typical OX App Suite migration take for a small business?

For a business with under 20 mailboxes and no unusually large mail archives, a well-sequenced migration, domain verification, mailbox provisioning, data transfer, and DNS cutover typically completes within one to three business days, with most of the time spent on data transfer rather than active administrative work. Businesses with mailboxes containing several gigabytes of historical mail per user, or with complex folder structures built over many years, should expect data transfer to take longer, sometimes stretching the process to a week. Rushing a larger migration to meet an artificial one-day deadline is more likely to produce the exact folder-mapping and duplication errors covered earlier than a properly paced multi-day window would.

Is OX App Suite suitable for a solo consultant, or is it better suited to larger teams?

OX App Suite scales down reasonably well for a solo consultant who mainly needs professional email on a custom domain. However, the collaboration features, shared calendars, document co-editing, and granular permission structures are underused at that scale and represent capabilities a single user isn’t paying to leverage fully. Solo consultants who anticipate hiring within the next year benefit from starting on OX App Suite early since the collaboration infrastructure is already in place when a second person joins, rather than migrating later. For a certain consultant, they’ll remain solo; a simpler single-user email plan may be more cost-effective, and that trade-off is worth discussing directly with a reseller before committing to a multi-user platform.

What’s the most common security mistake businesses make in the first month after OX App Suite setup?

The most common gap is leaving two-factor authentication optional rather than enforced account-wide, which means adoption depends entirely on individual users remembering to turn it on. In practice, a meaningful percentage never do until prompted. The second most common gap, covered in more detail earlier regarding OX Guard, is assuming encryption is automatic when it actually requires per-user activation. Enforcing two-factor authentication as a mandatory account-wide policy during initial rollout, rather than leaving it as an opt-in recommendation communicated once in an onboarding email, closes the largest and most avoidable security gap in the first month.

Glossary

MX Record: A DNS entry that specifies which mail server receives inbound email for a domain, including priority order for failover.

SPF (Sender Policy Framework): A DNS TXT record listing servers authorized to send mail on behalf of a domain, used to prevent spoofing.

DKIM (DomainKeys Identified Mail): A cryptographic signing standard that verifies an email wasn’t altered in transit and confirms it came from an authorized sending domain.

DMARC (Domain-based Message Authentication, Reporting and Conformance): A policy layer built on SPF and DKIM that tells receiving servers what to do when authentication checks fail, and provides reporting on authentication activity.

IMAP (Internet Message Access Protocol): A mail retrieval protocol that keeps messages synchronized across multiple connected devices.

POP3 (Post Office Protocol 3): A mail retrieval protocol that downloads messages to a single device, without keeping other devices in sync.

SMTP (Simple Mail Transfer Protocol): The protocol used to send outbound mail between servers and from clients to a mail server.

TLS (Transport Layer Security): An encryption protocol that protects data, including email, while it’s in transit between servers.

CalDAV / CardDAV: Standard protocols used to sync calendar and contact data between a mail server and external client applications.

OX Guard: An OX App Suite feature that adds end-to-end PGP-based encryption and digital signing to individual email messages.

OX Drive, OX App Suite’s integrated file storage and document collaboration component, which typically pools storage capacity with the mailbox.