Este guia mostra o essencial: como montar uma requisição GET e POST, enviar cabeçalhos e JSON, lidar com autenticação, tratar erros — e, no fim, como pegar um comando curl de terminal (aqueles que aparecem na documentação de APIs) e convertê-lo em código PHP.

O que é o cURL no PHP

O cURL é uma biblioteca de transferência de dados que suporta HTTP, HTTPS, FTP e vários outros protocolos. No PHP, ela é exposta pela extensão php-curl, que na maioria das hospedagens já vem ativada. Com ela, o seu código pode agir como um cliente HTTP: fazer requisições a outros servidores e receber as respostas.

É a ferramenta padrão para consumir APIs, integrar serviços externos (gateways de pagamento, envio de e-mail, redes sociais), baixar arquivos remotos e testar endpoints. Toda requisição cURL em PHP segue o mesmo esqueleto de quatro funções:

Requisição GET

O exemplo mais simples: buscar dados de uma URL. O ponto-chave é a opção CURLOPT_RETURNTRANSFER, que faz a resposta ser retornada como string (sem ela, o cURL imprime a resposta direto na saída):

Requisição POST

Para enviar dados (criar um registro, submeter um formulário a uma API), você ativa o modo POST com CURLOPT_POST e passa os dados em CURLOPT_POSTFIELDS:

Passar um array em CURLOPT_POSTFIELDS envia os dados como formulário (application/x-www-form-urlencoded ou multipart). Para enviar JSON, veja mais abaixo.

Enviar cabeçalhos (headers)

Muitas APIs exigem cabeçalhos — um token de autenticação, o tipo de conteúdo. Use CURLOPT_HTTPHEADER com um array de strings:

Enviar JSON

O caso mais comum ao consumir APIs modernas: enviar um corpo em JSON. Você codifica os dados com json_encode(), passa o resultado em CURLOPT_POSTFIELDS e declara o Content-Type:

Autenticação básica

Para APIs que usam autenticação HTTP básica (usuário e senha), use CURLOPT_USERPWD:

Para autenticação por token (Bearer), use o cabeçalho Authorization, como mostrado na seção de headers.

Tratar erros e ver o código de resposta

Uma requisição pode falhar (servidor fora do ar, timeout, SSL) ou retornar um status de erro (404, 500). Sempre verifique os dois:

O curl_error() traz a mensagem de uma falha de conexão; o curl_getinfo() com CURLINFO_HTTP_CODE traz o status HTTP da resposta (200, 404, 500…). Uma requisição pode “ter sucesso” no cURL e ainda assim devolver um 404 — por isso os dois cheques.

Nunca desative a verificação de SSL

Ao topar com um erro de SSL, muitos tutoriais sugerem CURLOPT_SSL_VERIFYPEER = false como “solução”. Isso desliga a verificação do certificado e abre a porta para ataques de interceptação (man-in-the-middle). Não faça isso em produção. O certo é manter a verificação ligada e, se necessário, apontar um pacote de certificados válido (CA bundle) atualizado no servidor.

Como converter um comando curl (terminal) para PHP

A documentação de muitas APIs mostra exemplos como um comando curl de terminal. Traduzir para PHP é direto quando você conhece o mapa. Veja este comando:

Cada parte do comando tem um equivalente em PHP:

O comando acima, traduzido para PHP, fica assim:

O padrão é sempre o mesmo: a URL vai no curl_init(), e cada flag do terminal (-X, -H, -d, -u) vira uma opção correspondente no curl_setopt().

Perguntas frequentes

O que é o cURL no PHP?
É a forma de fazer requisições HTTP a partir do código PHP, usando a extensão php-curl. Com ele, o seu script atua como cliente HTTP: consome APIs, envia dados a outros servidores e baixa conteúdo remoto. As requisições seguem quatro funções — curl_init(), curl_setopt(), curl_exec() e curl_close().

Como fazer uma requisição GET com cURL no PHP?
Inicie a sessão com curl_init() passando a URL, defina curl_setopt($ch, CURLOPT_RETURNTRANSFER, true) para receber a resposta como string, execute com curl_exec() e feche com curl_close(). O CURLOPT_RETURNTRANSFER é essencial: sem ele, a resposta é impressa direto na saída em vez de retornada.

Como enviar dados por POST com cURL no PHP?
Ative o POST com curl_setopt($ch, CURLOPT_POST, true) e passe os dados em CURLOPT_POSTFIELDS. Para dados de formulário, use um array. Para JSON, use json_encode() nos dados e adicione o cabeçalho Content-Type: application/json com CURLOPT_HTTPHEADER.

Como ver o código de status HTTP da resposta?
Use curl_getinfo($ch, CURLINFO_HTTP_CODE) depois do curl_exec(). Ele retorna o status HTTP (200, 404, 500…). Isso é importante porque uma requisição pode completar com sucesso no cURL e mesmo assim devolver um erro como 404 — o curl_exec() retornar false indica falha de conexão, não status de erro HTTP.

Como converter um comando curl do terminal para PHP?
Mapeie cada flag para uma opção do cURL: a URL vai no curl_init(); -X vira CURLOPT_POST ou CURLOPT_CUSTOMREQUEST; -H (cabeçalhos) vira CURLOPT_HTTPHEADER como array; -d (dados) vira CURLOPT_POSTFIELDS; e -u (autenticação) vira CURLOPT_USERPWD. O padrão de tradução é sempre o mesmo.

cURL ou file_get_contents: qual usar?
O cURL é mais completo e recomendado: funciona mesmo com o allow_url_fopen desligado e dá controle sobre método, cabeçalhos, autenticação e timeout. O file_get_contents() é mais simples para uma leitura rápida de URL, mas depende do allow_url_fopen ativo e oferece pouco controle. Para consumir APIs, prefira o cURL.

Conclusão

O cURL no PHP se resume a um padrão de quatro funções — curl_init(), curl_setopt(), curl_exec(), curl_close() — e a diferença entre uma requisição e outra está nas opções que você define pelo curl_setopt(): CURLOPT_POST para enviar dados, CURLOPT_HTTPHEADER para cabeçalhos, CURLOPT_POSTFIELDS para o corpo. Lembre sempre do CURLOPT_RETURNTRANSFER para receber a resposta como string, verifique tanto o curl_error() quanto o status HTTP, e nunca desligue a verificação de SSL em produção. Com esse esqueleto, você consome praticamente qualquer API — e traduzir um comando curl de documentação para PHP vira questão de mapear cada flag para a sua opção.

O post cURL no PHP: como fazer requisições HTTP (GET, POST e mais) apareceu primeiro em Homehost.

O allow_url_fopen é a diretiva do PHP que decide se funções como file_get_contents() e fopen() podem abrir arquivos por uma URL remota — como se lê um arquivo local. Quando um script falha com a mensagem “http:// wrapper is disabled … by allow_url_fopen=0”, é porque essa permissão está desligada. Entender essa diretiva é entender uma escolha entre conveniência e segurança.

Este guia explica o que o allow_url_fopen faz, como verificar e alterar o seu estado, por que ele costuma vir desativado por padrão e — o ponto mais importante — quando vale a pena usar o cURL como alternativa mais segura para buscar conteúdo remoto.

O que é o allow_url_fopen

O allow_url_fopen é uma diretiva do php.ini que controla se as funções de manipulação de arquivos do PHP podem acessar arquivos remotos por URL, e não apenas arquivos locais no servidor.

Quando está ligado (On), você pode fazer algo assim:

O PHP trata a URL remota como se fosse um arquivo local, baixando o conteúdo. Isso afeta principalmente as funções file_get_contents(), fopen() e afins. (Um detalhe: incluir código remoto com include/require depende de outra diretiva, o allow_url_include, que é ainda mais restrita — e deve ficar sempre desligada.)

Quando está desligado (Off), qualquer tentativa de abrir uma URL remota com essas funções falha, tipicamente com o aviso: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0.

Como verificar se está ativo

Antes de mudar qualquer coisa, veja o estado atual. A forma mais direta, pelo código:

Você também pode consultar o phpinfo() e procurar por allow_url_fopen — o guia do php.ini mostra como. Se o valor for Off e o seu script precisa ler URLs remotas, aí sim considere ativá-lo (ou, melhor ainda, usar cURL — veja mais abaixo).

Como ativar o allow_url_fopen

Se você tem certeza de que precisa (e entende os riscos), há os caminhos habituais.

No php.ini

No php.ini:

Em hospedagem compartilhada, pelo painel — no cPanel, em Select PHP Version → Options, marcando allow_url_fopen.

No .htaccess

Em servidor Apache, pelo .htaccess:

Um ponto importante: o allow_url_fopen não pode ser alterado por ini_set() no código. Ele é lido na inicialização do PHP e faz parte da categoria de diretivas que só valem se definidas na configuração (php.ini, .htaccess ou painel) — nunca em tempo de execução. Se você viu por aí um ini_set('allow_url_fopen', 1), saiba que ele não tem efeito.

Por que ele vem desligado: a questão de segurança

Por que muitas hospedagens desligam por padrão

Um script que abre URLs remotas é uma porta de entrada para ataques. Se um invasor conseguir controlar a URL que o seu código abre, ele pode forçar o servidor a acessar endereços internos da rede (ataque conhecido como SSRF) ou, em cenários piores, injetar código remoto. Por isso, muitas hospedagens deixam o allow_url_fopen desligado por padrão — é uma camada de proteção, não um capricho.

O risco não é teórico. Quando um script usa uma URL vinda de fora (de um formulário, de um parâmetro) sem validação, e o allow_url_fopen está ligado, um atacante pode manipular essa URL para fazer o servidor buscar recursos que não deveria — de páginas internas da rede a metadados de infraestrutura. É o tipo de brecha que costuma passar despercebido até ser explorado.

Por isso, a recomendação geral é: mantenha desligado, a menos que você precise mesmo — e, se precisar, valide rigorosamente qualquer URL antes de abri-la, e nunca use uma URL que venha diretamente da entrada do usuário.

A alternativa recomendada: cURL

Na maioria dos casos em que se quer buscar conteúdo remoto, há uma opção melhor que ligar o allow_url_fopen: usar o cURL, a biblioteca do PHP feita exatamente para requisições HTTP. O cURL funciona mesmo com o allow_url_fopen desligado, dá muito mais controle (cabeçalhos, timeout, métodos, autenticação) e é a forma consagrada de fazer requisições em PHP.

Esse trecho faz o mesmo que o file_get_contents() de uma URL, mas sem depender do allow_url_fopen. Uma abordagem robusta é o script tentar o file_get_contents() se a diretiva estiver ligada e cair para o cURL caso contrário — assim o código funciona em qualquer servidor, com ou sem a diretiva. Para a maioria dos projetos, adotar o cURL de saída é a escolha mais segura e portável.

Perguntas frequentes

O que é o allow_url_fopen no PHP?
É a diretiva que controla se o PHP pode abrir arquivos remotos por URL usando funções como file_get_contents() e fopen(), tratando o endereço remoto como se fosse um arquivo local. Quando está desligada, essas funções não conseguem acessar URLs externas e retornam um aviso indicando que o wrapper http:// está desabilitado.

Como ativar o allow_url_fopen?
Defina allow_url_fopen = On no php.ini, ou php_value allow_url_fopen 1 no .htaccess em servidores Apache. Em hospedagem compartilhada, ative pelo painel (no cPanel, em Select PHP Version → Options). Não é possível ativá-lo por ini_set() no código, porque a diretiva é lida na inicialização do PHP.

Por que o allow_url_fopen vem desligado?
Por segurança. Scripts que abrem URLs remotas podem ser explorados: se um atacante controla a URL, ele pode forçar o servidor a acessar endereços internos (ataque SSRF) ou injetar código. Muitas hospedagens desligam a diretiva por padrão como proteção. Só ative se realmente precisar, validando qualquer URL antes de usá-la.

Qual a mensagem de erro quando o allow_url_fopen está desligado?
Ao tentar abrir uma URL remota com a diretiva desligada, o PHP retorna algo como: file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0. É o sinal claro de que a função tentou acessar um recurso remoto e foi bloqueada pela configuração.

Como buscar conteúdo remoto sem o allow_url_fopen?
Use o cURL, a biblioteca de requisições HTTP do PHP. Ela funciona mesmo com o allow_url_fopen desligado e dá mais controle sobre a requisição. Uma prática comum é usar file_get_contents() quando a diretiva está ativa e cair para o cURL quando não está, deixando o código portável entre servidores.

