Business email is the one service most companies never think about until it stops working. Moving it to a new provider can feel risky, because your invoices, customer conversations and supplier contacts all live in those mailboxes. With a little planning, the move is straightforward, and the steps below cover what to do before, during and after the switch.
The reasons are usually practical. You are changing hosting providers anyway, your current mailbox is running out of space, or you want your email hosted somewhere with better support and security. Sometimes the move is about having your email, website and domain under one roof so there is a single provider to call when something goes wrong.
Start by taking stock of what is actually in your email system. Beyond the messages themselves, most businesses hold contacts, calendar appointments and rules or filters that have been built up over years. Export copies of your contacts and calendar from your current provider, and note any shared mailboxes or aliases such as info@ or sales@, because those are easy to forget in a migration.
Keep your old service running until the move is complete. The goal is to copy your data across, not to delete it at the source. Once the new mailboxes are working and you have verified the content arrived, you can close the old account at your own pace.
Tell your team what is happening before the cutover. Everyone should know the date the switch happens, whether their email address stays the same, and what to do if they cannot connect on the morning of the move. If your staff use email signatures, prepare the updated versions in advance, because a signature that still carries the old provider's settings is a small detail that looks unprofessional after a migration.
Your new provider will usually offer a way to bring your old mail across. Many providers offer a migration tool that connects to your old mailbox and copies the folders and messages into your new one. If no tool is available, a standard IMAP connection can do the same job: your email app connects to the old server, downloads everything, and uploads it into the new account.
Large mailboxes take time, so start the copy well before your switchover date rather than on the morning you planned to cut over. Check afterwards that your folders arrived intact, including the sent items, because a migration that copies only the inbox has not copied everything.
The moment that actually moves your email is the change to your MX records. The MX record in your domain's DNS tells other mail servers where to deliver messages for your domain. Until it changes, mail keeps flowing to your old provider. When it changes, new mail starts arriving at your new provider instead.
Because the MX record lives in DNS, the cutover usually takes effect within a few hours as the change spreads. During that window, some senders may still deliver to the old server while others go to the new one. That is normal, and it is exactly why the old mailbox should stay active for a while. Messages sent during the overlap can be forwarded or copied over afterwards.
Once the MX record has updated, test the basics before you announce anything. Send a message to your own address from an external account such as a personal email and confirm it arrives in the new mailbox. Send a message out and confirm it is delivered, ideally to a couple of different providers. Update your phone, tablet and desktop mail apps with the new server settings, and check that shared mailboxes and aliases are working.
If you have email authentication records, confirm they were carried across correctly. SPF and DKIM records are tied to the server that sends your mail, so a new mail server may need new records, and a missing record is the classic reason a freshly moved business suddenly lands in spam folders. Your provider should check these for you as part of the move.
Plan to keep the old mailbox active for at least a week after the cutover, longer if your industry deals in slow-moving correspondence. Automatic replies, old invoices and system notifications can arrive days later, and it is much easier to forward stragglers from a live mailbox than to recover them from a closed account. Set a reminder to close the old service once nothing has arrived for several days.
Hosting Australia includes free migration of your website and email when you move to our hosting, and the team handles the mailbox copies, the MX cutover and the record checks as part of the process. If you are planning to move your business email, contact us first and we can confirm what needs to be exported, what the cutover involves and how to keep your mail flowing through the change.
At some point most businesses think about moving a domain name to a different provider. The reasons vary: better prices, a support team that answers, or simply having everything in one place. A domain transfer sounds technical, but it is a routine process that runs every day. The key is understanding what a transfer actually does, because it is not the same as changing your website or your email.
A domain transfer moves the management of your domain name from one registrar to another. The registrar is the company that holds your domain's registration and handles renewals. After a successful transfer, your new registrar manages the domain, sends the renewal reminders and deals with changes to its details.
Importantly, a transfer does not move your website or your email. Those services are controlled by DNS records, and the records stay exactly where they are unless you change them. If your hosting stays where it is, your website and email keep working through the transfer without interruption. This is the detail that surprises most business owners, and it is also the detail that makes transfers safe.
Transferring is worth considering when you want to consolidate your domains with one provider, when your current registrar charges more for renewals, or when you simply do not trust the company holding your most important digital asset. Moving your domains to the same provider as your hosting can also simplify things, because renewals, invoices and support all live in one place.
Many businesses transfer when they move their hosting, even though the two processes are separate. It is a good moment to review your domain portfolio, update contact details and decide which names you actually need.
If your goal is to point your domain at a new website, or to change where your email is delivered, you do not need a transfer at all. Those changes are made with DNS records, usually nameserver changes, and they can be done through your current registrar in minutes. Transferring the domain instead would change nothing about your website or email, and it would add an unnecessary step. If you are not sure which process you need, ask your provider before starting anything.
To transfer a domain you typically need three things: the domain must be unlocked at your current registrar, you need an authorisation code (sometimes called an EPP code), and you need access to the registrant email address on the account. The code is a password that proves you control the domain, and it is generated by your current registrar.
For Australian domains there is an extra layer. A .au domain can only be transferred if the registrant remains eligible under auDA rules, so the ABN or ACN linked to the domain must be current and match the registrant. If your business details have changed since the domain was registered, fix them before you start the transfer, or the new registrar's checks can fail.
Once you have requested the transfer with your new provider, the process usually runs like this. Your new registrar submits the transfer request to the registry using the authorisation code, and your current registrar sends a confirmation email to the registrant address. You approve the request, and the transfer completes, typically within a few days. Most transfers include at least a year of renewal at the new provider, which is why the fee can look higher than a standard renewal.
Do not start a transfer when your domain is about to expire. Renew it first at your current registrar, or time the transfer so there is plenty of room before the expiry date. Domains that were registered or transferred very recently may also be locked for a short period, so check before you begin.
Most transfer problems come from the same handful of mistakes. The confirmation email goes to an old address nobody checks, so the request lapses. The domain is still locked at the old registrar. The registrant details no longer match the current business, which matters for .au domains. Or the transfer is started during a busy period and forgotten, leaving the domain with no provider actively managing its renewal. Each of these is avoidable with a quick check beforehand.
A transfer is a good excuse to look at every domain your business holds. Businesses often accumulate names over the years: an old brand, a project that never launched, or a defensive registration that has been renewing quietly. Decide which ones you still use, which ones protect your main name from confusion, and which ones can be allowed to lapse. Consolidating a handful of domains onto one registrar, with one renewal date and one invoice, is easier to manage than tracking them across several accounts, and it reduces the chance that a forgotten domain expires without anyone noticing.
Domain transfers are an everyday task for the Hosting Australia team. We can check whether your domains are ready to move, confirm the registrant details are correct for .au eligibility, handle the transfer request and make sure renewals land in the right place afterwards. If you would like your domains consolidated onto one account, contact us and we can walk you through what is involved.
Many small business owners assume their website belongs to them because they paid for it. The reality is more complicated. A website is made of separate parts, and each part has its own owner. If the details were not set up correctly at the start, you can discover years later that the person who built your site also holds the keys to it. This guide explains how ownership works and how to check yours in a few minutes.
Your website is really three services working together. The domain name is your address, such as yourbusiness.com.au. The hosting is the service that stores your website files and serves them to visitors. And the design and content are the pages, text and images that make up the site itself. These can be owned, controlled and billed by different people, and they often are.
That separation is normal and useful, but it becomes a problem when the people who control each part are not the people who should. The safest arrangement for a business is simple: the business owns the domain and the hosting account, and any designer or developer works on them with permission rather than owning them.
Every domain name has a registrant, the person or organisation legally registered as its owner. In Australia the registrant for a .com.au domain must be a commercial entity, and the name must match the registered business details. Whoever is listed as the registrant makes the important decisions: renewing the domain, changing its details, transferring it to another provider or selling it.
If a web designer registered your domain under their own name because it was convenient at the time, they are the registrant, not you. That works while the relationship is healthy, but if the designer closes their business, disappears or the relationship ends badly, you can be locked out of your own address. Customers who type your domain could land on a parked page or a competitor, and recovering the name can take weeks of paperwork.
Your hosting account is controlled by whoever opened it. The account holder receives the login details, the invoices and the support access, and they decide who else can get in. If your website was built on the designer's hosting account, the designer controls your files, your databases and your email, and you may have no way to reach any of them if the relationship ends.
Hosting accounts should be opened in the business's name, with the business's own contact details and a business email address that the business controls. The designer can still be added as a user with the access they need to build and maintain the site, but the account itself stays yours.
Design and content are covered by copyright, which means ownership depends on who created the work and what your agreement says. Work created by a designer for a client does not automatically belong to the client unless the agreement assigns it. Most professional designers license the finished website to the business, and some keep the rights to templates or code they reuse across clients. A written agreement should state clearly what the business owns and what the designer retains, so there are no surprises later.
Ownership rarely gets tangled on purpose. It drifts through small decisions: registering the domain on the spot during a meeting using the designer's account, hosting the site under the developer's plan because it was cheaper, or using the developer's email address for renewal notices. Each decision seems harmless at the time, and each one moves a piece of your online presence out of your control.
You can check where things stand right now without any technical knowledge:
If any of those checks fail, fix the issue while the relationship is still friendly. Updating a registrant or moving hosting to an account in your name is straightforward paperwork when everyone cooperates, and it becomes much harder after a dispute or a closure. If your domain details no longer match your current business, correct them now, because .au renewals are checked against active ABN and ACN details.
Your website should work for your business, not hold it hostage. If you are unsure who owns your domain or hosting, or you would like help moving them into your name, the Hosting Australia team can check the current setup with you and make the change safely.
You send a carefully written email to a customer, and it never arrives. Or it arrives, but only after you check the spam folder and forward it with an apology. For small businesses this is frustrating, and it is often fixable. The problem is usually not your internet connection or your email app. It is missing email authentication records in your domain's DNS.
Receiving servers such as Gmail and Outlook have become strict about which messages they trust. They check whether an email claiming to come from your domain is actually authorised by your domain. If those checks cannot be confirmed, your mail is more likely to be filtered or rejected. Three DNS records do most of the work: SPF, DKIM and DMARC. Once they are published correctly, your legitimate mail has a verifiable identity and far fewer reasons to be treated as suspicious.
SPF, which stands for Sender Policy Framework, is a DNS record that lists the mail servers allowed to send email for your domain. When a receiving server gets a message from your domain, it looks up this list and checks whether the sending server is on it. If your business sends mail only through your hosting provider's mail server, the SPF record includes that server and nothing else needs to change.
Problems start when other services send mail using your domain, such as your website's contact form, a booking system, an email marketing tool or an invoice platform. Each of those services has its own sending servers, and they must be added to the SPF record. If they are missing, their mail can be rejected even though it is perfectly legitimate. If you use many services, the record can grow complicated, which is exactly why providers publish a fixed format for you to copy.
DKIM, or DomainKeys Identified Mail, works differently. Your outgoing mail server signs each message with a private key, and the matching public key is published in your DNS as a DKIM record. Receiving servers can use the public key to verify that the message was genuinely signed by your domain and was not altered in transit.
DKIM signatures are usually added by the service that sends your mail. Your hosting provider's mail server signs your outgoing messages automatically, and services like email marketing platforms provide their own DKIM records for you to publish. A message signed by your domain is much harder to impersonate, which is why spoofed emails that pretend to come from your business often fail when DKIM is in place.
DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance, tells receiving servers what to do when SPF and DKIM checks fail. Without DMARC, each receiving server decides for itself, which leads to inconsistent results. With DMARC, you set a policy: messages that fail the checks can be sent to the spam folder or rejected outright.
DMARC also produces reports that show which services are sending mail using your domain. That visibility is valuable, because it reveals senders you may have forgotten about, and it can expose attempts by scammers to impersonate your business. Most small businesses start with a policy that only monitors, then tighten it once they confirm all legitimate senders pass.
All three records are published as text entries in your domain's DNS, the same system that points your domain to your website and your email. Adding or updating them does not interrupt your website or your inbox, and the changes usually take effect within a few hours. Your hosting provider can tell you what each record should contain, add them for you and check them afterwards.
If you are unsure whether your domain has these records, ask your provider to run a quick check. A domain that has none of them, or that has an SPF record listing a service you no longer use, is a domain that will keep fighting its own email.
A common situation is a business using an external service, such as a marketing platform or a booking system, that sends email on its behalf. The vendor will provide the exact SPF entry to include and a DKIM record to publish, and they usually have setup instructions for each DNS host. In most cases the customer needs to request the records from the vendor, and the hosting provider adds the DNS entries the vendor specifies. If the vendor's instructions are missing or unclear, ask them directly, because only they know their sending infrastructure.
Email authentication is not glamorous, but it protects a channel that carries your invoices, quotes and customer conversations. If your mail is landing in spam, start with SPF and DKIM, add DMARC once those are confirmed, and keep the records up to date whenever you change email providers or add a new sending service. The Hosting Australia team checks and adds these DNS records for customers every week, so contact us if you would like yours reviewed.
When a customer visits your website, their browser exchanges information with the server that hosts it. That information may include contact form details, login credentials or other data entered on the site. An SSL/TLS certificate allows the connection to use HTTPS, which encrypts data while it travels between the browser and server.
For a small business, the terminology can make a fairly practical task sound more complicated than it is. The certificate confirms that the browser has connected to the domain covered by the certificate through a trusted process. It does not secure every part of the website, but it is an important part of setting up a protected connection.
SSL is the familiar name, although modern secure connections use TLS. When a visitor opens an HTTPS address, the web server presents its certificate. The browser checks the certificate, the domain it covers and the chain of trust leading back to a recognised certificate authority. If those checks succeed, the browser and server establish an encrypted connection.
Encryption helps prevent information from being read in plain text while it is travelling across the network. This applies to data sent from the browser to the server and data returned to the browser. The certificate also helps the browser check that the domain matches the certificate presented by the server.
You can usually recognise an HTTPS page by the address beginning with https:// and the security information shown by the browser. Browser interfaces change, so a padlock or another symbol should not be treated as a general verdict on the whole website. It mainly indicates the state of the connection.
Domain Validation, usually shortened to DV, establishes control of the domain. The certificate authority may check this through a DNS record, a file placed on the website or another approved domain control method. DV is commonly suitable where the main requirement is to enable HTTPS for a domain.
Organisation Validation, or OV, adds checks about the organisation requesting the certificate. It still covers the secure connection, but the certificate authority carries out organisation validation as part of issuing it. The right choice depends on what needs to be validated, rather than on the encryption being described as stronger or weaker.
A standard certificate may cover one hostname or a defined set of hostnames. A wildcard certificate can cover subdomains, depending on the certificate and how it is issued. Before ordering, list the addresses that need coverage, such as the main domain, www address and any named subdomains. This avoids discovering later that an important hostname was left out.
HTTPS protects data in transit between the browser and server. It does not patch an outdated website, remove malware or stop someone from using a weak password. It also does not replace software updates, secure account practices or reliable backups.
This distinction matters because a compromised website can still have a valid certificate. The connection to that site may be encrypted even while the site itself contains harmful or altered content. Website security therefore needs several layers. HTTPS is one of them, not a substitute for the rest.
Keep the website platform, plugins and themes maintained. Use strong, unique passwords for administrative accounts, limit access to people who need it, and keep tested backups. Those tasks address risks that a certificate was never designed to handle.
Certificates expire and must be renewed. Some hosting setups automate renewal, while others require an administrator to complete or confirm the process. Check who is responsible, how renewal is handled and whether there are any domain validation steps that could fail after a DNS or hosting change.
Installing the certificate is only part of the move to HTTPS. The website should direct visitors from HTTP addresses to the HTTPS versions. Redirects need to be configured carefully so they do not create loops, send visitors to the wrong page or leave both versions available without a clear preference.
Mixed content is another common issue. It occurs when an HTTPS page still loads an image, script, stylesheet or other resource over HTTP. Browsers may warn about or block that resource. Updating internal links and checking templates, plugins and embedded items can resolve these references.
After setup, test the main pages, forms and administrative areas. Check more than the home page, since an old HTTP reference may only appear in a particular template or piece of content. It is also worth confirming that every required domain and subdomain is covered by the certificate.
Start with a simple inventory of the domains and subdomains your business uses. Note where each website is hosted, who controls DNS and whether email, customer portals or other services use separate hostnames. This gives your provider the information needed to identify suitable certificate coverage.
Ask how validation will be completed, who will install the certificate and who will monitor renewal. If you are replacing an existing certificate, plan the change so the new certificate is active before the old one expires. Keep a record of the certificate type, covered names and responsible contact.
Hosting Australia offers SSL certificates and can help you work through the practical details for your website. If you are unsure which domains need coverage, whether a wildcard is appropriate or how to correct mixed content and redirects, contact Hosting Australia to discuss the current setup.
A well-managed certificate gives browsers the information they need to validate the domain and create an encrypted HTTPS connection. Pair it with updates, strong passwords and backups, then keep renewal responsibilities clear. That provides a sound, practical approach without expecting HTTPS to solve problems outside its purpose.
When you choose a website address for your Australian business, the ending matters more than most people expect. The letters after the dot tell customers what kind of organisation you are, and in Australia they also come with rules about who can register them. If you are setting up a new domain, or checking that the one you already hold is still on solid ground, this guide explains the options in plain English.
Australia has several domain endings, each run under licensing rules set by auDA, the organisation that administers the .au namespace. The ending you can register depends on your legal structure and how the name you want connects to your business or activity:
Most Australian businesses register a .com.au because it is the address customers expect to see on a sign, a business card or an email footer. To hold one you need a commercial entity, such as a business registered with an ABN or a company with an ACN, and the name must match or be closely connected to your registered business name, company name or Australian trade mark.
The practical effect is simple: a business trading as Coastal Cleaning Pty Ltd can register coastalcleaning.com.au, but it cannot register a name belonging to an unrelated business. Your ABN details and your domain need to tell the same story, because both are checked against auDA rules at registration and can be reviewed later.
The .net.au ending also requires a commercial entity, and the name must match your registered details in the same way. It was traditionally aimed at network and technology providers, but any eligible business can use it. If your first-choice .com.au is already taken by someone else, a .net.au version can work as an alternative, even though most customers will still look for the .com.au version first.
The .org.au ending is different because it is reserved for non-profit organisations and incorporated associations. That makes it a good fit for a charity, a community group or a sporting club that does not hold a business ABN but still wants a credible Australian web address of its own.
The .au direct namespace opened in 2021, allowing shorter addresses such as yourbusiness.au without the com or net in the middle. Eligibility is broader: you need a verifiable Australian connection, which can be citizenship, residency, or a business presence with an active ABN or ACN.
Existing holders of longer .au names had first access during the launch period, and the shorter names have been available on the open market since. Many businesses keep their .com.au as the main address and also register the matching .au name so nobody else can take it, then point the shorter version to the same website. A few dollars a year can save a lot of confusion later.
Australian domain eligibility is not a once-only check. auDA can review registrations at any time, and since May 2026 registrars are required to verify that the ABN or ACN linked to a domain is still current and active when that domain comes up for renewal.
This matters more than business owners realise. If you restructured and cancelled an old ABN, that number will no longer pass the check, and your renewal can be blocked, which eventually puts the domain at risk of deletion. It is worth reviewing your details once a year: look up your domain on the auDA WHOIS service, confirm the ABN or ACN shown there matches the one that is active today, and fix any mismatch with your domain provider well before the renewal window closes.
Start with the ending your customers expect: .com.au for almost every business, .org.au for a not-for-profit, and .id.au or .au direct for a personal site. Then check whether your exact business name is available, along with the common variations customers might type.
If the .com.au you want is held by an unrelated party, weigh up whether a .net.au or .au version is worth using, or whether a small change to the name is cleaner. Register only the versions you genuinely need, and point any extras at your main website so a confusingly similar address cannot be used against you later.
A domain is a small decision with long-term consequences, and it does not need to be complicated. If you are unsure which ending you qualify for, or whether the details on your current domain are still correct, your hosting provider can check availability, walk you through the eligibility rules and keep your renewals on track. The Hosting Australia team helps Australian small businesses with domain registration every day, so contact us if you would like a hand.
A website can feel like one product, but several services work together behind the scenes. Two of the most important are your domain name and web hosting. They are connected, but they are not the same thing.
Understanding the difference makes it easier to launch a site, move providers and troubleshoot problems. It also helps you avoid a common business risk: assuming that paying for one service automatically keeps every part of your online presence active.
Your domain name is the address people type to reach you, such as yourbusiness.com.au. Registering it gives you the right to use that name for a set licence period, provided you continue to meet any applicable rules and renew it when required.
Web hosting is the service that stores and serves the website itself. This can include your pages, images, WordPress files, databases and other data needed to display the site. When someone visits your domain, their browser ultimately needs to connect to the server that holds those files.
A useful comparison is a shop and its street address. The domain is the public address, while the hosting is the premises containing the business. Having an address does not create the shop, and renting premises does not tell customers where to find them. The two must be connected correctly.
You can often register a domain and buy hosting from the same provider, but that is not compulsory. A domain can remain with one provider while the website is hosted elsewhere. Keeping them together may simplify administration, while keeping them separate may suit an existing setup. Either approach can work when access, renewals and DNS are managed carefully.
The Domain Name System, or DNS, links readable domain names with the technical destinations used by internet services. For a website, DNS records can direct visitors to the server where the site is hosted. This avoids asking people to remember a numerical IP address.
Nameservers identify where the authoritative DNS records for a domain are managed. Inside that DNS zone, different record types handle different jobs. An A record can point a name to an IPv4 address, an AAAA record can point to an IPv6 address, and a CNAME can make one hostname refer to another name.
Email uses the same domain but may have a different destination. MX records direct incoming email towards the relevant mail service, while TXT records are commonly used for email authentication and service verification. This is why changing website hosting does not always mean changing email hosting.
Imagine that your website is moving to a new server but your email is staying with Microsoft 365 or another mail provider. The web records may need to change, while the MX and supporting email records should remain in place. Replacing the whole DNS zone without checking it can interrupt services that were not meant to move.
DNS answers can also be cached. After a record changes, some visitors may briefly receive the previous answer until the cached information expires. The practical approach is to prepare the correct records, allow for caching and test the website and email separately.
Moving a website normally involves more than copying files. The new hosting environment must be ready, the website and database must be transferred, and the domain's DNS must direct visitors to the new destination. Any required SSL setup, redirects and application configuration also need to be checked.
The domain registration does not have to move just because the hosting moves. You may only need to update selected DNS records or change which nameservers are authoritative. Likewise, transferring a domain to another registrar does not automatically move the website files to new hosting.
Before changing DNS, make a simple service map. Record where the domain is registered, where DNS is hosted, where the website lives and where email is delivered. Also note any subdomains used for booking systems, customer portals, newsletters or third-party tools. This turns a risky guess into a controlled change.
Test the new website before directing normal traffic to it where possible. Check important pages, forms, images and logins. After the DNS change, confirm that the public domain reaches the intended site, HTTPS works and email continues to send and receive through the expected provider.
A reliable setup is not only about technical records. Your business should know which company manages each service and who can access each account. Store account details securely, use a business-controlled contact address and remove access for people who no longer need it.
Keep domain contact information current so renewal and account notices reach the right person. Treat domain renewal and hosting renewal as separate checks, even when they appear on the same invoice or in the same customer portal. If a domain expires, the website and domain-based email can stop working even if the hosting account is still active.
Document the current nameservers and important DNS records before making changes. If a web developer, marketing platform or email provider asks for a DNS update, confirm the exact record name, type and value. Avoid deleting unrelated records simply because their purpose is not immediately obvious.
Domains, hosting and DNS are separate building blocks, but together they create a working online presence. Know where each part is managed, renew each service on time and review the full service map before a move. If you would like help connecting a domain to suitable hosting, contact Hosting Australia for practical guidance.
Every small business starts somewhere, and for many of them that somewhere is a free email account. Gmail, Outlook.com and similar services are fast, familiar and free, which makes them an easy choice when you are setting up a website or registering a domain. But there is a real difference between a personal inbox and email that represents your business. This guide compares the two, explains what email hosting actually includes, and helps you decide which one your business needs.
Free email services have a lot going for them. They are genuinely free, easy to set up, and work well on phones, laptops and tablets. Spam filtering is generally good, storage is generous, and most people already know how to use them because they use them every day.
For personal use, a free provider is often the right choice. For a hobby project or a one-off enquiry address, it is hard to argue with free. The problems start when a business relies on a free address for customer communication, quotes, invoices and bookings.
A free address like yourname@gmail.com says nothing about your business. When a customer receives an email from a free provider, they cannot tell whether it comes from a one-person operation or an established company, and they have no way to verify the sender. A message from you@yourbusiness.com.au is instantly recognisable and builds trust before the first word is read.
There are other practical problems too. A free account belongs to the provider, not to you. If the account is suspended, locked or compromised, you can lose access to every customer conversation, quote and invoice it holds, and free services do not come with a support team you can call. When an employee leaves, a free address they created goes with them, along with all the business history attached to it. And because free accounts are funded by advertising, your business activity supports a business model you do not control.
Email hosting gives you professional mailboxes on your own domain: you@yourbusiness.com.au instead of you@gmail.com. Behind the scenes, your email provider runs the mail servers that receive and send mail for your domain, and handles the technical details that keep delivery working.
In practical terms, email hosting usually includes webmail you can open in a browser, IMAP and SMTP settings so your mail works in Outlook, Apple Mail or on your phone, spam and virus filtering, multiple mailboxes for staff, aliases and forwarding addresses, and backups of your mail. Because the mailboxes belong to your domain, you can move them to another provider if you ever want to, without losing your email address.
Here is how the two options compare in everyday business use:
Moving is easier than most people expect, and a good provider will handle the migration for you. The steps are simple: set up your new mailboxes on your domain, move or forward the mail you want to keep, point your domain's MX records at your new email provider, and send a test message to make sure everything works. Then update your email signature, invoices, business cards and online listings, and keep the old free account running for a little while in case anyone writes to the old address.
One thing worth understanding: your website hosting and your email are separate services, even when the same provider supplies both. Email is directed by MX records, while web traffic uses A and CNAME records. Changing your web host does not change your email, and changing email providers does not move your website. A migration checklist that covers both, completed with your provider's help, keeps every service working through the change.
Business email is a favourite target for attackers, because a compromised inbox can be used to send fake invoices and requests that look like they come from you. Strong passwords, two-factor authentication and good spam filtering make a real difference. The Australian Cyber Security Centre publishes practical guidance on securing business email, and it is worth reading even if you are happy with your current setup.
There is no rule that says every business must pay for email hosting. If you run a side project and email is a minor part of it, a free address may be all you need. But if customers contact you by email, if you send quotes or invoices, or if more than one person needs a professional address, email hosting on your own domain quickly pays for itself in trust, control and peace of mind.
If you would like to talk through your options, the Hosting Australia team can explain our email services, help you migrate your mailboxes, and make sure your domain, website and email all work together. Get in touch and we will take care of the technical side while you get back to running your business.
Cloudflare is one of the most popular ways to add speed, security and a content delivery network to an existing website. The free plan includes fast DNS, a CDN, DDoS protection and a Universal SSL certificate, which makes it tempting for small business owners to try. The move itself is simple in theory: add your domain, copy your records, change your nameservers. In practice, small mistakes can take your website or email offline for hours. Here is what to check before you switch.
When you move your domain to Cloudflare, you are changing your authoritative nameservers at your registrar. After the change, Cloudflare answers every DNS query for your domain, not your old host or registrar. Your hosting itself does not move. Your website files, database and email remain exactly where they are. Only the signposts that point visitors and mail servers to your services change hands.
Cloudflare scans your existing DNS and imports most records automatically, but it does not always get every record right. Export your current zone file first, or copy every record from your hosting control panel. Pay attention to records that are easy to miss, such as TXT records used for email authentication, SPF and DKIM entries, CNAME records for third-party tools, and any records used by services like Shopify, Office 365 or Google Workspace. Compare the import against your export record by record.
Email is the most common casualty of a messy DNS move. Your MX records tell mail servers where to deliver your mail, and they must stay DNS-only, which Cloudflare calls grey cloud. If you set them to proxied, or orange cloud, mail delivery breaks. Along with MX, keep your SPF, DKIM and DMARC TXT records intact, and verify them after the cutover. Send a test message to an external address and check your spam folder before you declare the move finished.
If your domain has DNSSEC enabled at your registrar, you must disable it before updating your nameservers, or your domain can become unreachable for everyone. The process is simple: disable DNSSEC at your registrar, wait for the change to clear, then update your nameservers. After Cloudflare has activated the domain, you can turn DNSSEC back on through Cloudflare and add the DS records it provides at your registrar. Skipping this step is the single most common way a Cloudflare move goes wrong.
Cloudflare offers several SSL modes. Flexible encrypts traffic between the visitor and Cloudflare only, and is not recommended for most sites because the connection between Cloudflare and your server stays unencrypted. Full requires a certificate on your server, and Full strict requires a valid certificate that Cloudflare trusts. If your hosting already has a working SSL certificate, Full strict is the safest choice. If you pick a mode that does not match your server setup, you can trigger redirect loops or mixed content warnings, so test your site in each mode before going live.
Each DNS record in Cloudflare has a proxy status. Proxied records, shown with an orange cloud, route through Cloudflare and gain the CDN, caching and security benefits. DNS-only records, shown grey, simply resolve normally. A common setup proxies your web records, such as the A or AAAA record for your domain and www, while leaving everything mail related grey. Anything that must connect directly to its origin, such as some third-party validation services, should stay grey unless you know the service supports proxying.
If your site runs WordPress, a proxied setup can cache your pages aggressively. Install the official Cloudflare plugin so that updates and new posts automatically purge the cache, otherwise you may publish content and still show an old version to visitors. You should also make sure your hosting records the real visitor IP from Cloudflare, usually via the CF-Connecting-IP header, so analytics and security tools see genuine visitors rather than Cloudflare addresses. Test logging into wp-admin and submitting a form before you announce the move.
DNS changes propagate gradually and can take time to settle. Lower your TTL values on the records you are moving a day before the switch so the old values expire quickly, then change your nameservers at a quiet time for your business. Keep your old nameservers written down. If something breaks, you can switch back in minutes. After the cutover, test your website from a phone and a computer, send and receive email, and check your SSL certificate from a few devices.
Moving to Cloudflare is a sensible step for many websites, but it touches DNS, email and security all at once. If any of this feels unfamiliar, ask your hosting provider to review your records before you switch. A few minutes of checking now is far cheaper than a morning of downtime later.
A backup is a copy of data. A disaster recovery plan is the set of decisions, people and steps that turn that copy into a working website again. The difference matters when a WordPress site is hacked, an update breaks checkout, a domain expires or a provider account becomes inaccessible.
Backups are essential, but they do not decide which copy is safe, who can approve a restore, how email and DNS will be checked, or what customers should be told. A practical plan answers those questions before pressure and uncertainty arrive.
You do not need enterprise language to set useful recovery targets. Begin with two plain questions:
Set these targets according to what the site does. A brochure site and a busy online store have different consequences when unavailable. Your targets guide backup frequency, retention, technical options and the order in which services return.
Write down one person who can declare an incident, one person or provider responsible for the technical restore, and one business contact who approves the recovered site. Add an alternate for each role. Do not leave ownership with a generic label such as 'the web team' if nobody knows who has authority after hours.
Record how the restore starts. Does the business open a support ticket, use a hosting control panel or contact a developer? Note where credentials and multi-factor authentication recovery methods are held securely. Confirm who can access the hosting account, WordPress administration, domain registrar, DNS provider and backup storage. A technically sound backup is of little use if the only authorised account belongs to a former employee.
A website is rarely one isolated system. The plan should list the WordPress files and database, but also every dependency required for normal operation:
This service map prevents a website restore from accidentally disrupting email or pointing visitors to the wrong server. It also exposes dependencies that the backup may not contain. WordPress explains that a typical full restore needs both website files and the database. DNS zones, mailboxes and external platforms may need separate protection or documentation.
When malware or unauthorised access is suspected, simply placing old files over the current installation can preserve the problem. First isolate the affected site where practical and retain useful logs. Identify a recovery point from before the compromise, then restore into a clean or rebuilt environment rather than trusting contaminated components.
Before returning the site to service, update WordPress, themes and plugins as appropriate, remove anything unrecognised, rotate relevant passwords and keys, and address the entry point if it is known. Scan the restored site and check that administrative users are legitimate. The Australian Signals Directorate's Information Security Manual guidance recommends secure, resilient backups and coordinated testing of restoration from a common point in time.
A successful backup notification proves that a process ran. It does not prove that the copy is complete or that the team can restore it. Schedule a test restore to a non-production location. Time the exercise, record which backup was used and compare the result with the recovery objectives.
Check more than the home page. Test key pages, WordPress login, forms, search, images, checkout or bookings, scheduled tasks and outbound email. Confirm HTTPS and DNS behaviour. Review logs for errors, then document gaps and update the plan. NIST describes testing as the way to validate recovery capabilities and identify planning gaps in its contingency planning guide.
Decide who updates staff, customers and suppliers, and through which channel if the website or business email is unavailable. Prepare short message templates for an outage, a security investigation and service restoration. State what is known, what users need to do and when the next update will come. Avoid guessing at causes or recovery times.
Keep the contact list and plan somewhere accessible when WordPress and company email are down. Record decisions and actions during the incident. After service returns, review what happened, what data may have changed and which controls or instructions need improvement.
Your first version can fit on one page. Include:
Review the page after major website, staff or provider changes. If your current hosting makes backups and recovery harder to manage than they should be, review Hosting Australia's WordPress hosting options and discuss the restore process before choosing a plan.
A backup gives you recovery material. A tested plan gives your business a controlled way to use it. Define acceptable loss and downtime, assign ownership, map dependencies, practise a clean restore and keep communication ready. That is what turns backup files into business resilience.
