Professional email on your domain: leave @gmail behind

An address such as sales@yourcompany.com gives customers a consistent way to reach your business. It also lets your organization manage addresses independently of a particular employee’s personal account.

That continuity depends on more than the address. Your business needs control of the domain, access to email administration, and a procedure for handling staff changes. This guide explains what to prepare, which settings matter, and how to test a new service before relying on it.

Keep business communication under business control

Email on your own domain can help organize customer conversations and maintain recognizable addresses as your team changes.

Business need	Practical approach
A consistent public address	Use a role address such as sales@ or accounts@, with responsibility assigned to the appropriate staff
Individual accountability	Give staff their own accounts rather than sharing passwords
Staff continuity	Document how access is revoked and business correspondence is retained or reassigned
Provider changes	Keep control of the domain and plan how existing messages will be moved

A domain-based address does not automatically give your organization control of the mailbox. Keep the registrar and email administration accounts under business control, with authorized recovery contacts and documented access.

For role addresses, ask whether the service uses a mailbox, alias, group, or shared-access feature. These options behave differently; an alias alone is not a separate inbox.

Understand the domain, DNS, and mailbox responsibilities

You can register a domain, host a website, and operate email with different providers. The arrangement works when the settings and responsibilities are clear.

Component	Its role
Domain registration	Keeps the domain registered to your organization or designated registrant
DNS hosting	Publishes the records that direct website and email traffic
MX records	Tell sending mail systems where to deliver incoming messages
Email service	Provides the mailboxes and the settings used to access and send mail
Email application	Lets a person read and send messages through the configured service

MX records direct incoming delivery. They do not create mailboxes or authorize every system that sends messages using your domain.

Changing email providers does not normally require transferring the domain registration or moving the website. In many cases, you can update the relevant records at the existing DNS provider.

If your activation instructions require CR Servers nameservers, confirm the exact settings before changing them: ns1.crservers.net, ns2.crservers.net, and ns3.crservers.net. Nameservers are not MX destinations. A nameserver change affects the domain’s DNS management, so preserve the records needed by the website and other services.

For the registration side, read the guide to domain registration in Costa Rica.

Set up mailboxes and authenticate outgoing mail

Before changing delivery records, list the addresses your business uses. Include individual accounts, public role addresses, aliases, and addresses configured in forms or billing tools.

Create the required accounts at the new service and confirm storage limits, access methods, and administration responsibilities. Use unique passwords and enable multifactor authentication where supported.

Then review these settings with the email provider:

• MX: publish the destinations and priorities supplied for your service.
• SPF: identify the systems that send mail for your domain, including approved external tools, and use their documented configuration.
• DKIM: where supported, enable message signing and publish the DNS record supplied by the sending service.
• DMARC: review authentication alignment and reporting before applying a policy that could reject legitimate messages.

SPF and DKIM serve different purposes. Google’s documentation explains SPF sender authorization and DKIM signing. Use the instructions for your actual email service rather than copying another provider’s records.

Authentication helps receiving systems assess messages. It does not guarantee inbox placement. Incorrect configuration can also affect legitimate mail, so include website forms, invoicing systems, and other senders in your checks.

Plan the migration separately from the DNS change

Changing MX records redirects incoming mail as DNS caches update. It does not copy old messages, contacts, calendars, or settings to the new service.

Before switching:

1. Inventory existing data and addresses. Record accounts, aliases, forwarding rules, mailbox sizes, and any data that needs separate export.
2. Confirm the migration method. Establish what can be transferred, who performs the work, and what will remain outside the mailbox migration.
3. Preserve recovery copies. Retain appropriate exports or backups before making changes.
4. Prepare staff devices. Confirm supported connection settings and how each person will sign in.
5. Agree on the transition period. Keep access to the previous service while verifying delivery and any remaining data transfer.

Do not assume that keeping old and new MX destinations together will duplicate messages to both services. Follow the migration design agreed with the provider.

Test both delivery and daily use

Before updating signatures or closing the previous service, complete a short acceptance test:

• Send a message from an external account to each important business address.
• Reply and confirm that the recipient sees the intended sender and reply address.
• Send new messages to more than one external mail service.
• Check spam folders, rejection notices, and authentication results.
• Test aliases, role addresses, attachments, and staff devices.
• Test website forms and any system that sends invoices or notifications.
• Confirm that required historical messages are accessible.

Repeat checks during the transition. Record problems with timestamps and relevant error messages, without sharing passwords or unnecessary message contents.

Frequently asked questions

Can I use Gmail with an address on my domain?

Distinguish the service from the application. A free @gmail.com account is different from an organization-managed Google Workspace account using a custom domain.

An email application may also access an account hosted elsewhere if it supports that service’s connection methods. Seeing a familiar interface does not establish where the mailbox is hosted or who controls its administration.

Is forwarding to a personal inbox the same as a business mailbox?

No. Forwarding redirects incoming messages; it does not by itself provide a separately managed mailbox, staff access controls, or correctly configured outgoing mail. Check where messages are stored and how replies are sent.

Do the website and email have to use the same provider?

No. Using one provider may simplify coordination, but separate providers can work well. The important points are knowing who manages DNS and ensuring that the website and mail records remain correct.

What happens when an employee leaves?

Follow your organization’s access and retention procedures. Revoke the person’s access, review connected devices and forwarding rules, and arrange continued handling of business correspondence through authorized accounts. A domain address alone does not perform these steps.

What should I confirm about invoices and support?

Ask which billing details, payment methods, support languages, and service hours apply to the proposed email service. Confirm what assistance is included for setup and migration.

Choose email around your business requirements

Review CR Servers professional email options with your address list, storage needs, and migration requirements. Confirm the supported authentication settings and the responsibilities for setup before changing delivery records.

If the mailbox will also be used for a Costa Rican company’s registered email, review the separate guide to corporate email and the Registro Nacional.