allow_url_fopen e allow_url_include são a mesma coisa?
Não. O allow_url_fopen permite ler arquivos remotos com funções como file_get_contents(). O allow_url_include, mais perigoso, permitiria incluir e executar código remoto com include/require. O allow_url_include deve ficar sempre desligado, pois executar código externo é uma falha de segurança grave.

Conclusão

O allow_url_fopen é uma daquelas diretivas em que a resposta certa quase nunca é “simplesmente ligue”. Ela permite que o PHP abra URLs remotas com file_get_contents() e fopen(), mas vem desligada por padrão em muitas hospedagens justamente porque essa conveniência abre espaço para ataques como o SSRF. Antes de ativá-la, verifique com ini_get('allow_url_fopen') o estado atual, e considere se o cURL não resolve melhor — na maioria dos casos, resolve, com mais segurança e sem depender da diretiva. Se ainda assim precisar ligá-la, faça-o no php.ini ou no .htaccess (nunca por ini_set), e valide toda URL antes de abri-la. Segurança e funcionalidade, aqui, andam em lados opostos da mesma chave — e vale saber qual você está girando.

O post allow_url_fopen: o que é, como ativar e os riscos apareceu primeiro em Homehost.

Se um menu do WordPress some ao salvar, as opções de um tema não gravam, ou um formulário grande envia os dados pela metade — sem nenhuma mensagem de erro —, a causa provável é o max_input_vars: o PHP está descartando silenciosamente as variáveis que passam de um certo limite. É um dos problemas mais confusos justamente por não dar erro nenhum.

O max_input_vars controla quantas variáveis o PHP aceita em uma única requisição; o max_input_time, seu parente próximo, controla quanto tempo o PHP gasta processando esses dados. As duas diretivas do php.ini atuam sobre o mesmo ponto — o envio de formulários grandes — e este guia explica o que cada uma faz, por que causam esses sintomas e como ajustá-las.

O que é o max_input_vars

O max_input_vars é a diretiva do PHP que limita o número de variáveis de entrada que o servidor aceita em uma única requisição. Isso vale para os dados enviados por POST, GET e cookies somados.

O valor padrão é 1000. Na maioria dos sites, isso é mais que suficiente. Mas há um comportamento que torna essa diretiva traiçoeira: quando o limite é ultrapassado, o PHP não gera erro — ele simplesmente descarta as variáveis além do limite. A requisição continua, aparentemente com sucesso, mas com parte dos dados faltando.

É essa “falha silenciosa” que confunde. Você salva uma configuração, o site diz que salvou, mas metade dos dados não foi gravada — e não há mensagem nenhuma explicando o porquê.

Os sintomas: quando suspeitar do max_input_vars

O max_input_vars é especialmente comum em sites WordPress, porque page builders, temas complexos e plugins robustos geram muitos campos de uma vez. Os sintomas típicos:

• Itens de menu somem depois de salvar um menu grande no WordPress.
• Opções de tema ou do customizer não gravam — você salva, mas voltam ao valor anterior.
• Formulários longos enviam dados incompletos, perdendo os campos finais.
• Configurações de plugins pesados (páginas com dezenas ou centenas de campos) não persistem.

O padrão comum a todos: os primeiros dados são salvos, os últimos não — porque o PHP processa até o limite e descarta o resto. Se você percebe que “só o final do formulário se perde”, o max_input_vars é o suspeito número um.

Como verificar o valor atual

Antes de mudar, confirme o valor em vigor. Crie um arquivo com phpinfo() e procure por max_input_vars, ou consulte pelo painel. O guia do php.ini mostra como localizar e ler essas configurações. Se o valor estiver em 1000 (o padrão) e você tem um formulário grande falhando, é sinal de que precisa aumentá-lo.

Como aumentar o max_input_vars

Assim como outras diretivas do PHP, há mais de um caminho, dependendo do seu acesso.

No php.ini (ou pelo painel)

O caminho mais direto. No php.ini, ajuste:

Em hospedagem compartilhada, faça isso pelo painel — no cPanel, em Select PHP Version → Options, localizando max_input_vars. Um valor de 3000 resolve a grande maioria dos casos; sites muito complexos podem precisar de 5000.

No .htaccess

Em servidor Apache, pelo .htaccess na raiz do site:

Se essa linha gerar um erro 500, o servidor não aceita php_value no .htaccess (comum em PHP-FPM) — use então o php.ini ou o painel.

Criando um php.ini próprio

Se você não tem acesso ao php.ini global, pode criar um arquivo php.ini (ou .user.ini) na raiz do site com a linha max_input_vars = 3000. O guia do php.ini detalha esse método.

Não exagere no valor

Aumente o max_input_vars para o que o seu site precisa (3000 ou 5000 costumam bastar), não para um número gigante. Um limite muito alto abre espaço para que uma requisição maliciosa envie um volume enorme de variáveis e consuma memória do servidor. O limite existe também como proteção — eleve-o com critério, na medida da sua necessidade.

O max_input_time: o parente próximo

O max_input_time controla quanto tempo (em segundos) o PHP pode gastar analisando os dados de entrada de uma requisição — o POST, o GET e os uploads. É diferente do max_execution_time, que mede o tempo de execução do script; o max_input_time mede só a fase de leitura da entrada.

Enquanto o max_input_vars limita a quantidade de variáveis, o max_input_time limita o tempo de processá-las. Os dois se relacionam porque um formulário muito grande pode esbarrar em ambos: ter variáveis demais (max_input_vars) e demorar demais para ser lido (max_input_time).

O valor padrão costuma ser 60 segundos (ou -1, que faz o PHP usar o max_execution_time). Se você tem formulários enormes, uploads pesados combinados com muitos campos, ou um checkout complexo que falha por tempo, vale aumentá-lo:

Ajusta-se pelos mesmos caminhos do max_input_vars: php.ini, .htaccess (php_value max_input_time 120) ou painel. Na prática, o max_input_vars é a causa da maioria dos problemas de “formulário não salva”; o max_input_time entra quando o volume de dados é grande o bastante para a leitura demorar.

Ativei e ainda não funciona? Verifique

Se você aumentou o max_input_vars e o problema persiste:

• Confirme que o novo valor está ativo: use o phpinfo() e procure max_input_vars — se ainda mostra 1000, a mudança não pegou (arquivo errado, ou faltou reiniciar num VPS).
• O gargalo pode ser outra diretiva: se o formulário também envia muitos dados em volume (não só em quantidade de campos), o post_max_size pode ser o limite real. Verifique-o também.
• Editou o php.ini certo? Em cPanel, o php.ini ativo costuma ficar na home do usuário, não na raiz do WordPress. O phpinfo() mostra qual arquivo está em uso.
• ini_set não resolve este caso: o max_input_vars não pode ser alterado por ini_set() no código, porque o PHP já processou a entrada antes de o script rodar. Use php.ini, .htaccess ou painel — nunca o código.

Esse último ponto é importante e pouca gente sabe: diferente do display_errors ou do memory_limit, o max_input_vars não funciona via ini_set(), porque quando o seu script começa a rodar, a entrada já foi lida (e truncada). Tem de ser definido antes, na configuração.

Perguntas frequentes

O que é o max_input_vars no PHP?
É a diretiva que define o número máximo de variáveis de entrada que o PHP aceita em uma única requisição, somando POST, GET e cookies. O valor padrão é 1000. Quando uma requisição ultrapassa esse limite, o PHP descarta as variáveis excedentes sem gerar erro, o que causa perda silenciosa de dados em formulários e menus grandes.

Por que meu menu ou formulário do WordPress não salva tudo?
A causa mais comum é o max_input_vars. Menus grandes, page builders, temas complexos e plugins com muitos campos podem gerar mais de 1000 variáveis numa requisição. Ao ultrapassar o limite, o PHP descarta o excedente silenciosamente, então parte dos itens ou opções não é salva. Aumentar o max_input_vars para 3000 costuma resolver.

Como aumentar o max_input_vars?
Defina um valor maior no php.ini (max_input_vars = 3000), no .htaccess em Apache (php_value max_input_vars 3000), ou pelo painel de hospedagem (no cPanel, em Select PHP Version → Options). Em hospedagem compartilhada, o painel é o caminho mais simples. Depois, confirme com phpinfo que o novo valor está ativo.

Qual a diferença entre max_input_vars e max_input_time?
O max_input_vars limita a quantidade de variáveis de entrada numa requisição; o max_input_time limita o tempo (em segundos) que o PHP gasta lendo esses dados. Um trata do “quantos campos”, o outro do “quanto tempo para processá-los”. Formulários muito grandes podem esbarrar nos dois.

Posso alterar o max_input_vars pelo ini_set no código?
Não. Diferente de outras diretivas, o max_input_vars não pode ser alterado por ini_set(), porque o PHP processa os dados de entrada antes de o seu script começar a rodar. Quando o código executa, a entrada já foi lida e truncada. Por isso, é preciso definir o valor no php.ini, no .htaccess ou no painel.

Qual valor devo usar para o max_input_vars?
Depende do tamanho dos seus formulários, mas 3000 resolve a grande maioria dos casos, e 5000 atende sites bem complexos. Evite valores exagerados: um limite muito alto pode permitir que requisições maliciosas consumam memória do servidor. Aumente na medida da necessidade real do seu site.

Conclusão

Quando dados somem de um formulário ou menu sem nenhum erro, o max_input_vars é quase sempre o culpado: o PHP está descartando em silêncio tudo que passa do limite de 1000 variáveis. A solução é direta — aumentar o valor para 3000 (ou 5000 em sites complexos) no php.ini, no .htaccess ou pelo painel, lembrando que essa diretiva não funciona via ini_set() no código. O max_input_time, seu parente, entra quando o problema é o tempo de leitura de dados grandes. Com os dois ajustados na medida certa, os formulários voltam a salvar tudo — e você para de perder configurações sem entender por quê.

O post max_input_vars e max_input_time: resolvendo formulários que não salvam apareceu primeiro em Homehost.

Quando um script PHP falha e a página aparece totalmente em branco, quase sempre o motivo é que a exibição de erros está desligada — o PHP encontrou o erro, mas foi configurado para não mostrá-lo. Para revelar a mensagem, é preciso ativar o display_errors. É a primeira coisa a fazer para depurar qualquer problema de PHP.

Por padrão, muitos servidores vêm com a exibição de erros desativada (o que é correto para um site no ar). Mas, ao desenvolver ou diagnosticar um problema, você precisa ver as mensagens. Este guia mostra como ativar a exibição de todos os erros do PHP pelos três caminhos possíveis — direto no código, no php.ini e no .htaccess —, como usar o error_reporting para escolher o que aparece, e por que é essencial desligar tudo isso quando o site voltar ao ar.

Por que o PHP não mostra os erros

Quando uma página PHP dá erro e aparece totalmente em branco (a famosa “tela branca da morte”), o que aconteceu foi o seguinte: o PHP executou o script, encontrou um erro fatal, interrompeu tudo — e, como estava configurado para não exibir erros, não mostrou nenhuma mensagem. O resultado é uma página vazia, sem pista nenhuma.

Isso é controlado por duas diretivas do php.ini que trabalham juntas:

• display_errors — decide se os erros aparecem na tela (On) ou não (Off).
• error_reporting — decide quais tipos de erro são considerados (erros fatais, avisos, notices, etc.).

Em um servidor de produção, o display_errors normalmente vem desligado de propósito, por segurança. Para desenvolver ou diagnosticar, você precisa ligá-lo temporariamente. Há três formas de fazer isso.

Caminho 1: direto no código PHP (ini_set)

A forma mais rápida e localizada, ideal para depurar um script específico, é adicionar estas linhas no início do arquivo PHP:

O que cada linha faz:

• ini_set('display_errors', 1) — liga a exibição de erros na tela para este script.
• ini_set('display_startup_errors', 1) — mostra também os erros que ocorrem na inicialização do próprio PHP (que o display_errors sozinho não pega).
• error_reporting(E_ALL) — pede que todos os níveis de erro sejam reportados: fatais, avisos (warnings), notices e o resto.

Há uma limitação importante: se o erro for de sintaxe no próprio arquivo onde você colocou essas linhas, elas não chegam a rodar — o PHP falha antes de executá-las. Nesse caso, use um dos outros dois caminhos, ou coloque o código de teste num arquivo separado que inclua o problemático.

Caminho 2: no php.ini

Para ligar a exibição de erros para todo o site (útil em um ambiente de desenvolvimento inteiro), ajuste as diretivas no php.ini:

Lembre-se de que, ao editar o php.ini diretamente, a mudança só vale depois de reiniciar o servidor web (Apache) ou o PHP-FPM. Em hospedagem compartilhada, você faz esse ajuste pelo painel — no cPanel, em Select PHP Version → Options, localizando display_errors e error_reporting. O guia do php.ini detalha cada forma de editar.

Caminho 3: no .htaccess

Se você usa servidor Apache e não tem acesso ao php.ini, pode ligar a exibição pelo .htaccess, na raiz do site:

Esse caminho é prático porque vale para todo o site sem precisar reiniciar nada, mas depende de o servidor ser Apache e de permitir diretivas php_value/php_flag no .htaccess (o que não acontece em setups com PHP-FPM). Se as linhas gerarem um erro 500, é sinal de que o servidor não aceita esse método — use então o php.ini ou o painel.

Entendendo o error_reporting

O error_reporting é o que define quais erros você quer ver. O valor mais usado para depurar é o E_ALL, que mostra tudo, mas há outros níveis úteis:

Para depurar, E_ALL é o recomendado — você quer ver tudo, inclusive os notices, que muitas vezes apontam a origem de um bug (como uma variável não definida). O display_errors liga a exibição; o error_reporting filtra o que é exibido. Os dois precisam estar configurados para você ver o erro.

Ver erros sem exibi-los na tela: o log

Nem sempre você quer os erros aparecendo na tela — especialmente num site que tem visitantes. A alternativa é registrar os erros em um arquivo de log, em vez de exibi-los:

Assim, os erros não aparecem para os visitantes, mas ficam gravados num arquivo que só você acessa. É o método ideal para produção: você continua sabendo o que deu errado (consultando o log), sem expor nada ao público. Muitos painéis de hospedagem já mantêm um arquivo de log de erros do PHP que você pode consultar sem configurar nada.

Por que desligar em produção

Nunca deixe display_errors ligado num site no ar

As mensagens de erro do PHP expõem informações valiosas para um atacante: caminhos de arquivos no servidor, nomes de banco de dados, trechos de código, versões de software. Deixar o display_errors ligado em produção é entregar um mapa da sua infraestrutura a qualquer visitante. Em um site no ar, mantenha display_errors = Off e use o log de erros para acompanhar os problemas com segurança.

A regra de ouro: display_errors ligado no desenvolvimento, desligado na produção. Ao terminar de depurar um problema num site que está no ar, lembre-se de remover as linhas de ini_set que você adicionou, ou de desligar a diretiva no painel. Deixá-la ligada é um dos deslizes de segurança mais comuns em PHP.

Erros ainda não aparecem? Verifique

Se você ativou tudo e a página continua em branco, alguns pontos a checar:

• Erro de sintaxe no arquivo: se o próprio arquivo tem um erro de sintaxe, o ini_set dentro dele não roda. Ative pelo php.ini ou .htaccess, ou verifique o log de erros.
• A configuração não foi aplicada: se editou o php.ini, confirme que reiniciou o serviço e que editou o arquivo certo (veja como no guia do php.ini).
• O erro está sendo logado, não exibido: consulte o arquivo de log de erros do PHP (o painel da hospedagem costuma ter um “Error Log”).
• Cache de página: se o site usa cache, limpe-o para garantir que está vendo a execução real do PHP.

Perguntas frequentes

Como exibir todos os erros no PHP?
Adicione ao início do seu script as linhas ini_set('display_errors', 1);, ini_set('display_startup_errors', 1); e error_reporting(E_ALL);. A primeira liga a exibição na tela, a segunda inclui erros de inicialização e a terceira faz com que todos os tipos de erro sejam reportados. Para todo o site, ajuste as mesmas diretivas no php.ini ou no .htaccess.

Por que meu PHP não mostra erros e a tela fica em branco?
Porque a diretiva display_errors está desligada. Quando o PHP encontra um erro fatal e a exibição está desativada, ele interrompe o script e devolve uma página vazia, sem mensagem. Ativando o display_errors e o error_reporting(E_ALL), a mensagem de erro passa a aparecer, revelando a causa do problema.

Qual a diferença entre display_errors e error_reporting?
São complementares. O display_errors decide se os erros aparecem na tela ou não (On/Off). O error_reporting decide quais tipos de erro são considerados (fatais, avisos, notices). Para ver um erro, os dois precisam estar configurados: a exibição ligada e o nível incluindo aquele tipo de erro. O valor error_reporting(E_ALL) mostra todos.

Como exibir erros do PHP sem acesso ao php.ini?
Você tem dois caminhos. No próprio código, adicione ini_set('display_errors', 1) e error_reporting(E_ALL) no início do script. No Apache, pode usar o arquivo .htaccess com php_flag display_errors on e php_value error_reporting E_ALL. Em hospedagem compartilhada, também dá para ajustar pelo painel, no cPanel em Select PHP Version.

É seguro deixar a exibição de erros ligada?
Não em produção. As mensagens de erro expõem caminhos de arquivos, nomes de banco de dados e outros detalhes que ajudam um atacante. Em um site no ar, mantenha display_errors = Off e registre os erros num log (log_errors = On) para acompanhá-los com segurança. A exibição na tela deve ficar ligada apenas em ambiente de desenvolvimento.

Onde ficam os logs de erro do PHP?
O local é definido pela diretiva error_log no php.ini. Em muitas hospedagens, há um arquivo de log de erros acessível pelo painel de controle (procure por “Error Log” no cPanel). Se você define o error_log manualmente, aponte para um caminho onde o PHP tenha permissão de escrita, e consulte esse arquivo para ver os erros registrados.

O que significa error_reporting(E_ALL)?
É o comando que diz ao PHP para reportar todos os níveis de erro: erros fatais, avisos (warnings), notices, avisos de código obsoleto (deprecated) e o resto. É o valor recomendado durante o desenvolvimento, porque mostra o quadro completo — inclusive os notices, que costumam apontar a origem de bugs sutis, como o uso de uma variável não definida.

Conclusão

Uma tela em branco no PHP quase nunca é um mistério — é só o erro escondido. Para revelá-lo, o essencial é: no código, ini_set('display_errors', 1) mais error_reporting(E_ALL) no topo do script; ou, para o site todo, as mesmas diretivas no php.ini ou no .htaccess. Lembre da divisão de papéis — o display_errors liga a exibição, o error_reporting escolhe o que aparece — e da regra de ouro: ligado só em desenvolvimento. Num site no ar, mantenha desligado e acompanhe pelo log de erros. Com a exibição ativada, o PHP deixa de esconder o problema e passa a te dizer exatamente onde ele está.

O post Display errors PHP: como exibir todos os erros do PHP apareceu primeiro em Homehost.

O php.ini é o arquivo de configuração do PHP — é nele que se define o comportamento da linguagem no servidor: quanto de memória cada script pode usar, por quanto tempo pode rodar, se os erros aparecem na tela, o tamanho máximo de upload e dezenas de outros ajustes. Cada linha do arquivo é uma “diretiva”: um parâmetro com um valor.

Se você já se deparou com um erro de “memory size exhausted”, um upload que falha por ser grande demais, ou uma tela em branco sem mensagem de erro, a solução quase sempre passa pelo php.ini. Este guia explica o que é o arquivo, como descobrir onde ele está, como editá-lo (pelo cPanel ou direto no servidor), e quais são as principais diretivas que você pode ajustar.

O que é o php.ini

O php.ini é o arquivo de configuração principal do PHP. Toda vez que o PHP é iniciado, ele lê esse arquivo para saber como deve se comportar: quais recursos liberar, quais limites impor, o que fazer com os erros. É, na prática, o painel de controle da linguagem no servidor.

O nome vem do formato do arquivo: .ini (de initialization), um formato de texto simples usado para configuração. Cada configuração é uma diretiva, escrita como uma chave e um valor separados por um sinal de igual:

Linhas que começam com ponto e vírgula (;) são comentários — o PHP as ignora. É por isso que, ao abrir um php.ini, você vê muitas linhas começando com ;: são diretivas desativadas ou explicações.

Onde fica o arquivo php.ini

A localização do php.ini varia conforme o sistema operacional e a forma como o PHP foi instalado — não há um único lugar fixo. Mas há duas formas rápidas de descobrir onde ele está.

Pelo comando php –ini

Se você tem acesso ao terminal (SSH), o jeito mais direto é rodar:

O comando mostra o caminho do arquivo carregado (na linha “Loaded Configuration File”) e de eventuais arquivos adicionais. Em sistemas Linux, o php.ini costuma ficar em caminhos como /etc/php/8.x/apache2/php.ini ou /etc/php/8.x/cli/php.ini — note que pode haver arquivos diferentes para o PHP do servidor web (Apache) e o da linha de comando (CLI).

Pela função phpinfo()

Se você não tem acesso ao terminal, mas pode subir um arquivo PHP para o site, crie um arquivo com este conteúdo e acesse-o pelo navegador:

Na página gerada, procure por “Loaded Configuration File” — é o caminho do php.ini em uso. Um cuidado importante: apague esse arquivo depois de consultar, porque o phpinfo() expõe muitos detalhes do servidor que podem ajudar um atacante.

Como editar o php.ini

Aqui está a parte que mais gera dúvida, porque depende do tipo de hospedagem. Depois de qualquer alteração, confirme que ela pegou: acesse novamente o phpinfo() (ou rode php -i) e veja se a diretiva está com o novo valor.

Em hospedagem compartilhada, você não edita o arquivo direto

Na maioria das hospedagens compartilhadas, o php.ini é um arquivo global do servidor, compartilhado por todos os sites — por isso você não tem permissão para editá-lo diretamente. Em vez disso, o painel oferece uma interface para ajustar as diretivas só do seu site. No cPanel, isso fica em Select PHP Version → Options. As alterações feitas ali valem apenas para a sua conta, com segurança.

No cPanel (hospedagem compartilhada)

Este é o caminho para a maioria dos sites hospedados. No cPanel:

1. Acesse o cPanel e clique em Select PHP Version (Selecionar versão do PHP).
2. Clique em Switch To PHP Options (ou “Options”).
3. Você verá a lista de diretivas ajustáveis (memory_limit, max_execution_time, upload_max_filesize, display_errors, etc.).
4. Clique no valor da diretiva que quer mudar, escolha o novo valor e salve.

As mudanças entram em vigor na hora, sem precisar reiniciar nada, e afetam só o seu site. É o método recomendado para quem está em hospedagem compartilhada.

Editando o arquivo diretamente (VPS ou dedicado)

Se você tem um VPS ou servidor dedicado, com acesso de administrador, edita o arquivo diretamente:

1. Localize o arquivo com php --ini.
2. Abra-o com um editor de texto (por exemplo, nano /etc/php/8.x/apache2/php.ini).
3. Encontre a diretiva (a busca do editor ajuda), altere o valor e salve.
4. Reinicie o serviço para aplicar: o Apache (systemctl restart apache2) ou o PHP-FPM, conforme o seu setup.

O passo 4 é o que muita gente esquece: ao editar o arquivo direto, a mudança só vale depois de reiniciar o servidor web ou o PHP-FPM. Sem isso, o PHP continua com a configuração antiga em memória.

Criando um php.ini próprio na hospedagem compartilhada

Muitas hospedagens compartilhadas, mesmo sem dar acesso ao php.ini global, permitem que você crie um arquivo de configuração próprio na pasta do seu site. Dependendo do servidor, ele se chama php.ini ou .user.ini, e vale só para o seu diretório e subpastas.

Pelo gerenciador de arquivos do cPanel, na raiz do site (public_html), crie um arquivo novo chamado php.ini (ou .user.ini) e adicione só as diretivas que quer mudar, uma por linha:

O .user.ini é o mecanismo do PHP (em instalações com PHP-FPM ou CGI) para configurações por diretório — funciona de forma parecida com o que o .htaccess faz para o Apache. Após criar o arquivo, a mudança pode levar alguns minutos para valer (o PHP relê o .user.ini periodicamente). Se o cPanel tiver o MultiPHP INI Editor, ele oferece essa mesma edição por uma interface gráfica, sem criar o arquivo à mão.

Pelo .htaccess ou ini_set (alternativas)

Há ainda duas formas de ajustar diretivas sem tocar no php.ini, úteis quando você não tem acesso a ele:

• No .htaccess (só em Apache), com php_value nome_da_diretiva valor.
• No próprio código PHP, com a função ini_set('diretiva', 'valor') — mas só funciona para diretivas que podem ser mudadas em tempo de execução.

