SEC_E_MAX_REFERRALS_EXCEEDED (0x80090338) Fix

Quick answer

For advanced users: the client is chasing Kerberos referrals in a loop—usually because DNS points to a domain that isn't authoritative for the target SPN, or a misconfigured SPN forces cross-domain referrals. Check DNS SRV records, run setspn -Q for duplicate SPNs, and verify trust paths. If it's urgent, force NTLM on that connection.

What's actually happening here

The error 0x80090338 (SEC_E_MAX_REFERRALS_EXCEEDED) means the Kerberos client received more than the max allowed (default 10) referral tickets while trying to obtain a service ticket for a target. A referral is what happens when your domain doesn't have the target's SPN—it sends you to another domain in the forest or trust. That's normal in multi-domain forests. What's not normal is getting bounced around endlessly.

I've seen this most often in two scenarios. First, a SQL Server or IIS service account's SPN is registered on the wrong computer object, so when a client asks for MSSQLSvc/sqlserver.corp.com, the DC says "I don't host that, go ask domain B." Domain B says "Not me, try domain A." Round and round until the counter hits the ceiling. Second, DNS is pointing the client to a DC that isn't in the client's domain, or the DC's own DNS has stale SRV records that send Kerberos lookups to a domain that can't answer.

The reason step 3 works (deleting and re-adding the SPN) is that you're breaking the circular referral chain at its source. But don't jump straight there—first you need to know whether you're dealing with a duplicate SPN, a DNS issue, or a trust routing problem. The fix differs.

Fix steps (in order)

Reproduce and isolate. Note the exact client and service. Run klist on the client to purge tickets (klist purge) and retry. If the error persists, move to step 2.
Check DNS for the client's domain. On the client, run nltest /dsgetdc:yourdomain.com. If it returns a DC outside your domain or fails, your DNS is broken. Also verify the DC's SRV records: nslookup -type=SRV _kerberos._tcp.yourdomain.com. If you see foreign DCs, fix DNS first—Kerberos can't work correctly with wrong DC discovery.
Inspect SPNs for duplicates. From an admin prompt on a DC or member server with RSAT, run setspn -Q MSSQLSvc/sqlserver.corp.com (replace with your service class and name). If more than one account shows up, that's your problem. A duplicate SPN means the DC picks the wrong target, then referrals bounce. Delete the SPN from the incorrect account: setspn -D MSSQLSvc/sqlserver.corp.com WRONGACCOUNT. Keep it only on the real service account.
Verify the SPN is on the right account and is correctly scoped. For SQL Server, the SPN must match the server's FQDN or NetBIOS name as the client uses it. If clients connect via a CNAME or a load balancer VIP, that won't match the host SPN. Re-add the SPN using the exact name clients use: setspn -A MSSQLSvc/sqlserver.corp.com svc_sql. Then restart the service (SQL Server or IIS app pool) to register it.
Check trust paths if you're in a multi-domain forest. Run nltest /domain_trusts from the client and from the DC. If there are external trusts or a parent-child trust that's partially broken, referrals can loop. Look for trust attributes—TRUST_ATTRIBUTE_QUARANTINED can cause weird behavior. If you find a broken trust, that's a separate fix, but it's the root cause here.
Force NTLM as a temporary workaround. If you need access now and can't fix the root cause, you can bypass Kerberos. For a SQL connection, add TrustServerCertificate=True;Integrated Security=SSPI and set the connection string option Authentication=SqlPassword if you have credentials. For file shares, map the drive with net use \server\share /user:domain\user—that often falls back to NTLM. For IIS, disable Windows Authentication or set providers to NTLM in web.config. This is a band-aid, not a fix.

Alternative fixes if the main ones fail

Sometimes the above doesn't resolve it, because the referral loop is coming from a misconfigured realm in the Kerberos config on Unix/Linux clients. If you're on a Mac or Linux box, check /etc/krb5.conf—the [realms] section may map the service realm to a DC that doesn't exist. Fix the kdc entry to point to the correct DC.

Another angle: check the client's local Kerberos registry setting MaxReferrals. It's at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. If someone cranked it down from the default of 10, even a valid two-hop referral might exceed it. Set it to 10 or delete the value. But only do this after you've confirmed there isn't an actual loop—raising the limit on a broken setup just delays the timeout.

Also check if the server has the DisableStrictNameChecking registry key set on the target machine. That's sometimes needed for aliases, but if you've set it and then also created an SPN for the alias, you can get into referral hell. Remove the alias SPN if the key is present.

Prevention

The root cause is almost always SPN hygiene or DNS drift. Set up a scheduled task that runs setspn -X weekly—it finds duplicate SPNs automatically. For SQL Server, make sure your service accounts are dedicated—don't use a machine account unless you know the implications. When you introduce a load balancer or change the server's FQDN, immediately update SPNs; don't let old ones linger.

For DNS, enable scavenging on your AD-integrated zones and make sure DC SRV records aren't stale. If you have multiple domains, document the trust paths and test them with nltest /sc_query after any AD change. Kerberos referrals are a feature, but only when the routing is sane.

The real fix is to treat Kerberos errors as a signal that your identity infrastructure has a flaw. Patching the immediate error with NTLM is fine for tonight, but you'll see this again next time the DNS scavenger runs or a server is rebuilt without proper SPN cleanup. Spend the hour to find the duplicate SPN or the wrong DNS record—it's cheaper than explaining to your boss why the payroll app fails every Monday.