Darian Vance

Posted on Jan 16 • Originally published at wp.me

Solved: T-Minus365 Godaddy De-Federation Guide updated late 2025

#devops #programming #tutorial #cloud

🚀 Executive Summary

TL;DR: This guide provides IT professionals with updated strategies for late 2025 to de-federate Microsoft 365 from GoDaddy, regaining full administrative control. It details three methods—Direct Re-Control, Tenant-to-Tenant Migration, and Phased Partner Change—to resolve issues like restricted access and ensure seamless service continuity.

🎯 Key Takeaways

Recognizing symptoms such as restricted Global Administrator access, email delivery issues, or delayed directory synchronization is crucial for identifying the need for GoDaddy de-federation.
Meticulous DNS zone transfer and reconfiguration of essential Microsoft 365 records (MX, SPF, CNAMEs) are critical steps to ensure uninterrupted service after GoDaddy releases domain control.
PowerShell commands like Get-MsolPartnerContract, Set-MsolDomainAuthentication, and Get-MsolAccountSku are vital for verifying partner relationships, managing domain authentication types, and executing license transfers during the de-federation process.

This post provides a comprehensive guide for IT professionals navigating Microsoft 365 de-federation from GoDaddy, updated for late 2025 considerations. We detail symptoms, three distinct migration strategies, and actionable technical steps to regain full administrative control and ensure seamless service continuity.

Symptoms: Recognizing the Need for De-Federation

Before diving into solutions, it’s crucial for IT professionals to identify the tell-tale signs that your Microsoft 365 environment is still tethered to GoDaddy’s management. These symptoms often indicate a lack of full administrative control and potential future complications:

Email delivery issues, non-delivery reports (NDRs) for internal or external mail, or unexpected mail routing paths.
Authentication challenges for users, especially with modern authentication, multi-factor authentication (MFA), or conditional access policies that don’t behave as expected.
Delayed or failed directory synchronization, leading to discrepancies between your on-premises Active Directory and Azure Active Directory (if applicable).
Inability to directly manage Microsoft 365 licenses, provision new services, or modify core tenant settings without GoDaddy’s intervention or using their custom portal.
Lack of direct, unfettered access to all Microsoft 365 admin centers (e.g., Exchange Admin Center, SharePoint Admin Center, Teams Admin Center) with full Global Administrator privileges. Often, you may only have delegated admin access, which can be restrictive.
Unexplained changes in DNS records, particularly MX, SPF, or CNAME records related to Microsoft 365 services, without explicit organizational approval or knowledge.
Difficulty integrating third-party applications or services that require full Azure AD or Microsoft 365 tenant administrative control.

Solution 1: Direct M365 Tenant & Domain Re-Control (The “Takeover” Method)

This strategy is ideal for organizations that want to retain their existing Microsoft 365 tenant (which GoDaddy initially provisioned under their Cloud Solution Provider agreement) but completely remove GoDaddy’s administrative delegation and take direct control of their domain and billing. This often involves converting your subscriptions to direct Microsoft billing or a new CSP.

Key Steps for Direct Re-Control:

Engage GoDaddy for Release:

This is the crucial first step. Formally request GoDaddy to release your domain’s authoritative DNS control and transfer the billing responsibility for your Microsoft 365 subscriptions. Document all communications and confirm the exact date/time frames for these actions. GoDaddy should remove their delegated admin permissions and, ideally, convert your subscriptions to direct Microsoft billing or allow a transfer to a new CSP.

Verify M365 Tenant Ownership & Access:

Ensure you have at least one Global Administrator account that is not a GoDaddy delegated admin account (e.g., an account ending in yourcompany.onmicrosoft.com). If not, you may need GoDaddy’s help to create one.
Confirm direct, unrestricted access to admin.microsoft.com with this independent Global Admin account.
Identify and remove any lingering GoDaddy-specific service principals or enterprise applications that might retain permissions. These can sometimes grant GoDaddy continued access even after delegated admin removal.

   # Connect to Azure AD PowerShell
   Connect-MsolService

   # List any delegated admin partners. Ideally, after GoDaddy's removal, this should be empty or only list legitimate current partners.
   Get-MsolPartnerContract

   # Review service principals. Look for entries explicitly named "GoDaddy" or "GD".
   # Exercise extreme caution before removing anything you don't fully understand.
   Get-MsolServicePrincipal | Select-Object DisplayName, AppPrincipalId

DNS Zone Transfer & Reconfiguration:

Once GoDaddy confirms they’ve released your domain, transfer the domain’s authoritative DNS from GoDaddy’s servers to your preferred DNS host (e.g., Azure DNS, Cloudflare, Amazon Route 53, or an on-premises DNS server). This involves changing the nameserver records at your domain registrar.
Immediately replicate all necessary Microsoft 365 DNS records in your new DNS host. This is critical for uninterrupted service.

   # Essential Microsoft 365 DNS Records (replace 'yourdomain.com' with your actual domain)

   # MX Record (Mail Exchanger - for inbound email)
   # Type: MX
   # Host/Name: @ or yourdomain.com
   # Value: yourdomain-com.mail.protection.outlook.com
   # Priority: 0 or 10 (ensure it's the lowest numerical value for highest priority)
   # TTL: 3600 (or as recommended by your DNS host)

   # CNAME Record (Autodiscover - for Outlook and other client configuration)
   # Type: CNAME
   # Host/Name: autodiscover
   # Value: autodiscover.outlook.com
   # TTL: 3600

   # TXT Record (SPF - Sender Policy Framework for email authentication)
   # Type: TXT
   # Host/Name: @ or yourdomain.com
   # Value: v=spf1 include:spf.protection.outlook.com -all
   # TTL: 3600
   # (Adjust '-all' to '~all' if you need a softfail, and add other sending IPs if applicable)

   # CNAME Records (Teams/Skype for Business - for client sign-in and connectivity)
   # Type: CNAME
   # Host/Name: sip
   # Value: sipdir.online.lync.com
   # TTL: 3600

   # Type: CNAME
   # Host/Name: lyncdiscover
   # Value: webdir.online.lync.com
   # TTL: 3600

   # TXT Record (Microsoft 365 Domain Verification)
   # Type: TXT
   # Host/Name: @ or yourdomain.com
   # Value: MS=msXXXXXXXX (this is a unique value provided by Microsoft 365)
   # TTL: 3600

Update Domain Authentication (If Federate):

While less common for standard GoDaddy M365 offerings, if your domain was set to a federated authentication type (e.g., for specific hybrid setups or ADFS integration previously managed by GoDaddy), you must convert it to a managed domain to ensure direct authentication via Azure AD.

   # Connect to MSOnline PowerShell
   Connect-MsolService

   # Verify current domain authentication type for your domain
   Get-MsolDomain -DomainName "yourdomain.com" | Select-Object Authentication

   # If the output shows 'Federated', convert it to 'Managed'.
   # This command will remove the federation trust and allow Azure AD to manage user authentication.
   Set-MsolDomainAuthentication -DomainName "yourdomain.com" -Authentication Managed -Confirm:$false

Post-Migration Verification:

Thoroughly test email flow by sending and receiving emails internally and externally.
Verify user authentication from various clients (Outlook desktop, Outlook Web App, Teams, SharePoint).
Check the Microsoft 365 Service Health Dashboard in admin.microsoft.com for any alerts.
Ensure new user provisioning, license assignments, and administrative tasks function correctly.

Solution 2: Tenant-to-Tenant Migration (The “Fresh Start” Method)

This approach involves moving all users, data, and services from your existing GoDaddy-provisioned Microsoft 365 tenant to a completely new, independently managed Microsoft 365 tenant. This is often the preferred choice for larger organizations seeking a clean break, integrating with an existing corporate tenant, or when the GoDaddy-managed tenant is perceived as too restrictive or customized.

Prerequisites for Tenant-to-Tenant Migration:

A new, target Microsoft 365 tenant established and configured with basic settings and at least one Global Administrator.
Adequate licensing in the target tenant for all users and services being migrated.
A robust migration tool (e.g., BitTitan MigrationWiz, AvePoint Fly, or other specialized tools) is highly recommended for data fidelity and efficiency. Native PowerShell scripting can be used for some aspects but is often more complex for full data migration.
A clear communication plan for end-users regarding new credentials, data migration timelines, and potential service interruptions.

