How to Set Up Domain Email in Outlook 365

By /

The most popular advice about setting up domain email in Outlook 365 is also the most misleading: enter your address, type your password, and start sending. That only connects an app to an account. It doesn’t prove that your business owns the domain, route incoming messages correctly, protect outgoing mail from spoofing, or preserve the website, booking system and older email service already using that domain.

For an Australian small business or home office, the safe approach is a controlled migration. You’ll verify identity, audit DNS, prepare mailboxes, test delivery, change routing, and secure every account before staff rely on the new setup. The same careful process also prevents avoidable disruption for home users who need practical assistance with computer repair, WiFi, printers, laptops or email on everyday devices.

Table of Contents

Why Email Setup is a DNS Project Not Just a Login

Outlook is the visible part of the service, but Microsoft 365 domain email is controlled by DNS. DNS records tell the internet where to deliver messages, which services may send on your behalf, and whether Microsoft can confirm that you control the domain. The Outlook desktop application just connects to the Exchange Online mailbox once those foundations are in place.

For a business using name@company.com.au, the process starts in the Microsoft 365 admin centre, not in Outlook on a Windows computer. An administrator adds the custom domain, verifies ownership, selects the email services, and authorises the domain at the registrar. Microsoft recommends adding the domain before creating users, because creating accounts first can leave you configuring those accounts twice. The temporary onmicrosoft.com address is a staging identity, not the professional address customers should use.

Practical rule: Confirm domain ownership first, create mailboxes second, and configure Outlook clients last.

That order matters for a local business whose domain may also support a website, contact form, booking platform or accounting system. A careless DNS change can leave the website online but send customer enquiries to an old mailbox, or it can route mail to Microsoft 365 before the new users are ready. Review domain name registration and management before changing records if you’re unsure who controls the registrar account.

Microsoft’s Australian workflow uses Setup → Get your custom domain set up → Get Started → Add domain. Administrators can also use Settings → Domains → Add domain. The business’s .com.au domain follows the same Microsoft 365 process as other regions, but the registrar and DNS provider still control the records, so you’ll need access to both systems.

The key decision is whether you’re making a clean move or working around existing services. If the domain has only one old mailbox, the migration may be straightforward. If it supports website forms, scanners, a CRM and a legacy mail provider, manual review is safer than accepting every automatic wizard change.

Preparing Your Domain and Microsoft 365 Admin Centre

Before touching DNS, establish who owns the domain and what currently depends on it. Sign in to the Microsoft 365 admin centre with an administrator account, then open Setup, choose Get your custom domain set up, select Get Started, and choose Add domain. The alternative path is Settings, Domains, then Add domain.

Microsoft will provide a verification TXT record. Add that record at the registrar or DNS host, then return to Microsoft 365 and complete verification. DNS is managed where the domain’s DNS hosting lives, not inside Outlook, and not necessarily at the company that designed the website.

An illustration showing a person configuring a domain and setting up a Microsoft 365 admin account.

Build an inventory before the switch

Export or record the existing DNS entries before making changes. Pay particular attention to:

  • Website records: Preserve the A and CNAME records that keep the website, subdomains and hosted services working.
  • Current mail routing: Record the existing MX records and identify the provider currently receiving mail.
  • Sending services: List website forms, scanners, accounting platforms, CRMs, newsletters and booking systems that send from the domain.
  • Addresses: Prepare every user mailbox, alias, shared address and catch-all arrangement that customers or suppliers use.
  • Historical mail: Decide whether older messages need to be migrated, archived or retained at the previous provider.

Creating users after verification gives you a clean list of mailboxes to license and test. It also prevents a common failure where the domain changes after accounts were created with the temporary Microsoft address, forcing users to be reconfigured.

Keep the old DNS information in a dated backup. Don’t delete unrelated website records just because Microsoft presents a list of recommended entries. The correct migration changes mail-related records while leaving web, verification and third-party service records intact.

Configuring MX and Authentication Records Safely

The MX record controls where incoming mail goes. Microsoft 365 displays the domain-specific destination in the admin centre. Copy that value exactly, use the host or name expected by the registrar, and remove older MX records only after the Microsoft 365 mailbox environment is ready. Microsoft recommends a TTL of 3600 seconds, or the registrar’s default, and the new MX record normally receives the highest available priority, commonly 0. The exact destination must come from your tenant, not from a guessed example.

An MX change doesn’t alter the website, but deleting the wrong A or CNAME record can. It can also expose a gap if invoices or customer enquiries arrive after mail begins routing to Microsoft 365 but before the corresponding mailbox exists. For broader context, see what an email hosting service does.

Treat authentication as a set

SPF lists authorised sending services. Microsoft’s documented Microsoft 365-only value is v=spf1 include:spf.protection.outlook.com -all. Publish one SPF TXT record for the domain. If a website form, scanner, accounting platform or CRM also sends mail, merge its authorised service into that same record. Never create a second SPF record, and don’t apply a hard failure policy until every legitimate sender has been identified.

DKIM adds a cryptographic signature to outgoing messages. Microsoft 365 supplies two selector-specific CNAME records. Publish both at the registrar, wait for them to resolve, and then enable DKIM in Microsoft 365. A missing or incorrect CNAME is a common reason DKIM fails.

DMARC checks whether SPF or DKIM aligns with the visible From domain. Create the TXT record at _dmarc.yourdomain, enable reporting, and begin with monitoring or quarantine while you identify legitimate senders. Once the reports show that genuine business systems pass, move towards a reject policy. Microsoft’s example enforcement value is v=DMARC1; p=reject, but applying rejection too early can block real booking confirmations or invoices.

