How to stop ex-employees retaining access to business email

Removing a former employee's access can require session revocation, delegated-access review, connected-app checks and device follow-up. Preserve business data under an informed process before deleting anything. The available controls depend on the platform and licence. Record who now owns the account's work and recovery arrangements.

This guide combines a task-specific answer and action checklist with a supporting technical reference. Use the sections relevant to your situation, verify current product and platform details, and keep the customer journey in view. The aim is to make a sound decision and check the result, rather than assume that one purchase or setting solves every related problem.

A practical sequence for this specific task

Work through the topic-specific checks below in a controlled order. They identify the decisions that matter for this task, including the dependencies or limitations that can be missed when attention goes only to a headline product or the most visible symptom.

1. Revoke sessions and delegated access.
2. preserve business data lawfully.
3. recover devices.
4. access review.
5. do not advise deleting evidence.

Use the sequence as an assessment checklist, then consult the current instructions for the exact platform or service involved. Confirm access and recovery before a change, record the starting position and test the relevant customer or administrator workflow afterwards. If a step involves production data or an irreversible action, establish a safe method before proceeding.

Configure devices without sharing account credentials

Set up business email using the provider's current client or protocol instructions. The appropriate app, server settings and authentication method depend on the service and plan. Avoid treating an old configuration example as authoritative, especially when the provider has changed its supported authentication methods.

Protect the device as well as the account. Use a suitable screen lock, keep software maintained and enable available multifactor controls. Decide how business data will be handled on personal devices and what the organisation will do if a device is lost or a staff member leaves. The exact management features depend on the product and licence, so verify them before relying on a remote action.

Test more than the presence of old messages. Send a new message, receive a reply, check folder behaviour and verify calendar or contact functions that the business needs. A client can display cached mail even when it is no longer connected correctly. Compare with webmail to help distinguish an account problem from a device configuration problem.

Keep support instructions understandable and avoid circulating passwords in messages or shared documents. Use named access or delegation where supported, and maintain account recovery through business-controlled channels. A device setup is successful when the user can perform the required tasks securely and the business retains a practical way to administer access.

Protect accounts and verify high-impact requests

Business email can be used to reset other accounts, communicate with customers and approve important work, so account protection has consequences beyond the mailbox. Use unique credentials, enable available multifactor authentication and keep recovery routes under organisational control. Review delegated access, forwarding rules and sessions when something suspicious occurs or when staff leave.

Train the team to verify unusual requests through a trusted independent route. A familiar display name, an urgent tone or an authenticated message is not enough to prove that a payment change or sensitive request is legitimate. Agree how bank-detail changes, credential requests and unexpected attachments will be checked before anyone acts.

Provide a reporting process that people can use without embarrassment or delay. Preserve relevant evidence and involve the appropriate administrator or specialist when account compromise is suspected. Avoid simply deleting the message and assuming the risk has ended. Investigate whether credentials, forwarding or access were affected and follow the organisation's incident process.

After recovery, review why the control failed and what should change. Technical settings, user guidance and approval workflows should support one another. No single security feature can guarantee that every misleading message will be blocked, so combine preventive controls with verification and a practical response plan.

Use domain email as a controlled business identity

A custom domain address can make a business's identity more consistent across its website, documents and messages. The practical benefit is not that every free email address is automatically unprofessional, but that the organisation can build a recognisable address structure and retain control when staff or suppliers change.

Choose clear display names and sensible addresses. Personal mailboxes can identify individual team members, while role addresses can support functions such as enquiries or accounts. Decide who monitors each role address and whether it is a mailbox, alias or shared resource under the current plan. Avoid creating addresses that nobody is responsible for checking.

Keep signatures readable and accurate. Include useful contact details and the relevant business identity without overwhelming every message with large images or tracking-heavy decorations. Test the appearance on mobile devices and in replies. Information that is important to the recipient should remain understandable when images are blocked or formatting is simplified.

Introduce the new identity with a planned transition. Update the website, forms and materials the business controls, and decide how old addresses will remain monitored where practical. Test receiving and replying before telling customers to use the new address. A recognisable identity depends on consistent use and reliable delivery, not merely on purchasing a mailbox.

Connect mail records without disrupting the website

Mail setup commonly requires DNS records that tell other systems where to deliver messages and how to evaluate authorised sending. Follow the current email provider's instructions for the exact domain and service. Record the existing values before changing them, especially when the domain already supports another mail provider or website.

MX records direct inbound mail to the intended service. Authentication records are a separate part of the configuration and may include SPF, DKIM and DMARC. Do not replace the whole DNS zone simply to change email unless the project intentionally includes moving DNS authority. Preserve web and third-party verification records that remain necessary.

Provision the required accounts before switching inbound delivery. If messages begin arriving at the new provider before the relevant mailboxes or aliases exist, delivery can fail even when the MX record is technically correct. Check the actual addresses the business publishes, including role addresses, and verify the provider's handling of aliases or shared resources.