Detailed Migration Steps:

Initial Preparation of Source and Target Tenants:

Source (GoDaddy) Tenant: Conduct a comprehensive audit of all users, mailboxes (including shared mailboxes and resource mailboxes), SharePoint sites, Teams, and OneDrive data. Document all distribution lists, security groups, and any custom configurations.
Target Tenant: Provision initial global admin accounts. Verify the default yourcompany.onmicrosoft.com domain. Configure any required organizational settings, security defaults, or conditional access policies.
Create a dedicated migration account in both tenants with the necessary administrative permissions (e.g., Application Impersonation for mailboxes, SharePoint Admin roles).
1. Domain Coexistence and Preparation:

To minimize downtime, a common strategy is to perform a staged domain transfer. This allows you to migrate data while users are still active in the source tenant.

Free Up Primary Domain in Source: Before adding your custom domain (yourdomain.com) to the target tenant, it must be removed from the source GoDaddy tenant. This usually involves changing the primary email address and User Principal Name (UPN) for all users in the *source* tenant from user@yourdomain.com to an address using the default .onmicrosoft.com suffix (e.g., user@yourcompany.onmicrosoft.com).

   # Connect to Exchange Online PowerShell in the source tenant
   Connect-ExchangeOnline -UserPrincipalName admin@yourcompany.onmicrosoft.com

   # Get all mailboxes and update their primary SMTP address and UPN
   Get-Mailbox -ResultSize Unlimited | ForEach-Object {
       $user = $_
       $oldPrimarySmtp = ($user.EmailAddresses | Where-Object {$_.IsPrimarySMTPAddress}).SmtpAddress
       $newPrimarySmtp = $user.UserPrincipalName -replace "@yourdomain.com","@yourcompany.onmicrosoft.com"

       # Set the new .onmicrosoft.com address as primary, keep old custom domain as a secondary SMTP address for continued mail flow during transition.
       Set-Mailbox $user.Identity -PrimarySmtpAddress $newPrimarySmtp -EmailAddresses @{add=$oldPrimarySmtp} -ErrorAction SilentlyContinue

       # Also update the User Principal Name (UPN) in Azure AD
       # Connect-MsolService (if not already connected)
       # Set-MsolUserPrincipalName -UserPrincipalName $user.UserPrincipalName -NewUserPrincipalName ($user.UserPrincipalName -replace "@yourdomain.com","@yourcompany.onmicrosoft.com")

       Write-Host "Updated $($user.UserPrincipalName): Primary SMTP/UPN changed to $newPrimarySmtp"
   }

Add Domain to Target Tenant: Once the custom domain is no longer primary in the source tenant, you can add yourdomain.com to the *target* tenant and verify it via a TXT DNS record (similar to Solution 1, Step 3).
Provision Users in Target: Create new user accounts in the target tenant. Assign appropriate licenses. For password hashes, consider implementing Azure AD Connect with Password Hash Synchronization or ADFS for seamless sign-on if integrating with on-premises AD.
1. Data Migration Execution:
Mailboxes: Utilize your chosen migration tool to migrate mailbox content (emails, calendars, contacts) from the source to the target tenant. Most tools support pre-stage migrations to move historical data, followed by incremental passes to catch new changes, and a final cutover pass.
OneDrive & SharePoint: Use specialized migration tools for OneDrive content, preserving permissions and metadata. For SharePoint Online, tools are essential for migrating sites, lists, libraries, and permissions.
Teams: Teams content (chats, files, tabs, channels) also requires specialized migration tools. Teams settings and membership often need to be re-created via scripting or manually.
1. DNS Cutover:
Once all data is migrated, verified, and users are ready, update your domain’s DNS records (MX, CNAMEs, SPF) to point to the new target Microsoft 365 tenant. This is the final cutover point.
Ensure the domain is completely removed from the source GoDaddy tenant before performing the final DNS cutover.
1. Post-Migration Cleanup & Verification:
Remove all users and data from the source GoDaddy tenant.
Cancel GoDaddy subscriptions associated with Microsoft 365.
Thoroughly test all services (email, Teams calls, SharePoint access) in the new tenant.
Update any relevant applications, connectors, or devices that might have hard-coded references to the old tenant.