Nem toda diretiva pode ser alterada por esses meios: algumas só valem se definidas no php.ini. Mas para ajustes comuns (como memory_limit ou display_errors), costumam funcionar.

As principais diretivas do php.ini

O php.ini tem dezenas de diretivas. Estas são as que você mais provavelmente vai precisar ajustar, agrupadas por finalidade:

Algumas dessas diretivas têm guias próprios com o passo a passo detalhado:

• Como aumentar o memory_limit (resolve o erro “Allowed memory size exhausted”).
• Como alterar o max_execution_time (resolve “Maximum execution time exceeded”).
• Como ajustar o upload_max_filesize e post_max_size (resolve falhas em uploads grandes).
• Como resolver o erro de register_globals em aplicações legadas.
• Como exibir os erros do PHP com display_errors e error_reporting (resolve a “tela branca” sem mensagem).
• Como ajustar o max_input_vars e max_input_time (resolve menus e formulários que não salvam tudo).
• O que é o allow_url_fopen e quando ativá-lo com segurança (acesso a URLs remotas).

Cuidados ao editar o php.ini

O php.ini é poderoso, e um valor errado pode ter efeitos indesejados:

• Valores muito altos de memory_limit ou max_execution_time podem deixar um script problemático consumir recursos demais do servidor — em vez de resolver, mascaram o problema real.
• display_errors ligado em produção expõe caminhos de arquivos e detalhes internos a qualquer visitante; deve ficar ligado só em desenvolvimento.
• Erros de sintaxe no arquivo (uma diretiva escrita errado) podem impedir o PHP de iniciar. Ao editar direto, mude uma diretiva por vez e teste.
• Cuidado com php.ini em nível de diretório e malware: arquivos php.ini locais são um alvo conhecido de ataques — é comum malware criar ou alterar um php.ini numa pasta para mudar o comportamento do PHP sem ser notado. Se encontrar um php.ini que você não criou, ou diretivas estranhas num arquivo seu, investigue: pode ser sinal de site comprometido.

Uma boa prática, ao editar o arquivo diretamente, é comentar a linha original (colocando ; na frente) e adicionar a nova logo abaixo, em vez de sobrescrever — assim você tem o valor antigo à mão para reverter.

Perguntas frequentes

O que é o arquivo php.ini?
É o arquivo de configuração do PHP. Ele é lido toda vez que o PHP inicia e define o comportamento da linguagem no servidor: limites de memória e tempo, exibição de erros, tamanho de upload e muitos outros ajustes. Cada configuração é uma diretiva, escrita no formato diretiva = valor.

Onde fica o php.ini?
A localização varia conforme o sistema operacional e a instalação. Para descobrir, rode php --ini no terminal e veja a linha “Loaded Configuration File”, ou crie um arquivo com <?php phpinfo(); ?>, acesse pelo navegador e procure o mesmo campo. Em Linux, costuma ficar em caminhos como /etc/php/8.x/apache2/php.ini.

Como editar o php.ini na hospedagem compartilhada?
Em hospedagem compartilhada você normalmente não edita o arquivo diretamente, porque ele é global. Use o painel: no cPanel, acesse Select PHP Version e depois Options, onde é possível ajustar as diretivas só do seu site. As mudanças valem na hora e afetam apenas a sua conta.

Por que minha alteração no php.ini não fez efeito?
Se você editou o arquivo diretamente num VPS ou servidor dedicado, provavelmente faltou reiniciar o serviço: as mudanças só valem após reiniciar o Apache ou o PHP-FPM. Verifique também se editou o php.ini correto — pode haver um arquivo para o Apache e outro para a linha de comando (CLI), além de confirmar o caminho com php –ini.

Como ver as configurações atuais do PHP?
Crie um arquivo com <?php phpinfo(); ?>, envie para o seu site e acesse pelo navegador: a página mostra todas as diretivas e seus valores atuais. Lembre-se de apagar o arquivo depois, pois ele expõe informações do servidor. Pela linha de comando, php -i mostra as mesmas informações.

Posso mudar configurações do PHP sem acesso ao php.ini?
Sim, em muitos casos. No Apache, você pode usar o arquivo .htaccess com php_value diretiva valor. No próprio código, a função ini_set() altera diretivas em tempo de execução. Nem toda diretiva aceita esses métodos, mas os ajustes mais comuns, como memory_limit e display_errors, costumam funcionar.

Conclusão

O php.ini é o centro de controle do PHP: um arquivo de texto onde cada diretiva ajusta um aspecto do comportamento da linguagem. O essencial para dominá-lo: descubra onde ele está com php --ini ou phpinfo(); edite pelo caminho certo — no cPanel (Select PHP Version → Options) se você está em hospedagem compartilhada, ou direto no arquivo (lembrando de reiniciar o serviço) se tem VPS ou dedicado; e conheça as diretivas principais — memory_limit, max_execution_time, upload_max_filesize, display_errors — que resolvem a maioria dos problemas do dia a dia. Com o php.ini sob controle, ajustar o ambiente PHP deixa de ser tentativa e erro e vira configuração consciente.

Para consumir APIs e fazer requisições HTTP a partir do PHP, veja também o guia de cURL no PHP.

O post php.ini: o que é, onde fica e como configurar apareceu primeiro em Homehost.

O nslookup é um comando que consulta o DNS: você dá a ele um domínio, e ele devolve as informações registradas no DNS daquele domínio — o endereço IP, o servidor de e-mail, os registros de texto e outros. É a ferramenta mais universal para investigar DNS, presente no Windows, no macOS e no Linux, sem precisar instalar nada.

Se você já configurou um domínio, mudou um servidor de e-mail ou tentou descobrir por que um site não carrega, o nslookup é o instrumento que responde à pergunta “o que o DNS está dizendo sobre este domínio agora?”. Este guia mostra o que é o nslookup, como usá-lo para consultar cada tipo de registro, como interpretar a resposta, e por que às vezes ele parece “mentir” — além da diferença para o dig, seu primo mais moderno.

O que é o nslookup

O nslookup — de name server lookup, ou “consulta ao servidor de nomes” — é uma ferramenta de linha de comando para consultar o DNS. Ele faz, manualmente e sob demanda, o mesmo tipo de pergunta que o seu navegador faz automaticamente toda vez que você acessa um site: “qual é o endereço deste domínio?”.

A diferença é que, com o nslookup, você faz a pergunta, escolhe exatamente o que quer saber, e vê a resposta crua do servidor DNS — sem a intermediação do navegador. Isso o torna a ferramenta padrão para verificar se um registro foi configurado corretamente, diagnosticar por que um e-mail ou site não funciona, e confirmar se uma alteração no DNS já se propagou.

Ele vem instalado por padrão em praticamente todos os sistemas — Windows, macOS e Linux —, e por isso é a primeira ferramenta que se alcança quando algo relacionado a DNS precisa ser investigado.

Como abrir o nslookup

O nslookup roda no terminal do seu sistema:

• Windows: abra o Prompt de Comando (tecle Win + R, digite cmd e Enter) ou o PowerShell.
• macOS: abra o Terminal (em Aplicativos → Utilitários).
• Linux: abra o seu terminal de preferência.

Em todos eles, o comando é digitado da mesma forma. Se o nslookup não estiver disponível em alguma distribuição Linux enxuta, ele faz parte do pacote de utilitários de DNS (como o dnsutils ou bind-utils), que também traz o dig.

O uso mais básico: descobrir o IP de um domínio

A forma mais simples do comando é digitar nslookup seguido do domínio:

A resposta vem mais ou menos assim:

Isso já traz duas informações importantes, e entender cada linha é a chave para usar o nslookup bem — o que veremos a seguir.

Como ler a resposta do nslookup

A saída do nslookup confunde muita gente por causa das primeiras linhas. Vamos por partes:

Os dois pontos que mais geram dúvida:

As primeiras linhas não são a resposta. O “Servidor” e o “Address” do topo dizem apenas quem respondeu — normalmente o seu resolvedor de DNS (o do provedor, ou o 8.8.8.8 se você usa o Google). A resposta que você quer está embaixo, em “Nome” e “Address”.

“Resposta não autoritativa” é normal, não é erro. Significa apenas que a resposta veio do cache de um resolvedor intermediário, e não diretamente do servidor autoritativo (o dono da zona). Na esmagadora maioria das consultas é o que você verá, e está tudo certo — é assim que o DNS funciona no dia a dia.

Consultando cada tipo de registro com -type=

Aqui está o que torna o nslookup poderoso: o parâmetro -type=, que permite pedir um tipo específico de registro em vez do IP padrão. É assim que você inspeciona toda a configuração de um domínio:

Cada um desses corresponde a um tipo de registro da zona DNS — e é a forma prática de verificar cada configuração. Quer confirmar se o registro MX do seu domínio aponta para o servidor certo? nslookup -type=mx. Publicou um SPF e quer ver se está no ar? nslookup -type=txt. Cada guia de registro da nossa série usa exatamente esse comando para a verificação.

Consultando um servidor DNS específico

Por padrão, o nslookup pergunta ao resolvedor configurado no seu sistema. Mas você pode escolher a qual servidor perguntar, colocando o IP do servidor no final do comando:

Esse comando consulta diretamente o DNS do Google (8.8.8.8), ignorando o resolvedor do seu provedor. É uma técnica valiosa por dois motivos:

• Testar propagação: consultando servidores diferentes (o do seu provedor, o do Google, o da Cloudflare), você vê se uma alteração recente já chegou a todos — porque a propagação de DNS não acontece ao mesmo tempo em todo lugar.
• Contornar cache local: se o seu provedor ainda tem um valor antigo em cache, perguntar direto a outro servidor mostra o valor mais atual.

O modo interativo

Se você digitar apenas nslookup e Enter, sem um domínio, ele entra no modo interativo — um prompt próprio onde você pode fazer várias consultas seguidas sem redigitar o comando:

Dentro dele, set type= muda o tipo de registro para as próximas consultas, e você digita um domínio por vez. Para sair, digite exit. O modo interativo é conveniente quando você vai inspecionar vários registros de um mesmo domínio em sequência.

Por que o nslookup às vezes parece “mentir”

Um ponto que confunde e vale entender: às vezes o nslookup mostra um valor que não bate com o que você acabou de configurar, ou que difere do que outra pessoa vê. Isso raramente é um bug — é o cache em ação.

O nslookup, por padrão, pergunta ao seu resolvedor, que guarda respostas em cache por um tempo (o TTL do registro). Se você mudou um registro há pouco, o resolvedor pode ainda estar servindo o valor antigo até o cache expirar. Por isso:

• Uma alteração recente pode não aparecer imediatamente — é a propagação de DNS em curso.
• Consultar direto o servidor autoritativo (ou um resolvedor público como o 8.8.8.8) pode mostrar um valor diferente do resolvedor do seu provedor.
• Duas pessoas em provedores diferentes podem ver respostas diferentes durante uma janela de propagação.

Entender isso evita o erro clássico de concluir que “o registro está errado” quando, na verdade, ele só ainda não propagou.

nslookup vs dig: qual usar

Se você pesquisou sobre consulta de DNS, provavelmente encontrou também o dig. Os dois fazem o mesmo trabalho essencial, mas têm perfis diferentes:

Na prática: o nslookup é a escolha natural no Windows e para consultas rápidas do dia a dia. O dig é preferido por quem trabalha com redes e quer ver todos os detalhes da resposta (TTL exato, seção de autoridade, tempo de consulta). O equivalente ao nslookup -type=mx dominio no dig é dig dominio MX +short. Saber os dois é útil; começar pelo nslookup é o caminho mais simples.

nslookup para diagnosticar problemas

O nslookup é uma das primeiras ferramentas em qualquer diagnóstico de DNS. Alguns usos práticos:

• Site não carrega: nslookup dominio — se não retorna IP, o problema é de DNS, não do servidor do site.
• E-mail não chega: nslookup -type=mx dominio — confirma se há registro MX e se aponta para o servidor certo.
• Verificação de domínio falha: nslookup -type=txt dominio — checa se o registro TXT de verificação foi publicado.
• Trocou de hospedagem: nslookup -type=ns dominio — mostra se os servidores de nomes já são os novos.

Se a consulta revela que o DNS está mesmo com problema, o passo seguinte é diagnosticar a causa — e para isso há um guia dedicado sobre como resolver problemas de DNS, que usa o nslookup junto de outras técnicas.

Perguntas frequentes

