Cybersecurity

mins

How to Defederate GoDaddy Microsoft 365 - Step-by-Step Guide (2026)

Published on
February 20, 2026
How to Defederate GoDaddy

If your Microsoft 365 environment was set up through GoDaddy, there's a good chance GoDaddy still controls more of your tenant than you realise. They manage your federation, hold delegated admin access, and sit between you and Microsoft on almost every administrative decision, limiting your ability to enforce security policies, manage licensing, and access direct Microsoft support.

Defederating fixes that. It moves your Microsoft 365 tenant out of GoDaddy's managed environment and puts you back in full control.

This guide covers the complete process for 2026, including a critical new step added in November 2025 that most older guides miss entirely. Follow the steps in order. Don't skip ahead to cancellation.

What you'll need:

  • Global Admin access to your Microsoft 365 tenant (we cover how to get this if GoDaddy holds it)
  • Access to your DNS provider - GoDaddy, Cloudflare, or wherever your domain records live
  • About 60–90 minutes for the core process; DNS propagation adds 24–48 hours
Rather have an expert handle this?
CyberQuell's team defederates GoDaddy tenants routinely - with zero downtime and a security hardening pass included.

See our GoDaddy Defederation Service →
  OR  Book a free 15-min consultation →

What Does "Federated with GoDaddy" Actually Mean?

Federation in this context means that GoDaddy manages your Microsoft 365 services, including your domain and email setup. When your domain is federated with GoDaddy, GoDaddy controls much of the configuration and administration for your Microsoft 365 tenant - licensing, user management, DNS settings, and critically, how your users authenticate.

Instead of Microsoft handling your logins directly, GoDaddy sits in the middle and routes authentication. This creates a dependency that limits what you can do, how you can secure your environment, and what support you can access.

What you lose when you're federated through GoDaddy

Control Area GoDaddy-Federated Fully Managed by You
User login routing GoDaddy controls it Microsoft handles it directly
MFA & Conditional Access Restricted or unavailable Full control
License management GoDaddy-bundled Direct from Microsoft
Admin settings Limited Full Global Admin rights
Direct Microsoft support Blocked on many tenant issues Full access
Third-party IdP (Okta, etc.) Cannot configure Full control

Benefits of defederating

  • Full Global Admin rights over your entire tenant
  • Ability to enforce MFA, Conditional Access, and Zero Trust policies
  • Direct licensing from Microsoft - pick plans that fit your needs
  • Full access to Microsoft Defender for Office 365 and the complete security toolset
  • Direct Microsoft support access for tenant-level issues

Before You Start, Is Defederation Right for You?

For most organisations using GoDaddy-managed Microsoft 365, defederation is the right move,  especially as your security and compliance requirements mature. But there are a few situations where you should pause first.

You should definitely defederate if:

  • You need to enforce MFA or Conditional Access policies and GoDaddy's layer is blocking it
  • You're planning a migration to direct Microsoft 365 or Google Workspace
  • A compliance audit has flagged federated admin access as a control gap
  • You want direct Microsoft support for tenant-level issues
  • You're an MSP taking over an existing client tenant

Consider pausing if:

  • You rely heavily on GoDaddy-bundled services (hosting, website builder, marketing tools) tied to your Microsoft 365 subscription. Have a replacement plan ready first
  • You're mid-contract with early termination fees. Do the maths before proceeding
  • You have no in-house IT support and no MSP partner. Defederation requires technical precision; an error in DNS or PowerShell can cause outages
Note for 2026: GoDaddy has been actively pushing customers toward direct Microsoft relationships. The defederation process is now more streamlined and better documented than it was two years ago. If you've been putting this off, now is a good time.

The Critical Warning: Read Before You Cancel Anything

Before you touch anything in GoDaddy's portal, you need to understand one thing that almost every incomplete guide skips:

If you cancel your GoDaddy subscription before removing them as Delegated Admin, GoDaddy runs an automated script that deletes all users in your tenant and removes your primary domain.