Solution 3: Phased Migration via Partner Change (The “Managed Transition” Method)

This strategy focuses on transitioning your existing Microsoft 365 subscriptions and domain management from GoDaddy to either direct Microsoft billing or a different Cloud Solution Provider (CSP). This approach is suitable when you want to retain your existing tenant but require a managed disentanglement from GoDaddy’s specific management layers without performing a full tenant-to-tenant migration.

Key Principles:

Minimize disruption by leveraging your existing tenant infrastructure and data.
The primary focus is on administrative control transfer and billing, not data migration.
Requires active cooperation (at least initially) from GoDaddy for a smooth transition.

Steps for a Managed Transition:

Select a New Partner or Direct Billing:

Research and select a new CSP or decide to move to direct billing with Microsoft. Evaluate their support, pricing, and technical expertise.
If opting for a new CSP, they will need delegated admin access to your existing Microsoft 365 tenant. This is typically granted by accepting an “Admin relationship” link they provide.
1. Initiate Subscription Transfer:
Formally inform GoDaddy of your intent to transfer your Microsoft 365 subscriptions. They will provide their specific process, which may involve canceling existing GoDaddy-billed subscriptions and purchasing new ones through Microsoft directly or your new CSP.
Critical: Ensure license continuity. The new subscriptions must be in place and assigned to users before the GoDaddy subscriptions are fully removed to avoid any service interruption or data loss due to unassigned licenses.

   # Connect to MSOnline PowerShell
   Connect-MsolService

   # List current subscriptions and their IDs (SkuPartNumber will often indicate the provider)
   Get-MsolAccountSku | Select-Object SkuPartNumber, ActiveUnits, ConsumedUnits, @{N="LicensesRemaining";E={$_.ActiveUnits - $_.ConsumedUnits}}

   # Process for license transfer (example - specific commands depend on actual SKUs and transfer method):
   # 1. Identify GoDaddy-provisioned SKUs.
   # 2. Purchase equivalent (or desired) SKUs from Microsoft direct or your new CSP.
   # 3. For each user, carefully remove the old GoDaddy license and assign the new license.
   #    This can be done individually or scripted.
   #
   #    # Example (DO NOT run blindly, careful planning and testing required):
   #    # For each user, get their current GoDaddy licenses
   #    $GoDaddySkuPartNumber = "ENTER_GODADDY_SKUPARTNUMBER_HERE" # e.g., "M365_BUSINESS_STANDARD"
   #    $NewSkuPartNumber = "ENTER_NEW_SKUPARTNUMBER_HERE"       # e.g., "CONTOSO:M365_BUSINESS_STANDARD"

   #    Get-MsolUser -All | ForEach-Object {
   #        $user = $_
   #        $userLicenses = Get-MsolUser -UserPrincipalName $user.UserPrincipalName | Select-Object -ExpandProperty Licenses
   #        $hasGoDaddyLicense = $userLicenses | Where-Object {$_.ServiceStatus.AccountSku.SkuPartNumber -eq $GoDaddySkuPartNumber}
   #
   #        if ($hasGoDaddyLicense) {
   #            Write-Host "Processing user $($user.UserPrincipalName)..."
   #            # Remove old GoDaddy license
   #            Remove-MsolUserLicense -UserPrincipalName $user.UserPrincipalName -LicenseContext $GoDaddySkuPartNumber -ErrorAction SilentlyContinue
   #            Write-Host "Removed GoDaddy license from $($user.UserPrincipalName)."
   #
   #            # Add new license from Microsoft/new CSP
   #            Add-MsolUserLicense -UserPrincipalName $user.UserPrincipalName -LicenseContext $NewSkuPartNumber -ErrorAction SilentlyContinue
   #            Write-Host "Added new license to $($user.UserPrincipalName)."
   #        }
   #    }