O que é o nslookup?
É um comando de terminal usado para consultar o DNS de um domínio. O nome vem de name server lookup. Com ele, você pergunta ao DNS informações sobre um domínio — o endereço IP, o servidor de e-mail, os registros de texto e outros — e vê a resposta diretamente, sem a intermediação do navegador. Está disponível no Windows, macOS e Linux por padrão.

Como usar o nslookup no Windows?
Abra o Prompt de Comando (tecle Win + R, digite cmd e Enter) e digite nslookup seguido do domínio, por exemplo nslookup seusite.com.br. Para consultar um tipo específico de registro, use o parâmetro -type, como em nslookup -type=mx seusite.com.br. O comando funciona da mesma forma no PowerShell.

Como consultar o registro MX com o nslookup?
Use o comando nslookup -type=mx seusite.com.br. Ele retorna os servidores de e-mail do domínio com suas prioridades. É a forma mais rápida de conferir se o registro MX está configurado e apontando para o servidor certo, útil quando um domínio não recebe e-mails.

O que significa “resposta não autoritativa” no nslookup?
Significa que a resposta veio do cache de um servidor DNS intermediário (o resolvedor), e não diretamente do servidor autoritativo, que é o dono da zona do domínio. Não é um erro: é o comportamento normal da maioria das consultas, já que o DNS usa cache para ser rápido.

Qual a diferença entre nslookup e dig?
Os dois consultam o DNS, mas o nslookup vem instalado por padrão no Windows, Mac e Linux e tem uma saída mais simples, enquanto o dig oferece uma resposta mais técnica e detalhada, sendo preferido em diagnósticos avançados. No Windows, o dig precisa ser instalado à parte. Para o dia a dia, o nslookup costuma bastar.

Por que o nslookup mostra um resultado diferente do que configurei?
Quase sempre por causa do cache. O resolvedor de DNS guarda as respostas por um tempo (o TTL), então uma alteração recente pode não aparecer até o cache expirar — é a propagação de DNS em andamento. Consultar diretamente outro servidor, como o 8.8.8.8, colocando o IP dele no fim do comando, costuma mostrar o valor mais atual.

Como consultar um servidor DNS específico com o nslookup?
Coloque o IP do servidor no final do comando, depois do domínio. Por exemplo, nslookup seusite.com.br 8.8.8.8 consulta diretamente o DNS do Google, ignorando o resolvedor do seu provedor. É útil para testar a propagação de uma alteração e para contornar um cache local desatualizado.

O nslookup funciona no Linux e no Mac?
Sim. O nslookup está disponível no macOS e na maioria das distribuições Linux, além do Windows. Em algumas distribuições Linux mínimas pode ser preciso instalar o pacote de utilitários de DNS (como dnsutils ou bind-utils), que também inclui o dig.

Conclusão

O nslookup é a lupa do DNS: um comando simples, presente em qualquer sistema, que responde à pergunta “o que o DNS diz sobre este domínio?”. Guarde o essencial: nslookup dominio traz o IP, e o parâmetro -type= abre a porta para todos os outros registros — mx para e-mail, txt para SPF e verificações, ns para servidores de nomes, ptr para o reverso. Ao ler a resposta, lembre que as primeiras linhas dizem só quem respondeu, e que “resposta não autoritativa” é normal. E quando um valor não bate com o esperado, o culpado quase sempre é o cache — não o registro. Com o nslookup na mão, configurar e diagnosticar DNS deixa de ser adivinhação e vira verificação.

O post nslookup: o que é e como usar para consultar o DNS apareceu primeiro em Homehost.

Um registro TXT é um campo de texto livre no DNS de um domínio, usado para guardar informações que outros serviços leem — principalmente para autenticar e-mail e provar a propriedade do domínio. Diferente de registros como o A ou o MX, que têm um formato rígido, o TXT aceita praticamente qualquer texto. É essa flexibilidade que fez dele o “canivete suíço” do DNS.

Se você já configurou SPF, DKIM ou verificou um domínio no Google, você usou um registro TXT — mesmo sem perceber. Este guia explica o que é o registro TXT, para que ele serve na prática, as regras técnicas que causam a maioria dos erros (aspas e limite de caracteres), e o passo a passo para adicionar um no Registro.br ou em qualquer painel de DNS.

O que é um registro TXT

Os registros de DNS mais conhecidos têm um trabalho único e um formato fixo: o registro A guarda um endereço IP, o registro MX guarda o servidor de e-mail, o CNAME guarda um apelido. Cada um só aceita o tipo de dado para o qual foi feito.

O registro TXT (de text) é diferente: ele guarda texto livre. Foi criado originalmente para associar notas legíveis por humanos a um domínio, mas com o tempo virou um espaço de uso geral — um lugar onde qualquer serviço pode publicar uma informação para ser lida por outros servidores na internet.

A ideia é simples: você coloca um texto no DNS do seu domínio, e qualquer serviço no mundo pode consultá-lo. Como o DNS é público e confiável, e só quem controla o domínio pode editar seus registros, um TXT vira uma forma de o dono do domínio declarar algo publicamente e de forma verificável. É essa característica que sustenta quase todos os usos modernos do TXT.

Para que serve o registro TXT

Na prática, o TXT é usado hoje para algumas finalidades bem definidas:

Os dois primeiros são, de longe, os mais comuns — e vale detalhar cada um.

Autenticação de e-mail (SPF, DKIM, DMARC)

O uso mais frequente do TXT hoje é a autenticação de e-mail. Os três protocolos que protegem um domínio contra falsificação e garantem a entrega das mensagens — SPF, DKIM e DMARC — são todos publicados como registros TXT no DNS.

Um registro SPF, por exemplo, é um TXT que começa com v=spf1 e lista os servidores autorizados a enviar e-mail pelo domínio. O DMARC é um TXT no nome _dmarc com a política de tratamento. Ou seja: quando alguém diz “publique o SPF no seu DNS”, o que está pedindo é a criação de um registro TXT.

Como esse é um assunto grande por si só, ele tem um guia próprio: veja SPF, DKIM e DMARC para entender como os três funcionam e como configurá-los. Aqui, o que importa reter é que o “envelope” de todos eles é o registro TXT.

Verificação de propriedade de domínio

O segundo grande uso: provar que um domínio é seu. Quando você vai usar um serviço que precisa confiar que você controla um domínio — Google Workspace, Microsoft 365, Search Console, ferramentas de e-mail marketing, redes sociais para empresas —, ele quase sempre pede uma verificação por TXT.

O funcionamento é engenhoso: o serviço gera um valor único (algo como google-site-verification=aBc123...) e pede que você o publique como um TXT no DNS do domínio. Só quem controla o domínio consegue fazer isso. O serviço então consulta o DNS, encontra o valor exato que gerou, e conclui: “esta pessoa realmente controla este domínio”. Feito isso, o TXT de verificação pode até ser removido — ele já cumpriu o papel.

É rápido, não afeta o funcionamento do site nem do e-mail, e por isso virou o método padrão de verificação de propriedade na internet.

Validação de certificado SSL

Há ainda um uso técnico importante: emitir um certificado SSL provando o domínio pelo DNS, em vez de por um arquivo no servidor. Essa é a validação DNS-01, em que a autoridade certificadora pede um TXT específico para confirmar o controle do domínio — o único caminho para certificados wildcard. O detalhe desse processo está no guia da porta 80, que compara os métodos de validação.

As regras do registro TXT (onde a maioria erra)

O TXT é flexível, mas tem algumas regras técnicas que causam a maior parte dos erros de configuração.

Aspas e o limite de 255 caracteres

Cada “string” dentro de um registro TXT tem um limite de 255 caracteres. Valores maiores (como uma chave DKIM longa) precisam ser divididos em várias strings entre aspas, uma seguida da outra — o servidor DNS as junta na leitura. E o conteúdo do TXT costuma ir entre aspas duplas. A maioria dos painéis cuida das aspas automaticamente, mas em painéis manuais o descuido com aspas e com o limite é a causa nº1 de um TXT que “não funciona”.

Além disso, uma regra que diferencia o TXT dos demais — e que é o oposto exato da regra do CNAME:

Vários registros TXT podem coexistir no mesmo nome. Enquanto um nome com CNAME não pode ter nenhum outro registro, um mesmo nome pode ter quantos TXT forem necessários — é comum um domínio ter, ao mesmo tempo, um TXT de SPF, um de verificação do Google, um de verificação da Microsoft, e assim por diante. Eles convivem sem conflito, porque cada serviço procura o TXT com o prefixo que reconhece (v=spf1, google-site-verification=, etc.) e ignora os demais.

Há uma exceção importante dentro dessa regra: só pode haver um registro SPF por domínio. Não é uma limitação do TXT em si, mas do SPF — ter dois TXT de SPF no mesmo nome invalida a autenticação. Se você usa vários serviços de envio, eles devem ser combinados em um único registro SPF, não em vários.

Como consultar um registro TXT

Verificar os registros TXT de um domínio é a forma mais rápida de conferir se um SPF, um DMARC ou uma verificação foram publicados corretamente:

O comando nslookup devolve todos os registros TXT daquele nome — normalmente você verá vários, um para cada serviço. Para checar um TXT em um subdomínio específico (como o _dmarc ou uma chave DKIM), basta consultar o nome completo, por exemplo nslookup -type=txt _dmarc.seusite.com.br .

Fazer essa consulta depois de qualquer alteração é essencial, porque a mudança só vale após a propagação de DNS — muitos serviços de verificação falham simplesmente porque foram checados cedo demais.

Como adicionar um registro TXT no Registro.br

Para domínios .br que usam o DNS do Registro.br:

1. Acesse registro.br e faça login com a conta dona do domínio.
2. Selecione o domínio e vá em Editar zona DNS.
3. Adicione uma nova entrada do tipo TXT.
4. No campo de nome, coloque o que o serviço pedir: em branco ou @ para o domínio raiz (caso mais comum, como o SPF), ou o nome específico (como _dmarc).
5. No valor, cole exatamente o texto fornecido pelo serviço — sem alterar nada, respeitando maiúsculas, minúsculas e sinais.
6. Salve a zona e aguarde a propagação.

O ponto mais importante é o passo 5: cole o valor exatamente como recebido. Um espaço a mais, uma letra trocada ou uma aspa removida faz a verificação falhar. Copie e cole diretamente da tela do serviço, sem digitar à mão.

Como adicionar um registro TXT em qualquer painel de DNS

Se o DNS do seu domínio é gerenciado pela hospedagem, o processo é feito no painel dela (como o cPanel), mas os campos são sempre os mesmos:

• Tipo: TXT
• Nome / Host: o nome do registro (@, _dmarc, ou o que o serviço indicar)
• Valor / Conteúdo / TXT Data: o texto a ser publicado
• TTL: pode deixar o padrão

Vale o mesmo cuidado do Registro.br: cole o valor exato e confirme, antes de tudo, onde o DNS do domínio está sendo gerenciado — se está no Registro.br ou na hospedagem. Adicionar o TXT no painel errado é um erro comum, e o registro simplesmente não aparece nas consultas porque foi criado numa zona que não é a que responde pelo domínio.

Problemas comuns com o registro TXT

Registro TXT e os outros registros DNS

O TXT é um entre os vários tipos de registro que compõem uma zona DNS. Veja onde ele se encaixa:

Para entender como todos eles se organizam dentro da zona DNS de um domínio, o guia do servidor DNS mostra o quadro completo.

Perguntas frequentes

O que é um registro TXT?
É um tipo de registro DNS que guarda texto livre associado a um domínio. Diferente de registros com formato fixo, como o A ou o MX, o TXT aceita praticamente qualquer texto, para que serviços externos o leiam. Seus usos mais comuns são a autenticação de e-mail (SPF, DKIM, DMARC) e a verificação de propriedade de domínio.

Para que serve o registro TXT?
Serve principalmente para dois fins: autenticar o e-mail do domínio (o SPF, o DKIM e o DMARC são todos registros TXT) e provar a propriedade do domínio a serviços como Google e Microsoft, que pedem a publicação de um TXT único. Também é usado para validação de certificados SSL pelo DNS e para guardar metadados diversos.

SPF e DKIM são registros TXT?
Sim. Tanto o SPF quanto o DKIM e o DMARC são publicados como registros TXT no DNS do domínio. O SPF é um TXT que lista os servidores autorizados a enviar e-mail; o DMARC é um TXT no nome _dmarc com a política; e o DKIM é um TXT com a chave pública. Por isso, configurar autenticação de e-mail é, na prática, criar registros TXT.