This is not a hypothetical. It happens. The account deletion is triggered by GoDaddy's offboarding automation and is not reversible through standard Microsoft support channels. Recovering from it requires a Microsoft escalation and can take days — during which your business has no email, no Teams, and no Microsoft 365 access.

The safe sequence is non-negotiable:

  1. Complete all defederation steps (Sections 5–12)
  2. Remove GoDaddy as Delegated Admin (Section 12)
  3. Remove the GoDaddy Enterprise App from Azure AD (Section 13)
  4. Confirm both are done and verified
  5. Only then: cancel your GoDaddy Microsoft 365 subscription (Section 14)
If you registered your domain with GoDaddy: your domain registration is completely separate from your Microsoft 365 billing relationship. Cancelling the M365 reseller subscription does not affect your domain registration. Keep your domain, just cancel the M365 billing relationship.

Pre-Defederation Checklist

Run through this before you start. Each unchecked item is a potential point of failure during migration.

Access & credentials

  • You have Global Admin access to the Microsoft 365 Admin Center, or you know how to request it from GoDaddy (covered in Section 5)
  • You have access to your DNS provider (the portal where your MX, SPF, and DKIM records live)
  • You know which email address is the Global Admin account. It should not be a GoDaddy-managed email

Users & licenses

  • You have a full list of all users, their assigned licenses, and their roles
  • You've confirmed which users are on GoDaddy-assigned licenses vs. Microsoft-direct licenses
  • You know the total user count — you will need to reset every user's password

Email & DNS

  • You know what email security is in place — check your MX records at MXToolbox right now
    • If MX records point to GoDaddy → standard process applies
    • If MX records point to Proofpoint, Barracuda, or Mimecast → read Section 10 before touching DNS
  • Your current SPF record is documented — you'll update it post-defederation
  • DKIM status is noted — you'll enable this directly in M365 Security Center after migration

Applications & integrations

  • You've identified any third-party apps connected to M365 via OAuth (Salesforce, Slack, Zoom, backup tools, etc.) — these will need to re-authenticate after federation is removed
  • Any backup solution using GoDaddy-managed credentials is noted — it will break and need to be reconnected

SharePoint

  • Users have been warned that SharePoint and OneDrive URLs may require re-bookmarking
  • Any internal documentation or intranet pages with hardcoded SharePoint links are noted for post-migration update

Scheduling & communication

  • You've scheduled this during a low-traffic window. Weekend evenings are strongly recommended
  • Users have been notified at least 48 hours in advance that they will need to reset their passwords and re-authenticate on all devices
  • Your helpdesk (or you) is available during and immediately after the process to handle re-authentication issues

Step 1 - Get Global Admin Access from GoDaddy

Before you can run any defederation commands, you need confirmed Global Admin access to your Microsoft 365 tenant. In many GoDaddy-federated setups, GoDaddy holds the primary Global Admin role.

How to request Global Admin access

  1. Log into your GoDaddy account and navigate to your Microsoft 365 product
  2. Look for an option to "Transfer Admin Access" or contact GoDaddy support directly
  3. GoDaddy will typically assign you a Global Admin account — confirm this by logging into admin.microsoft.com and checking that your account shows the Global Administrator role under Users → Active users → [your account] → Roles

If GoDaddy is unresponsive: Escalate through Microsoft Support by calling the Microsoft 365 admin support line. Provide your tenant domain and explain that you are the domain owner seeking to establish direct Global Admin access. Microsoft can verify ownership through domain DNS and assist in breaking the GoDaddy dependency.

Verify you have Global Admin before proceeding. Do not attempt the PowerShell commands in Section 7 without confirming this.

Step 2 - Prepare Your End Users

Defederation requires every user to reset their password. If users don't know this is coming, you'll get a flood of "I can't log in" support requests at 8am on a Monday.

Send this notification 48–72 hours before:

Subject: Important: Email system update on [Date] — action required

Hi team,

We're making an important update to how our Microsoft 365 environment is managed. This will improve our security posture and give us full control over our tools and policies.

What's happening: We're moving our Microsoft 365 tenant out of GoDaddy's managed environment.