Regain Domain Control:

Request GoDaddy to release the authoritative DNS control for your domain. This process is identical to Solution 1, Step 3.
Transfer your domain’s nameservers to your own chosen DNS host.
Verify all critical Microsoft 365 DNS records are correctly configured in your new DNS host (MX, SPF, CNAMEs, etc., as detailed in Solution 1, Step 3).
1. Remove Delegated Administration:
Once all subscriptions are transferred and you have direct control over your domain and administrative access, remove GoDaddy’s delegated administrator privileges from your tenant.
In the Microsoft 365 admin center (admin.microsoft.com), navigate to Settings > Partner relationships. Locate GoDaddy in the list, select them, and choose the option to ‘Remove partner relationship’.
As an extra precaution, verify there are no lingering GoDaddy service principals or applications that might inadvertently grant them access (refer to Solution 1, Step 2 PowerShell commands).
1. Post-Transition Audit:
Confirm billing accuracy with your new provider or Microsoft direct.
Thoroughly review all tenant settings, security policies, and user permissions to ensure they align with your organizational standards, as GoDaddy might have applied their defaults.
Test email flow, user authentication, and access to all Microsoft 365 services to ensure full functionality.

Comparison of De-Federation Strategies

Choosing the right strategy depends on your current situation, desired level of control, internal resources, and tolerance for complexity and potential downtime. Below is a comparative overview:


Feature	Solution 1: Direct M365 Tenant & Domain Re-Control (“Takeover”)	Solution 2: Tenant-to-Tenant Migration (“Fresh Start”)	Solution 3: Phased Migration via Partner Change (“Managed Transition”)
Primary Goal	Regain full administrative control of existing tenant & domain; remove GoDaddy’s management layer.	Move all data/users to a brand new, independently managed M365 tenant.	Transfer M365 billing & domain management from GoDaddy to another CSP/Microsoft direct.
Existing Tenant Used?	Yes, the same tenant remains in place.	No, a new target tenant is established and utilized.	Yes, the same tenant remains in place.
Overall Complexity	Medium. Primarily involves DNS, administrative permissions, and subscription changes.	High. Extensive data migration, user recreation, and careful domain management.	Medium. Requires coordination with GoDaddy and a new partner/Microsoft.
Potential Downtime	Low-Medium (primarily during DNS propagation and cutover, which can be managed).	Medium-High (depending on the volume of data, migration tool efficiency, and user re-onboarding).	Low (focuses on subscription and admin transfer, not data movement; generally seamless).
Data Migration Required?	No. All tenant data (mailboxes, OneDrive, SharePoint) remains in its original location.	Yes. Full migration of mailboxes, OneDrive, SharePoint, Teams, etc., to the new tenant.	No. All tenant data remains in place.
GoDaddy Cooperation Required?	Essential for domain release and removal of delegated admin permissions.	Required for domain release (for the old tenant cleanup), but not for the actual migration process itself.	Highly recommended and often necessary for smooth subscription transfer and delegated admin removal.
Best Suited For	Organizations wanting to keep their existing tenant and simply remove GoDaddy’s management layer to gain direct control.	Organizations needing a complete separation, integrating into another existing corporate tenant, or where the GoDaddy tenant is perceived as too deeply customized or restricted.	Organizations looking to switch billing partners or gain more direct control over existing subscriptions while keeping their tenant and minimizing disruption.
Cost Implications	Potential for new direct Microsoft/CSP licensing costs.	Migration tool costs, new tenant licensing, potential for consultant fees.	New direct Microsoft/CSP licensing costs (potentially different from GoDaddy’s).

The “T-Minus365 Godaddy De-Federation Guide updated late 2025” implies that these processes are evolving, and staying informed about Microsoft’s and GoDaddy’s latest policies regarding CSP agreements and delegated administration is crucial. Always consult official documentation and, if necessary, engage professional services for complex migrations.

By carefully planning and executing one of these strategies, IT professionals can successfully de-federate from GoDaddy and regain full, direct control over their Microsoft 365 environment, ensuring long-term flexibility, security, and adherence to their organizational governance standards.