Como Adicionar um Subdomínio ao Seu Domínio

Um subdomínio é um prefixo adicionado a um domínio raiz que cria um espaço de nomes distinto e endereçável de forma independente sob o mesmo nome de domínio. Por exemplo, dado o domínio raiz example.com, o nome de host blog.example.com é um subdomínio totalmente qualificado onde blog é o rótulo de terceiro nível. Os subdomínios são resolvidos através de registos DNS — tipicamente um registo A apontando para um endereço IPv4, um registo AAAA para IPv6, ou um registo CNAME que cria um alias para outro nome de host — e não requerem nenhuma taxa adicional de registo de domínio.

Do ponto de vista prático, os subdomínios permitem executar aplicações web separadas, ambientes de staging, sites regionais ou microsserviços sob um único domínio registado, com raízes de documentos independentes, certificados SSL e configurações de servidor. Este guia abrange o processo técnico completo: criação de registos DNS, configuração de alojamento, provisionamento de SSL, verificação de propagação e modos de falha comuns que a maioria dos tutoriais omite.

O Que É um Subdomínio e Como Difere de um Subdiretório

Antes de tocar no DNS, vale a pena compreender a diferença arquitetural entre um subdomínio e um subdiretório, pois a escolha afeta o SEO, a configuração do servidor e o âmbito do SSL.

John Mueller do Google confirmou que o Google geralmente trata os subdomínios como parte do mesmo site quando o conteúdo está claramente relacionado, mas o comportamento do orçamento de rastreamento, indexação e equidade de links pode diferir. Para conteúdo estreitamente integrado, como um blog corporativo, um subdiretório é frequentemente a escolha de menor atrito. Para uma aplicação separada — um portal de clientes, um gateway de API ou um ambiente de staging — um subdomínio é a decisão arquitetural correta.

Casos de Uso Comuns para Subdomínios

• Ambientes de staging e QA: staging.example.com ou dev.example.com — isolados da produção, frequentemente protegidos por HTTP Basic Auth ou listas de permissões de IP.
• Endpoints de API: api.example.com — permite implementação independente, limitação de taxa e terminação TLS.
• Portais de clientes ou dashboards SaaS: app.example.com — contexto de autenticação separado e cookies de sessão.
• Sites regionais ou específicos por idioma: de.example.com, us.example.com — suporta segmentação hreflang e roteamento de servidor específico por localização geográfica.
• Documentação e suporte: docs.example.com, support.example.com — frequentemente servidos a partir de plataformas como GitBook, Zendesk ou uma wiki auto-alojada.
• CDN ou entrega de média: cdn.example.com, static.example.com — apontado via CNAME para uma rede de edge CDN.
• Infraestrutura de correio: mail.example.com — usado como nome de host para serviços SMTP/IMAP, distinto dos registos MX.

Passo 1: Aceder à Interface de Gestão de DNS

Os registos DNS de um domínio são geridos onde quer que os servidores de nomes autoritativos do domínio estejam alojados. Este não é sempre o mesmo local que o seu alojamento web. O servidor de nomes autoritativo é definido pelos registos NS no seu registador de domínio.

Determine onde o seu DNS é gerido:

dig NS example.com +short

Se o resultado mostrar servidores de nomes pertencentes ao seu registador (por exemplo, ns1.registrar.com), gira o DNS no registador. Se mostrar servidores de nomes pertencentes a um fornecedor de alojamento ou a um serviço como o Cloudflare, gira o DNS aí em vez disso.

Depois de identificar o painel de controlo correto:

1. Inicie sessão na interface de gestão de DNS.
2. Localize a secção Editor de Zona DNS, Gestão de DNS ou Ficheiro de Zona.
3. Selecione o domínio para o qual pretende criar o subdomínio.

Se o seu domínio estiver registado através do Registo de Domínios AlexHost, o editor de zona DNS está acessível diretamente a partir do dashboard da sua área de cliente.

Passo 2: Criar o Registo DNS para o Subdomínio

Irá criar um de três tipos de registo dependendo da sua infraestrutura.

Registo A — Apontar para um Endereço IPv4

Use um registo A quando o subdomínio resolve para um endereço IP de servidor específico. Este é o cenário mais comum para subdomínios alojados num VPS ou Servidor Dedicado.

