Microsoft 365 DNS Cleanup after sfbo retirement

Arjan Cornelissen
Office-365, Security, Teams
Page content

What You No Longer Need After Skype for Business Online’s Retirement

Many tenants still carry Skype for Business (SfBO) and Lync-era DNS baggage years after moving to Microsoft Teams. This post explains which legacy DNS records you can safely remove, when to keep the SIP federation record, and how to audit and clean up across all your verified domains.

1) Why these records existed

Historically, Skype for Business Online and Lync used several DNS records to enable client sign‑in, service discovery, and SIP routing:

  • _sip._tls.<domain> (SRV) — Directed clients to the SIP service (e.g., sipdir.online.lync.com).
  • sip.<domain> (CNAME) — Alias for the SIP service host.
  • lyncdiscover.<domain> (CNAME) — Auto‑discovery entry for client bootstrapping.
  • _sipfederationtls._tcp.<domain> (SRV) — Enabled federation (chat/calls/presence) with external organizations via sipfed.online.lync.com.
  • msoid.<domain> (CNAME) — Legacy identity (WS‑Trust) era; no longer used in modern auth.

As Microsoft retired SfBO and moved tenants to Teams Only, the client discovery/sign‑in path changed, reducing what’s needed on public DNS for Teams‑only deployments. Microsoft’s current reference for External DNS records is consolidated under Microsoft 365 services.
Sources: Microsoft Learn – External DNS

2) What changed after SfBO decommissioning

With the decommissioning of Skype for Business Online, Microsoft’s guidance for Teams‑only tenants removed the need for the three classic records (_sip._tls, sip, lyncdiscover). The only SIP‑related DNS record that can still be required is the federation SRV record when you actually federate with other organizations.
Sources: Microsoft Learn – External DNS

If you previously ran hybrid (SfB Server on‑premises) and completed your migration to Teams Only, Microsoft’s decommissioning guidance also calls out updating or removing stale SfB DNS entries as part of the final cutover.
Source: Microsoft Learn – Manage DNS when decommissioning

3) What you can safely remove (Teams‑only)

For tenants that are fully Teams‑only (no on‑prem SfB/Lync, no Islands mode):

  • Remove:
    • _sip._tls.<domain> (SRV)
    • sip.<domain> (CNAME)
    • lyncdiscover.<domain> (CNAME)
    • msoid.<domain> (CNAME)

These records are not required for Teams‑only operation and can be deleted to reduce clutter and potential security scan noise.
Sources: Microsoft Learn – External DNS

4) The one DNS record you might still need

If you use external access (federation)—i.e., your users chat/call with users in other Microsoft 365 tenants using their native identities—keep:

_sipfederationtls._tcp.<domain>  SRV  priority 100  weight 1  port 5061  target sipfed.online.lync.com

This SRV record enables SIP federation. If External access is disabled for your tenant, you can remove it.
Sources: Microsoft Learn – External DNS

Where to check:
Teams admin center → External access.
If “Users can communicate with external Teams users” is enabled, retain the federation SRV record. If disabled, you may remove it. (Federation dependency is reflected in Microsoft’s DNS and decommissioning guidance.)
Sources: Microsoft Learn – External DNS, Microsoft Learn – Manage DNS when decommissioning

5) Quick decision table

DNS record Keep or remove (Teams‑only)? Why
_sip._tls.<domain> (SRV) Remove Not needed post‑SfBO deprecation for Teams‑only.
sip.<domain> (CNAME) Remove Same as above.
lyncdiscover.<domain> (CNAME) Remove Same as above.
_sipfederationtls._tcp.<domain> (SRV) Keep only if federation is ON Required for external SIP/Teams federation.
msoid.<domain> (CNAME) Remove Legacy identity (WS‑Trust) era; not used in modern auth.

References for the above decisions: Microsoft Learn – External DNS

6) How to verify your tenant’s federation setting

  1. Open Teams admin center → External access.
  2. If “Allow communication with external Teams users” is On, your tenant uses federation—keep the SRV record.
  3. If it’s Off, you can remove _sipfederationtls._tcp.<domain>.

Supporting docs: Microsoft Learn – Manage DNS when decommissioning, Microsoft Learn – External DNS

7) How to audit your current DNS (PowerShell & CLI)