Posso ter vários registros TXT no mesmo domínio?
Sim. Ao contrário do CNAME, vários registros TXT podem coexistir no mesmo nome — é normal um domínio ter um TXT de SPF, um de verificação do Google e outros ao mesmo tempo. A única exceção é o SPF: deve haver apenas um registro SPF por domínio, combinando todos os serviços de envio em uma só linha.

Como adicionar um registro TXT no Registro.br?
Acesse o registro.br, faça login, selecione o domínio e vá em Editar zona DNS. Adicione uma entrada do tipo TXT, informando o nome (em branco ou @ para a raiz, ou o nome específico como _dmarc) e colando no valor exatamente o texto fornecido pelo serviço. Salve e aguarde a propagação. O mais importante é colar o valor sem alterar nada.

Como consultar os registros TXT de um domínio?
Use nslookup -type=txt seusite.com.br no Windows, Mac ou Linux, ou dig seusite.com.br TXT +short no Mac e Linux. O comando lista todos os registros TXT do nome. Para um subdomínio específico, como uma verificação DKIM ou o DMARC, consulte o nome completo, por exemplo _dmarc.seusite.com.br.

Por que meu registro TXT não funciona?
As causas mais comuns são: a propagação de DNS ainda não terminou; o valor foi digitado com algum erro (um espaço extra, uma letra trocada); uma chave longa passou de 255 caracteres sem ser dividida em strings; ou o registro foi criado na zona errada (no Registro.br quando o DNS está na hospedagem, ou vice-versa). Confira sempre com nslookup ou dig.

Qual o limite de tamanho de um registro TXT?
Cada string dentro de um registro TXT tem o limite de 255 caracteres. Valores maiores, como chaves DKIM, precisam ser divididos em várias strings entre aspas, colocadas em sequência — o servidor DNS as concatena na leitura. A maioria dos painéis modernos faz essa divisão automaticamente, mas em painéis manuais é preciso atenção.

Conclusão

O registro TXT é o campo de texto livre do DNS — o mais flexível de todos, e por isso o mais versátil. Guarde o essencial: ele serve, acima de tudo, para autenticar e-mail (SPF, DKIM e DMARC são todos TXT) e para provar a propriedade de um domínio a serviços externos; ao contrário do CNAME, vários TXT convivem no mesmo nome (com a única exceção do SPF, que deve ser único); e a maioria dos erros vem de detalhes de digitação — um valor colado errado, uma aspa faltando ou o limite de 255 caracteres. Na dúvida, um nslookup -type=txt mostra exatamente o que está publicado. Com isso, o TXT deixa de ser aquele campo misterioso do painel e vira uma ferramenta que você configura com confiança.

O post Registro TXT: o que é, para que serve e como configurar apareceu primeiro em Homehost.

O registro MX é o que diz para onde vai o e-mail de um domínio. Quando alguém envia uma mensagem para contato@seusite.com.br, o servidor de quem envia consulta o registro MX do seusite.com.br para descobrir qual servidor de e-mail deve receber aquela mensagem. Sem um MX correto, o domínio simplesmente não recebe e-mail.

MX vem de Mail eXchanger (trocador de correio). É um dos registros DNS mais importantes de qualquer domínio que use e-mail — e um dos que mais gera confusão, por causa de um número que aparece ao lado dele e quase ninguém explica: a prioridade. Este guia cobre o que é o registro MX, como a prioridade funciona, por que ele nunca pode apontar para um CNAME, e o passo a passo para configurar ou alterar o MX no Registro.br e no cPanel.

O que é o registro MX

Quando você envia um e-mail, ele não vai direto para o computador do destinatário. Ele vai para o servidor de e-mail responsável pelo domínio de destino, que guarda a mensagem até o destinatário buscá-la. A pergunta é: como o servidor de quem envia descobre qual é esse servidor de destino?

A resposta é o registro MX. Ele fica na zona DNS do domínio e aponta para o nome do servidor que deve receber os e-mails daquele domínio:

O fluxo é este: alguém envia para contato@seusite.com.br → o servidor de envio consulta o MX do seusite.com.br → o MX responde mail.seusite.com.br → o servidor de envio resolve o registro A desse nome, obtém o IP e entrega a mensagem ali. Tudo isso em frações de segundo, antes de a mensagem sair.

É por isso que o MX é o registro que “liga” o e-mail: um domínio pode ter o site em um servidor e o e-mail em outro, e é o MX que define esse segundo destino de forma independente.

A prioridade do MX: o número que confunde todo mundo

Menor número = maior prioridade

Todo registro MX tem um número de prioridade, e a lógica é invertida do que parece: quanto menor o número, mais importante o servidor. Um MX com prioridade 10 recebe antes de um com prioridade 20. O de número maior só entra em ação se o de menor número estiver indisponível. Não existe “prioridade alta” com número alto — é o contrário.

Um domínio pode ter vários registros MX, e é aí que a prioridade importa. Ela cria uma ordem de preferência entre os servidores:

O servidor de envio sempre tenta o menor número primeiro. Se aquele servidor não responde, ele passa para o próximo em ordem crescente. Isso dá redundância: se o servidor principal ficar fora do ar, o backup recebe as mensagens e as repassa quando o principal voltar, em vez de o e-mail simplesmente falhar.

E se dois MX têm o mesmo número? Aí o tráfego é distribuído entre eles, de forma aproximadamente igual — é uma maneira de fazer balanceamento de carga entre servidores equivalentes.

Para a maioria dos domínios, porém, a configuração é simples: um ou dois registros MX que o próprio provedor de e-mail define. Os números específicos vêm prontos na documentação de quem hospeda o seu e-mail.

O MX nunca aponta para um CNAME

Uma regra que causa erros silenciosos: o valor de um registro MX deve ser um nome com registro A (ou AAAA) — nunca um CNAME.

O motivo está na especificação do DNS. Quando um servidor de envio consulta o MX e recebe um nome, ele espera resolver esse nome direto para um IP. Se esse nome for um apelido (CNAME) apontando para outro nome, cria-se uma indireção que a especificação proíbe nesse contexto — e muitos servidores de e-mail rejeitam ou tratam mal essa configuração.

Na prática: o MX deve apontar para algo como mail.seusite.com.br, e esse nome precisa ter um registro A com o IP do servidor. Apontar o MX para um nome que é CNAME é um erro comum e difícil de diagnosticar, porque às vezes funciona em alguns servidores e falha em outros.

Como consultar o registro MX de um domínio

Verificar o MX de qualquer domínio é rápido, e útil para confirmar uma configuração ou diagnosticar por que um e-mail não chega:

O comando nslookup devolve os servidores MX do domínio com suas prioridades. Se não vier nada, o domínio não tem MX configurado — e não recebe e-mail. Além da linha de comando, há ferramentas web de MX lookup que fazem a mesma consulta pelo navegador e ainda checam se os servidores respondem.

Vale um teste rápido sempre que você configurar ou alterar o e-mail de um domínio: consultar o MX confirma, em segundos, se a mudança já está valendo (lembrando que ela depende da propagação de DNS).

Como configurar o registro MX no Registro.br

Para domínios .br que usam o DNS do próprio Registro.br, o caminho é este:

1. Acesse registro.br e faça login com a conta dona do domínio.
2. Clique no domínio e vá em Editar zona DNS (ou “DNS” → “Editar zona”).
3. Adicione uma nova entrada do tipo MX.
4. No campo de nome, deixe em branco ou use @ para se referir ao domínio raiz.
5. No valor, informe o servidor de e-mail (por exemplo, mail.seusite.com.br), e no campo de prioridade, o número (comece com 10 para o principal).
6. Salve a zona.

Um cuidado que evita a falha mais comum: remova os registros MX antigos ao trocar de provedor de e-mail. Deixar um MX antigo junto do novo faz parte das mensagens irem para o servidor errado — e o problema aparece de forma intermitente, difícil de rastrear.

Se o seu domínio não usa o DNS do Registro.br, mas sim o da sua hospedagem, a edição é feita no painel dela (como o cPanel), e não no Registro.br. Vale conferir onde está o DNS do domínio antes de procurar o campo de MX no lugar errado.

Como configurar MX no cPanel (e para o Google)

Em hospedagens com cPanel, o MX é editado na ferramenta Roteamento de e-mail (ou “Entrada MX”). Lá você define se o e-mail é entregue localmente (no próprio servidor da hospedagem) ou em um servidor remoto — este último é o caso de quem usa Google Workspace, Microsoft 365 ou outro serviço externo.

O passo a passo detalhado para apontar o MX a um serviço externo, com o exemplo do Google, está no guia de como configurar um MX externo do Google no cPanel. A ideia central: ao usar um e-mail externo, o roteamento passa para “servidor remoto” e os MX apontam para os servidores do provedor escolhido.

MX e os outros registros de e-mail

O MX não trabalha sozinho. Ele diz para onde o e-mail vai, mas quem garante que ele chegue à caixa de entrada (e não ao spam) é um conjunto de registros que atuam juntos:

Vale entender a divisão: o MX cuida do recebimento (por onde o e-mail entra no seu domínio); já o SPF, DKIM e DMARC e o DNS reverso cuidam do envio e da reputação. Um domínio com MX certo recebe e-mail; um domínio com todos eles certos recebe e consegue entregar sem cair no spam. E o servidor por trás do MX se conecta pelas portas de e-mail padrão (como a 25, entre servidores).

Problemas comuns com o registro MX

O último caso é mais comum do que parece: a pessoa altera o MX no Registro.br, mas o domínio aponta os servidores DNS para a hospedagem — então a edição no Registro.br não tem efeito nenhum, porque quem responde pela zona é outro. Antes de editar, confirme onde o DNS do domínio está sendo gerenciado.

Perguntas frequentes

O que é um registro MX?
É o registro DNS que indica para qual servidor de e-mail as mensagens de um domínio devem ser entregues. MX significa Mail eXchanger. Quando alguém envia um e-mail para um endereço do seu domínio, o servidor de envio consulta o MX para descobrir o servidor de destino. Sem um MX válido, o domínio não recebe e-mail.

Como funciona a prioridade do MX?
Cada registro MX tem um número de prioridade, e quanto menor o número, maior a prioridade. O servidor de envio tenta primeiro o MX de menor número; se ele não responder, passa para o próximo em ordem crescente. Isso permite ter um servidor principal (por exemplo, prioridade 10) e um de backup (prioridade 20) que só entra em ação se o principal cair.

O que significa a prioridade 10 e 20 no MX?
São a ordem de preferência entre servidores. O MX de prioridade 10 recebe os e-mails normalmente; o de prioridade 20 é um backup, usado só quando o de 10 está indisponível. Os números em si não têm valor absoluto: o que importa é qual é o menor. Poderiam ser 5 e 50 e o efeito seria o mesmo.

O registro MX pode apontar para um CNAME?
Não. O valor do MX deve ser um nome com registro A (ou AAAA), nunca um CNAME. A especificação do DNS não permite essa indireção no contexto do MX, e muitos servidores de e-mail rejeitam a configuração. O MX deve apontar para um nome como mail.seusite.com.br, que por sua vez tem um registro A com o IP do servidor.

Como consultar o registro MX de um domínio?
Use nslookup -type=mx seusite.com.br no Windows, Mac ou Linux, ou dig seusite.com.br MX +short no Mac e Linux. O comando devolve os servidores MX do domínio com suas prioridades. Se não retornar nada, o domínio não tem MX configurado e, portanto, não recebe e-mail.

Como configurar o MX no Registro.br?
Acesse o registro.br, faça login, selecione o domínio e vá em Editar zona DNS. Adicione uma entrada do tipo MX, deixando o nome em branco ou com @, informando o servidor de e-mail no valor e o número no campo de prioridade. Salve a zona. Importante: remova os MX antigos ao trocar de provedor, e confirme que o DNS do domínio é mesmo o do Registro.br, e não o da hospedagem.

Por que meu domínio não recebe e-mails?
A causa mais comum é o registro MX ausente ou incorreto. Verifique com nslookup ou dig se existe um MX e se ele aponta para o servidor certo. Outras causas: MX apontando para um CNAME, MX antigo não removido após troca de provedor, ou a alteração feita no painel errado (Registro.br em vez da hospedagem, ou vice-versa). Lembre-se também da propagação de DNS após qualquer mudança.

