SF.gov Subdomain Standard

The City and County of San Francisco (City) seeks to serve the public with trustworthy, consistent, reliable and safe websites, regardless of department or service. To accomplish this goal, this policy standardizes and unifies the internet domain process.

This policy establishes the guidelines and procedures for the creation, management, and governance of public-facing and public-serving subdomains under the SF.gov root domain for the City and County of San Francisco. It supports compliance with California Assembly Bill 1637 (2023-2024), the Charter of the City and County of San Francisco, and the City’s Domain registration and management policy while ensuring a consistent, secure, and user-friendly digital presence.

SF.gov is the official root domain for the City and County of San Francisco. It is managed by the Department of Technology’s Network team, which also handles the delegation of all subdomains. Digital Services builds, maintains, and improves www.SF.gov, the City’s central website. They support the Committee on Information Technology (COIT) and the Department of Technology (DT) in determining the eligibility of SF.gov subdomains.

The requirements identified in this policy apply to all information resources operated by or for the City and County of San Francisco, its departments, and commissions. Elected officials, employees, consultants, and vendors working on behalf of the City and County of San Francisco are required to comply with this policy.

Departments shall not intentionally create non-City websites through arrangements with contractors or related organizations.

Departments with existing .gov domains prior to the adoption of this policy are not subject to the standards contained herein. For simplicity for San Franciscans, COIT recommends even these departments follow the use case patterns and naming conventions for their respective subdomains.

Subdomains or A records within the SF.gov hosted zone will be provisioned on a case-by-case basis. Departments must demonstrate that one or more of the following conditions apply:

Approved Use Cases:

• Specialized Entities with a unique public identity: Healthcare facilities, commercial entities, or arts and cultural institutions with distinct operational needs that are also recognized by the public as a separate public identity
• High-Volume Specialized Content: Sites with a high volume of similar pages that warrant separation from the main SF.gov platform
• Staff-Facing Services: Internal tools and resources primarily used by City employees
• Technical Requirements: Applications used for accepting payment or custom infrastructure that cannot be accommodated within the main SF.gov platform

Ineligible Use Cases:

• Department websites that have comparable functionality to SF.gov
• Project-specific websites with limited scope or duration
• Campaigns or initiatives without significant technical or identity needs
• Services that duplicate functionality available on www.SF.gov

Software as a Service (SaaS) products with non-.gov domains

Many City departments use SaaS services that serve content to the public on another domain (e.g. sanfrancisco.nextrequest.com). As of August 2025, the California State Association of Counties (CSAC) is working with the City and County of San Francisco on a statewide determination. That is outside the remit of this standard for the time being.

Vanity domains

Per Assembly Bill 1637 (2023-2024), local government agencies (ex: City and County of San Francisco) may use a non-.gov “vanity domain” as long as it redirects to their .gov site to serve the website and its content.

For instance, a department may already have existing, highly used domains (like sfrecycles.org) or wish to register a domain for a future purpose. The department will work with DT to move the domain to their central registrar or work with DT to register the vanity domain in the future. These domains must only be used for promotional and redirect purposes, not to serve websites and their contents.

To ensure consistency, clarity, and accessibility across all City digital properties, third-level domain names must follow standardized conventions that make them easy for the public to find, remember, and trust.

These naming standards apply to all new subdomains or A Name records and help maintain a cohesive online presence for San Francisco. The following requirements balance technical best practices with user-centered design principles.

General Requirements

• Names must be clear, concise, and descriptive of the content or service
• Names should avoid acronyms or initialisms unless widely recognized by the public
• Names should not include "SF" or "San Francisco" (e.g., use library.sf.gov, not sflibrary.sf.gov)
• Names should use American English spelling conventions
• Names should be lowercase and contain only alphanumeric characters
• Hyphens may be used when necessary for clarity, but should be minimized

Requesting a new third-level domain requires a formal application process to ensure alignment with City standards and strategic goals. The process involves collaboration between the requesting department, Digital Services, and the Department of Technology to evaluate technical feasibility and policy compliance. This section outlines the required documentation, review timeline, and appeals procedure for subdomain requests.

Application Requirements

Departments seeking a third-level domain must submit a formal request to Digital Services (DS) and Department of Technology (DT) including:

• Proposed name
• Business justification addressing eligibility criteria
• Content and technical strategy
• DAIS compliance plan, if for a public-facing and public-serving website
• Designated technical and content owners
• Timeline for development and launch

DT’s SNOW team with Digital Services will develop a form to manage these requests.

Review Process

• Initial review by Digital Services (DS) within two weeks
• Technical review by the Department of Technology (DT) takes place after an initial review by Digital Services (DS), within 7 to 14 days, depending on the complexity of the request and available resources.

Appeals Process

Departments whose requests are denied may appeal the decision to the Director of COIT within 30 days of notification. Departments must email coit.staff@sfgov.org to appeal. City Administrator leadership, including the Director of COIT, the Chief Digital Services Officer, and the Chief Information Security Officer (CISO) from Department of Technology, will review appeals on a case-by-case basis.

Effective subdomain management requires clear ownership, ongoing maintenance, and accountability throughout a subdomain's lifecycle. Each subdomain must have designated owners responsible for ensuring compliance with City policies and maintaining the quality and security of their digital services. This section defines ownership responsibilities, delegation procedures, and the process for decommissioning subdomains that are no longer needed or compliant.

Ownership and Responsibilities

• Each subdomain must have designated technical and content owners in their respective departments.
• Owners are responsible for maintaining compliance with City policies and standards and must self-certify.
• DT will work with departments on delegation for third- and fourth-level domains. (For example, Digital Services was delegated archive.sf.gov and creates sites like sfdph.archive.sf.gov.) See additional details in the appendix.

Decommissioning Process

• Subdomains without substantial active use or maintenance may be recommended for decommissioning
• Domains deemed non-compliant with City policies may be required to remediate or face decommissioning
  • When a website or domain is decommissioned, a department may request a specific redirect to be maintained for at least 12 months after decommissioning. If a redirect is not provided, the site will be redirected to www.SF.gov. A department may request more than 12 months of a redirect service.

This appendix provides technical definitions and clarifications to support understanding and implementation of the subdomain standard. These definitions establish a common vocabulary for discussing domain architecture and help distinguish between related but distinct concepts such as hostnames, subdomains, and websites

Definitions

Hostname: A human-readable label assigned to a specific device (computer, server, or networked device) on a network.

• Purpose: Identifies and distinguishes devices within a network in a more user-friendly way than using IP addresses.
• Format: Composed of letters, numbers, and hyphens. Can stand-alone (server1) or be part of a fully qualified domain name (FQDN) such as server1.example.com.
• Relation to IP Addresses: Mapped to an IP address via DNS or a local hosts file to route traffic to the correct device.
• Uniqueness: Must be unique within the same domain or subdomain to avoid conflicts, except in cases of deliberate duplication for load balancing.

Subdomains: A DNS-based subdivision of a larger domain name used to organize, separate, or delegate different services, environments, or regions under the same primary domain.

• Purpose: Creates logical or functional divisions within a domain for content delivery, services, or administrative control.
• Format: Appears as a prefix before the main domain (e.g., portal.sf.gov where portal is the subdomain).
• Relationship to DNS: Treated as a separate DNS zone or record within the hierarchy of the main domain. 

Key Distinction:

• A hostname is like a person’s name: it’s used to identify one specific computer, server, or device in a network.
• A subdomain is like a neighborhood name: it’s used to group together a set of related services or websites under one main address.

Websites: A collection of related web pages, images, videos, and other digital resources, typically identified by a shared domain name and hosted on a web server.

• A City website is a public website credited to the City and County of San Francisco or one of its departments, divisions, or programs. If a City employee or their delegated vendor updates the website with content, it is presumptively a City website..