To connect a company domain to business email, verify control of the domain, prepare the receiving accounts, publish the provider’s required routing records and configure the relevant sending authentication. These steps serve different purposes. A domain verification record does not route mail, and an MX change does not prove that outgoing messages authenticate correctly.
Google Workspace’s official guides separately describe MX, SPF and DKIM configuration. Use the values applicable to the actual provider and sending systems. This article explains the workflow and evidence to retain; it does not authorise a live DNS change or promise uninterrupted delivery. Google MX setup, SPF setup, DKIM setup.
What is the difference between a domain and an email address?
The domain is the part the business controls after the address separator, while a mailbox or supported alias defines how a particular address is handled by the mail service. Registering the domain does not automatically create every address the business intends to use.
Prepare an address inventory before changing routing. Include personal mailboxes, shared enquiry addresses, aliases and administrative contacts. Record who owns each destination and how messages will be monitored after the change.
Also identify systems that send using the domain: website forms, applications and campaign tools. The incoming-mail provider may not be the only authorised sender. A correct inbox migration can still leave outgoing application mail misconfigured if those services are overlooked.
Which DNS records do different jobs?
| Record or action | Purpose in the workflow | Evidence to inspect |
|---|---|---|
| Domain verification | Establish authorised control for the provider | Provider confirms the correct domain |
| MX | Direct incoming mail to receiving servers | Published routing matches the intended service |
| SPF | Describe relevant authorised sending systems | Current sender inventory and provider instructions |
| DKIM | Sign outgoing mail using a private key and publish the public key | Published selector and observed authenticated message |
| Service activation | Enable the provider’s mail service | Required users can actually receive and send |
This table is an editorial explanation of distinct responsibilities. It is not a universal record set to paste into DNS. The correct values depend on the domain, provider and systems in use.
How should incoming mail be prepared?
Google explains that senders look up the domain’s MX records to determine where mail should be delivered. Its setup also requires activating Gmail and verifying domain ownership. These are separate checks rather than one interchangeable setting.
Retain the current DNS configuration before changing it. Identify old receiving records and the intended new route. Follow the provider’s applicable migration instructions rather than deleting records without understanding their function.
Google continues to support documented legacy MX values for existing working setups. Do not change a working configuration simply because an older value looks different from the current example. First establish whether there is a genuine requirement to change it. MX instructions and legacy qualification.
How should SPF reflect the actual senders?
Start from the sending-system inventory. The Google guide includes examples for different combinations of sending services. That illustrates why a record copied from a single-provider tutorial can be incomplete for a business with several legitimate senders.
Use each provider’s current instructions and inspect the existing DNS before proposing a change. Do not add disconnected snippets until the zone contains an unexplained collection of records. The business needs a coherent understanding of which services are authorised to send.
This guide does not invent a universal numerical limit or promise that SPF alone prevents impersonation. It identifies a configuration task that must be checked against the actual sender arrangement. Retain a record of why each sending service is included and who can authorise future changes.
What does DKIM add?
Google describes a public key in the domain’s DNS and a private key used by the sending system to sign messages. Receiving servers use the public key to authenticate the signature. Publishing the record and enabling signing are therefore related but distinct steps.
The guide also warns that outbound gateway changes can interfere with DKIM. If a system adds content after signing, investigate the actual message path rather than assuming the DNS record is the only possible cause of an authentication problem.
Use the selector and key generated for the actual service. Do not place private keys in a project brief or public ticket. The DNS publication uses the public portion; the private signing material belongs in the authorised sending configuration. DKIM setup and gateway considerations.
An original mail cutover evidence record
Complete this record before and after an authorised change:
Domain control: registrar, DNS service and authorised administrator.
Receiving scope: required addresses and prepared destinations.
Sending scope: staff mail, website forms, applications and campaign systems.
Previous state: retained DNS and active service configuration.
Proposed state: provider-specific values and the reason for each change.
Verification: ownership result and published record observations.
Inbound test: external sender, intended recipient and actual delivery result.
Outbound test: sending system, reply identity and observed authentication result.
Historical data: migration scope checked separately from new-message delivery.
Recovery: unresolved differences, responsible role and route back where appropriate.
The record is an original operational aid. It does not establish success by itself; fill it with actual observations and retain evidence of failures as well as successes.
What should be tested beyond a personal inbox?
Test customer-facing shared addresses, website submissions and application notifications using controlled destinations. Confirm that replies return to a monitored address and that the sender identity remains appropriate to the business.
A newly received test message proves a narrower result than complete migration. Historical folders, contacts and calendars need their own verification against the agreed scope. Likewise, one successful sender does not demonstrate every application using the domain is configured correctly.
Keep the old and new evidence available while discrepancies are resolved. Do not erase the previous configuration merely because the new inbox opens successfully.
Discuss the setup through Spout’s business email service or start an enquiry with the address inventory and evidence record.
For each sending application, retain a controlled test message with its observed authentication result. A staff mailbox test does not establish the same result for a website or campaign service. Compare the actual sending path and current records before deciding which configuration requires correction.
Confirm the domain custodian can maintain the DNS records required by the chosen mail service.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.