Detalhe crítico: Introduza apenas o rótulo do subdomínio no campo Nome — blog, não blog.example.com. A maioria das interfaces DNS acrescenta o domínio raiz automaticamente. Introduzir o FQDN completo criará um registo para blog.example.com.example.com.

Registo AAAA — Apontar para um Endereço IPv6

Estrutura idêntica ao registo A, mas o valor é um endereço IPv6 completo:

Registo CNAME — Criar Alias para Outro Nome de Host

Use um registo CNAME quando o subdomínio deve resolver para outro nome de host em vez de um IP direto. Os cenários comuns incluem apontar para um CDN, uma plataforma de terceiros (Shopify, HubSpot, Netlify) ou outro nome de host interno.

Restrição arquitetural: Um registo CNAME não pode coexistir com nenhum outro tipo de registo no mesmo rótulo. Não pode criar um CNAME para o próprio example.com (o apex da zona) — apenas para subdomínios. No apex, use um registo A ou, se o seu fornecedor de DNS suportar, um registo proprietário ALIAS ou ANAME.

Registo de Subdomínio Wildcard

Um registo A wildcard resolve qualquer subdomínio não definido para um único IP:

Isto é útil para aplicações SaaS multi-inquilino onde cada cliente obtém um subdomínio (por exemplo, customer1.example.com). Tenha em atenção que um registo wildcard não provisiona automaticamente SSL para cada subdomínio — precisa de um certificado SSL wildcard ou de um cliente ACME que suporte desafios DNS-01.

Passo 3: Configurar o Servidor Web ou Painel de Alojamento

Criar um registo DNS torna o subdomínio resolvível, mas não serve conteúdo automaticamente. Deve configurar o servidor web ou o painel de alojamento para aceitar e encaminhar pedidos para o novo nome de host.

Configurar um Subdomínio no cPanel

Se o seu alojamento usa cPanel — disponível nos planos de VPS com cPanel — o processo é:

1. Inicie sessão no cPanel.
2. Navegue até Domínios > Subdomínios.
3. No campo Subdomínio, introduza o rótulo (por exemplo, blog).
4. Selecione o domínio raiz no menu suspenso.
5. Defina a Raiz do Documento — o cPanel usa por defeito public_html/blog, mas pode especificar qualquer caminho.
6. Clique em Criar.

O cPanel cria automaticamente o registo DNS A na zona BIND do WHM se o DNS do domínio for gerido localmente. Se o DNS for gerido externamente (por exemplo, Cloudflare), deve adicionar o registo manualmente conforme descrito no Passo 2.

Configurar um Subdomínio no Nginx

Para um VPS a executar Nginx, crie um novo bloco de servidor:

server {
    listen 80;
    listen [::]:80;
    server_name blog.example.com;

    root /var/www/blog;
    index index.html index.php;

    access_log /var/log/nginx/blog.access.log;
    error_log  /var/log/nginx/blog.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Guarde o ficheiro em /etc/nginx/sites-available/blog.example.com, depois ative-o:

sudo ln -s /etc/nginx/sites-available/blog.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Configurar um Subdomínio no Apache

Crie um novo ficheiro de virtual host em /etc/apache2/sites-available/blog.example.com.conf:

<VirtualHost *:80>
    ServerName blog.example.com
    DocumentRoot /var/www/blog

    <Directory /var/www/blog>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/blog.error.log
    CustomLog ${APACHE_LOG_DIR}/blog.access.log combined
</VirtualHost>

Ative e recarregue:

sudo a2ensite blog.example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Passo 4: Provisionar um Certificado SSL para o Subdomínio

Cada subdomínio que serve tráfego web deve ser protegido com TLS. Um subdomínio é um nome de host distinto e não está coberto pelo certificado de domínio único do domínio raiz, a menos que use um certificado wildcard.

Opção 1 — Let’s Encrypt com Certbot (Subdomínio Único)

sudo certbot --nginx -d blog.example.com

Ou para Apache:

sudo certbot --apache -d blog.example.com

O Certbot modifica a configuração do virtual host automaticamente e configura um cron job para renovação.

Opção 2 — Certificado Wildcard Let’s Encrypt (Desafio DNS-01)

Um certificado wildcard cobre *.example.com, protegendo todos os subdomínios atuais e futuros com um único certificado. Isto requer verificação por desafio DNS-01:

sudo certbot certonly 
  --manual 
  --preferred-challenges dns 
  -d "*.example.com" 
  -d "example.com"

O Certbot irá solicitar que crie um registo TXT (_acme-challenge.example.com) na sua zona DNS. Após adicionar o registo e verificar a propagação, o Certbot emite o certificado. Os certificados wildcard devem ser renovados a cada 90 dias; automatize a renovação com um plugin DNS para o seu fornecedor (por exemplo, certbot-dns-cloudflare).

Opção 3 — Certificado SSL Comercial

Para organizações que requerem validação estendida (EV) ou um período de validade mais longo, um certificado comercial de uma CA de confiança é adequado. A AlexHost oferece Certificados SSL incluindo opções de validação de domínio, validação de organização e wildcard. Após a compra, instale o certificado colocando os ficheiros .crt e .key no servidor e referenciando-os na configuração do virtual host.

Passo 5: Verificar a Propagação de DNS

As alterações de DNS não entram em vigor globalmente no instante em que as guarda. Cada resolver armazena em cache os registos durante a duração do valor TTL. Com um TTL de 3600, os resolvers podem servir o registo antigo até uma hora após efetuar uma alteração.

Verifique a propagação a partir de múltiplos pontos de observação globais:

# Check from a specific DNS resolver
dig A blog.example.com @8.8.8.8 +short
dig A blog.example.com @1.1.1.1 +short

# Check authoritative answer directly
dig A blog.example.com +trace

Para uma verificação visual em múltiplas regiões, use whatsmydns.net ou dnschecker.org. A propagação global completa normalmente termina entre 15 minutos e 2 horas para TTLs de 3600 ou inferior. As frequentemente citadas “até 48 horas” aplicam-se principalmente a valores TTL de 86400 (24 horas) definidos no registo anterior — um padrão comum em muitos registadores.

Dica profissional: Antes de efetuar alterações de DNS, reduza o TTL do registo existente para 300 (5 minutos) pelo menos um ciclo de TTL com antecedência. Isto reduz drasticamente o tempo de espera de propagação durante a alteração real.

Passo 6: Testar a Funcionalidade de Ponta a Ponta

Após a propagação, realize um teste funcional completo:

# Confirm DNS resolution
dig A blog.example.com +short

# Confirm HTTP response
curl -I http://blog.example.com

# Confirm HTTPS and certificate validity
curl -I https://blog.example.com

# Inspect the TLS certificate
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -subject -dates

Verifique que:

• A resposta curl -I retorna 200 OK ou o código de redirecionamento esperado.
• O sujeito do certificado TLS corresponde a blog.example.com ou *.example.com.
• A data de expiração do certificado está correta.
• Não aparecem avisos de conteúdo misto na consola de desenvolvimento do navegador.

Erros Comuns e Como Evitá-los

CNAME no apex da zona: Tentar criar um registo CNAME para o próprio example.com irá quebrar a entrega de correio e outros registos DNS. Use um registo A ou um registo ALIAS/ANAME no apex.

Subdomínio não servido pelo servidor web: O DNS resolve corretamente, mas o navegador retorna 404 ou ligação recusada. Causa: o servidor web não tem nenhum virtual host correspondente ao nome de host do subdomínio. Solução: adicione o bloco de servidor ou virtual host conforme descrito no Passo 3.

Incompatibilidade de certificado SSL: O navegador mostra um erro de certificado. Causa: o certificado existente cobre apenas example.com, não blog.example.com. Solução: emita um novo certificado especificamente para o subdomínio ou substitua por um certificado wildcard.

O cPanel cria um registo DNS local mas o DNS é gerido externamente: Ao usar o Cloudflare ou outro fornecedor de DNS externo com alojamento cPanel, o assistente de subdomínios do cPanel cria um registo na zona BIND local do WHM, que nunca é consultada. Deve adicionar o registo A manualmente no Cloudflare (ou no seu fornecedor de DNS externo). Esta é uma das fontes de confusão mais comuns para utilizadores de alojamento partilhado.

DNS wildcard sem SSL wildcard: Um registo DNS *.example.com resolve todos os subdomínios para o seu servidor, mas cada novo subdomínio irá acionar um aviso de certificado a menos que tenha um certificado SSL wildcard instalado. Não confie apenas no DNS wildcard para subdomínios de produção.

Fuga de âmbito de cookie: Se a sua aplicação define cookies em .example.com (note o ponto inicial), esses cookies são enviados para todos os subdomínios. Isto pode expor tokens de sessão de um subdomínio de alta segurança para um menos seguro. Defina o âmbito dos cookies explicitamente para o nome de host pretendido.

Gestão de Subdomínios em Diferentes Ambientes de Alojamento

Para aplicações de alto tráfego que requerem acesso root completo e configurações de servidor personalizadas, um Servidor Dedicado dá-lhe controlo completo sobre DNS, software de servidor web e gestão de certificados sem as restrições de um ambiente partilhado.

Lista de Verificação de Decisões Técnicas

Antes de criar um subdomínio, analise o seguinte:

• Onde estão os servidores de nomes autoritativos? Execute dig NS example.com +short para confirmar antes de iniciar sessão em qualquer painel.
• Registo A ou CNAME? Use A/AAAA para um IP de servidor. Use CNAME para um nome de host de plataforma de terceiros. Nunca use CNAME no apex da zona.
• O servidor web está configurado para aceitar o novo nome de host? Um registo DNS por si só não serve conteúdo.
• O subdomínio precisa do seu próprio certificado SSL? Sim, a menos que um certificado wildcard já esteja instalado.
• O TTL está definido baixo antes da alteração? Reduza-o para 300 pelo menos um ciclo de TTL antes de efetuar alterações para minimizar o atraso de propagação.
• O cPanel está a gerir o DNS localmente enquanto um fornecedor externo é autoritativo? Se sim, adicione o registo no fornecedor externo, não no cPanel.
• O subdomínio precisa de ser bloqueado da indexação por motores de busca? Se for um ambiente de staging ou interno, adicione X-Robots-Tag: noindex ao nível do servidor ou use HTTP Basic Auth.
• Os âmbitos de cookie estão definidos corretamente? Defina explicitamente o atributo Domain nos cookies para evitar partilha não intencional entre subdomínios.

FAQ

Posso criar um subdomínio sem acesso ao DNS do domínio raiz?

Não. Um subdomínio requer um registo DNS (A, AAAA ou CNAME) na zona do domínio raiz. Sem acesso de escrita à zona DNS autoritativa, não pode criar um subdomínio publicamente resolvível.

Um subdomínio afeta o SEO do domínio raiz?

Depende da relação de conteúdo e da ligação interna. O Google pode associar um subdomínio ao domínio raiz, mas a equidade de links não flui tão livremente como entre URLs de subdiretório. Para conteúdo estreitamente integrado com o site principal, um subdiretório é geralmente preferível do ponto de vista de SEO. Para aplicações separadas ou ambientes de staging, um subdomínio é a escolha correta e deve ser noindex se não for destinado à pesquisa pública.

Quantos subdomínios posso criar sob um domínio?

A especificação DNS não impõe nenhum limite prático ao número de subdomínios. Os registadores e painéis de alojamento podem impor limites flexíveis, mas estes são administrativos, não técnicos. Um único domínio pode ter centenas de subdomínios.

Qual é a diferença entre um registo DNS wildcard e um certificado SSL wildcard?

Um registo DNS wildcard (*.example.com) encaminha todos os subdomínios não definidos para um único endereço IP ao nível do DNS. Um certificado SSL wildcard (*.example.com) protege todos os subdomínios de primeiro nível ao nível do TLS. São independentes: pode ter um sem o outro, mas ambos são necessários para servir todos os subdomínios via HTTPS sem provisionamento individual de certificados.

Por que razão o meu subdomínio resolve corretamente em dig mas retorna um erro no navegador?

A resolução DNS e o serviço HTTP são camadas separadas. Se dig retorna o IP correto mas o navegador mostra um erro, o servidor web nesse IP não está configurado para lidar com pedidos para esse nome de host (server_name no Nginx ou ServerName no Apache). Adicione o bloco de virtual host apropriado e recarregue o servidor web.