What this means for you:

  • The change will happen on [Date] starting at approximately [Time]
  • You will be logged out of Outlook, Teams, and all Microsoft 365 apps
  • You will need to reset your password before you can log back in
  • Your emails, files, and calendar data are not affected — everything will be there when you log back in

What you need to do: When prompted, follow the password reset steps. Use a password you haven't used before. If you have Microsoft Authenticator set up, you may need to re-register it.

If you have any issues logging back in, contact [IT contact / helpdesk email] immediately.

— IT Team

Prepare your helpdesk with answers to:

  • Where to go to reset a password (aka.ms/sspr or the admin-triggered reset process)
  • How to reconnect Outlook on desktop and mobile
  • How to re-authenticate the Teams mobile app
  • What to do if the Microsoft Authenticator app prompts have changed

Step 3 - Remove Federation with PowerShell

This is the core defederation step. It converts your domain's authentication method from "Federated" (GoDaddy-managed) to "Managed" (directly Microsoft).

Install the Microsoft Graph PowerShell SDK

Use the Microsoft Graph SDK — not the legacy MSOnline module, which is being deprecated.

Install-Module -Name Microsoft.Graph -Scope CurrentUser

Check your current domain federation status

Connect-MgGraph -Scopes "Domain.ReadWrite.All", "User.ReadWrite.All", "Directory.ReadWrite.All"

Get-MgDomain -DomainId "yourdomain.com" | Select-Object Id, AuthenticationType

The output should show AuthenticationType: Federated. Once done, it should show Managed.

Convert the domain from Federated to Managed

Set-MsolDomainAuthentication -DomainName "yourdomain.com" -Authentication Managed

Note: If you get a deprecation warning on Set-MsolDomainAuthentication, use the Graph API approach instead:
$params = @{ authenticationType = "Managed" }
Update-MgDomain -DomainId "yourdomain.com" -BodyParameter $params

Verify the conversion

Get-MgDomain -DomainId "yourdomain.com" | Select-Object Id, AuthenticationType

This should now return AuthenticationType: Managed. If it still shows Federated, wait 10–15 minutes and run the verification again before re-running the conversion command.

Common errors

  • "Insufficient privileges" — Your account doesn't have an active Global Admin role or the session hasn't refreshed. Disconnect (Disconnect-MgGraph), wait 5 minutes, reconnect, and retry.
  • Domain stuck in "Pending" — Wait 15 minutes, re-run the verification. If still pending after 30 minutes, sign out of the Admin Center, sign back in, and check domain status under Settings → Domains.

Step 4 - Reset All User Passwords

Defederation removes the federated authentication trust between GoDaddy and Microsoft. Every user's existing login token is now invalid. They must reset their passwords before they can access any Microsoft 365 service — email, Teams, SharePoint, everything. This is expected behaviour, not an error.

Option A: Single user reset (Admin Center UI)

