Why use a mailbox on your own domain?
A mailbox such as [email protected] can give a team a consistent contact address for platform accounts, billing notices, support requests and internal work. The domain is the part after the @; the mail host is the service that receives and stores messages. These are separate pieces, and controlling one does not automatically mean controlling the other.
For a media-buying team, email is also part of account operations. A platform account may use an address for sign-in, notices or recovery, depending on the platform and its policies. Keeping that address available and monitored helps the team respond to legitimate requests and manage access. It does not replace compliance with platform rules, identity checks or account-security requirements.
An own-domain setup offers more control over addresses and the ability to change mail hosts without changing the domain itself. That control comes with ongoing responsibility: the domain must remain renewed, its configuration must stay in order, and someone must be accountable for the mail service and recovery process.
Choose a mail host before creating addresses
A mail host provides the service that handles the team’s mail. Options include business email services such as Google Workspace, Microsoft’s business suite or Zoho Mail, as well as email included with some web-hosting plans. Compare them by looking at administration tools, security options, support, reliability information, data-handling terms and how well the service fits the team’s existing workflow.
Do not choose solely on the basis of familiarity or the fact that a service is bundled with something else. Consider who will manage accounts when a team member leaves, how access can be recovered, and whether the service supports the team’s preferred approach to shared addresses. Review the provider’s current documentation and terms before committing; capabilities and conditions can change.
Keep the domain registrar and mail host distinct in your planning, even if one company provides both. The registrar manages the domain registration, while the mail host handles email. Knowing which provider controls each part makes support requests and handovers less confusing. Record the provider names, administrative contacts and account-recovery route in a secure internal system, not in a mailbox that depends on the same domain.
Decide who owns and administers the setup
The team should be able to identify the person or business entity that controls the domain registration and the mail-host account. Where possible, use organizational contact details and accounts rather than tying essential services to one employee’s personal inbox. Keep account ownership consistent with the business’s actual structure and with the requirements of the relevant providers.
Assign clear responsibilities. A domain administrator handles registration, renewal and registrar access. A mail administrator manages users, aliases, security settings and service access. In a small team, one person may perform both roles, but the responsibilities should still be documented, with a trusted backup who can take over if needed.
Use individual administrator identities where the provider supports them, rather than sharing one password among the team. Protect administrator access with available security measures, and store recovery information in an approved password manager or other controlled system. Limit administrative privileges to people who need them. When someone changes roles or leaves, review access promptly and transfer responsibilities through the provider’s supported processes.
If the domain or mailbox service is received from a seller or another team, treat the handover as a transfer of control, not merely a delivery of login details. Confirm who owns the domain, who can contact the registrar and mail host, and whether the business has authorized access. Put the agreed scope and responsibilities in writing. Do not rely on access that the previous holder can quietly revoke.
Create mailboxes and aliases with a purpose
A mailbox is an account that can sign in and receive messages directly. An alias is an additional address that routes mail to an existing mailbox, usually without being a separate sign-in account. The distinction matters: a team may want named mailboxes for staff who handle account operations, while using role-based addresses such as billing@ or support@ as aliases or shared mail destinations.
Plan addresses around real responsibilities. A platform account should have a designated owner or team role, and the associated email should be monitored by someone authorized to manage that account. Avoid making one person’s personal address the only route for business-critical notices. At the same time, do not create shared access in a way that makes accountability unclear or conflicts with a platform’s requirements for individual users.
Keep the address list small enough to maintain. Document what each address is for, where it delivers mail, who monitors it and who can change its routing. When an employee leaves or a role changes, update the mailbox or alias deliberately. Do not assume that forwarding continues indefinitely or that every service treats aliases as separate identities; check the mail provider’s guidance and the platform’s own rules.
Configure DNS and test delivery
The domain’s DNS settings tell other systems where to send mail and help establish that outgoing messages are authorized. The exact configuration depends on the mail host. Because DNS mistakes can interrupt delivery or affect trust in messages, use the provider’s current setup instructions and make changes through the account that controls the domain’s DNS.
This guide does not explain individual DNS records. Refer to the site’s existing DNS articles for a fuller explanation of DNS concepts and record management. Before changing anything, identify which provider is authoritative for the domain’s DNS and make sure the person doing the work has appropriate access. Avoid copying settings from an unrelated domain or relying on old notes without checking them against the mail host’s current instructions.
After setup, test the addresses in both directions: send and receive messages, check that role-based aliases reach the intended destination, and verify that administrators can access the service. Test from outside the organization as well as within it. If delivery fails, check the mail host’s status and configuration guidance, and confirm that the DNS changes are published as expected. Keep a record of the working setup and of who is responsible for future changes.
Protect continuity and keep records current
A mailbox is useful only if the team can still reach it. Review who has access, whether recovery methods remain valid and whether messages are being monitored. Keep recovery routes independent where practical: if the only way to regain access to the mail host is an address on the same domain, a domain problem can become a circular recovery problem.
Maintain a simple operational record containing the registrar, mail host, DNS administrator, renewal responsibility, authorized administrators and the purpose of each address. Store it securely and keep it current. Do not place the only copy inside the mailbox system it describes. A protected business document or password-management system can provide a separate reference point.
Changes deserve a basic handover. When a provider, administrator or address changes, update the records and confirm that the new arrangement works. Review the team’s platform accounts as part of that process: make sure each account has an approved, monitored contact address and that access changes follow the platform’s procedures. Avoid changing addresses casually, especially when they are used for sign-in or recovery.
Treat domain renewal as account security
A domain is registered for a term and must be renewed to remain under the team’s control. Assign a named role to monitor renewal notices and confirm that the registrar’s contact details and payment arrangements are current. Do not assume that a reminder sent to an address on the domain will be useful if the mail service is already unavailable.
A lapsed domain can create a serious chain of problems. The team may lose control of the addresses at that domain, making it harder to receive password resets, security alerts or administrative messages for accounts that use them. If another party later obtains the domain, they may be able to receive mail sent to those addresses. The team could then face both account-recovery difficulties and risks to services that still trust the old email address.
The exact consequences depend on the registrar, mail host and each platform’s recovery and verification processes. Do not assume that a platform will restore access simply because the team previously controlled the domain. Keep domain ownership and renewal details under organizational control, and ensure more than one authorized person knows how to reach the registrar through an independent route.
Plan for a domain or mail-host failure
Prepare for disruption before it happens. Decide who will contact the registrar and mail host, where the team’s records are stored, and how account owners will identify services tied to the affected domain. Maintain an inventory of important platform accounts and their registered contact addresses, but store it securely because it is sensitive operational information.
If the domain is lost or the mail host becomes unavailable, use the providers’ official recovery and support processes. Contact the registrar and mail host through channels that do not depend on the affected mailbox. For platform accounts, follow each platform’s own account-recovery procedure and provide information through its approved channels. Do not try to bypass verification or use someone else’s identity.
An own-domain mailbox can make a team’s setup more manageable, but it does not remove dependency. It shifts responsibility to the team to maintain the domain, service access, DNS configuration and recovery plan. Treat the address as part of the account’s working infrastructure: assign ownership, document the setup, monitor it and plan for the possibility that the domain or service may not always be available.