Depending on where you look on GitHub Enterprise, you may see options for verifying, approving, or otherwise doing something magical with domains.
For example, Organizations have this:
And GitHub Pages shows this:
So, what does it all mean?
Verified and approved domains
If a domain is Approved, it means that the domain is confirmed to have a level of trust. Organization administrators can restrict email notifications to only approved domains, preventing GitHub from sending email notifications to organization members that are not in an approved domain. An organization can also choose to verify a domain.
Verification is simply proving that you own a given domain. This is accomplished by creating a special DNS record. GitHub will provide the value for this record. During verification, it checks that the two values match. If they do, it proves you have administrative (owner) access to the domain. The DNS record is only needed to perform this initial one-time verification. Verified domains have all the benefits of an approved domain, but they bring an extra benefit. If the web and public email domains used for the organization’s profile are verified, a
demoops.com would each require verification).
Pages verified domains
Verification of a domain for Pages prevents other GitHub users from using your domain or its immediate subdomains. When you verify the domain for Pages, the verification automatically includes immediate subdomains. For example,
demoops.com would cover
src.demoops.com, but not
x.y.demoops.com). This verification prevents domain takeovers. Takeovers happen when you have a dangling DNS entry (or a wildcard) and point it to GitHub. Users can associate a Pages site with a provided, custom domain. If the domain has not been verified, any user can create a Pages site and associate the domain name. Once the site is verified, however, GitHub restricts which organizations (or individuals) can use that domain name. As a result, it restricts the access to use that domain name. This is why GitHub (and others in the industry) generally recommend against wildcard DNS records (such as
*.demoops.com, which matches any subdomain for
demoops.com). A more specific record is less exploitable.
If you need to understand more about the process, it’s covered in the GitHub docs:
- Verifying/approving domains for organizations and enterprises
- Verifying custom domains for GitHub pages
If you want to know more about (sub)domain takeovers, Mozilla provides a great article. If you’re interested in understanding the seriousness of the problem, check out these articles: