Business Email

Business email is mailbox service on a domain the organization owns, used by its people. At Novatelia that means domain mail: setup, an agreed migration, authentication records, administration, and a backup method when one is required.

It is an address at the organization’s own domain, delivered to a mailbox on the platform the design names, rather than a consumer mailbox the company does not control.

The organization confirms domain and DNS control, chooses Microsoft 365, Google Workspace, or a named host, and agrees mailboxes, authentication records, and a cutover. Novatelia prepares the values and verifies them with the domain owner. Prices are not listed on this page.

Yes, within an agreed scope: mailboxes, migration from the system the customer is leaving, and the DNS records the domain owner publishes. The domain remains the customer’s.

The customer owns the domain and the mail environment. Novatelia does not take ownership by configuring it.

MX for inbound delivery, SPF for the sending infrastructure, DKIM signing for those senders, and a DMARC policy the domain owner accepts. The exact values come from the platform. Examples on this page are illustrative and are not a customer zone.

An MX record identifies the preferred mail exchangers for incoming mail. It does not authenticate senders.

SPF is the Sender Policy Framework. It publishes authorized sending infrastructure for the domain identity SPF evaluates. It is not a universal allow-list of visible From addresses, and it does not by itself establish DMARC alignment.

DKIM is DomainKeys Identified Mail. A cryptographic signature, published through a selector, supports authentication and an integrity check of the signed content. A valid signature does not prove the message is benign.

DMARC checks whether SPF or DKIM results align with the visible From domain and applies the domain’s policy: none, quarantine, or reject. The domain owner publishes the policy.

MX directs where inbound mail is delivered. SPF declares which infrastructure may send for the SPF identity. They answer different questions and both can be required.

SPF and DKIM produce authentication results. DMARC looks for alignment of those results with the visible From domain and applies the policy. All three are configured for the services that actually send. Together they do not eliminate spoofing, spam, phishing, or every deliverability problem.

No. DMARC helps receivers apply the domain owner’s policy to unaligned mail. It does not stop every phishing message, including messages that do not spoof the organization’s exact domain.

None asks receivers to report or take no policy action. Quarantine asks them to treat failing mail with suspicion, often as junk. Reject asks them to refuse it. The domain owner chooses, usually after monitoring.

No. Rejection is unsafe until legitimate senders authenticate and align. The published approach starts where monitoring is safer than rejection.

Yes. An incorrect MX can send inbound mail to the wrong host or to none. An incorrect SPF, DKIM, or DMARC policy can cause legitimate mail to be rejected. Records are checked against the platform’s values before cutover.

No. The party who controls the zone publishes MX, SPF, DKIM, and DMARC. Novatelia supplies the values and verifies them.

Mail can be migrated from the agreed source when the tool and the permissions support it. The scope is the inventory. Fidelity depends on the source and the target.

Hosting mail can be a source for Microsoft 365 when the migration method supports that host. The result is validated for the mailboxes in scope. It is not assumed for every control panel.

Google Workspace can be the target when the source method supports the mail in scope. The move is specified for that account. It is not automatic.

Calendars migrate when the source can export them and the target can accept them. Calendar migration is conditional. Not every calendar object is promised.

No. The cutover is planned inside an agreed window. DNS changes propagate according to TTL and resolver behavior. An interruption-free cutover is not promised, and zero data loss is not promised.

An alias is an additional address that delivers to an existing mailbox. It does not create a separate store or a separate sign-in.

A shared mailbox is a mailbox that several authorized people can open, subject to the platform’s license and permission model. Access to the mailbox and permission to send as it are different grants.

A distribution group sends a message to its members. It is not a mailbox, unless the platform also provides a separate shared mailbox that was explicitly created.

A shared mailbox has its own store and delegated access. An alias is only an extra address on a mailbox. A distribution group is a third object: it expands to recipients.

The platform can classify spam, use sender reputation, check authentication, quarantine suspicious mail, and let users report messages, where those controls exist. Administrators review what the policy quarantined. Legitimate mail can still be quarantined, and malicious mail can still arrive.

No. Filtering reduces unwanted mail. It does not promise an empty junk folder.

MFA where the platform offers it, administrative roles, account lifecycle, authentication policy, and careful delegation on shared mailboxes. Platforms do not all offer the same controls. Suspicious sign-in handling follows the platform’s own signals. This page does not provide a sign-in form.

No. Which mail platform is required? The platform is chosen in the design. Microsoft 365 and Google Workspace are the published productivity options. Another host is used only when the requirement names it.

No. Google Workspace is one published option. It is chosen when the design selects it. It is not mandatory.

No. A live mailbox, a synchronized copy, native retention, and an independent backup are different. A backup is selected when a copy outside the live mailbox is required, and a restore is tested only when that test is in scope.

Business email is human communication through company mailboxes. Transactional email is application-generated mail such as receipts and system notices, with its own sending infrastructure, reputation, and volume. An ordinary mailbox service is not treated as suitable for unrestricted bulk application mail.

Where the scope includes them: domain and DNS notes, the platform, the mailbox and alias inventory, shared access, routing, SPF, DKIM, DMARC, migration exceptions, the backup decision, administrator roles, and cutover notes. Passwords and mailbox contents are not published. Not every project includes every item.

Open the RFQ draft or contact Novatelia. An RFQ saves a browser draft. It does not publish a mailbox price, partner status or quotation reference.