After the change, test inbound and outbound mail from independent accounts. DNS caching can mean not every sender sees a new value immediately, so retain appropriate overlap with the previous service during a migration. Check the authoritative configuration and delivery evidence before attributing every problem to propagation or making additional changes.

Understand SPF, DKIM and DMARC as distinct controls

Email authentication helps receivers assess whether a message is authorised to use a sending identity. SPF describes permitted sending sources for a domain used in the mail transaction. DKIM adds a cryptographic signature associated with a domain. DMARC builds on alignment with the visible From domain and provides a policy and reporting framework. These controls have related but different roles.

Inventory every legitimate sender before changing policy. A mailbox provider, website form, invoicing system and marketing service may all send on behalf of the business. Use the providers' current record instructions, keep SPF configuration coherent and consider its lookup limits. Do not create a second unrelated SPF record simply because another service supplied an example.

Begin DMARC work with visibility and a plan for legitimate sources. Moving directly to a strict policy without understanding the senders can interfere with valid business messages. Reporting and alignment checks help identify missing configuration, but they require interpretation. Seek specialist help where the sending environment is complex or where the business cannot afford delivery disruption.

Authentication is not the same as encryption or proof that a message's content is honest. An authenticated sender can still send a misleading message, and correct records do not guarantee inbox placement. Combine authentication with account security, sensible sending practices and a process for verifying unusual requests.

Move email in stages and verify each data type

An email migration should begin with the source accounts, destination accounts and data types defined. Confirm what the chosen migration method can transfer and what requires another process. Messages, folders, contacts, calendars and permissions may have different limitations. A provider-to-provider move should not be described as complete until the required business data has been checked.

Run a pilot where practical. Choose an account that represents the important features without exposing the whole organisation to a first attempt. Verify the destination structure, dates, attachments and access on the devices people use. Record omissions and decide how they will be handled before proceeding with the wider move.

Plan the delivery cutover separately from the data copy. Provision destination accounts first, preserve relevant authentication settings and change MX records at the agreed stage. Keep both services available for appropriate overlap and check whether a final synchronisation is needed. DNS caching and user activity mean that zero interruption or zero missed messages should not be promised casually.

After cutover, verify receiving, sending, replying, calendars and shared resources as applicable. Help users reconnect their clients and distinguish a local display issue from a server-side migration problem. Retain the source data until the acceptance checks and the organisation's retention decisions allow decommissioning. Document the final state for future administration.

Investigate delivery failures using evidence

When a message does not arrive, first determine whether it was rejected, delayed, placed in a spam folder or never submitted by the sending application. These situations need different investigations. Capture the relevant sender, recipient, timestamp and non-sensitive parts of any error or bounce message, then use the provider's available logs or support process.

Check mailbox quota, address spelling, account status and the relevant DNS records. Compare a direct webmail test with the affected client or application. If ordinary messages work but a website form does not, the form's sending method and authentication deserve attention. If only one recipient domain rejects messages, the receiver's response can provide useful context.

For spam placement, review authentication, content, sending patterns and the legitimacy of the recipient relationship. Correct DNS is valuable but cannot guarantee inbox delivery. Avoid sudden unsolicited sending and misleading content. Do not assume that changing providers alone will resolve every reputation or consent problem.

After a change, test the same path that originally failed and monitor subsequent messages. Keep a concise record of the cause and resolution. When requesting help, share enough evidence to investigate without exposing passwords or unnecessary customer information. A useful diagnosis explains the failed stage rather than attributing every delivery problem to one generic cause.

Give role addresses a clear operating model

Role addresses such as enquiries, sales or support can provide continuity when team members change. They need an operating model, though: who reads incoming messages, who replies, how work is allocated and how unresolved requests are handed over. Without those decisions, a shared address can become an inbox that everyone assumes somebody else is monitoring.

Check how the current product implements the role address. An alias, separate mailbox, forwarding rule and shared inbox are different arrangements. Their access, storage and licensing implications can differ. Choose the arrangement that supports the workflow rather than creating another account by default or sharing a personal mailbox password among staff.

Agree how replies should identify the business and the responsible person. Review access when team membership changes, and avoid giving more administrative control than the role requires. Where the platform supports delegation or shared-resource permissions, use those features with named accounts rather than an informal shared password.

Test the workflow during absence and handover. A useful role address should continue functioning when the usual person is away. Record how urgent messages are escalated and how duplicates or conflicting replies are avoided. A larger support volume may need a dedicated ticketing process; an email address alone does not provide every feature of a helpdesk.

Make ownership and handover part of the work

A digital service should remain accessible when a staff member, freelancer or agency leaves. Put business assets in accounts controlled by the organisation, use named access where the platform supports it and avoid relying on one person's private email address for recovery. The precise permissions available will depend on the service, so check the current controls rather than assuming every product has the same roles.

Document the important locations: the registrar, website platform, hosting account, email administration area, backups and billing records. Describe what each account controls and which other services depend on it. This inventory is particularly useful when a supplier changes or when several people have contributed to the same project over time.