Qual a diferença entre registro MX e registro A?
O registro A liga um nome a um endereço IP. O registro MX diz para qual servidor entregar o e-mail do domínio — e esse MX aponta para um nome, que por sua vez tem um registro A com o IP. Ou seja, os dois trabalham juntos: o MX define o destino do e-mail, e o A resolve o endereço real desse destino.

Conclusão

O registro MX é o endereço de entrega do e-mail do seu domínio: é ele que diz aos servidores do mundo inteiro para onde mandar as mensagens que chegam para você. Três coisas resumem o essencial: menor número de prioridade = servidor preferido, com os demais servindo de backup; o MX aponta para um nome com registro A, nunca para um CNAME; e ao configurar ou trocar de provedor, remova os MX antigos e edite no painel que realmente controla o DNS — Registro.br ou hospedagem, nunca os dois pela metade. Um nslookup -type=mx confirma em segundos se está tudo no lugar. E lembre-se de que o MX cuida do recebimento: para o e-mail também sair bem, ele anda de mãos dadas com SPF, DKIM, DMARC e o DNS reverso.

O post Registro MX (DNS MX): o que é, prioridade e como configurar apareceu primeiro em Homehost.

DNS reverso é a consulta que descobre o nome de domínio a partir de um endereço IP — o caminho inverso do DNS comum. Enquanto o DNS normal parte de um nome (seusite.com.br) e chega a um IP, o DNS reverso parte de um IP e chega a um nome. Quem faz esse trabalho é um tipo específico de registro: o PTR.

Na navegação do dia a dia, você nunca percebe o DNS reverso. Mas há um lugar onde ele é decisivo: o e-mail. Servidores de e-mail do mundo inteiro checam o DNS reverso de quem envia antes de aceitar a mensagem — e um IP sem PTR configurado, ou com PTR errado, é uma das causas mais comuns de e-mail caindo direto no spam. Este guia explica o que é o DNS reverso, como funciona o registro PTR, por que ele é diferente de todos os outros registros, e como configurá-lo.

O que é DNS reverso

O DNS que você conhece funciona numa direção: você digita homehost.com.br e ele devolve o endereço IP do servidor. Isso é o DNS direto (forward), e é o registro A que faz esse trabalho.

O DNS reverso (rDNS) faz o caminho contrário: parte de um endereço IP e descobre qual nome está associado a ele. Se o DNS direto responde “qual o IP deste nome?”, o reverso responde “qual o nome deste IP?”.

Para entender por que isso é útil, pense em quem recebe uma conexão. Um servidor que recebe um e-mail vê apenas o IP de quem está enviando — um número, sem contexto. O DNS reverso é o que permite a ele perguntar: “este IP diz pertencer a quem?”. Se a resposta for coerente, a conexão ganha credibilidade; se não houver resposta, ela fica suspeita.

O registro PTR

O DNS reverso é possível graças a um tipo de registro chamado PTR (pointer record, ou registro de ponteiro). Ele é o espelho do registro A:

O PTR guarda, para um determinado IP, o nome de domínio canônico daquele endereço. Quando um servidor faz uma consulta reversa, é o PTR que responde. Ele é a base de tudo que envolve DNS reverso — a ponto de “DNS reverso” e “registro PTR” serem, na prática, dois nomes para o mesmo assunto: o conceito e o registro que o implementa.

A zona in-addr.arpa: o IP de trás para frente

Aqui está a parte mais curiosa do DNS reverso, e que revela como ele foi encaixado no sistema.

O DNS foi construído para ler nomes da direita para a esquerda, do mais geral para o mais específico: em blog.seusite.com.br, o .br é a raiz, depois vem com, seusite e por fim blog. Os IPs funcionam ao contrário — em 200.151.24.50, a parte mais geral (a rede) fica à esquerda.

Para encaixar o IP nessa lógica de “geral primeiro”, o DNS reverso inverte o endereço e adiciona um sufixo especial:

O IP aparece de trás para frente, seguido de .in-addr.arpa — um domínio reservado exclusivamente para o DNS reverso. É nessa “zona reversa” que os registros PTR vivem. Para IPv6, a lógica é a mesma, com o sufixo .ip6.arpa.

Você raramente vai digitar isso à mão — as ferramentas montam o nome invertido sozinhas. Mas entender esse formato explica por que o DNS reverso parece tão diferente: ele não mora junto dos outros registros do seu domínio. Mora numa árvore própria, organizada por IP, não por nome.

Por que o PTR é diferente de todos os outros registros

Você não configura o PTR no DNS do seu domínio

Este é o ponto que mais confunde. Registros como A, CNAME, MX e TXT ficam na zona do seu domínio, e você os edita no painel da hospedagem. O PTR não. Ele fica na zona reversa do bloco de IP, que pertence a quem é dono daquele IP — normalmente a sua hospedagem, o provedor de nuvem ou o seu ISP. Por isso você pode procurar a vida inteira no painel do seu domínio e nunca achar onde criar um PTR: ele simplesmente não está lá. Para configurá-lo, é preciso pedir a quem controla o IP.

A lógica por trás disso é justa: quem prova ser o dono de um IP é quem o administra, não quem só aponta um nome para ele. Qualquer pessoa pode criar um registro A dizendo que o seu domínio aponta para o IP 8.8.8.8 — mas isso não lhe dá controle nenhum sobre o 8.8.8.8. O PTR, por morar do lado do IP, só pode ser definido por quem realmente o controla. É isso que dá valor a ele como sinal de confiança.

Na prática:

• Em hospedagem compartilhada, o PTR já vem configurado pelo provedor, apontando para um nome dele. Você normalmente não precisa (nem pode) mexer.
• Em VPS ou servidor dedicado, você geralmente pode solicitar um PTR personalizado ao provedor, apontando o IP para o hostname do seu servidor de e-mail.
• No seu DNS, o que você configura é o registro A correspondente — porque o PTR só tem valor se “fechar o círculo” com ele, como veremos a seguir.

FCrDNS: o teste que os servidores realmente fazem

Ter um PTR configurado não basta. O que os servidores de e-mail de verdade verificam é algo mais rígido, chamado FCrDNS (Forward-Confirmed reverse DNS), ou DNS reverso com confirmação direta — também conhecido como “círculo completo”.

O motivo de existir é uma brecha. Como o PTR é definido por quem controla o IP, um spammer que aluga um IP poderia apontar o PTR dele para mail.google.com e tentar herdar a reputação do Google. O FCrDNS fecha essa brecha exigindo que os dois lados concordem entre si:

Ou seja: o PTR aponta o IP para um nome, e o registro A daquele nome precisa apontar de volta para o mesmo IP. Se as duas pontas batem, o servidor tem uma garantia razoável de que quem envia é quem diz ser. Se não batem — ou se falta uma das pontas — a mensagem perde credibilidade.

É por isso que configurar DNS reverso é sempre um trabalho de dois lados: pedir o PTR a quem controla o IP, e criar o registro A correspondente no seu domínio. Um sem o outro não fecha o círculo.

Por que isso importa tanto para e-mail

O DNS reverso é, acima de tudo, uma ferramenta anti-spam. E a razão é histórica: máquinas domésticas infectadas, usadas por botnets para disparar spam, quase nunca têm PTR configurado — porque o dono do IP (o provedor de internet residencial) não configura reverso para cada cliente. Servidores de e-mail legítimos, ao contrário, têm.

Isso transformou o PTR num filtro de primeira linha:

• Um IP sem PTR é tratado com forte desconfiança — muitos servidores recusam a conexão de cara.
• Um PTR genérico (do tipo ip-200-151-24-50.provedor.net, atribuído automaticamente) é melhor que nada, mas fraco: não identifica o seu domínio.
• Um PTR próprio, com FCrDNS fechado, é o que os grandes provedores esperam de quem envia e-mail a sério.

O DNS reverso não substitui o SPF, DKIM e DMARC — ele os complementa. Enquanto esses três autenticam o domínio e o conteúdo da mensagem, o PTR valida o IP de envio. Juntos, formam a base da entregabilidade: um domínio que quer chegar à caixa de entrada precisa dos quatro alinhados. Se os seus e-mails vão para o spam mesmo com SPF e DKIM corretos, o DNS reverso do IP de envio é um dos primeiros lugares a investigar.

Como consultar o DNS reverso de um IP

Você pode verificar o PTR de qualquer IP com o comando nslookup ou dig:

O dig -x já cuida de inverter o IP e consultar a zona .in-addr.arpa para você. Se houver um PTR, o comando devolve o hostname; se não houver, a resposta vem vazia (ou como NXDOMAIN).

Para conferir o FCrDNS — o círculo completo — faça as duas pontas: consulte o PTR do IP e depois o registro A do nome que ele devolveu. Se o A voltar ao IP original, está tudo certo. A ferramenta Qual é meu IP mostra o hostname reverso do seu IP atual, um jeito rápido de ver isso.

Como configurar o DNS reverso

O processo tem sempre duas etapas, nesta ordem:

1. Crie o registro A no DNS do seu domínio, apontando o hostname do servidor (por exemplo, mail.seusite.com.br) para o IP dele. Essa ponta você controla.
2. Solicite o PTR a quem controla o IP — a sua hospedagem, o provedor de VPS ou o provedor de nuvem. Informe o IP e o hostname que ele deve apontar (o mesmo do registro A). Em muitos painéis de VPS, há um campo de “DNS reverso” ou “rDNS”; em outros, é preciso abrir um chamado.

Feitas as duas, aguarde a propagação de DNS e confirme com o dig -x. Uma observação importante: o PTR deve apontar para um nome que existe e resolve de volta ao IP — apontar para um hostname sem registro A quebra o FCrDNS e é um erro comum.

Problemas comuns de DNS reverso

Perguntas frequentes

O que é DNS reverso?
É a consulta que descobre o nome de domínio associado a um endereço IP, o caminho inverso do DNS comum. Enquanto o DNS direto parte de um nome e chega a um IP (pelo registro A), o DNS reverso parte de um IP e chega a um nome, usando o registro PTR. Sua aplicação mais importante é na verificação de servidores de e-mail.

O que é um registro PTR?
PTR (pointer) é o tipo de registro DNS que faz o DNS reverso funcionar: ele associa um endereço IP a um nome de domínio. É o espelho do registro A, que faz o contrário. O PTR fica numa zona especial terminada em .in-addr.arpa (para IPv4) ou .ip6.arpa (para IPv6), organizada por IP em vez de por nome.

Por que não consigo criar o PTR no painel do meu domínio?
Porque o PTR não fica na zona do seu domínio, e sim na zona reversa do bloco de IP, que pertence a quem controla aquele IP — normalmente a sua hospedagem, o provedor de VPS ou o ISP. Para criar ou alterar um PTR, é preciso solicitar a eles, e não editar no DNS do domínio. É a diferença fundamental do PTR para os registros A, CNAME, MX e TXT.

Para que serve o DNS reverso?
Sua função principal é a entrega de e-mail. Servidores de destino consultam o DNS reverso do IP de quem envia para verificar se ele é legítimo: um IP sem PTR, ou com PTR que não confere, é tratado como suspeito e a mensagem costuma ir para o spam ou ser recusada. Também é usado em diagnóstico de rede e em logs, para mostrar nomes em vez de números.

O que é FCrDNS?
FCrDNS (Forward-Confirmed reverse DNS) é a verificação completa que os servidores de e-mail realmente fazem. Não basta ter um PTR: o nome que o PTR devolve precisa ter um registro A que aponte de volta ao mesmo IP. Se as duas pontas batem, o círculo se fecha e o IP ganha credibilidade. É o que impede um spammer de apontar o PTR para um nome que não é dele.

DNS reverso substitui SPF, DKIM e DMARC?
Não. Eles são complementares. O SPF, DKIM e DMARC autenticam o domínio e o conteúdo da mensagem; o DNS reverso valida o IP de envio. Um bom setup de entregabilidade tem os quatro configurados e alinhados. Se os e-mails vão para o spam mesmo com SPF e DKIM corretos, o DNS reverso do IP de envio é um dos primeiros pontos a checar.

Como consultar o DNS reverso de um IP?
Use nslookup 200.151.24.50 no Windows, Mac ou Linux, ou dig -x 200.151.24.50 +short no Mac e Linux, que já inverte o IP e consulta a zona reversa. Se houver um PTR, o comando devolve o hostname; se não houver, a resposta vem vazia. Para checar o FCrDNS, consulte também o registro A do nome devolvido e veja se ele volta ao IP original.

