Qboxmail: email domains, mailboxes, and aliases

What the integration manages

Qboxmail connects the ISP contract with CRM: it imports or creates domains, assigns them to customers, maintains mailboxes and aliases, and makes each domain sellable as a service instance. The local copy supports search and billing, while Qboxmail remains authoritative for remote state.

The domain is the container. Configure and verify it before creating mailboxes and aliases, and never create duplicates to bypass a failed synchronization.

API configuration

Under Settings → Qboxmail, enter the complete API base ending in /api and the token generated in Qboxmail. Production normally uses https://api.qboxmail.com/api; a sandbox requires both sandbox URL and sandbox token.

Store the token as a secret and keep it out of screenshots and support messages. Diagnose environment, missing /api, token validity, and reachability before changing customer resources.

Import, create, and assign a domain

Synchronize imports contract domains and refreshes the local copy. Assign an imported domain to the correct CRM customer. To create one, select customer, enter the name without www, choose the purchased plan, and set and confirm the Postmaster password.

Verify ownership, spelling, plan, and customer before creation. CRM assignment is required to link the domain to a service and expose it to the correct account holder.

DNS, verification, and lifecycle

Domain detail exposes the ownership, MX, and related records required by Qboxmail. Publish each type, name, and value exactly in the authoritative DNS zone, wait for propagation, and select Verify.

Ownership validation is separate from working mail delivery: verify MX and all provider records, then test send and receive. Disable and re-enable change remote availability. Delete only after backup, commercial termination, and review of every mailbox and alias.

Mailboxes and synchronization

Open Mailboxes from domain detail. The table lists address, remote code, and state; synchronization rereads Qboxmail accounts, and the page can perform a controlled refresh when local data is stale.

Create a mailbox with local part, first name, last name, unique confirmed password, and quota where the plan supports it. Send credentials securely and never reuse the Postmaster password. Disable preserves the account; Delete removes it and requires prior retention review.

Aliases

An alias receives mail without owning a mailbox and forwards to one or more destinations. Create it from domain detail or from a mailbox action that preselects the destination. Enter a valid alias name and authorized destinations, then synchronize and test.

Editing and deletion act remotely. Prevent forwarding loops, typing errors, and unauthorized external destinations; repeat a real delivery test after every change.

Service link and Customer Area

The Qboxmail service-specific field selects an available compatible domain. After assignment, technical domain and commercial service must belong to the same CRM customer.

Customer Area can show state and DNS information, request synchronization and verification, change passwords for owned mailboxes, and create, edit, or delete aliases for the linked domain. Tenant and ownership checks must prevent access to any other customer’s domain.

Checks and common problems

If data is missing, synchronize the correct level: domains first, then mailboxes or aliases for one domain. If DNS verification fails, query authoritative nameservers and wait for TTL rather than changing values repeatedly. If a mailbox does not receive, separate account state, quota, MX, propagation, and spam filtering.

• Match API URL and token environment
• Protect token and Postmaster password
• Synchronize before creating
• Assign the correct CRM customer
• Publish every required DNS record
• Verify ownership and mail delivery separately
• Use secure passwords and suitable quotas
• Check alias destinations and loops
• Link the correct service instance
• Test sending and receiving
• Retain required data before deletion