Fix CO_E_MALFORMED_SPN 0x80004033 – SPN Malformed Error

Quick Answer for Advanced Users

Run setspn -Q / to find duplicates, then setspn -D / to remove the bad one, then setspn -A / to re-register it clean.

Why You're Seeing This

This error means Windows tried to authenticate using Kerberos, but the SPN it found was garbage. The format's wrong, or there's a duplicate. Happens all the time when someone renames a server, moves a service account between domains, or just types the SPN wrong in a script. I had a client last month whose entire print queue died because of this — someone changed the DNS alias for the print server but forgot to update the SPNs. Every print job failed with this exact error.

Fix Steps

1. Identify the service and account. Check the event log for the exact service name. Example: MSSQLSvc/sqlserver.contoso.com:1433 is SQL Server. The error message in the Application log often tells you which SPN.
2. Check for duplicates. Open an admin command prompt. Run setspn -Q service/hostname. If it returns more than one account, you've got duplicates. That's your culprit.
3. Delete the bad SPN. Use setspn -D service/hostname offending_account. You need the exact account domain\username.
4. Re-register the SPN. Run setspn -A service/hostname correct_account. For SQL Server, you'd also run setspn -A MSSQLSvc/hostname:port correct_account.
5. Force Kerberos to refresh. On the client machine, run klist purge in an admin command prompt. Then try the operation again.

Alternative Fixes

If deleting and re-adding doesn't work, check if the hostname in the SPN matches the DNS name the client is using. A client connecting to server1.corp.com needs an SPN for that exact FQDN, not just server1. Also, if the server is behind a load balancer, the SPN must match the virtual name, not the physical node. Had a case where the load balancer's hostname was in DNS but the SPN was for the node — took two hours to find.

Another option: if you're dealing with COM+ or DCOM, verify the service account has the right permissions. Sometimes the account is correct but can't authenticate because SPN is fine but delegation is broken. Check with setspn -L accountname to list all SPNs. If you see an SPN that looks like host/server1 but the client is using server1.corp.com, add the FQDN version.

Prevention

Never manually edit SPNs unless you have to. Use Group Policy or scripts to set them consistently. When you rename a server, run setspn -X to check for duplicates before and after. And if you're using a service account, keep a document of which SPNs it owns. I swear, half the calls I get are from some admin who typed an SPN wrong six months ago and now it's biting them.