Todo site precisa de DNS reverso?
Não necessariamente. Um site comum, que só serve páginas, funciona sem PTR. Ele se torna importante quando o servidor envia e-mail: aí o DNS reverso do IP de envio passa a ser decisivo para a entrega. Em hospedagem compartilhada, o provedor já cuida disso; em VPS ou servidor dedicado que envia e-mail, vale configurar um PTR próprio.

Conclusão

O DNS reverso é o caminho de volta do DNS: do IP para o nome, feito pelo registro PTR e guardado na zona .in-addr.arpa. Três coisas resumem o que importa: o PTR não fica no DNS do seu domínio — ele é controlado por quem dona o bloco de IP, então se configura pedindo à hospedagem ou ao provedor; o que os servidores checam é o FCrDNS, o círculo completo em que o PTR e o registro A concordam sobre o mesmo IP; e a razão de tudo isso é o e-mail — o DNS reverso é o quarto pilar da entregabilidade, ao lado de SPF, DKIM e DMARC. Um site comum vive sem ele; um servidor que manda e-mail, não.

O post DNS reverso e registro PTR: o que é e como configurar apareceu primeiro em Homehost.

Um registro CNAME é um apelido no DNS: ele aponta um nome de domínio para outro, em vez de apontar para um endereço IP. Quando você configura www.seusite.com.br para seguir seusite.com.br, é um CNAME que faz isso — o apelido www herda o destino do nome principal.

É um dos registros DNS mais usados e, ao mesmo tempo, um dos que mais gera erro de configuração — quase sempre pela mesma razão: o CNAME tem uma regra rígida que quase ninguém conhece, e ela é o motivo pelo qual “não dá para usar CNAME na raiz do domínio”. Este guia explica o que é o CNAME, como ele funciona, quando usar (e quando não), e como resolver o problema da raiz.

O que é um registro CNAME

O DNS funciona como uma agenda de contatos da internet: ele traduz nomes que humanos entendem em endereços que máquinas usam. O registro mais básico dessa agenda é o registro A, que liga um nome diretamente a um endereço IP — seusite.com.br → 200.151.24.50.

O CNAME (Canonical Name, ou nome canônico) faz algo diferente: em vez de apontar para um IP, ele aponta para outro nome. É um apelido. Quando alguém procura o apelido, o DNS responde “na verdade, o nome de verdade é este outro” e refaz a busca a partir dali.

Nesse exemplo, quem acessa www.seusite.com.br recebe do DNS a instrução de olhar para seusite.com.br, que tem um registro A apontando para o IP. O resultado final é o mesmo endereço — mas por um caminho de duas etapas. Se quiser entender a agenda inteira, o servidor DNS é o guia do sistema como um todo.

Para que serve o CNAME

A vantagem do CNAME aparece na manutenção. Imagine um servidor com vários nomes apontando para ele: www, loja, blog, app. Há duas formas de configurar isso.

Com registros A, cada nome guarda o IP diretamente. Se o servidor muda de IP, você precisa editar todos os registros, um a um — e esquecer de um significa um subdomínio quebrado.

Com CNAME, cada nome aponta para o domínio principal, e só o principal guarda o IP num registro A. Muda o IP? Você edita um único registro, e todos os apelidos acompanham automaticamente. É a diferença entre atualizar uma agenda inteira e atualizar um contato só.

Por isso o CNAME é o registro natural para:

• O www apontando para o domínio raiz (o uso mais comum de todos).
• Serviços de terceiros: apontar loja.seusite.com.br para o endereço de uma plataforma de e-commerce, ou status.seusite.com.br para uma ferramenta externa.
• Validação de domínio: Google, Microsoft e provedores de certificado costumam pedir um CNAME para provar que o domínio é seu.
• CDN e cloud: o endereço de uma CDN muda de IP o tempo todo; um CNAME apontando para o nome dela absorve essas mudanças sem você fazer nada.

A regra de ouro do CNAME

A regra que explica quase todos os erros de CNAME

Um nome que tem um registro CNAME não pode ter nenhum outro registro. Nada de A, MX, TXT ou outro CNAME no mesmo nome — só o CNAME, sozinho. A razão é lógica: o CNAME diz “para tudo deste nome, consulte aquele outro”. Se houvesse um MX ao lado, o DNS não saberia se o e-mail segue o apelido ou o registro local. Para evitar essa ambiguidade, a especificação simplesmente proíbe a convivência.

Essa única regra é a origem da maioria dos problemas com CNAME. E ela leva direto ao erro mais comum de todos.

Por que não se usa CNAME na raiz do domínio

A raiz do domínio (também chamada de apex, zone apex ou naked domain) é o nome sem nada na frente: seusite.com.br, e não www.seusite.com.br.

A raiz obrigatoriamente tem outros registros. Ela precisa de um registro MX para receber e-mail, e quase sempre de registros NS e outros. Pela regra de ouro, se a raiz tivesse um CNAME, ela não poderia ter mais nada — o que quebraria o e-mail e o próprio funcionamento da zona.

Por isso a especificação do DNS não permite CNAME na raiz. E é aqui que muita gente trava: quer que seusite.com.br (sem o www) aponte para uma CDN ou um serviço externo que só fornece um nome, não um IP fixo. Com CNAME proibido na raiz, parece um beco sem saída.

A saída tem dois caminhos:

1. Registro A com o IP do serviço — funciona, mas só se o serviço tiver um IP fixo. Muitas CDNs não têm.
2. ALIAS, ANAME ou CNAME flattening — registros especiais que imitam um CNAME na raiz, mas se comportam como um A. O provedor de DNS resolve o nome de destino nos bastidores e devolve o IP já pronto, contornando a proibição. Não fazem parte do padrão original do DNS; são uma extensão que cada provedor implementa com um nome próprio.

Se o seu provedor oferece ALIAS ou ANAME, é isso que você usa para apontar a raiz a um serviço externo. Se não oferece, a alternativa é manter a raiz num registro A e redirecionar tudo para o www (que pode ser CNAME à vontade).

Ao contrário do registro TXT, do qual vários podem coexistir no mesmo nome, o CNAME precisa ficar sozinho.

CNAME record: por que o nome parece “invertido”

Existe uma confusão sutil e muito difundida sobre qual lado é, de fato, o “CNAME” — e vale esclarecer, porque é comum até entre quem já mexe em DNS.

Veja de novo a linha:

No dia a dia, as pessoas chamam o lado esquerdo (www.seusite.com.br) de “o CNAME”. Mas, tecnicamente, isso está trocado. CNAME significa Canonical Name — nome canônico — e o nome canônico é o destino, à direita. O lado esquerdo é o apelido; o lado direito é o nome verdadeiro, o canônico, que dá nome ao registro.

Na prática, a troca não atrapalha a configuração — todo painel de DNS entende o que você quer. Mas saber disso ajuda a ler a documentação técnica sem se perder: quando um texto diz “o CNAME aponta para tal lugar”, ele está falando do valor à direita.

CNAME vs registro A: qual usar

A regra prática: a raiz e endereços de IP fixo pedem registro A; subdomínios que seguem outro nome pedem CNAME. O www é o caso clássico de CNAME; o seusite.com.br puro é o caso clássico de A.

O custo escondido: cadeias de CNAME

Um CNAME pode apontar para um nome que, por sua vez, é outro CNAME, que aponta para mais um — formando uma cadeia. O DNS segue cada elo até chegar num registro A e obter o IP.

Funciona, mas cobra um preço. Cada elo da cadeia é uma consulta DNS a mais antes de o navegador saber para onde ir — e essas consultas acontecem em série, uma esperando a outra. Uma cadeia longa adiciona latência perceptível ao primeiro acesso, antes mesmo de o site começar a carregar.

Por isso a recomendação é manter as cadeias curtas: um CNAME apontando direto para o nome que tem o registro A é o ideal. Se você encontrar um subdomínio lento e desconfiar do DNS, vale investigar quantos saltos ele faz — o problema pode estar numa cadeia que cresceu sem ninguém perceber. Ferramentas de diagnóstico como as descritas em problemas de DNS ajudam a rastrear isso.

Como criar um registro CNAME

O caminho geral é parecido em qualquer provedor:

1. Acesse a zona DNS do seu domínio, no painel de hospedagem ou no registrador.
2. Crie um novo registro do tipo CNAME.
3. No campo Nome (ou Host), coloque só o apelido — normalmente o subdomínio, como www ou loja. Não repita o domínio inteiro; o painel completa sozinho.
4. No campo Valor (ou Destino, Aponta para), coloque o nome canônico completo, terminando em ponto quando o painel exigir: seusite.com.br.
5. Defina o TTL (tempo de cache) e salve.

Depois de salvar, a mudança não é instantânea: ela depende da propagação de DNS, que pode levar de minutos a algumas horas conforme o TTL anterior. Para conferir se o CNAME já está valendo, um comando resolve:

Se o comando nslookup devolver o nome canônico, o registro está ativo e propagado ao menos naquele servidor DNS.

Problemas comuns com CNAME

Os principais registros DNS

O CNAME é um entre vários tipos de registro. Veja onde ele se encaixa:

Perguntas frequentes

O que é um registro CNAME?
É um tipo de registro DNS que aponta um nome de domínio para outro nome, em vez de apontar para um endereço IP. Funciona como um apelido: quando alguém consulta o nome com CNAME, o DNS responde qual é o nome canônico de verdade e refaz a busca a partir dele. O uso mais comum é fazer o www apontar para o domínio principal.

Qual a diferença entre CNAME e registro A?
O registro A aponta um nome diretamente para um endereço IP; o CNAME aponta um nome para outro nome. Na prática, o A é usado na raiz do domínio e em IPs fixos, enquanto o CNAME é ideal para subdomínios e para serviços externos cujo IP muda, porque ele acompanha o destino automaticamente sem você precisar editar o IP.

Por que não posso usar CNAME na raiz do domínio?
Porque um nome com CNAME não pode ter nenhum outro registro, e a raiz do domínio obrigatoriamente precisa de outros, como o MX para receber e-mail. Um CNAME na raiz quebraria isso. A solução é usar um registro A, ou os registros ALIAS, ANAME ou CNAME flattening, que imitam um CNAME na raiz mas se comportam como um A.

Um nome com CNAME pode ter outros registros?
Não. Essa é a regra fundamental do CNAME: o nome que tem um registro CNAME não pode ter A, MX, TXT nem qualquer outro registro junto. O CNAME precisa ficar sozinho, porque ele redireciona toda consulta daquele nome para o nome canônico, e a presença de outro registro criaria ambiguidade.

O que significa CNAME?
CNAME é a sigla de Canonical Name, ou nome canônico. O nome canônico é o destino do registro, o nome verdadeiro para o qual o apelido aponta. Por isso, tecnicamente, o “CNAME” é o valor à direita da configuração, e não o apelido à esquerda, embora no dia a dia muita gente chame o apelido de CNAME.

Como testar se um CNAME está funcionando?
Use o comando nslookup -type=cname www.seusite.com.br no Windows, Mac ou Linux, ou dig www.seusite.com.br CNAME +short no Mac e Linux. Se o comando devolver o nome canônico de destino, o registro está ativo e propagado naquele servidor DNS. Se não devolver nada, pode ser que a propagação ainda não tenha concluído.

Quanto tempo o CNAME demora para funcionar?
Depende da propagação de DNS, que varia conforme o TTL configurado no registro anterior. Pode ser de alguns minutos a algumas horas. Enquanto a propagação não termina, alguns servidores DNS já mostram o novo destino e outros ainda mostram o antigo, o que é normal durante a transição.

Posso apontar um CNAME para outro CNAME?
Pode, formando uma cadeia de CNAMEs, e o DNS segue cada elo até chegar a um registro A. Porém, cada elo é uma consulta DNS a mais, feita em série, o que adiciona latência ao primeiro acesso. O recomendado é manter a cadeia curta, com o CNAME apontando direto para o nome que tem o registro A.

Conclusão

O registro CNAME é o apelido do DNS: ele aponta um nome para outro, e não para um IP, o que o torna a escolha certa para subdomínios como o www e para serviços externos que mudam de endereço. Guarde três coisas: um nome com CNAME não pode ter mais nenhum registro — essa única regra explica quase todos os erros; por isso não se usa CNAME na raiz do domínio, e a saída é o registro A ou o ALIAS/ANAME do seu provedor; e cadeias longas custam latência, então aponte direto para o nome que tem o registro A. Com isso, o CNAME deixa de ser fonte de erro e vira a ferramenta de manutenção que ele foi feito para ser.

O post Registro CNAME: o que é, como funciona e quando usar apareceu primeiro em Homehost.