Keep passwords, recovery codes and private keys in an appropriate credential store, separate from public-facing project notes. Grant only the access a person needs, remove obsolete access and maintain a way to recover the account if the normal administrator is unavailable. Where multifactor authentication is available, set it up with a recovery process that does not create another single point of failure.

Finish with a practical handover test. The receiving person should be able to identify the right account, find the relevant documentation and complete a safe routine action. A list of logins is not enough if nobody understands the relationship between them. Include renewal dates, escalation contacts and the process for approving future changes.

Compare the full service and renewal terms

Compare services against a consistent list of requirements rather than the largest discount on a sales page. Introductory prices, renewal prices, billing periods and optional extras can change the practical cost. Read the current product page and checkout details before ordering, and distinguish the advertised headline from the exact configuration selected in the basket.

Features that sound similar can cover different responsibilities. A managed service may handle one specific task while leaving application updates or content changes to the customer. A backup feature may cover a particular data source but exclude another service. Ask who does each necessary job, what access they require and what happens when the normal process fails.

Avoid treating an upgrade as a diagnosis. More capacity can help a genuinely constrained application, but it will not necessarily correct a broken configuration, an inaccessible page or an unclear enquiry process. Likewise, purchasing a domain, certificate or mailbox does not automatically complete the work of connecting it to the website and testing the result.

Keep a copy of the terms and configuration that informed the decision. Note who owns the subscription, where renewal notices go and how to obtain help through the provider's current support routes. Review the service after launch against actual use. A modest plan that meets the requirements and can be operated reliably is often a better fit than a complex package nobody on the team can administer.

Worked hypothetical example

Consider a hypothetical project involving a company completing an employee departure process. This example illustrates a decision process; it is not a claim about a real Trodomains customer or a measured result. The project owner first records the relevant services and accounts, then defines the action that needs to work at the end. The owner keeps any unrelated service in scope for continuity checks without moving it unnecessarily. The team writes down the current position and selects a small test that represents the important workflow. If the test fails, it records the specific stage and investigates that evidence instead of buying an unrelated upgrade or making several new changes together. Once the cause or requirements are clearer, the team compares a suitable service against the real operating responsibilities and current terms. The final check follows the user journey through to its business outcome, not merely to an attractive page or a saved setting. The owner records the outcome and any limitations, assigns follow-up work and keeps the recovery information accessible to the right people. The useful lesson is the method: define, test, verify and retain control. The time, cost and result would depend on the actual project.

Decision and verification checklist

Keep the evidence proportionate to the decision. For a simple content change, a recorded review and end-to-end check may be enough. A production migration, account-security event or transactional recovery can need a more detailed record and relevant technical expertise. Do not use the table as permission to make a destructive change without understanding its scope.

Before closing the task, confirm who now owns routine operation, which notices they receive and where the recovery instructions are kept. Check that access no longer depends on an obsolete supplier or staff account. Set a follow-up review against the original objective and keep unresolved points visible. Successful operation means the business can maintain the result, not only that the initial change was completed.

Frequently asked questions

Is a role address the same as an extra mailbox?

Not necessarily. It can be implemented as an alias, forwarding arrangement, separate mailbox or shared resource, depending on the provider and current plan. Check access, storage and licensing before choosing. The team still needs an owner, a reply process and absence cover; an address by itself does not establish that incoming customer requests will be handled.

Do authentication records guarantee inbox delivery?

No. SPF, DKIM and DMARC support assessment of sending identity and alignment, but delivery also depends on other factors, including receiver decisions and legitimate sending practices. Authentication is not encryption or proof that a request is honest. Verify unusual payment or credential requests independently and investigate delivery problems using the actual evidence.

Should the old email service end as soon as MX changes?

Allow appropriate overlap and verify the required data and workflows before decommissioning. DNS caches and ongoing user activity can complicate a migration. Check receiving, sending, role addresses, clients and non-mail data where relevant. Review current billing and cancellation terms, and make the final decision against the documented acceptance checks rather than a single successful message.

Does every device contain an independent backup?

A synchronised client is not automatically a separate recovery copy. Deletion or account changes can propagate, and cached messages may not include every required data type. Check the current service's retention and recovery scope and test any separate export or backup method. Document the business information that must remain accessible when a user or provider changes.

How should Professional Email and Microsoft 365 be compared?

Start with the required workflows. An email-only service may fit domain messaging, while a broader suite may support collaboration needs that the business will actually use. Verify current plan features, licences and management responsibilities. Compare full and renewal costs, migration work and support scope rather than assuming that the longest feature list is automatically the best fit.

Your next steps

Return to the original question and confirm that the chosen action addresses it. Review the task-specific checklist, the relevant evidence and any outstanding dependency before calling the work complete. Keep the result connected to the business workflow that prompted the investigation.

Trodomains provides a relevant service destination for this guide. Compare its current details, price, renewal terms and management scope with your requirements before ordering. If the issue is configuration, content or process rather than a missing service, resolve that cause first. Keep the final checks and ownership notes so the result can be maintained.