Below are lightweight checks you can run from any Windows machine or PowerShell session. Replace contoso.com with your domain(s).

PowerShell (Windows / cross‑platform)

$domain = "contoso.com"

# Legacy records that can be removed for Teams-only tenants
Resolve-DnsName -Name ("_sip._tls." + $domain) -Type SRV -ErrorAction SilentlyContinue
Resolve-DnsName -Name ("sip." + $domain) -Type CNAME -ErrorAction SilentlyContinue
Resolve-DnsName -Name ("lyncdiscover." + $domain) -Type CNAME -ErrorAction SilentlyContinue

# Federation (keep only if External access is ON)
Resolve-DnsName -Name ("_sipfederationtls._tcp." + $domain) -Type SRV -ErrorAction SilentlyContinue

If present, results will show the record details; if absent, you’ll get no output thanks to -ErrorAction SilentlyContinue. (This mirrors community validation patterns.)

Command prompt (nslookup)

nslookup -type=SRV _sip._tls.contoso.com
nslookup -type=CNAME sip.contoso.com
nslookup -type=CNAME lyncdiscover.contoso.com
nslookup -type=SRV _sipfederationtls._tcp.contoso.com

Online tools

Use MXToolbox or DNSChecker SRV/CNAME lookups to confirm removal and propagation.

8) Multi‑domain tenants: audit at scale

If your tenant has many verified domains, script the audit:

# Example: loop through all connected domains
$domains = Get-MgDomain -All

$results = foreach ($d in $domains.Id) {
  [pscustomobject]@{
    Domain         = $d
    SIP_TLS_SRV    = [bool](Resolve-DnsName "_sip._tls.$d" -Type SRV -ErrorAction SilentlyContinue)
    SIP_CNAME      = [bool](Resolve-DnsName "sip.$d" -Type CNAME -ErrorAction SilentlyContinue)
    LyncDiscover   = [bool](Resolve-DnsName "lyncdiscover.$d" -Type CNAME -ErrorAction SilentlyContinue)
    Federation_SRV = [bool](Resolve-DnsName "_sipfederationtls._tcp.$d" -Type SRV -ErrorAction SilentlyContinue)
  }
}
$results | Format-Table -AutoSize

9) Step‑by‑step cleanup

  1. Confirm Teams‑only: Ensure your tenant coexistence mode is Teams Only (TAC → Teams upgrade). Microsoft’s decommissioning steps explicitly include DNS cleanup when moving to Teams Only.
  2. Check External access: If federation is Off, plan to remove _sipfederationtls._tcp. If On, keep it.
  3. Locate your DNS zone(s): Azure DNS, Cloudflare, GoDaddy, Route53, etc.
  4. Remove legacy records: _sip._tls, sip, lyncdiscover, and msoid.
  5. Retain/adjust federation SRV: Keep or delete _sipfederationtls._tcp per step 2.
  6. Validate: Use PowerShell/nslookup to confirm removal and that federation (if retained) resolves to sipfed.online.lync.com:5061.
  7. Allow propagation: Expect up to 24–48 hours globally for TTLs to expire, depending on your DNS configuration.

10) Risks & considerations

  • Removing _sipfederationtls._tcp when you still federate will break external chat, calls, and presence with other tenants. Double‑check TAC External access first.
    Source: Microsoft Learn – External DNS
  • Keeping deprecated records doesn’t usually break Teams, but it adds noise (e.g., security scans flagging legacy endpoints) and can confuse future admins. Microsoft’s decommissioning guidance specifically instructs removing stale SfB records in Teams‑only orgs.
    Source: Microsoft Learn – Manage DNS when decommissioning
  • Hybrid or still decommissioning on‑prem SfB? Follow Microsoft’s hybrid decommission steps before DNS removal to avoid disrupting any remaining dependencies.
    Source: Microsoft Learn – Disable hybrid to complete migration

11) Conclusion

Cleaning up legacy SfBO/Lync DNS records is an easy win:

  • Reduces attack surface and scanner noise
  • Avoids admin confusion (no more “why do I see Lync/SfB in DNS?”)
  • Aligns with Microsoft’s Teams‑only guidance

Remove _sip._tls, sip, lyncdiscover, and msoid. Keep _sipfederationtls._tcp only if you use federation. You’ll end up with a leaner, more accurate DNS footprint for Microsoft 365 and Teams.

Handy references