For tenants with fewer than 10 users:

  1. Go to Microsoft 365 Admin Center → Users → Active Users
  2. Select the user and click Reset password
  3. Check Require this user to change their password when they first sign in
  4. Send the temporary password via a secondary channel — SMS, personal email, or phone call (not their M365 email, which they can't access yet)

Option B: Bulk reset via PowerShell (recommended for 10+ users)

# Connect to Microsoft Graph

Connect-MgGraph -Scopes "User.ReadWrite.All"

# Get all member accounts (excludes guest accounts)

$users = Get-MgUser -All | Where-Object { $_.UserType -eq "Member" }

# Set a temporary password — update this to meet your password policy

$tempPassword = "TempPass@" + (Get-Random -Minimum 1000 -Maximum 9999)

# Build the password profile

$passwordProfile = @{

    Password                      = $tempPassword

    ForceChangePasswordNextSignIn = $true

}

# Reset password for each user

foreach ($user in $users) {

    Update-MgUser -UserId $user.Id -PasswordProfile $passwordProfile

    Write-Host "Password reset for: $($user.DisplayName) - $($user.UserPrincipalName)"

}

Write-Host ""

Write-Host "All passwords reset to: $tempPassword"

Write-Host "Users will be required to create a new password on first login."

Communicate the temporary password to users via SMS, Teams mobile (if already signed in on a mobile device), or personal email — before they try to log in.

Option C: Bulk reset via CSV (for unique per-user temporary passwords)

# CSV format: UserPrincipalName,TempPassword

# Example row: john@yourcompany.com,Welcome2026!

Connect-MgGraph -Scopes "User.ReadWrite.All"

$users = Import-Csv -Path "C:\users_to_reset.csv"

foreach ($user in $users) {

    $passwordProfile = @{

        Password                      = $user.TempPassword

        ForceChangePasswordNextSignIn = $true

    }

    Update-MgUser -UserId $user.UserPrincipalName -PasswordProfile $passwordProfile

    Write-Host "Reset complete: $($user.UserPrincipalName)"

}

What users will experience:

  • Signed out of all Microsoft 365 apps on all devices simultaneously
  • Prompted to set a new password on next login attempt
  • Microsoft Authenticator pairings may need to be re-established if MFA is active
  • Mobile apps (Outlook, Teams) will require manual re-sign-in

Step 5 - Reassign Licenses

Under GoDaddy's managed environment, licenses were assigned through GoDaddy's billing layer. Now that you're managing the tenant directly, confirm and reassign licenses from Microsoft.

  1. Go to Microsoft 365 Admin Center → Billing → Licenses
  2. Verify your available license counts match what you expect
  3. Go to Users → Active users and check each user's assigned license
  4. For any user showing an unassigned or GoDaddy-specific license, click their profile → Licenses and apps → assign the correct plan

Purchasing going forward - CSP vs. Microsoft Direct

  • Microsoft Direct: Buy licenses from Microsoft at microsoft.com/microsoft-365. Simple, standard pricing, direct relationship with Microsoft support.
  • CSP (Cloud Solution Provider): Buy through a Microsoft partner. Often includes bundled support, consolidated billing, and partner-managed licensing. Recommended for organisations that want a managed IT relationship.

If you don't already have a licensing arrangement post-GoDaddy, contact CyberQuell to discuss CSP licensing options.

Step 6 - Handle Third-Party Email Security

This section only applies if you use Proofpoint, Barracuda, Mimecast, or another third-party email security vendor. To check: go to MXToolbox, enter your domain, and look at your MX records. If they point to anything other than *.mail.protection.outlook.com, read this section before updating DNS.

Why this step matters

Under GoDaddy's federated setup, your email security vendor's connection to your M365 tenant ran through GoDaddy's delegated access layer. When you remove that layer, connector configurations can break and inbound mail can queue or bounce during the transition. The fix is to re-establish your email security vendor's connection directly with your now-independent tenant.

Proofpoint

Proofpoint routes inbound mail via its own MX records (e.g., yourdomain.pphosted.com).

During defederation: Do not change your MX records as part of the standard DNS update in Section 11. Your MX records should continue pointing to Proofpoint, not directly to Microsoft.

After defederation is complete:

  1. Log into the Proofpoint Admin Console
  2. Navigate to Email Firewall → Relay (Inbound) and verify the smart host still points to your M365 inbound address: yourdomain-com.mail.protection.outlook.com
  3. Update your SPF record to include both Proofpoint and Microsoft:
    v=spf1 include:pphosted.com include:spf.protection.outlook.com -all
  4. Enable DKIM signing in both Proofpoint and Microsoft 365 Security Center, configure one to sign and one to verify, not both signing simultaneously
  5. Send test emails inbound and outbound before closing the change window

Barracuda Email Security Gateway

  1. Barracuda routes inbound via its own MX (*.barracudanetworks.com) — leave these unchanged during defederation
  2. After defederation, log into Barracuda Cloud Control and verify the destination server still shows your M365 MX address under Domains
  3. If the inbound connector was originally provisioned by GoDaddy, re-create it:
    • In M365 Admin Center → Exchange Admin Center → Mail flow → Connectors
    • Delete the old GoDaddy-provisioned inbound connector
    • Create a new inbound connector from Barracuda using Barracuda's current IP ranges
  4. Update your SPF record:
    v=spf1 include:barracudanetworks.com include:spf.protection.outlook.com -all

Mimecast

  1. Mimecast MX records are independent of GoDaddy — leave them unchanged
  2. After defederation, log into Mimecast Administration Console
  3. Navigate to Administration → Gateway → Policies and verify delivery routes point to the correct M365 inbound connector
  4. If Mimecast was using a GoDaddy-delegated Azure AD app registration for directory sync, re-grant permissions:
    • Azure AD → App registrations → find the Mimecast app → re-grant admin consent
  5. Test inbound and outbound mail flow before closing the change window

No third-party email security?

If you're currently relying on GoDaddy's basic email filtering, defederation is the right moment to upgrade. With your tenant fully under your control, you can now configure Microsoft Defender for Office 365 directly — including anti-phishing policies, safe links, and safe attachments that GoDaddy's federated environment previously restricted. See our Email Security with Microsoft Defender for Office 365 service →

Step 7 - Update DNS Records

If you have Proofpoint, Barracuda, or Mimecast: re-read Section 10 before updating MX records. Your MX records may need to stay pointing at your email security vendor, not Microsoft directly.

MX Record (Mail Exchange)

Points inbound email to Microsoft's servers. Find your exact value in Microsoft 365 Admin Center → Settings → Domains → [your domain] → DNS records.

Type:     MX

Name:     @ (or your domain)

Value:    yourdomain-com.mail.protection.outlook.com

Priority: 0

SPF Record (Sender Policy Framework)

Prevents spoofing by declaring which servers can send email for your domain.

Type:  TXT

Name:  @

Value: v=spf1 include:spf.protection.outlook.com -all

If you use third-party sending tools (Mailchimp, HubSpot, Salesforce), include them:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

DKIM (DomainKeys Identified Mail)

  1. Go to security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM
  2. Select your domain and click Enable — Microsoft generates two CNAME records
  3. Add both CNAME records to your DNS provider

DMARC Record

Start with a reporting-only policy and tighten it over time:

Type:  TXT

Name:  _dmarc

Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Once you've confirmed clean mail flow over a few weeks, graduate to p=quarantine then p=reject.

Autodiscover (for Outlook auto-configuration)

Type:  CNAME

Name:  autodiscover

Value: autodiscover.outlook.com

DNS propagation timing

DNS changes propagate globally over 24–48 hours. Most mail servers pick up new records within 2–4 hours, but some may cache old records longer. Use MXToolbox to monitor propagation — don't make additional DNS changes during this window, as each change restarts the propagation clock.

Validation tools:

Step 8 - Remove GoDaddy as Delegated Admin

This step removes GoDaddy's ability to administer your tenant. Do not skip it.

  1. Go to Microsoft 365 Admin Center → Settings → Partner relationships
  2. Find GoDaddy in the partner list
  3. Select their entry and click Remove partner
  4. Confirm the removal

Verify it's done

  • The partner relationships page should be empty (or show only your intended partners)
  • Go to Users → Active users and search for any accounts with @godaddy.com or @secureserver.net addresses - delete any you find

If you're an MSP managing this on behalf of a client: be careful not to remove your own GDAP relationship. Only remove GoDaddy's entry. Your own partner relationship will appear separately.

Step 9 - Remove the Enterprise App (Critical - November 2025 Requirement)

⚠️ If you followed a guide written before November 2025, stop here and complete this step before cancelling GoDaddy. This requirement is new. Skipping it leaves GoDaddy with persistent access to your tenant even after you've removed their delegated admin relationship.

What's the issue?

When GoDaddy sets up a federated Microsoft 365 tenant, they install an enterprise application in your Azure Active Directory called "Partner Center Web App" (sometimes listed as "MicrosoftPartnerCenter"). This application has API permissions that allow GoDaddy to authenticate into your tenant and perform administrative actions.

Removing GoDaddy as a Delegated Admin (Step 8) does not remove this application. The app continues to exist in your Azure AD with its permissions intact. As long as it's there, GoDaddy retains a technical pathway into your environment — even after you've formally ended the partner relationship. This is a security risk.

How to find and remove it

  1. Go to the Azure Active Directory portal and sign in with your Global Admin account
  2. In the left menu, click Enterprise applications
  3. In the search bar, type Partner Center — look for "Partner Center Web App" or "MicrosoftPartnerCenter"
  4. Click the application to open it
  5. Verify it belongs to GoDaddy by reviewing the Application ID and publisher details in the Properties tab
  6. In the left menu of that app, click Properties
  7. Click Delete at the top and confirm when prompted

Verify it's gone

  1. Refresh the Enterprise Applications list and search Partner Center again — it should return no results
  2. Go to Azure AD → App registrations → All applications and search again to confirm no residual registration
  3. Check Azure AD → Audit logs — you should see a "Delete application" event confirming the removal

What if I can't find the app?

Not every GoDaddy-federated tenant has this app — it depends on how the tenant was originally provisioned. If your search returns nothing, you're clear. Do not search for alternatives or delete other apps.

If you find it but get a permissions error on deletion, confirm your account has the Application Administrator or Global Administrator role in Azure AD → Roles and administrators.

Step 10 - Cancel Your GoDaddy Subscription

Only do this after the previous steps are fully complete and verified.

  1. Log into your GoDaddy account
  2. Navigate to My Products and find your Microsoft 365 subscription
  3. Cancel the Microsoft 365 reseller subscription

What to expect:

  • Your domain registration with GoDaddy is not affected
  • Any GoDaddy website hosting, marketing tools, or other products remain active unless you cancel those separately
  • If you paid for M365 licenses through GoDaddy, check whether any pro-rata refund applies under their terms

Post-Defederation Checklist

Don't close the change window until every item below is confirmed.

Authentication

  • At least 3 users from different departments have successfully logged in with new passwords
  • MFA prompts are appearing as expected on first login
  • No user is stuck in an authentication loop (see Troubleshooting section below if so)

Email

  • Send a test email inbound from an external address and confirm receipt
  • Send a test email outbound and confirm it lands in the inbox (not spam) at the recipient
  • Check mail flow in Exchange Admin Center → Mail flow → Message trace if anything looks off

Applications

  • Outlook desktop — signed in and sending/receiving
  • Teams — signed in, messages sending, calls working
  • SharePoint and OneDrive — accessible, files loading
  • Mobile apps (Outlook, Teams) — re-authenticated and functional

DNS

  • MX records updated and resolving correctly (verify at MXToolbox)
  • SPF record updated to remove GoDaddy's sending infrastructure
  • DKIM enabled in Microsoft 365 Security Center
  • DMARC record in place — minimum p=none with a reporting address

GoDaddy access — final verification

  • GoDaddy no longer appears under Admin Center → Settings → Partner relationships
  • "Partner Center Web App" no longer appears in Azure AD → Enterprise applications
  • No GoDaddy admin user accounts remain in Admin Center → Users → Active users

SharePoint

  • Communicate to users that some SharePoint URLs may have changed — provide correct links
  • Update any internal documentation, intranet pages, or bookmarked links

Security Wins You Can Unlock Now

This is one of the most important reasons to defederate — and most guides skip it entirely. Under GoDaddy's federated setup, a number of Microsoft security controls were either unavailable or operating in a degraded state. Now that you own your tenant directly, you can implement the full Microsoft security stack.

1. Conditional Access

Conditional Access is Microsoft's policy engine for controlling who can access what, from where, and under what conditions. Under GoDaddy federation, many Conditional Access policies couldn't be applied to federated users. Start with these two immediately:

  • Require MFA for all users — applies to every sign-in, every app
  • Block legacy authentication — legacy protocols like SMTP AUTH, IMAP, and POP3 without modern auth bypass MFA entirely and are a major attack vector

Both are configured in Azure AD → Security → Conditional Access → New policy.

Pro tip: Use reporting-only mode first. This lets you see what would be blocked before you enforce the policy — preventing accidental lockouts.

2. Microsoft Defender for Office 365

GoDaddy's bundled email filtering is basic. Defender for Office 365 (included in Business Premium, or available as an add-on) adds:

  • Safe Links - scans URLs in emails and Office documents at click-time, not just at delivery
  • Safe Attachments - detonates attachments in a sandbox before delivery to users
  • Anti-phishing policies - impersonation protection for your domain and key executives
  • Attack simulation training - controlled phishing simulations to train your users

Post-defederation is the right time to configure these properly. See our Email Security with Microsoft Defender for Office 365 service →

3. Microsoft Secure Score

Go to security.microsoft.com → Secure Score. This gives you a scored view of your current security posture with prioritised, actionable recommendations. Most tenants coming out of a GoDaddy-federated environment have a Secure Score below 40%. There are usually 15–20 quick wins you can address in the first week.

4. Audit Logging and Microsoft Purview

With GoDaddy's delegated access removed, your audit logs now reflect your tenant's actual activity — without GoDaddy administrative actions mixed in. Enable unified audit logging in Microsoft Purview Compliance Portal → Audit. This is a baseline requirement for SOC 2, HIPAA, and ISO 27001 compliance.

5. Azure AD Identity Protection

Available with Azure AD P2 (included in Business Premium), Identity Protection flags risky sign-ins and compromised credentials automatically. Configure risk-based Conditional Access policies to require step-up authentication or block sign-ins when anomalous activity is detected.

Want a guided security hardening pass right after defederation? See our Microsoft 365 Security Assessment service →

Troubleshooting Common Issues

"Insufficient privileges" error in PowerShell

Cause: The account doesn't have an active Global Admin role, or the session hasn't refreshed since the role was assigned.

Fix:

  1. Disconnect and reconnect: Disconnect-MgGraph then reconnect with the required scopes
  2. Confirm the account has Global Admin assigned in Admin Center → Users → Active users → [your account] → Roles
  3. If the role was just assigned, wait 5 minutes for it to propagate before retrying

Domain stuck in "Pending" or "Federated" after running the PowerShell command

Cause: The conversion command ran but hasn't fully propagated, or there's a cached federation state.

Fix:

  1. Wait 10–15 minutes and re-run the verification:
    Get-MgDomain -DomainId "yourdomain.com" | Select-Object AuthenticationType
    It should return Managed. If still Federated, re-run the conversion command.
  2. If it persists after 30 minutes, sign out of the Admin Center, sign back in, and check domain status under Settings → Domains

Users stuck in an MFA authentication loop after password reset

Cause: The user's MFA registration (Authenticator app pairing) was tied to the federated identity and is now orphaned.

Fix:

  1. Go to Admin Center → Users → Active users → [user] → Manage multifactor authentication
  2. Delete their existing MFA registrations
  3. On next login, the user will be prompted to re-register MFA from scratch

Emails bouncing or delayed after DNS update

Cause: MX record propagation is not complete — normal, takes 24–48 hours.

Fix:

  1. Check propagation at MXToolbox MX Lookup
  2. Do not change MX records again during propagation — each change extends the propagation window
  3. If bounces persist past 48 hours, verify the MX record value is exactly correct (no trailing spaces, correct priority)
  4. Check that your SPF record doesn't have a hard -all rejecting a sending source you haven't updated yet

GoDaddy admin account still visible in Active Users after removing delegated admin

Cause: Delegated admin removal removes the relationship, but doesn't automatically delete user accounts GoDaddy created in your tenant.

Fix:

  1. Go to Admin Center → Users → Active users
  2. Search for any accounts with @godaddy.com or @secureserver.net addresses
  3. Select and delete them
  4. Confirm Admin Center → Settings → Partner relationships is empty

SharePoint access broken for some users after re-authentication

Cause: SharePoint caches session tokens separately from the main M365 auth flow.

Fix:

  1. Ask the affected user to go to sharepoint.com and sign out explicitly
  2. Clear browser cookies for *.sharepoint.com and *.microsoft.com
  3. Sign back in with new credentials
  4. If the issue persists, test a private/incognito window first to rule out extension conflicts

Third-party backup tool throwing authentication errors

Cause: Backup solutions that use OAuth app registrations tied to federated auth need to re-authenticate.

Fix:

  1. Log into your backup solution's admin portal
  2. Disconnect the Microsoft 365 integration
  3. Re-connect using your new Global Admin credentials — this re-grants the required OAuth permissions
  4. Verify the backup job completes a full run successfully before considering this resolved

MFA prompting on every single login for all users

Cause: Default Microsoft security policies may trigger MFA on every session if no Conditional Access policy was configured before defederation.

Fix:

  1. Go to Azure AD → Security → Conditional Access
  2. Review any active policies — check whether any are set to "Every time" for session frequency
  3. Configure a Compliant Device policy so users on managed, compliant devices aren't challenged on every login
  4. Alternatively, configure a persistent browser session policy for trusted locations

Ready to Take Full Control?

If you've worked through this guide and everything is running smoothly, your tenant is yours. The next step is making it secure.

Prefer to hand this off entirely?
Defederation, DNS, security hardening, all handled by CyberQuell with zero downtime guaranteed.
Book a free 15-min consultation →

FAQs

Find answers to commonly asked questions about our cybersecurity solutions and services.

Will we lose emails during defederation?

No. Email data lives in Exchange Online mailboxes, which are not affected by federation status. There may be a brief period during the password reset phase where users cannot access their email, but no mail is lost. Inbound mail may queue temporarily during DNS propagation but will deliver once propagation completes.

Do users lose access to SharePoint and OneDrive during the process?

Temporarily, yes. During the password reset step, users are signed out of all Microsoft 365 services. Once they reset their password and re-authenticate, full access is restored. Data is not affected.

Will our SharePoint URLs change?

In most cases, no. SharePoint URLs are based on your tenant name (e.g., yourcompany.sharepoint.com), which does not change during defederation. The exception is if you're also changing your primary tenant domain as part of this process. If you're only defederating and keeping the same domain, URLs stay the same.

What happens to our data retention and archiving policies?

They stay intact. Retention policies, eDiscovery holds, and archive mailboxes in Microsoft Purview are tenant-level configurations, not tied to federation status.

Can we use Okta, Entra ID, or another third-party identity provider after defederation?

Yes, this is one of the primary benefits of defederating. Under GoDaddy's federated setup, you couldn't add a third-party IdP because GoDaddy controlled the federation configuration. Post-defederation, you have full control of Azure AD and can configure any supported identity provider.

What if our domain is registered with GoDaddy? Do we lose it?

No. Your domain registration is completely separate from your Microsoft 365 billing relationship. Cancelling the M365 reseller subscription does not affect your domain registration. Keep your domain registered wherever it is.

How long does the full defederation process take?

The active steps take approximately 60–90 minutes for most tenants. DNS propagation adds 24–48 hours, though email flow typically resumes within 2–4 hours for most recipients.

Can an MSP do this on behalf of a client?

Yes. If you're an MSP handling this for a client, note the following:

  • If you're a CSP partner, do not remove your own Partner Center access when removing GoDaddy's — only remove GoDaddy's entry
  • After defederation, establish a GDAP relationship with the client's tenant for ongoing scoped management
  • The Enterprise App removal step targets GoDaddy's app specifically — leave your own Partner Center app if you have one registered

See CyberQuell's White Label SOC for MSPs →

Will defederation affect our Microsoft 365 backups?

Third-party backup tools that authenticate via OAuth app registrations will lose their connection and need to be re-authenticated. No backup data is lost — you're simply reconnecting the integration

Is there a rollback option if something goes wrong?

There is no simple one-click rollback. Converting a domain from federated to managed destroys the original GoDaddy federation configuration. Most problems post-defederation are authentication or DNS issues, not data loss, and both are fully recoverable with the steps in this guide.

Protect Your Business from Cyber Threats

Get in touch with our cybersecurity experts to discuss your security needs and solutions.