A successful send test isn’t proof of a safe migration. It only proves that one message travelled. Authentication testing must also confirm who was allowed to send it.

Stage the work in this order: verify the domain, prepare mailboxes, review DNS, configure SPF, publish DKIM records, then introduce DMARC monitoring. Test from independent Gmail and Outlook.com accounts and inspect the full headers for aligned spf=pass, dkim=pass and dmarc=pass. Review aggregate DMARC reports through a complete operating cycle before enforcing rejection.

Executing the Cutover and Connecting Outlook Clients

Once the domain is verified and the mailboxes are prepared, schedule the cutover when someone can monitor delivery. Avoid changing MX late in the day before a busy trading period. DNS changes aren’t instantaneous, and different receiving systems may continue using cached records for a while.

Create the user mailboxes, assign the appropriate Microsoft 365 licences, and confirm each address exists before changing mail routing. Test internal delivery in Outlook on the web, then send to independent external accounts and reply back. Outlook on the web is the cleanest test because it separates mailbox and DNS problems from desktop-profile problems.

A controlled client rollout

After the new MX record is active and external delivery works, connect user devices:

  1. Outlook on the web: Confirm sending, receiving, folders, aliases and shared addresses.
  2. Outlook desktop: Add the Microsoft 365 account through the normal account setup. Let modern authentication and autodiscover provide the service settings rather than entering a guessed server name.
  3. Mobile devices: Add the account through the Outlook mobile app, approve the Microsoft sign-in prompt, and verify calendar and mailbox access where those services are included.
  4. Operational checks: Send a test invoice, website enquiry and appointment confirmation if those systems are part of the business workflow.

If autodiscover isn’t resolving correctly, check the Microsoft-provided DNS records and confirm that the device isn’t retaining an old Outlook profile. Don’t repeatedly delete and recreate profiles before proving that DNS and the mailbox are correct. That can hide the underlying problem and make historical mail harder to locate.

Keep a short migration log with the time of the DNS change, test addresses, failed messages and affected devices. That record helps distinguish propagation from configuration errors and gives a technician enough information to troubleshoot without repeating every step.

Securing Your Mailboxes Against Phishing and Fraud

An Outlook connection is not a security control. A mailbox can send and receive normally while the domain lacks DKIM, DMARC alignment, administrator separation or reliable account recovery. Small offices are especially exposed when one person uses a global administrator account for daily email and every device shares the same weak sign-in habits.

The Australian Signals Directorate found that phishing accounted for 74% of reported cybercrime incidents and 55% of reported losses across its five categories in FY2023–24. The figures are reported in Microsoft’s guidance on email authentication and phishing protection. For a business handling invoices, supplier changes or customer payments, a spoofed message can create a financial problem even when the Outlook software itself is working perfectly.

Apply identity controls after setup

Enforce strong multi-factor authentication for every mailbox. Create a separate administrator account for administrative work and use a normal account for email, browsing and daily tasks. This reduces the damage caused if a user enters credentials into a fake Microsoft sign-in page.

Protect shared mailboxes and review who can send from them. Check forwarding settings and inbox rules after migration, particularly if an older provider or compromised account was involved. Backups and recovery methods should be tested, not merely assumed to exist.

The most useful verification happens in message headers. Send a test message to an independent mailbox, open the full headers, and check that the results show:

  • SPF pass: The sending infrastructure is authorised.
  • DKIM pass: Microsoft 365 signed the message and the selector records resolve.
  • DMARC pass: The authenticated domain aligns with the visible From domain.

These checks matter because SPF alone doesn’t prove that the visible sender is trustworthy. DKIM and DMARC add the relationship between the authenticated service and the address a customer sees.

Staff training supports the technical controls. Teach people to verify changed bank details through a known phone number, distrust urgent payment requests, and avoid signing in through unexpected links. Practical phishing awareness training should use the language of invoice fraud and supplier impersonation, not just abstract security terminology.

Troubleshooting Common Migration Issues and Getting Help

When mail still arrives at the old provider, check the public MX records and remove obsolete MX entries after confirming the Microsoft destination. If DKIM fails, check that both Microsoft-provided CNAME records exist exactly as supplied and that they resolve publicly. If Outlook keeps asking for a password or shows stale folders, test the mailbox in Outlook on the web first, then review autodiscover, licensing and the local Outlook profile.

A practical fault-finding order is:

  • Routing: Confirm the active MX destination and priority.
  • Identity: Confirm the domain is verified and the user has a licensed mailbox.
  • Authentication: Check SPF consolidation, DKIM selectors and DMARC alignment.
  • Clients: Test Outlook on the web before repairing desktop or mobile profiles.
  • Business systems: Test website forms, scanners, CRMs, booking tools and accounting platforms.

Home users often need help for a related but different reason. A stubborn router, unreliable WiFi, printer setup, damaged laptop profile or confusing Microsoft sign-in can make an otherwise correct mailbox appear broken. Practical assistance for computer repair home users should include patient explanations and device testing, not just a password reset.

For small offices across Bayside, Port Phillip and Kingston, Computer Daddy provides on-site and remote support for domain and email setup, website and email troubleshooting, Microsoft 365 migrations, computer repairs and ongoing managed IT services. Hand over the migration when you can’t identify the registrar, the domain supports several sending systems, or customer mail is already being lost.

Computer Daddy can audit your DNS, migrate business mail to Microsoft 365, configure Outlook on computers and mobiles, and secure the environment with authentication and MFA. Visit Computer Daddy to arrange practical support for your small office or home setup.

Scroll to Top