Um e-mail institucional como secretaria@nomedaescola.com.br ou contato@nomedaescola.com.br transmite seriedade, organiza a comunicação interna e fortalece a identidade da sua instituição.

Neste guia completo, você vai aprender do zero como criar e-mails institucionais para a sua escola ou instituição — mesmo sem nenhum conhecimento técnico.

O que é um e-mail institucional?

Um e-mail institucional é um endereço de e-mail que usa o domínio próprio da sua organização, em vez de um serviço genérico como Gmail ou Hotmail.

Exemplos:

• direcao@nomedaescola.com.br
• secretaria@nomedaescola.edu.br
• financeiro@nomedoinstituto.com.br

A parte que vem depois do @ é o domínio — e é ele que identifica a sua instituição. Para ter esse tipo de e-mail, você precisa primeiro ter um domínio próprio registrado.

Por que ter um e-mail institucional?

Muitas escolas e instituições ainda usam e-mails gratuitos por acharem que é suficiente. Mas a diferença é grande:

Profissionalismo e credibilidade Pais, alunos, fornecedores e parceiros percebem instantaneamente quando uma instituição tem identidade própria. Um e-mail com domínio institucional transmite organização e seriedade — especialmente importante em comunicados oficiais, matrículas e cobranças.

Organização interna Com e-mails institucionais, cada setor tem o seu endereço: secretaria@, financeiro@, pedagogico@, direcao@. Fica muito mais fácil organizar quem responde o quê, sem misturar comunicações pessoais com institucionais.

Segurança e controle Se um funcionário sair da instituição, você simplesmente desativa o e-mail dele no painel. Com Gmail pessoal, você perde o acesso a toda aquela comunicação para sempre.

Proteção contra spam e vírus Serviços de e-mail profissional incluem filtros de AntiSpam e AntiVírus que protegem sua instituição de golpes — algo crítico quando você lida com dados de alunos e responsáveis.

O que você vai precisar

Para ter um e-mail institucional, você precisa de dois elementos:

1. Um domínio próprio O domínio é o endereço da sua instituição na internet. Exemplos: nomedaescola.com.br, nomedoinstituto.com.br. Sem ele, não é possível criar e-mails com o nome da sua instituição.

2. Um serviço de hospedagem de e-mail É o serviço que vai armazenar e gerenciar as suas caixas de e-mail. Funciona como uma “caixa de correio digital” — você contrata, cria os endereços que quiser e acessa de qualquer dispositivo.

A boa notícia é que muitos planos de hospedagem já incluem os dois — domínio e e-mail — em um único pacote.

Passo 1 — Escolha e registre o seu domínio

Qual extensão escolher?

Para instituições brasileiras, as principais categorias de domínio são:

.com.br

Qualquer pessoa física ou jurídica

A opção mais prática para escolas particulares e cursos livres. Registro rápido e sem burocracia.

Fácil — registro simples

.edu.br

Instituições reconhecidas pelo MEC

Mais prestígio acadêmico, mas exige comprovação junto ao MEC. Processo pode ser demorado.

Burocrático — exige comprovação

.org.br

ONGs e associações sem fins lucrativos

Indicado para institutos e fundações. Exige CNPJ ativo para o registro.

Médio — exige CNPJ

.com

Internacional, qualquer um

Alternativa global sem restrições. Boa opção caso o .com.br desejado já esteja ocupado.

Fácil — registro simples

Para a maioria das escolas particulares, cursos livres e instituições, o .com.br é a escolha mais prática. O .edu.br é mais valorizado academicamente, mas exige que a instituição seja reconhecida pelo MEC — o processo pode ser demorado.

Como escolher um bom nome de domínio?

• Use o nome da sua instituição de forma simples e direta
• Evite números, hifens e caracteres especiais
• Prefira nomes curtos e fáceis de digitar
• Verifique se o nome está disponível antes de decidir

Exemplos de bons domínios:

• nomedaescola.com.br
• nomedoinstituto.com.br
• nomedaescola.edu.br

Como verificar se o domínio está disponível?

Acesse o WHOIS da Homehost ou o site do Registro.br, digite o nome desejado e veja se está disponível. Se já estiver registrado por outra pessoa, você precisará pensar em uma variação.

Passo 2 — Contrate um plano de e-mail profissional

Com o domínio escolhido, o próximo passo é contratar um plano que gerencie suas caixas de e-mail.

Opções disponíveis

Hospedagem de e-mail profissional (recomendado para escolas e instituições) É o serviço mais indicado para quem precisa apenas de e-mails, sem necessidade de hospedar um site junto. Você tem total controle sobre as contas, com segurança profissional e suporte especializado.

A Homehost oferece planos de e-mail profissional com domínio grátis no primeiro ano:

Todos os planos incluem segurança TLS+SSL, AntiSpam, AntiVírus, suporte via WhatsApp e compatibilidade com celular (iOS e Android), Outlook e Webmail.

Dica

Para uma escola com até 10 e-mails (direção, secretaria, financeiro, pedagógico, contato), o plano Email Corp já é mais do que suficiente e ainda sobra bastante espaço para crescer.

Google Workspace (Gmail com domínio próprio) Permite usar a interface do Gmail com o seu domínio (secretaria@nomedaescola.com.br). Custa aproximadamente R$ 34 por usuário por mês — o que pode ficar caro para instituições com muitos funcionários.

Microsoft 365 (Outlook com domínio próprio) Semelhante ao Google Workspace, mas com Outlook. Custa em torno de R$ 25 por usuário por mês. Boa opção se a equipe já usa ferramentas Microsoft.

Para a maioria das escolas e instituições de pequeno e médio porte, a hospedagem de e-mail profissional é a opção mais econômica e completa, pois você paga uma mensalidade fixa independente do número de contas.

Passo 3 — Crie as contas de e-mail no painel

Após contratar o plano, você receberá acesso ao painel de controle. É lá que você cria e gerencia todos os e-mails da sua instituição.

Como criar uma conta de e-mail no painel de controle Homehost

1. Acesse o painel pelo link enviado pela sua hospedagem
2. Localize a seção E-mail e clique em Contas de E-mail
3. Clique em Criar
4. Preencha o nome do e-mail (ex: secretaria), escolha o domínio e defina uma senha forte
5. Clique em Criar — pronto, o e-mail já está ativo

Repita o processo para cada conta que precisar criar.

Quais e-mails criar?

Cada instituição tem necessidades diferentes, mas aqui estão os mais comuns para escolas:

Passo 4 — Configure o e-mail no celular e no computador

Com as contas criadas, você pode acessá-las de três formas:

Webmail (pelo navegador)

É a forma mais simples: basta acessar o endereço de webmail fornecido pela sua hospedagem. Por exemplo:

www.nomedaescola.com.br/webmail

Aplicativo de e-mail no celular (iOS e Android)

No celular, você pode configurar o e-mail no aplicativo nativo (Mail no iPhone, Gmail ou aplicativo de E-mail no Android) ou em aplicativos como Outlook. Você vai precisar das seguintes informações, fornecidas pela sua hospedagem:

• Servidor de entrada (IMAP): geralmente mail.nomedaescola.com.br
• Porta IMAP: 993 (com SSL)
• Servidor de saída (SMTP): geralmente mail.nomedaescola.com.br
• Porta SMTP: 465 ou 587 (com SSL)
• Usuário: o endereço de e-mail completo (ex: secretaria@nomedaescola.com.br)
• Senha: a senha definida na criação da conta

Outlook no computador

O Outlook é o programa de e-mail mais usado em ambientes profissionais. A configuração usa as mesmas informações acima (IMAP/SMTP). A maioria das hospedagens tem um tutorial específico para isso — e o suporte da Homehost pode auxiliar via WhatsApp caso tenha dificuldade.

Boas práticas para e-mails institucionais

Ter o e-mail configurado é só o começo. Veja algumas práticas importantes para usar bem:

Crie uma assinatura padronizada Defina um modelo de assinatura para todos os e-mails da instituição, com nome, cargo, telefone e logo. Isso reforça a identidade institucional em toda comunicação.

Nunca use o e-mail institucional para assuntos pessoais O e-mail da secretaria deve ser usado apenas para assuntos da secretaria. Misturar uso pessoal com institucional cria confusão e pode expor informações sensíveis.

Defina responsáveis por cada conta Cada e-mail deve ter um responsável claro. Evite contas compartilhadas sem controle — ninguém sabe quem respondeu o quê, e e-mails importantes ficam sem resposta.

Ative o filtro de AntiSpam Serviços de e-mail profissional já vêm com AntiSpam ativo. Certifique-se de que está habilitado, especialmente no período de matrículas, quando o volume de e-mails aumenta muito.

Faça backup regularmente Mesmo com hospedagens que fazem backup automático, é uma boa prática exportar as caixas de e-mail importantes periodicamente — especialmente e-mails com contratos, comprovantes e comunicações legais.

Perguntas frequentes

Preciso ter um site para ter e-mail institucional? Não. Você pode contratar apenas o serviço de e-mail profissional sem precisar de um site. O domínio pode ser registrado e usado só para e-mail, sem nenhuma página web vinculada a ele.

Posso usar o e-mail institucional no Gmail? Sim. É possível configurar o Gmail para enviar e receber e-mails do seu domínio institucional. No entanto, para uma instituição, o ideal é usar o próprio webmail ou um cliente como Outlook, para manter a separação entre e-mails pessoais e institucionais.

O que acontece com os e-mails se eu cancelar o plano? Se você cancelar o plano de hospedagem, perde o acesso às caixas de e-mail. Por isso, antes de cancelar qualquer serviço, sempre faça o backup de todos os e-mails importantes.

Quantas contas posso criar? Depende do plano contratado. No plano Email Corp da Homehost, por exemplo, você pode criar até 50 contas — mais do que suficiente para a maioria das escolas e instituições.

Posso criar listas de distribuição (e-mail para grupos)? Sim. A maioria das hospedagens permite criar listas de e-mail (ou forwarders), onde um único endereço encaminha as mensagens para vários destinatários ao mesmo tempo. Útil para enviar comunicados para toda a equipe pedagógica de uma vez.

Meu domínio .edu.br está demorando para ser aprovado. Posso começar com .com.br? Sim, e é exatamente isso que recomendamos. Registre o .com.br imediatamente, já configure os e-mails e comece a usar. Quando o .edu.br for aprovado, você migra as contas com calma — sem prejudicar a operação no dia a dia.

Resumo: o que fazer agora

1

Escolha o nome do domínio Defina o endereço da sua instituição na internet

2

Verifique a disponibilidade Consulte no WHOIS se o domínio está livre

3

Contrate um plano de e-mail Escolha um plano com domínio incluído

4

Crie as contas no cPanel Secretaria, direção, financeiro e demais setores

5

Configure nos dispositivos Celular, computador ou acesso pelo Webmail

6

Defina responsáveis e assinaturas Padronize quem usa cada conta e como assina

Pronto para dar esse passo? A Homehost oferece planos de e-mail profissional a partir de R$ 7,90/mês, com domínio grátis no primeiro ano e suporte via WhatsApp para ajudar em cada etapa da configuração.

Ficou com alguma dúvida? Entre em contato conosco

O post Como criar um e-mail institucional para escola ou instituição (Guia para iniciantes) apareceu primeiro em Homehost.

Precisa transferir seu domínio .br para outro registrador? Seja por insatisfação com o suporte atual, para centralizar todos os seus serviços em um só lugar ou por questão de preço, o processo é mais simples do que parece — mas tem detalhes importantes que podem travar tudo se você não souber.

Neste guia você vai entender a diferença entre os tipos de transferência, o passo a passo completo, os documentos exigidos e quanto tempo leva cada etapa.

O que é transferência de domínio .br?

Antes de começar, é importante entender que no Brasil existem dois tipos de transferência diferentes, e as pessoas frequentemente confundem os dois:

1. Transferência de Provedor (mudança de registrador) É quando você mantém o mesmo titular (CPF/CNPJ) mas muda a empresa responsável pela administração do domínio. Por exemplo: seu domínio está hospedado em outra empresa e você quer passar para a Homehost ou qualquer outro registrador credenciado. O domínio continua sendo seu — só a empresa que o administra muda.

2. Transferência de Titularidade (mudança de dono) É quando o CPF ou CNPJ que detém a propriedade do domínio muda. Ou seja, o domínio passa a pertencer a outra pessoa física ou jurídica. Este é um processo separado, com documentação específica e analisado diretamente pelo Registro.br.

Atenção

Não é possível transferir domínios de categorias Profissionais Liberais/Pessoas Físicas para Pessoas Jurídicas e vice-versa. A única exceção são os domínios Genéricos (como .com.br), que aceitam ambos os tipos de titulares.

Parte 1 — Como transferir o provedor (mudar de registrador)

Este é o caso mais comum: você quer migrar seu domínio de uma empresa para outra, sem trocar de dono.

Como descobrir qual é o provedor atual do seu domínio

Não sabe em qual registrador seu domínio está? Você pode descobrir isso em segundos usando o WHOIS — uma consulta pública que exibe as informações de registro de qualquer domínio.

Para domínios .br, o jeito mais direto é usar a ferramenta oficial do próprio Registro.br:

1. Acesse https://registro.br/whois
2. Digite o seu domínio (ex: seusite.com.br) e clique em Buscar
3. No resultado, procure o campo provider (ou “provedor”) — ele indica o nome do registrador atual

O resultado vai mostrar algo assim:

domain:      seusite.com.br
owner:       Seu Nome ou Empresa
provider:    HOMEHOST (36)

Se o campo provider aparecer como “Not assigned” ou vazio, significa que o domínio não tem provedor vinculado e está sendo administrado diretamente pelo Registro.br — o que simplifica a transferência, pois você só precisa selecionar o novo provedor sem precisar remover o atual.

Dica

Você também pode usar o WHOIS ou RDAP diretamente no terminal com o comando whois seusite.com.br, caso tenha o pacote instalado no seu sistema.

Pré-requisitos

Antes de começar, verifique:

• Você tem acesso ao ID e senha da sua conta no Registro.br
• O domínio não está em período de carência de 60 dias após um pagamento feito pelo provedor atual (se estiver, só é possível remover o provedor atual e aguardar)
• O e-mail cadastrado na conta está acessível (você vai precisar confirmar alterações)
• O domínio não está com status de bloqueio ou pendência

Passo a passo

Passo 1 — Acesse o Registro.br

Acesse Registro.br e faça login com seu ID e senha. Caso não lembre o ID, é possível acessar usando o CPF ou CNPJ do titular e clicar em “Não lembro ou não tenho a senha”.

Passo 2 — Localize o domínio que deseja transferir

Após o login, clique em Domínios para ver a lista de todos os domínios vinculados à sua conta. Clique no domínio que deseja transferir.

Passo 3 — Altere o Provedor de Serviços

Na página do domínio, localize a seção Provedor de Serviços e clique em Selecionar Provedor (ou “Selecionar outro provedor”, dependendo da interface).

Uma lista de provedores cadastrados será exibida. Selecione o novo registrador para o qual deseja transferir o domínio e clique em Continuar.

Se você não encontrar o novo provedor na lista: significa que ele ainda não está credenciado no Registro.br ou usa outro nome de exibição. Consulte o suporte do novo registrador para confirmar o nome exato que aparece no sistema.

Passo 4 — Confirme os termos e finalize

Leia e confirme os termos apresentados. Após concordar, a alteração de provedor é registrada no sistema do Registro.br.

Passo 5 — Contate o novo registrador

A alteração no Registro.br é apenas metade do processo. Você ainda precisa acessar o painel do novo registrador e concluir a transferência por lá — geralmente preenchendo uma ficha de transferência ou importando o domínio para sua conta. Cada empresa tem um processo ligeiramente diferente; consulte o suporte deles.

Caso especial: trocar o provedor de TODOS os domínios de um titular

Se você tiver vários domínios sob o mesmo CPF/CNPJ e quiser transferir todos de uma vez:

1. Após o login, clique em Titularidade
2. Selecione o titular cujos domínios você deseja migrar
3. Na seção Provedor de Serviços, clique em Selecionar Provedor
4. Escolha o novo provedor e confirme

Todos os domínios vinculados àquela titularidade serão transferidos de uma só vez.

Parte 2 — Como transferir a titularidade (trocar o dono do domínio)

Se o objetivo é passar o domínio para outra pessoa ou empresa, o processo é diferente e envolve documentação formal analisada pelo Registro.br.

Passo a passo

Passo 1 — Gere o formulário de solicitação

Acesse https://registro.br/ajuda/procedimentos-administrativos/transferencia-de-titularidade e preencha o formulário com:

• Nome do domínio
• Nome do titular atual
• CPF/CNPJ do novo titular
• E-mail de contato

Clique em Gerar Documento para criar a solicitação.

Passo 2 — Assine eletronicamente pelo Gov.br

O documento gerado precisa ser assinado eletronicamente pela conta Gov.br do titular atual. Não é aceita assinatura manual digitalizada.

Passo 3 — Reúna a documentação

Além da solicitação assinada, você vai precisar enviar:

Para pessoa física (titular identificado por CPF):

• Solicitação assinada eletronicamente pelo Gov.br
• Digitalização de documento oficial com CPF (RG, CNH) ou exportação de documento digital (ex: CNH Digital)
• Se houver procuração: ela também deve ser assinada eletronicamente pelo Gov.br

Para pessoa jurídica (titular identificado por CNPJ):

• Solicitação assinada eletronicamente
• CNPJ ativo e regular
• Documentos constitutivos da empresa atualizados
• Procuração com poderes específicos (quando aplicável)

Atenção ao tamanho dos arquivos: o Registro.br tem limite de tamanho por arquivo enviado. Verifique as instruções na página de procedimentos administrativos antes de enviar.

Passo 4 — Envie a documentação

Envie toda a documentação conforme as instruções da página de procedimentos administrativos do Registro.br.

Quanto tempo leva a transferência?

Os prazos variam conforme o tipo de operação:

Observação importante

Se você tentar trocar de provedor duas vezes seguidas em sequência rápida, o Registro.br pode aplicar uma trava de 72 horas antes de permitir a próxima alteração. Para evitar isso, caso precise passar por “Nenhum” antes de selecionar o novo provedor, aguarde as 72h antes de fazer a segunda troca.

Perguntas frequentes

O domínio fica fora do ar durante a transferência de provedor? Não necessariamente. A transferência de provedor em si não altera as configurações de DNS. O domínio só ficará fora do ar se você alterar os servidores DNS durante o processo — o que não é obrigatório na transferência.

A transferência de provedor custa alguma coisa? Transferir o provedor no sistema do Registro.br é gratuito. No entanto, o novo registrador pode cobrar uma taxa de transferência, que normalmente já inclui a renovação do domínio por mais um ano.

Preciso cancelar o domínio no registrador atual antes de transferir? Não. O processo é feito pelo Registro.br e o domínio permanece ativo durante toda a transferência. Nunca cancele o domínio antes de concluir a transferência.

Posso transferir o domínio se ele estiver próximo de vencer? Sim, mas atenção: verifique com o novo registrador se há restrições de prazo. Alguns exigem que o domínio tenha pelo menos alguns dias de validade para aceitar a transferência. O ideal é iniciar o processo com pelo menos 30 dias de antecedência do vencimento.

O que acontece com meu e-mail e site durante a transferência? Se você não alterar os servidores DNS, tanto o site quanto os e-mails continuam funcionando normalmente. A transferência de provedor apenas muda quem administra o registro — não afeta onde o domínio aponta.

Posso transferir um domínio que acabei de registrar? Para domínios internacionais, é necessário aguardar 60 dias do registro. Para domínios .br, não há este bloqueio por padrão, mas verifique a carência de 60 dias relacionada a pagamentos feitos pelo provedor atual.

Resumo rápido: qual é o seu caso?

Ficou com dúvida em alguma etapa? Entre em contato que responderemos.

O post Transferência de domínio no Brasil, usando o Registro.br apareceu primeiro em Homehost.

Se você está pensando em criar um site, loja virtual ou blog no Brasil, uma das primeiras dúvidas que aparece é: quanto custa registrar um domínio .br e qual hospedagem escolher?

Neste artigo você vai encontrar os preços atualizados para registro de domínios .br, as principais extensões disponíveis, o que avaliar na hora de escolher uma hospedagem e por que faz sentido manter tudo no mesmo lugar.

Dica importante: domínio e hospedagem são coisas diferentes

Antes de tudo, vale entender uma distinção que confunde muita gente:

• Domínio = o endereço do seu site (ex: minhaempresa.com.br). Um domínio é o nome que as pessoas digitam no navegador para te encontrar.
• Hospedagem = o serviço onde os arquivos do seu site ficam armazenados e disponíveis na internet.

São dois serviços diferentes, com cobranças separadas, mas que quase sempre são usados juntos. Pense assim: o domínio é a placa com o endereço, e a hospedagem é o imóvel em si. Você precisa dos dois para ter um site no ar.

O que é um domínio .br e quem regula o registro

O domínio é o endereço do seu site na internet — aquele nome que as pessoas digitam no navegador para te encontrar. O .br no final indica que o site é brasileiro, e todos os domínios com essa terminação são regulados pelo Registro.br, que é o departamento do NIC.br responsável pelo registro e manutenção de domínios no país.

Isso significa que, independentemente de onde você compre seu domínio .br, o registro oficial sempre passa pelo Registro.br. As empresas de hospedagem funcionam como intermediárias credenciadas — elas facilitam o processo e centralizam o gerenciamento para você.

Quais são as extensões .br disponíveis?

Existem dezenas de extensões .br, mas as mais usadas são:

Para a grande maioria dos negócios e projetos pessoais, o .com.br é a escolha certa — é o mais reconhecido pelos brasileiros e transmite credibilidade.

Quanto custa registrar um domínio .br?

O preço oficial do Registro.br é de R$ 40,00 por ano para a maioria das extensões .br, incluindo o .com.br. Esse valor é fixo e não muda com o tempo — você paga R$ 40 no primeiro ano, R$ 40 no décimo.

Ao registrar através de uma empresa de hospedagem credenciada, o preço pode variar um pouco, mas em geral fica na faixa de R$ 40 a R$ 80 por ano, dependendo do provedor e de eventuais promoções de primeiro ano.

Dica: a Homehost oferece uma promoção de registro de domínio .br por R$ 25,90 no primeiro ano.

Atenção ao preço de renovação: algumas registradoras oferecem o primeiro ano muito barato (R$ 5 a R$ 15) mas cobram R$ 70 a R$ 90 na renovação. Sempre confira o valor de renovação antes de fechar o registro — é esse número que importa no longo prazo.

Descontos por período mais longo

O Registro.br oferece desconto progressivo para quem registra o domínio por mais de um ano de uma vez. Se você já sabe que vai manter o site por muitos anos, vale considerar registrar por 2 ou 3 anos para economizar.

O que está incluído no preço

O valor de R$ 40/ano cobre apenas o registro e a manutenção do domínio. O Registro.br não oferece privacidade WHOIS — os dados do titular ficam públicos no banco de dados de domínios, chamado WHOIS.

Preciso de CNPJ para registrar um domínio .com.br?

Não. O domínio .com.br pode ser registrado tanto por pessoa física (CPF) quanto por pessoa jurídica (CNPJ). Você não precisa ter uma empresa aberta para ter um site .com.br.

Algumas extensões específicas, como .gov.br e .edu.br, têm restrições e exigem tipo específico de entidade.

Opções de hospedagem para sites .br

Depois de registrar o domínio, você precisa de uma hospedagem — o serviço que mantém os arquivos do seu site disponíveis na internet. As principais opções são:

Hospedagem compartilhada

Ideal para quem está começando. O servidor é compartilhado com outros sites, o que mantém o custo baixo. Funciona bem para blogs, sites institucionais, portfólios e lojas virtuais de pequeno porte.

Indicada para: blogs, sites de empresas locais, portfólios, landing pages.

Conheça aqui nossos planos de hospedagem compartilhada

Hospedagem WordPress

Otimizada especificamente para sites feitos em WordPress. Geralmente inclui instalação automática, atualizações gerenciadas e melhor desempenho para a plataforma.

Indicada para: blogs, sites de conteúdo e pequenas lojas WooCommerce.

Conheça aqui nossos planos de hospedagem WordPress

VPS (Servidor Virtual Privado)

Você tem recursos dedicados dentro de um servidor maior. Mais desempenho e flexibilidade, com custo intermediário.

Indicada para: lojas virtuais com tráfego médio, sistemas web, aplicações que precisam de mais controle.

Conheça aqui nossos servidores VPS

Servidor dedicado

Um servidor físico inteiro para o seu projeto. Máximo de desempenho e controle, mas também o maior custo.

Indicada para: grandes e-commerces, plataformas com alto volume de acessos, aplicações críticas.

Vale a pena registrar domínio e hospedagem no mesmo lugar?

Na maioria dos casos, sim. Manter domínio e hospedagem na mesma empresa traz vantagens práticas:

• DNS configurado automaticamente — o domínio já aponta para a hospedagem sem você precisar mexer em configurações técnicas
• Suporte centralizado — um único canal para resolver qualquer problema
• Renovação simplificada — tudo vence junto, sem risco de esquecer de renovar o domínio separadamente
• Painel único — você gerencia tudo em um só lugar

A única razão para separar costuma ser quando você já tem o domínio registrado em outro lugar e não quer pagar pela transferência, ou quando precisa de uma hospedagem muito específica que não oferece registro de domínio.

Quanto tempo leva para ativar um domínio .br?

Em geral, um domínio .br recém-registrado fica ativo em até 24 horas, mas na prática costuma propagar e já estar acessível em poucos minutos quando registrado por uma empresa credenciada com DNS já configurado.

Posso transferir meu domínio .br para outra empresa?

Sim. A transferência de domínio .br é um processo regulado pelo Registro.br e pode ser feita a qualquer momento, desde que o domínio não esteja em período de carência logo após o registro (geralmente os primeiros 60 dias). O processo é gratuito e leva alguns dias.

O que acontece se eu não renovar meu domínio .br?

Se você não renovar antes do vencimento, o domínio entra em período de carência — geralmente 30 dias — durante o qual ainda é possível renovar normalmente. Após esse período, o domínio fica disponível para qualquer pessoa registrar.

Após expirar o domínio fica com o status congelado por até 3 meses, mas ainda podendo ser renovado.

Depois deste prazo, o domínio entra em processo de liberação no Registro.br, para poder ser registrado novamente. Neste caso, não pode mais ser renovado e não há um prazo fixo para liberação de registro.

Por isso, recomendamos que ative a renovação automática sempre que possível. Perder um domínio que já tem tráfego e histórico pode ser um prejuízo significativo para o seu negócio.

Conclusão

Registrar um domínio .br custa a partir de R$ 40/ano diretamente pelo Registro.br, com variações nas registradoras credenciadas. O .com.br é a extensão mais indicada para a maioria dos projetos brasileiros, e pode ser registrado tanto por CPF quanto por CNPJ.

Na hora de escolher a hospedagem, avalie o tipo de projeto, o volume esperado de acessos e o nível de suporte que você vai precisar. Manter domínio e hospedagem no mesmo lugar simplifica bastante a gestão — especialmente para quem está começando.

Pronto para registrar o seu domínio .br? Confira os planos disponíveis na Homehost e comece hoje mesmo.

O post Registro de domínio .br: preços, tarifas e como escolher a melhor hospedagem apareceu primeiro em Homehost.

Saber como escrever um artigo é uma habilidade que vai muito além da escrita em si. Qualquer pessoa consegue colocar palavras no papel — mas transformar um texto em um conteúdo que seja lido até o final, bem ranqueado no Google e capaz de gerar resultado para o seu site exige um processo estruturado.

Neste guia, você vai aprender como escrever um artigo do rascunho à publicação no WordPress: como organizar as ideias, revisar o texto, configurar o SEO on-page e verificar os detalhes técnicos antes de clicar em “Publicar”. Se você já tem um texto pronto, pode ir diretamente para a parte de revisão — o checklist ao final cobre tudo.

Por que a maioria dos artigos não performa bem

Antes de entrar no passo a passo, vale entender o que geralmente dá errado. Os problemas mais comuns em artigos que não ranqueiam nem engajam são:

• Falta de estrutura: o texto existe, mas o leitor não sabe o que esperar em cada parte nem como as ideias se conectam
• Ausência de revisão: erros gramaticais, frases longas demais e parágrafos confusos que fazem o leitor abandonar a página antes de terminar
• SEO on-page mal configurado: título sem palavra-chave, meta description em branco, imagens sem alt text — detalhes que o Google considera na hora de ranquear
• Problemas técnicos de publicação: formatação quebrada, hierarquia de títulos errada, imagens pesadas que prejudicam o tempo de carregamento

O processo abaixo resolve todos esses pontos.

Parte 1: Como estruturar um artigo antes de escrever

Saber como escrever um artigo começa antes de digitar a primeira palavra. A estrutura é o esqueleto do conteúdo — sem ela, mesmo boas ideias ficam desorganizadas.

Defina a palavra-chave e a intenção de busca

Toda vez que alguém pesquisa algo no Google, há uma intenção por trás: aprender como fazer algo, comparar opções, ou encontrar um produto. Antes de escrever, defina:

• Qual palavra-chave principal o artigo vai abordar? Ela deve aparecer no título, no primeiro parágrafo e algumas vezes ao longo do texto — sem exageros.
• Qual é a intenção de quem pesquisa esse termo? Um artigo sobre “como escrever um artigo” tem intenção informacional — quem pesquisa quer aprender um processo, não comprar um produto. O formato ideal é um guia prático, não uma lista de dicas soltas.

Crie um esboço antes de escrever

Escrever sem um esboço é como construir sem planta. Antes de desenvolver o texto, defina:

1. Título: deve incluir a palavra-chave e deixar claro o que o leitor vai aprender
2. Introdução: apresenta o problema e o que o artigo vai resolver
3. Seções principais (H2): os grandes blocos de conteúdo — idealmente de três a seis seções
4. Subseções (H3): divisões dentro de cada seção, quando o tema exige mais detalhamento
5. Conclusão: resumo e chamada para ação

Com o esboço pronto, a escrita fica muito mais rápida e o texto, mais coeso.

Introdução: prenda o leitor nos primeiros parágrafos

A introdução é o trecho mais lido de qualquer artigo — e o que mais influencia se o leitor vai continuar ou abandonar a página. Uma boa introdução:

• Apresenta o problema ou a pergunta que o artigo vai responder
• Inclui a palavra-chave principal de forma natural, de preferência na primeira ou segunda frase
• Antecipa o que o leitor vai aprender — o que está por vir e por que vale a pena continuar lendo

Evite introduções genéricas que começam com “Nos dias de hoje…” ou “Você já parou para pensar…”. Vá direto ao ponto.

Parte 2: Como escrever um artigo com clareza e escaneabilidade

Com a estrutura definida, é hora de desenvolver o conteúdo. Estes são os princípios que fazem a diferença entre um texto que é lido e um que é abandonado na metade.

Parágrafos curtos e objetivos

Cada parágrafo deve ter uma ideia central. No ambiente digital, parágrafos com mais de cinco ou seis linhas tendem a ser pulados. Se um parágrafo está ficando longo, provavelmente pode ser dividido em dois — ou parte dele pode virar uma lista.

Frases diretas

Frases com mais de 25 a 30 palavras geralmente podem ser simplificadas. Quanto mais subordinadas e encaixes uma frase tiver, mais difícil ela é de processar. A regra prática: se você precisa reler uma frase para entendê-la, ela precisa ser reescrita.

Use subtítulos para organizar

Subtítulos (H2 e H3) funcionam como um mapa para o leitor. Eles permitem escanear o artigo antes de ler e encontrar rapidamente a seção de interesse. Um artigo de 1.500 palavras sem subtítulos é muito mais difícil de consumir do que um artigo bem dividido.

Listas e bullets com moderação

Listas funcionam muito bem para enumerações de três ou mais itens e para checklists. Mas transformar todo o artigo em bullets prejudica a fluidez e a profundidade do conteúdo. Use listas onde elas realmente organizam a informação — não como substituto de parágrafos bem escritos.

Tom consistente

Defina o tom antes de começar — formal, técnico, conversacional — e mantenha-o do início ao fim. Misturar registros no mesmo artigo gera estranheza e reduz a credibilidade.

Parte 3: Revisão — o passo que a maioria pula

Publicar sem revisar é o erro mais comum. Saber como escrever um artigo de qualidade inclui necessariamente um processo de revisão estruturado.

Checklist de revisão editorial

Estrutura e fluidez

• O artigo tem introdução, desenvolvimento e conclusão claramente definidos?
• Cada parágrafo tem uma ideia central?
• A transição entre seções é natural?
• O artigo responde à pergunta que o título promete?

Clareza

• Há frases excessivamente longas que podem ser simplificadas?
• Há jargões ou termos técnicos sem explicação para o público não especialista?
• Há redundâncias — ideias repetidas sem acrescentar informação nova?

Gramática e ortografia

• O texto foi verificado em uma ferramenta como LanguageTool (gratuito, em português)?
• A acentuação e o uso de crase estão corretos?
• A concordância verbal e nominal está correta nas frases longas?

Escaneabilidade

• O artigo usa subtítulos H2 e H3 para organizar as seções?
• Há negrito destacando as informações mais importantes? (Use com moderação — negrito em tudo é negrito em nada.)
• O tom está consistente do início ao fim?

Ferramentas gratuitas de revisão em português

LanguageTool (languagetool.org/pt-BR): o melhor verificador gramatical gratuito para português. Detecta erros de concordância, crase, pontuação e estilo. Tem extensão para Chrome e integração com Google Docs.

Quillbox (quillbot.com): ferramenta de IA que vai além da correção gramatical — ela sugere reformulações de frases inteiras, ajudando a melhorar a fluidez e o estilo do texto. Tem um parafrasador que reescreve trechos mantendo o sentido original, útil para simplificar frases longas ou evitar repetições. Funciona em português e está disponível como extensão para Chrome e com integração ao Google Docs e Microsoft Word.

Google Docs: o corretor nativo do Docs em português identifica os erros mais comuns. Escrever o artigo no Docs antes de colar no WordPress é uma boa prática — e evita trazer formatação residual indesejada.

Parte 4: SEO on-page no WordPress

Com o texto revisado, é hora de configurar o artigo no WordPress para que ele seja encontrado pelo Google. Se você usa Yoast SEO ou Rank Math, a maioria desses campos aparece no painel de edição.

Título e URL

• Título (H1): inclui a palavra-chave principal? Deve ter entre 50 e 60 caracteres para não ser cortado nos resultados do Google.
• URL (slug): está limpa e inclui a palavra-chave? Remova artigos e preposições desnecessários. Prefira como-escrever-um-artigo a como-e-possivel-escrever-um-artigo-bom.
• A URL não tem caracteres especiais, acentos ou espaços?

Meta description

• Está preenchida? É o texto que aparece nos resultados do Google abaixo do título — influencia diretamente a taxa de cliques.
• Tem entre 140 e 160 caracteres?
• Inclui a palavra-chave principal e um benefício claro para quem vai clicar?

Imagens

• A imagem destacada está configurada e tem alt text preenchido?
• Todas as imagens do artigo têm alt text com descrição relevante?
• As imagens estão comprimidas? Imagens pesadas são uma das principais causas de lentidão. Use TinyPNG ou o plugin Smush.
• O nome dos arquivos das imagens inclui a palavra-chave? Prefira como-escrever-um-artigo.jpg a imagem-1234.jpg.

Links internos e externos

• O artigo tem pelo menos dois ou três links internos para outros conteúdos do site?
• Os links externos apontam para fontes confiáveis?
• Links externos estão configurados para abrir em nova aba?
• Nenhum link está quebrado?

Categoria e tags

• O post está em uma categoria relevante (não “Sem categoria”)?
• As tags estão sendo usadas com moderação — no máximo três a cinco por post?

Parte 5: Verificações técnicas antes de publicar

Formatação visual

• Revisar no modo Pré-visualização antes de publicar — o editor pode diferir do resultado final.
• A hierarquia de títulos está correta? O H1 é o título do post. O conteúdo usa H2 para seções e H3 para subseções. Nunca pule do H1 para o H3.
• Não há formatação residual de Word ou Google Docs? Use “Colar como texto simples” (Ctrl+Shift+V) e reformate no editor.

Configurações de publicação

• O post está como Público (não Privado ou Protegido por senha)?
• A data e o fuso horário estão corretos?
• O autor está correto?

Performance após publicação

Um artigo bem escrito e bem configurado ainda pode fracassar se o servidor não conseguir entregá-lo com rapidez. Estudos do Google mostram que 53% dos visitantes abandonam um site mobile que demora mais de 3 segundos para carregar — e cada segundo adicional reduz conversões em média 7%.

Os fatores de hospedagem que mais impactam a experiência do leitor:

Tempo de resposta do servidor (TTFB): quanto tempo o servidor demora para começar a enviar dados. Um TTFB acima de 600ms já é considerado lento pelo Google. Servidores com LiteSpeed e cache de objeto configurado costumam ter TTFB abaixo de 200ms.

Uptime: um servidor instável prejudica o indexamento pelo Google e a confiança do leitor. O SLA deve ser de pelo menos 99,9%.

Localização do servidor: um servidor no Brasil entrega conteúdo mais rápido para visitantes brasileiros. A latência entre Brasil e EUA pode adicionar 80 a 150ms em cada requisição.

Após publicar, teste o tempo de carregamento da nova página em PageSpeed Insights ou GTmetrix. Se o site está lento mesmo com o conteúdo otimizado, o problema pode estar na infraestrutura de hospedagem — e vale avaliar uma migração para um plano com melhor performance, como a hospedagem WordPress da Homehost.

Checklist completo — use antes de cada publicação

Antes de escrever

• Palavra-chave principal definida
• Intenção de busca identificada
• Esboço com título, seções e conclusão criado

Revisão editorial

• Estrutura clara: introdução, desenvolvimento, conclusão
• Parágrafos curtos e objetivos
• Sem erros gramaticais (verificado no LanguageTool)
• Tom consistente do início ao fim
• Subtítulos organizando as seções

SEO on-page

• Título com palavra-chave (50–60 caracteres)
• URL limpa com palavra-chave
• Meta description preenchida (140–160 caracteres)
• Imagem destacada com alt text
• Todas as imagens com alt text e comprimidas
• Links internos e externos verificados
• Categoria correta; tags com moderação

Técnico

• Pré-visualização revisada
• Hierarquia de títulos correta (H2 → H3)
• Sem formatação residual
• Post configurado como Público
• Tempo de carregamento verificado após publicação

Conclusão

Aprender como escrever um artigo é um processo que melhora com a prática. Com o tempo, boa parte dessas etapas passa a ser automática — e o checklist fica como uma rede de segurança para os detalhes que escapam quando você está imerso no conteúdo.

A regra mais importante: um artigo nunca está pronto quando você termina de escrever. Ele está pronto quando passou pela revisão, pelo SEO on-page e pelas verificações técnicas. Só então clicar em “Publicar” faz sentido.

Se o seu site está lento mesmo com o conteúdo bem otimizado, o problema pode estar na infraestrutura. Uma hospedagem WordPress com servidor LiteSpeed, cache configurado e suporte especializado faz diferença mensurável nos resultados — especialmente para quem publica conteúdo com frequência.

Fontes e leituras complementares

• Google Search Central — Diretrizes de qualidade de conteúdo
• LanguageTool — Verificador gramatical em português
• PageSpeed Insights — Ferramenta de análise de performance
• Yoast SEO — Guia de SEO on-page para WordPress

O post Como escrever um artigo: guia completo do rascunho à publicação no WordPress apareceu primeiro em Homehost.

O substituto oficial do protocolo WHOIS é o RDAP — Registration Data Access Protocol. E se você tem um domínio, desenvolve sites ou trabalha com hospedagem, vale entender o que mudou.

Se você já precisou descobrir quem é o dono de um domínio, quando ele expira ou qual empresa o registrou, provavelmente usou uma ferramenta de WHOIS. Por mais de 40 anos, o WHOIS foi o protocolo padrão para consultar essas informações na internet.

Mas o WHOIS acabou.

Em 28 de janeiro de 2025, a ICANN — a organização responsável pela coordenação global de nomes de domínio — removeu a obrigação contratual para que registros e registradores de domínios gTLD oferecessem o serviço WHOIS. Desde então, centenas de registros começaram a desligar seus servidores WHOIS. Em setembro de 2025, 374 TLDs já não ofereciam mais WHOIS, de acordo com o TLD RDAP Monitor.

Por que o WHOIS durou tanto tempo — e por que acabou

O WHOIS foi formalizado em 1982 pelo RFC 812, quando a internet tinha apenas algumas centenas de hosts. O protocolo é simples na essência: o cliente abre uma conexão TCP na porta 43, envia um nome de domínio em texto plano, e recebe uma resposta de texto livre. Sem formato padronizado, sem criptografia, sem autenticação.

Por 40 anos, o WHOIS funcionou. Mas suas limitações técnicas tornaram-se problemas críticos à medida que a internet cresceu:

Falta de padronização: cada registro de domínio retornava informações em formatos completamente diferentes. Um script que funcionava para domínios .com quebrava em .org, e funcionava de forma diferente em .br. Automatizar consultas era um pesadelo.

Sem privacidade: o WHOIS exibia publicamente os dados de contato do registrante — nome, e-mail, telefone, endereço — para qualquer pessoa que perguntasse. A chegada do GDPR em 2018 tornou isso incompatível com a legislação de privacidade europeia.

Sem criptografia: as consultas eram feitas em texto puro, visíveis para qualquer um na rede. Sem TLS, sem HTTPS.

Sem controle de acesso: era tudo ou nada. Ou você exibia todos os dados publicamente, ou não exibia nada.

Sem suporte a caracteres internacionais: domínios com caracteres não-latinos (árabe, chinês, cirílico) não eram suportados adequadamente.

O que é o RDAP

O RDAP (Registration Data Access Protocol) foi desenvolvido pelo IETF — a organização responsável pelos padrões técnicos da internet — e publicado como padrão em 2015 nos RFCs 7480 a 7484. A ICANN exigiu que todos os registros gTLD implementassem RDAP a partir de 2019, e em janeiro de 2025 tornou o RDAP o protocolo definitivo.

A diferença fundamental é a arquitetura. Enquanto o WHOIS usava TCP na porta 43 com resposta em texto livre, o RDAP é uma API REST sobre HTTPS que retorna dados em JSON estruturado.

Na prática, uma consulta RDAP é simplesmente uma requisição HTTP:

https://rdap.org/domain/homehost.com.br

O retorno é um objeto JSON padronizado e legível por máquina, com todos os dados do domínio organizados em campos bem definidos.

RDAP vs WHOIS: as diferenças principais

O sistema de acesso em camadas do RDAP

Um dos avanços mais importantes do RDAP é o sistema de acesso diferenciado — algo que o WHOIS nunca conseguiu oferecer:

Acesso anônimo — qualquer pessoa pode consultar os dados públicos: nome do domínio, datas de registro e expiração, status, nameservers. É o que uma consulta RDAP padrão retorna.

Acesso autenticado — via token OAuth 2.0, o próprio registrante pode acessar seus dados completos, incluindo informações de contato.

Acesso privilegiado — reservado para autoridades policiais, organizações de proteção de propriedade intelectual e equipes de cibersegurança credenciadas. Permite acesso a dados não públicos mediante processo formal (o sistema SSAD da ICANN).

Isso resolve o dilema do WHOIS pós-GDPR: antes, ou você expunha tudo publicamente ou ocultava tudo. Agora, cada tipo de usuário acessa o nível de informação adequado ao seu contexto.

Os números da transição

A adoção do RDAP acelerou rapidamente após o sunset do WHOIS:

• Em janeiro de 2025: ~122 bilhões de consultas WHOIS por mês e ~7 bilhões de consultas RDAP
• Em agosto de 2025: ~49 bilhões de consultas WHOIS e ~65 bilhões de RDAP
• Em junho de 2025, as consultas RDAP superaram as WHOIS pela primeira vez

Até o final de 2025, 77% de todos os TLDs haviam implantado RDAP. Todos os gTLDs (como .com, .net, .org, .io) já completaram a transição. Entre os ccTLDs (como .br, .de, .uk), 34,2% já adotaram RDAP.

O registro.br já suporta RDAP há anos, com endpoint em rdap.registro.br

Como consultar o RDAP

1. Pelo navegador (o mais simples)

A ICANN mantém um portal oficial de consultas RDAP:

https://lookup.icann.org

Basta digitar qualquer domínio. O resultado é mais limpo e organizado que o WHOIS tradicional.

2. Direto pela URL (consulta manual)

O RDAP é uma API REST — você pode consultar diretamente pelo navegador ou por qualquer ferramenta HTTP:

Para domínios .com e gTLDs:

https://rdap.org/domain/seudominio.com

Para domínios .br:

https://rdap.registro.br/domain/seudominio.com.br

Para endereços IP:

https://rdap.org/ip/177.71.128.0

Para blocos de ASN:

https://rdap.org/autnum/52505

3. Pelo terminal (curl)

curl https://rdap.org/domain/homehost.com.br

Para visualizar o JSON de forma legível, instale o jq:

curl https://rdap.org/domain/homehost.com.br | jq .

Exemplo de saída parcial:

{
  "objectClassName": "domain",
  "ldhName": "homehost.com.br",
  "status": ["active"],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2006-03-14T00:00:00Z"
    },
    {
      "eventAction": "expiration",
      "eventDate": "2027-03-14T00:00:00Z"
    }
  ],
  "nameservers": [
    {"ldhName": "ns1.homehost.com.br"},
    {"ldhName": "ns2.homehost.com.br"}
  ]
}

4. No PowerShell (Windows)

# Instalar o módulo Get-RDAP
Install-Module -Name Get-RDAP

# Configurar política de execução (necessário na primeira vez)
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

# Importar o módulo
Import-Module Get-RDAP

# Consultar um domínio
Get-RDAP -Domain homehost.com.br

# Consultar múltiplos domínios de uma vez
@("homehost.com.br", "registro.br", "google.com") | ForEach-Object {
    Get-RDAP -Domain $_
}

5. Em Python

import requests
import json

def consultar_rdap(dominio):
    url = f"https://rdap.org/domain/{dominio}"
    resposta = requests.get(url)
    dados = resposta.json()
    
    print(f"Domínio: {dados.get('ldhName')}")
    print(f"Status: {dados.get('status')}")
    
    for evento in dados.get('events', []):
        if evento['eventAction'] == 'expiration':
            print(f"Expira em: {evento['eventDate']}")
    
    nameservers = [ns['ldhName'] for ns in dados.get('nameservers', [])]
    print(f"Nameservers: {', '.join(nameservers)}")

consultar_rdap("homehost.com.br")

6. Em Node.js

const https = require('https');

function consultarRDAP(dominio) {
    const url = `https://rdap.org/domain/${dominio}`;
    
    https.get(url, (res) => {
        let dados = '';
        res.on('data', (chunk) => dados += chunk);
        res.on('end', () => {
            const json = JSON.parse(dados);
            console.log(`Domínio: ${json.ldhName}`);
            console.log(`Status: ${json.status}`);
            
            const expiracao = json.events?.find(e => e.eventAction === 'expiration');
            if (expiracao) {
                console.log(`Expira em: ${expiracao.eventDate}`);
            }
        });
    });
}

consultarRDAP('homehost.com.br');

Como interpretar os status do RDAP

Um campo importante no retorno RDAP é o status, que usa os códigos EPP padronizados:

Para a maioria dos domínios ativos, você verá active combinado com clientTransferProhibited — que é o status normal e saudável.

O NIC.br e o RDAP

O NIC.br — Núcleo de Informação e Coordenação do Ponto BR — é a entidade responsável pelo registro e manutenção de todos os domínios sob o .br no Brasil, operando por meio do Registro.br desde 1995.

No contexto da transição para o RDAP, o NIC.br saiu na frente: o Registro.br disponibiliza uma API RDAP pública e documentada em rdap.registro.br, que retorna dados estruturados em JSON para domínios, entidades (identificadas por CPF ou CNPJ), nameservers, endereços IP e números de Sistema Autônomo (ASN).

Trata-se de uma das implementações RDAP mais completas entre os registros de ccTLD — domínios de código de país — em operação no mundo.

O registro.br implementou suporte a RDAP antes da exigência formal da ICANN. O endpoint oficial é:

https://rdap.registro.br/domain/seudominio.com.br

Os dados retornados para domínios .br incluem informações específicas do sistema brasileiro de registro, incluindo os dados de contato do registrante quando aplicável pela legislação brasileira.

O que muda para donos de domínio

Para a grande maioria dos donos de site e domínio, a mudança é transparente — você não precisa fazer nada. Os registradores (incluindo a Homehost) já gerenciam essa transição nos bastidores.

O que muda na prática:

Ferramentas WHOIS antigas podem parar de funcionar. Extensões de navegador, scripts e ferramentas que consultam a porta 43 diretamente podem retornar erros para domínios cujos registros já desligaram o WHOIS. A solução é usar as ferramentas acima, que consultam RDAP nativamente.

Menos dados de contato visíveis publicamente. Com o RDAP e o GDPR, dados pessoais do registrante (nome, e-mail, telefone) são ocultados por padrão em consultas anônimas. Isso é uma proteção para você como dono de domínio.

Consultas programáticas ficam muito mais simples. Se você desenvolve sistemas que precisam consultar dados de domínio, o RDAP com JSON estruturado é incomparavelmente mais fácil de integrar do que o WHOIS com texto livre.

Recursos e ferramentas úteis

• Portal ICANN RDAP: https://lookup.icann.org
• RDAP.org (bootstrap global): https://rdap.org
• Registro.br RDAP: https://rdap.registro.br
• Módulo PowerShell Get-RDAP: https://github.com/RobBiddle/Get-RDAP
• TLD RDAP Monitor: https://tldrdapmonitor.icann.org
• RFC 7480 (especificação RDAP): https://datatracker.ietf.org/doc/html/rfc7480

Fontes

• IETF — The current state of RDAP: https://www.ietf.org/blog/current-state-of-rdap/
• APNIC Blog — The current state of RDAP: https://blog.apnic.net/2026/02/10/the-current-state-of-rdap/
• ICANN — Launching RDAP; Sunsetting WHOIS: https://www.icann.org/en/announcements/details/icann-update-launching-rdap-sunsetting-whois-27-01-2025-en

A Homehost oferece registro de domínios com suporte ao RDAP. Todos os domínios registrados através da Homehost são compatíveis com o novo protocolo. Consulte nossos planos de registro de domínio.

O post O WHOIS foi aposentado: conheça o RDAP, o novo protocolo de domínios apareceu primeiro em Homehost.

Quando você olha para o painel de estatísticas do seu site e vê mil visitas por dia, uma parcela significativa dessas visitas nunca existiu — pelo menos não como você imagina. Não foi um ser humano que abriu o navegador, leu o seu conteúdo e tomou uma decisão. Foi um programa automatizado, rodando sem parar, acessando suas páginas, consultando seu banco de dados e consumindo os recursos do servidor pelo qual você paga todo mês.

Segundo o Relatório de Bots Maliciosos 2026 da Thales — a maior pesquisa anual sobre tráfego automatizado na internet, agora em sua 13ª edição consecutiva — bots já respondem por 53% de todo o tráfego web. O tráfego humano caiu para 47% e continua em queda. Dos 53% automatizados, 40% são bots maliciosos — um aumento de 3 pontos percentuais em relação ao ano anterior. Isso significa que dois quintos de todo o tráfego da internet está ativamente causando dano.

Para donos de sites hospedados, esse número tem uma consequência muito concreta: recursos sendo consumidos sem gerar nenhum resultado.

O que é um bot, afinal?

Um bot é simplesmente um programa de computador que realiza tarefas automatizadas na internet. Nem todo bot é ruim — os “spiders” do Google que indexam seu site são bots, por exemplo. Esses são chamados de bots legítimos ou benignos.

O problema são os bots maliciosos. O relatório da Thales classifica o tráfego automatizado em três categorias:

Bots benignos (13% do total): rastreadores de mecanismos de busca, verificadores de disponibilidade, ferramentas de monitoramento. Esses são úteis e necessários.

Bots maliciosos (40% do total): programas criados para realizar ações prejudiciais — desde scraping de conteúdo e tentativas de invasão até fraude de cliques, preenchimento de formulários automatizado e ataques de força bruta.

Agentes de IA (categoria nova em 2026): sistemas de IA que navegam autonomamente, coletam dados e executam tarefas em nome de usuários. Essa é a categoria que mais cresceu — ataques de bots com IA aumentaram 12,5 vezes em 2025 em relação ao ano anterior.

Como bots maliciosos prejudicam sua hospedagem

O impacto mais imediato e menos discutido dos bots maliciosos é o consumo de recursos do servidor.

Pense no comportamento de um visitante humano: ele acessa uma página, passa dois ou três minutos lendo, clica em um link e navega para outra seção. Esse ritmo gera uma carga previsível e gerenciável no servidor.

Agora pense no comportamento de um bot agressivo: ele pode acessar 50 páginas em dois segundos, cada uma gerando uma consulta ao banco de dados, processamento PHP, carregamento de arquivos e registro de log. Um único bot pode gerar o equivalente ao tráfego de centenas de usuários humanos — sem jamais converter, comprar ou se tornar um cliente.

Em ambientes de hospedagem compartilhada, esse impacto é amplificado. Os recursos do servidor — CPU, memória RAM, conexões de banco de dados — são divididos entre múltiplos clientes. Quando bots sobrecarregam um site, os outros sites no mesmo servidor também sofrem. É por isso que plataformas como CloudLinux utilizam isolamento por conta (LVE — Linux Virtual Environment): para garantir que o tráfego excessivo de um site não degrade os demais.

O efeito prático para o dono do site inclui:

Lentidão: páginas demoram mais para carregar porque os recursos estão sendo consumidos por requisições automatizadas que nunca vão converter.

Limite de bandwidth consumido: em planos com limite de transferência, bots consomem sua cota sem gerar resultado algum.

Banco de dados sobrecarregado: cada requisição de bot que gera uma consulta SQL concorre com os usuários reais pelo mesmo recurso.

Logs poluídos: dificulta identificar comportamento real dos visitantes e detectar problemas legítimos.

Risco de blacklist: bots que usam seu servidor como intermediário podem fazer seu IP aparecer em listas de bloqueio de spam.

Infográfico

O que os bots maliciosos estão fazendo no seu site

O relatório da Thales identifica os principais tipos de ataque automatizado em 2025:

Automação geral (29% dos ataques): varredura em busca de vulnerabilidades, coleta de dados, mapeamento da estrutura do site. É o tipo mais comum — bots que simplesmente exploram tudo que encontram.

Scraping de conteúdo: cópia automatizada do conteúdo do seu site para uso em outros lugares, sem autorização. Afeta tanto o desempenho quanto o SEO.

Credential stuffing: tentativas automatizadas de login usando combinações de usuário e senha vazadas de outros sites. Alveja páginas de login do WordPress, áreas de membros e painéis administrativos.

Account takeover (ATO): em 2024, ataques de tomada de conta aumentaram 40% impulsionados por bots com IA. Em 2025, o número continuou crescendo.

Ataques a APIs: 27% de todos os ataques de bots têm como alvo endpoints de API — incluindo a REST API do WordPress, que é amplamente utilizada por plugins e temas.

Form spam: preenchimento automatizado de formulários de contato, cadastro e comentários. Além de gerar spam, consome processamento e pode acionar disparadores de e-mail.

Por que os bots estão ficando mais difíceis de detectar

Até pouco tempo atrás, identificar um bot era relativamente simples: endereços IP suspeitos, user-agents fora do padrão, padrões de requisição muito rápidos.

Isso mudou. Bots maliciosos agora operam através de navegadores legítimos, fingerprints válidos, proxies residenciais e padrões de interação semelhantes aos humanos. Como resultado, bots maliciosos se misturam perfeitamente ao tráfego normal.

A IA acelerou esse processo de forma dramática. Bots modernos:

• Alteram endereços IP automaticamente para evitar bloqueios por reputação
• Simulam movimentos de mouse e pausas entre cliques
• Resolvem CAPTCHAs usando serviços especializados ou IA
• Distribuem as requisições ao longo do tempo para parecerem humanos
• Usam redes residenciais reais (proxies) para mascarar a origem

O resultado é que estratégias simples de bloqueio — como bloquear IPs suspeitos ou usar rate limiting básico — não são mais suficientes. Detecção comportamental e análise de contexto são necessárias.

O problema do tráfego de IA legítimo

O relatório de 2026 introduz uma complicação nova: a distinção entre bots maliciosos e agentes de IA legítimos está se tornando cada vez mais difícil de fazer.

Ferramentas como o ChatGPT (SearchGPT), o Perplexity, o Google Gemini e o Claude navegam ativamente em sites para coletar informações e responder perguntas dos usuários. Esses são bots legítimos — mas se comportam de forma muito similar aos maliciosos: acessam muitas páginas rapidamente, não convertem e consomem recursos.

Para donos de sites, isso cria uma decisão de gestão: bloquear todo o tráfego automatizado pode prejudicar sua visibilidade nos mecanismos de busca baseados em IA. Permitir tudo indiscriminadamente significa arcar com os custos de recursos.

A solução é um controle granular — algo que vai além do simples bloqueio e envolve identificar a intenção do tráfego automatizado.

Como proteger seu site e sua hospedagem

1. Cache agressivo com LiteSpeed

O LiteSpeed Web Server, presente nos planos de hospedagem da Homehost, tem uma vantagem significativa contra bots: páginas em cache são servidas diretamente pelo servidor web, sem acionar o PHP ou consultar o banco de dados. Um bot que acessa uma página em cache consome uma fração ínfima dos recursos de um acesso não cacheado.

Ativar o LiteSpeed Cache no WordPress e configurar cache para usuários não logados reduz drasticamente o impacto do tráfego automatizado no desempenho do site.

2. Rate limiting

Configurar limites de requisição por IP é uma das proteções mais eficazes contra bots simples. No nível do servidor, isso pode ser feito via .htaccess ou configurações do LiteSpeed. No nível de aplicação, plugins de segurança para WordPress como Wordfence e Solid Security oferecem rate limiting integrado.

Uma regra simples: limitar cada IP a no máximo 30–60 requisições por minuto elimina a maioria dos bots sem impactar visitantes humanos.

3. Proteção da página de login

A página de login do WordPress (/wp-login.php) é o alvo favorito de ataques de credential stuffing. Medidas eficazes:

• Mover o URL de login para um endereço personalizado
• Bloquear acessos ao /wp-login.php por IP após um número definido de tentativas
• Ativar autenticação de dois fatores para todos os usuários administradores
• Bloquear xmlrpc.php se não utilizar aplicativos que dependem dessa interface

4. Web Application Firewall (WAF)

Um WAF analisa o tráfego antes de chegar à aplicação e bloqueia padrões conhecidos de ataque. O Cloudflare oferece um WAF gratuito no plano básico que cobre a maioria das assinaturas de bots comuns. Para sites WordPress, o Wordfence tem um WAF integrado com regras atualizadas continuamente.

5. Bloqueio de user-agents conhecidos

Bots menos sofisticados ainda se identificam por user-agents reconhecíveis. Uma lista de bloqueio básica no .htaccess pode reduzir uma parcela do tráfego indesejado sem configuração complexa.

6. Monitoramento do tráfego real

Ferramentas como o Google Search Console mostram o que o Googlebot está indexando. O Google Analytics 4 com configuração adequada filtra parte do tráfego de bots. Para análise mais precisa, o Cloudflare Analytics mostra o tráfego antes da filtragem — o que frequentemente revela uma proporção surpreendentemente alta de requisições automatizadas.

O que esperar nos próximos anos

O relatório da Thales é explícito: a tendência não vai reverter. O tráfego humano continua a declinar como proporção da atividade total na internet. A IA vai acelerar esse processo — agentes autônomos que navegam, pesquisam e executam tarefas em nome de usuários são o próximo estágio, e eles já estão aqui.

Para donos de sites, isso significa que a gestão de tráfego automatizado deixa de ser um problema de segurança periférico e se torna parte da operação regular do site. Assim como você gerencia atualizações de plugins e backups, monitorar e controlar o tráfego de bots vai se tornar uma tarefa de manutenção padrão.

A boa notícia é que hospedagem bem configurada — com LiteSpeed, cache agressivo, WAF e rate limiting — absorve a maior parte desse tráfego sem impacto significativo para os usuários humanos reais. O segredo está em garantir que os recursos do servidor sirvam as pessoas que realmente importam para o seu negócio.

Resumo: o que fazer agora

Ação	Impacto	Dificuldade
Ativar LiteSpeed Cache no WordPress	Alto	Baixa
Configurar rate limiting básico	Alto	Média
Proteger /wp-login.php	Alto	Baixa
Ativar WAF (Cloudflare ou Wordfence)	Médio-alto	Baixa
Monitorar proporção de tráfego real	Médio	Baixa
Bloquear user-agents conhecidos	Complementar	Média

Fontes

• Thales 2026 Bad Bot Report: Bad Bots in the Agentic Age: https://cpl.thalesgroup.com/blog/application-security/bad-bots-in-the-agentic-age
• Imperva Bad Bot Report 2026 (blog): https://www.imperva.com/blog/bad-bot-report-2026-bots-agentic-age/
• Help Net Security — Bad bots make up 40% of internet traffic: https://www.helpnetsecurity.com/2026/04/30/thales-ai-driven-bot-traffic-rise-report/
• Business Wire — AI-driven Bot Attacks Surged 12.5x According to Thales Bad Bot Report: https://www.businesswire.com/news/home/20260428783532/en/AI-driven-Bot-Attacks-Surged-12.5x-According-to-Thales-Bad-Bot-Report

A Homehost oferece hospedagem de sites com LiteSpeed Web Server, CloudLinux com isolamento LVE e suporte técnico especializado. Nossos planos incluem infraestrutura otimizada para manter seu site rápido mesmo diante de tráfego automatizado elevado. Conheça nossos planos de hospedagem.

O post 53% do tráfego do seu site não é humano — e está consumindo seus recursos de hospedagem apareceu primeiro em Homehost.

Durante décadas, a internet funcionou com um contrato implícito de segurança chamado divulgação coordenada. O pesquisador encontra uma falha, avisa o fabricante, o fabricante corrige, e só então a falha é tornada pública. O processo inteiro levava em média 90 dias — tempo suficiente para que patches chegassem aos servidores antes que os atacantes soubessem o que procurar.

Esse contrato está sendo quebrado em 2026. E a razão é a inteligência artificial.

O que aconteceu com o Copy Fail

Em 29 de abril de 2026, foi divulgada uma falha crítica no kernel Linux chamada Copy Fail (CVE-2026-31431). Com um script Python de 732 bytes, qualquer usuário sem privilégios conseguia acesso root em praticamente qualquer servidor Linux construído desde 2017 — Ubuntu, Amazon Linux, RHEL, AlmaLinux, Fedora.

O que tornou essa falha diferente não foi a gravidade. Foi como ela foi encontrada.

A empresa de segurança Theori, ao descrever a descoberta, disse que o sistema deles precisou de aproximadamente uma hora de varredura automatizada com IA no subsistema de criptografia do kernel Linux. Um único prompt. Sem necessidade de engenharia manual de exploits. Sem harnessing.

Uma hora. Para encontrar uma falha que existia há 9 anos no kernel mais usado do mundo.

E então veio o Dirty Frag

Oito dias depois do Copy Fail, em 7 de maio, o pesquisador Hyunwoo Kim divulgou o Dirty Frag (CVE-2026-43284 + CVE-2026-43500). Mesma classe de bug, caminho de ataque diferente. Usuário sem privilégios consegue root de forma determinística em todas as principais distribuições Linux.

Mas o que o Dirty Frag revelou vai além da vulnerabilidade em si.

Hyunwoo Kim reportou a falha ao Linux Security Team em 29-30 de abril. Uma janela de embargo de 5 dias foi acordada. Os patches foram commitados no repositório público enquanto as distribuições preparavam os pacotes.

Nove horas depois do commit público, Kuan-Ting Chen — um pesquisador completamente independente — descobriu a mesma vulnerabilidade analisando o diff. Não por acaso: ele estava usando ferramentas de varredura assistida por IA que analisam automaticamente commits públicos em busca de padrões de correção de segurança.

O embargo foi efetivamente quebrado antes de terminar.

O tempo entre descoberta e exploração chegou a 10 horas

Essa não é uma anomalia de maio de 2026. É uma tendência em aceleração.

Em 2024, o tempo médio entre a publicação de um CVE e a existência de um exploit funcional era de 56 dias. Em 2025, caiu para 23 dias. No acumulado de 2026, está em torno de 10 horas — analisando mais de 3.500 pares CVE-exploit do catálogo da CISA, do VulnCheck e do ExploitDB.

Uma CVE publicada hoje pode ter exploit funcional antes do fim do dia.

Um exemplo concreto: em 21 de abril de 2026, o GitHub publicou o GHSA-6w67-hwm5-92mq (CVE-2026-33626), uma falha de SSRF no LMDeploy. Doze horas e trinta e um minutos depois, a equipe de pesquisa da Sysdig registrou a primeira tentativa de exploração em seus honeypots. O atacante não apenas verificou a falha — em oito minutos de sessão, já estava varrendo a rede interna por trás do servidor comprometido: AWS IMDS, Redis, MySQL, endpoint DNS de exfiltração.

Por que a divulgação coordenada está falhando agora

O sistema de divulgação coordenada foi construído sobre uma suposição: encontrar uma vulnerabilidade grave é caro e raro, então o número de pessoas capazes de fazê-lo era limitado.

Essa suposição não é mais verdadeira.

Ferramentas de IA com acesso à base de código pública do Linux, ao histórico de commits e aos boletins de segurança conseguem varrer subsistemas inteiros em busca de padrões de vulnerabilidade em horas. Pesquisadores independentes ao redor do mundo alimentam esses modelos com os mesmos diffs. O que antes exigia semanas de análise manual por um especialista sênior agora exige um prompt bem elaborado.

O resultado é o que a LWN.net descreveu como “descoberta paralela dentro da janela de embargo” — múltiplos pesquisadores e grupos encontrando a mesma falha de forma independente enquanto o embargo ainda está ativo. A informação não fica mais contida. Como descreveu o pesquisador Himanshu Anand: “ela tem pernas movidas a LLM”.

O que isso significa para quem tem um site hospedado

Para a maioria dos donos de site, esse contexto técnico parece distante. Mas as consequências são diretas.

Patches precisam ser aplicados em horas, não em dias. A janela de segurança entre a divulgação de uma vulnerabilidade e a existência de exploit funcional não é mais de semanas — é de horas. Servidores que esperam janelas de manutenção mensais para aplicar patches estão, na prática, deixando uma porta aberta.

A falha não precisa ser descoberta contra você diretamente. O CVE-2026-41940 do cPanel, por exemplo, estava sendo explorado desde fevereiro de 2026 — dois meses antes de qualquer patch existir. Atacantes com acesso a ferramentas de IA encontraram a falha antes do fabricante saber que ela existia.

Hospedagem compartilhada amplifica o risco. Em um servidor com múltiplos clientes, uma falha de escalonamento de privilégios como o Copy Fail ou o Dirty Frag significa que qualquer conta comprometida pode afetar todos os outros sites no mesmo servidor. A qualidade da isolação e a velocidade de patching da sua hospedagem importam mais do que nunca.

Como a Homehost responde a esse novo cenário

A Homehost acompanha continuamente os principais canais de divulgação de vulnerabilidades — LWN.net, Bugcrowd, CISA KEV, alertas das distribuições Linux — e aplica patches de segurança críticos assim que os pacotes estabilizados ficam disponíveis nas distribuições utilizadas em nossa infraestrutura.

Durante os eventos de Copy Fail e Dirty Frag, nossa equipe aplicou os kernels corrigidos e reiniciou os servidores afetados dentro das primeiras horas após a disponibilidade dos patches estabilizados para AlmaLinux e CloudLinux. Para servidores com KernelCare, o livepatch foi aplicado sem interrupção de serviço.

Nossa infraestrutura é construída sobre CloudLinux com CageFS — o que significa que cada conta de hospedagem opera em um ambiente isolado. Mesmo em um cenário de comprometimento de conta, a isolação impede o movimento lateral para outras contas no mesmo servidor.

O que você pode fazer

1. Verifique se sua hospedagem aplica patches ativamente Pergunte diretamente ao seu provedor de hospedagem quando os patches do Copy Fail e do Dirty Frag foram aplicados. Um provedor sério responde com data e hora. Um provedor que não sabe ou demora para responder é um sinal de alerta.

2. Mantenha o software da aplicação atualizado Patches de kernel são responsabilidade do provedor. Mas plugins desatualizados, temas e o próprio WordPress são responsabilidade sua. O CVE-2026-23550 no plugin Modular DS — exploração ativa com CVSS 10.0 — chegou em servidores perfeitamente patcheados porque o plugin do cliente estava desatualizado.

3. Use autenticação forte no painel de controle O backdoor identificado pela XLab no CVE-2026-41940 adulterava a página de login do cPanel para roubar senhas. Autenticação de dois fatores no cPanel e no painel da sua hospedagem elimina esse vetor.

4. Ative notificações de segurança O CISA mantém um catálogo público de vulnerabilidades ativamente exploradas em cisa.gov/known-exploited-vulnerabilities-catalog. Assinar as notificações por e-mail leva dois minutos e garante que você soube da vulnerabilidade no mesmo dia que os atacantes.

A mudança estrutural

O que está acontecendo em 2026 não é uma tempestade passageira de CVEs. É uma mudança estrutural permanente na velocidade da segurança ofensiva.

As ferramentas que encontraram o Copy Fail em uma hora existem, são acessíveis e melhoram a cada mês. O número de pessoas capazes de usá-las cresce continuamente. A suposição que sustentava a divulgação coordenada — de que vulnerabilidades graves são raras e caras de descobrir — não volta a ser verdadeira.

Para quem tem um site na internet, a consequência prática é simples: a qualidade da segurança da sua hospedagem importa mais em 2026 do que importava em 2020. Não porque os ataques ficaram mais sofisticados — mas porque ficaram mais rápidos.

Fontes

• LWN.net — LLM-driven security reports disrupt coordinated disclosure: https://lwn.net/Articles/1070698/
• Bugcrowd — What we know about Copy Fail (CVE-2026-31431): https://www.bugcrowd.com/blog/what-we-know-about-copy-fail-cve-2026-31431/
• Himanshu Anand / Threat Notes — The 90-day disclosure policy is dead: https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/
• Sysdig — CVE-2026-33626: How attackers exploited LMDeploy in 12 hours: https://webflow.sysdig.com/blog/cve-2026-33626-how-attackers-exploited-lmdeploy-llm-inference-engines-in-12-hours
• The Hacker News — cPanel CVE-2026-41940 Under Active Exploitation to Deploy Filemanager Backdoor: https://thehackernews.com/2026/05/cpanel-cve-2026-41940-under-active.html
• TechPlanet — AI is Breaking Vulnerability Disclosure: https://techplanet.today/post/ai-is-breaking-vulnerability-disclosure-how-llms-are-disrupting-security-culture

A Homehost oferece hospedagem de sites com infraestrutura CloudLinux, isolamento CageFS e monitoramento contínuo de segurança. Nossos servidores são atualizados ativamente assim que correções estabilizadas ficam disponíveis para as vulnerabilidades críticas. Conheça nossos planos de hospedagem.

O post IA Está Acelerando a Descoberta de Falhas em Servidores — e Isso é um Problema Sério para Quem Tem Site apareceu primeiro em Homehost.

O número que todo dono de domínio precisa ver

De cada 10 domínios ativos na internet, 7 ainda não têm proteção real contra falsificação de e-mail.

Esse é o dado central do Relatório de Adoção DMARC 2026 da EasyDMARC, que analisou 1,8 milhão dos domínios mais relevantes da web: apenas 10,7% deles têm o protocolo DMARC configurado com uma política que realmente bloqueia e-mails falsos.

Os outros 89,3% — mais de 1,6 milhão de domínios — estão vulneráveis a ter o nome da sua empresa usado por criminosos para enviar golpes, phishing e spam.

Segundo o relatório, que analisou 1,8 milhão de domínios, apenas 22,9% têm DMARC com enforcement real (p=quarantine ou p=reject). Os demais 77,1% ou não têm DMARC algum, ou usam p=none — que não bloqueia nenhum e-mail falso

Se você tem um site, uma loja virtual, ou qualquer presença digital com e-mail corporativo, esse dado provavelmente inclui você.

Por que seus e-mails estão indo para o spam (ou sendo bloqueados)

Você já enviou um e-mail importante — uma proposta, uma confirmação de pedido, uma mensagem para cliente — e ele simplesmente sumiu? Provavelmente foi para a caixa de spam. Ou pior: foi rejeitado silenciosamente pelo servidor de destino, sem que você soubesse.

A razão quase sempre é a mesma: autenticação de e-mail mal configurada ou ausente.

Desde 2024, Google (Gmail), Yahoo e Microsoft (Outlook) passaram a exigir que domínios que enviam e-mails tenham três protocolos configurados corretamente: SPF, DKIM e DMARC. Quem não cumpre as regras tem as mensagens jogadas no spam ou rejeitadas diretamente.

Em novembro de 2025, o Google endureceu ainda mais: e-mails de domínios não conformes agora sofrem rejeições temporárias e permanentes no nível do protocolo SMTP — ou seja, a mensagem nem chega a ser entregue. A Microsoft seguiu o mesmo caminho em maio de 2025.

Na prática, isso significa que se o seu domínio não estiver configurado corretamente, seus e-mails podem simplesmente não chegar a quem você quer alcançar.

O que são SPF, DKIM e DMARC (sem complicar)

Esses três protocolos trabalham juntos como uma espécie de “documento de identidade” para o seu e-mail. Veja o que cada um faz:

SPF (Sender Policy Framework) é uma lista publicada no DNS do seu domínio que diz quais servidores têm permissão para enviar e-mails em seu nome. Funciona como uma lista de funcionários autorizados: se um e-mail chega dizendo que veio da sua empresa, mas não veio de um servidor da lista, o servidor destinatário sabe que é suspeito.

DKIM (DomainKeys Identified Mail) é uma assinatura digital que vai embutida em cada e-mail que você envia. Ela prova duas coisas: que o e-mail realmente veio do seu domínio, e que ninguém alterou o conteúdo durante o caminho. Pense nela como um selo de lacre — se o lacre estiver intacto, o conteúdo é original.

DMARC (Domain-based Message Authentication, Reporting and Conformance) é o protocolo que une os dois anteriores e diz ao servidor de destino o que fazer quando um e-mail falha na verificação: ignorar, jogar no spam ou bloquear completamente. Ele também envia relatórios para você sobre o que está acontecendo com os e-mails enviados em nome do seu domínio — inclusive os não autorizados.

Sem DMARC configurado, mesmo que você tenha SPF e DKIM, não há nenhuma instrução para os servidores de destino sobre o que fazer com e-mails suspeitos. É como ter câmeras de segurança sem ninguém olhando o monitor.

O problema real: metade dos domínios que têm DMARC não usa de verdade

Dos 52,1% de domínios que já têm algum registro DMARC publicado, a maioria não está realmente protegida.

O DMARC tem três modos de operação, chamados de “políticas”:

• p=none — modo de monitoramento. Você recebe relatórios, mas nenhum e-mail falso é bloqueado. É o equivalente a uma câmera de segurança que grava mas não aciona nenhum alarme.
• p=quarantine — e-mails suspeitos vão para a caixa de spam do destinatário.
• p=reject — e-mails suspeitos são bloqueados e descartados.

O dado alarmante é que, dos domínios com DMARC, mais de 56% estão travados em p=none — sem nenhuma proteção real. Ao somar com os domínios que não têm DMARC algum, o resultado é que quase 90% dos domínios da internet não têm proteção efetiva contra falsificação de e-mail.

Significa que praticamente qualquer pessoa mal-intencionada pode enviar um e-mail fingindo ser do seu domínio — e não há nada configurado para impedir isso.

O que acontece quando o seu domínio é usado para golpes

Imagine o seguinte cenário: um cliente seu recebe um e-mail que parece ter sido enviado pelo seu negócio, pedindo para ele clicar em um link ou fazer um pagamento. O endereço de remetente é idêntico ao seu. O cliente confia, clica, e cai em um golpe.

Você não enviou nada. Mas o dano à reputação do seu negócio é real.

Isso se chama spoofing de e-mail, e é uma das técnicas de phishing mais usadas no mundo. Em 2026, a Microsoft detectou 8,3 bilhões de ameaças baseadas em e-mail apenas no primeiro trimestre — e 94% dos ataques de phishing têm o roubo de credenciais como objetivo principal.

Sem DMARC em p=reject, o seu domínio é um alvo fácil. Com DMARC configurado corretamente, qualquer tentativa de alguém fingir ser você é bloqueada antes de chegar à caixa de entrada do seu cliente.

Por que isso importa especialmente para quem tem e-commerce ou loja virtual

Se você vende online e processa pagamentos com cartão, há um motivo adicional para agir agora: o padrão PCI DSS v4.0, obrigatório desde 2025, exige DMARC de qualquer organização que lide com dados de cartões de pagamento. O não cumprimento pode gerar multas mensais entre US$ 5.000 e US$ 100.000.

Além disso, o dado mais revelador sobre o impacto real do DMARC vem de uma comparação entre países: nos países que adotaram mandatos nacionais de DMARC, as taxas de sucesso de ataques de phishing caíram de 69% para 14%. Nos países sem mandato, a vulnerabilidade chegou a 97%.

Como saber se o seu domínio está protegido agora

Você pode verificar a situação do seu domínio com ferramentas gratuitas online. Basta buscar por “DMARC checker” e inserir o seu domínio — em segundos você verá se tem SPF, DKIM e DMARC configurados, e qual política está ativa.

Se não tiver nada configurado, ou se estiver em p=none, sua proteção é zero.

O caminho para configurar corretamente segue uma sequência lógica:

1. Publique um registro SPF no DNS do seu domínio listando todos os servidores que enviam e-mail em seu nome — incluindo ferramentas de marketing, CRM e plataformas de transacional.

2. Configure o DKIM para cada serviço que envia e-mail pelo seu domínio. Cada serviço tem um procedimento diferente, mas todos envolvem publicar uma chave pública no DNS.

3. Publique o DMARC começando em p=none, com um endereço para receber relatórios. Acompanhe os relatórios por algumas semanas para garantir que todos os e-mails legítimos estão passando na autenticação.

4. Avance para p=quarantine quando estiver confiante que a configuração está correta.

5. Mude para p=reject para ter proteção total — e-mails falsos são descartados antes de chegar a qualquer caixa de entrada.

Um detalhe técnico importante: o SPF tem um limite de 10 consultas DNS. Se você usa muitas ferramentas de e-mail (marketing, CRM, suporte, transacional), pode ultrapassar esse limite sem perceber — e seus e-mails legítimos começam a falhar na autenticação. Isso é resolvido com uma técnica chamada “flattening” do SPF.

Como a Homehost pode ajudar

Toda hospedagem de sites da Homehost já inclui serviço de e-mail profissional com suporte para configuração de SPF, DKIM e DMARC.

Se você hospeda seu site conosco, os registros DNS necessários ficam acessíveis direto no painel de controle — e nossa equipe de suporte pode orientar a configuração.

Se você ainda usa um e-mail genérico como @gmail.com ou @hotmail.com para se comunicar com clientes, considere migrar para um e-mail com o seu próprio domínio (voce@suaempresa.com.br). Além de passar muito mais credibilidade, você terá controle total sobre a autenticação — e poderá proteger sua marca contra falsificação.

O que muda se você configurar tudo corretamente

A diferença é concreta e mensurável:

• Seus e-mails param de ir para a caixa de spam dos clientes
• Ninguém consegue enviar e-mails falsos fingindo ser você
• Sua reputação de domínio melhora, o que aumenta as taxas de entrega ao longo do tempo
• Você fica em conformidade com as exigências do Gmail, Yahoo e Outlook
• Você protege seus clientes de ataques de phishing que usam o seu nome

Em um cenário onde 70% dos domínios da internet ainda estão sem proteção real, configurar SPF, DKIM e DMARC é uma das ações de maior retorno que um dono de site pode tomar hoje — e o custo é zero, já que a configuração é feita nos registros DNS do seu domínio.

Resumo: o que você precisa saber

Os três trabalham juntos. Ter só SPF ou só DKIM não é suficiente. E ter DMARC em p=none é quase o mesmo que não ter nada.

Se o seu domínio ainda não está protegido, o momento de agir é agora — antes que alguém use o seu nome para enganar os seus clientes.

Fontes:

EasyDMARC DMARC Adoption Report 2026;
DuoCircle — “DMARC, SPF, and DKIM in 2026”;
Microsoft Security Blog —“Email Threat Landscape Q1 2026”;
Google Sender Requirements 2024–2026;
PCI Security Standards Council — PCI DSS v4.0.

Quer configurar o e-mail profissional do seu domínio com proteção completa? A Homehost oferece hospedagem de sites com e-mail corporativo, painel cPanel e suporte técnico para configuração de SPF, DKIM e DMARC. Conheça os planos da Homehost

O post 77% dos domínios na internet ainda estão desprotegidos: o que SPF, DKIM e DMARC têm a ver com isso apareceu primeiro em Homehost.

Se você tem um site em WordPress, marque na agenda: 20 de maio de 2026 é uma data importante. É quando sai o WordPress 7.0 — a maior atualização do CMS mais popular do mundo desde a chegada do editor de blocos em 2018.

Mas antes de sair clicando em “Atualizar”, vale entender o que muda — e o que você precisa verificar na sua hospedagem antes de fazer o upgrade.

O que é o WordPress 7.0?

O WordPress 7.0 é a primeira versão major de 2026 e representa a Fase 3 do projeto Gutenberg: o foco agora é em colaboração em tempo real. O objetivo é transformar o WordPress de uma ferramenta individual em uma plataforma de trabalho em equipe — algo parecido com o que o Google Docs faz há anos.

Nota: A colaboração em tempo real (co-editing) foi removida da versão 7.0 e adiada para o 7.1.

A versão foi originalmente planejada para abril, mas o time principal optou por adiar até 20 de maio para garantir a estabilidade do novo motor de colaboração. Uma boa decisão: é melhor chegar certo do que chegar rápido.

O Beta 1 (chamado de RC3 no calendário revisado) está previsto para 8 de maio de 2026 — em poucos dias. Se você quer testar antes de todo mundo, já é possível instalar via o plugin WordPress Beta Tester.

As principais novidades

Edição colaborativa em tempo real

A estrela do WordPress 7.0. Vários usuários podem editar o mesmo post ou página ao mesmo tempo, com sincronização automática. Funciona via HTTP polling por padrão, mas hospedagens com suporte a WebSockets vão oferecer uma experiência ainda mais fluida e instantânea.

Edições feitas offline são sincronizadas automaticamente quando o usuário reconecta. O sistema de Notes também ganhou sincronização em tempo real, com atalho de teclado para adicionar comentários diretamente no conteúdo.

WP AI Client — integração nativa com IA

O WordPress 7.0 não coloca uma IA genérica dentro do painel. Em vez disso, ele introduz uma API de cliente de IA (WP AI Client) que permite conectar qualquer ferramenta de IA ao seu site — OpenAI, Claude, Gemini, entre outras.

Junto com isso, vem a Abilities API, que permite que plugins registrem suas capacidades para que assistentes de IA possam reconhecê-las e utilizá-las automaticamente. Um passo importante para o futuro da automação no WordPress.

Um novo painel de Connectors (em Configurações > Connectors) centraliza todas as integrações externas de IA em um só lugar.

Novo painel administrativo — DataViews

O painel admin do WordPress recebe seu maior redesign em anos. O tradicional WP List Tables é substituído pelo DataViews, uma interface moderna com filtragem, ordenação, agrupamento e navegação sem recarregar a página — tudo mais fluido e com transições animadas usando a CSS View Transitions API.

Novos blocos e melhorias no editor

Bloco Breadcrumbs — nativo, sem precisar de plugin
Bloco Icons — biblioteca de ícones integrada ao editor
Cover block — com vídeo embutido como fundo
Grid block — agora responsivo e adaptável automaticamente
Gallery block — com suporte a lightbox nativo
Blocos podem ser configurados para aparecer ou sumir conforme o tamanho da tela
Processamento de imagens (redimensionamento e compressão) agora ocorre no navegador, reduzindo carga no servidor

Melhorias para desenvolvedores

Suporte a blocos em PHP puro — sem precisar de JavaScript
Campo de pesquisa melhorado no painel (mostra configurações relacionadas, não só nomes de ferramentas) Roundcube (webmail) atualizado
Softaculous com criação de ambientes de staging com um clique

O que muda na sua hospedagem?

Requisitos de PHP atualizados

O WordPress 7.0 encerra o suporte para PHP 7.2 e 7.3. O mínimo agora é PHP 7.4, e a recomendação oficial é PHP 8.3 ou superior para melhor desempenho e segurança.

O que fazer: verifique no seu cPanel a versão de PHP que está rodando. Se estiver abaixo do 7.4, é hora de atualizar antes de fazer o upgrade do WordPress.

Na Homehost, você pode verificar e trocar a versão do PHP diretamente pelo cPanel, em MultiPHP Manager — sem precisar contatar o suporte.

Colaboração em tempo real precisa de infraestrutura moderna

O motor de co-edição funciona via HTTP polling por padrão, o que roda em qualquer hospedagem compatível. Mas para a experiência ideal — colaboração sem delay — o ideal é uma hospedagem que suporte WebSockets.

Os planos da Homehost estão preparados para o WordPress 7.0. Nossos servidores com LiteSpeed + NVMe garantem o desempenho necessário para os novos recursos, especialmente o processamento de imagens no servidor e a sincronização de conteúdo colaborativo.

Quando devo atualizar?

Siga este checklist antes de atualizar para o WordPress 7.0:

• Verifique a versão de PHP — deve ser 7.4 ou superior (recomendado: 8.3)
• Faça um backup completo do site antes de qualquer atualização
• Teste em ambiente staging — crie uma cópia do site para testar o WordPress 7.0 antes de aplicar em produção
• Verifique compatibilidade dos plugins — especialmente os que dependem do editor ou da área administrativa
• Atenção a metaboxes personalizados — a edição colaborativa é desativada automaticamente em posts com metaboxes ativos
• Atualize seu tema — o novo editor iframed pode renderizar estilos de forma diferente

Recomendação: aguarde pelo menos 1 a 2 semanas após o lançamento de 20 de maio de 2026 antes de atualizar em sites de produção. Esse período é suficiente para que os principais plugins lancem suas atualizações de compatibilidade.

Por que isso importa para o seu site?

O WordPress alimenta mais de 40% de todos os sites na internet. A versão 7.0 sinaliza uma evolução importante: o CMS está deixando de ser uma ferramenta de uso individual para se tornar uma plataforma de colaboração de times — com suporte nativo a IA por cima.

Para agências digitais, freelancers e empresas que gerenciam conteúdo em equipe, essa é a atualização mais relevante em anos.

Sua hospedagem está pronta?

O WordPress 7.0 exige uma hospedagem moderna — com PHP 8.3, suporte a WebSockets, boa performance de servidor e backups automatizados.

Na Homehost, todos os planos já rodam com:

• PHP 8.3 disponível via MultiPHP Manager
• Servidores LiteSpeed + NVMe — mais rápidos que Apache convencional
• HTTP/3 e CloudFlare CDN em todos os planos
• Backup automático incluído
• Migração gratuita — sites e e-mails

Se você está em uma hospedagem WordPress antiga e quer garantir que seu site funcione 100% com o WordPress 7.0, fale com a gente pelo WhatsApp ou veja nossos planos de hospedagem WordPress.

O post WordPress 7.0 está chegando: o que muda para quem tem site hospedado? apareceu primeiro em Homehost.

No dia 29 de abril de 2026, o mundo da segurança digital foi abalado pela divulgação de uma das vulnerabilidades mais graves já encontradas no kernel Linux: a CVE-2026-31431, apelidada de “Copy Fail”. Em menos de 24 horas, especialistas de todo o mundo já a comparavam às piores falhas da história — e com razão.

Neste artigo, explicamos o que aconteceu, por que isso é tão sério, e o que a HomeHost fez imediatamente para proteger todos os seus clientes.

O impacto no mundo

O alcance da Copy Fail é difícil de exagerar. A falha ficou escondida no kernel Linux por quase nove anos — desde 2017 — e nesse período afetou silenciosamente todas as principais distribuições Linux do planeta: Ubuntu, Red Hat Enterprise Linux, Amazon Linux, Debian, SUSE, Fedora, Arch Linux e dezenas de outras.

A vulnerabilidade impactou uma parcela significativa de toda a infraestrutura cloud Linux do mundo e milhões de clusters Kubernetes. Na prática, isso significa servidores de empresas, bancos, e-commerces, plataformas de streaming, sistemas de saúde e governos — qualquer organização que use Linux, ou seja, a esmagadora maioria da internet global.

A CISA adicionou a CVE-2026-31431 imediatamente ao seu catálogo de vulnerabilidades exploradas conhecidas, e o CERT-EU emitiu alerta de emergência para toda a União Europeia.

O exploit já estava disponível publicamente — um script de apenas 732 bytes, funcional sem modificações em qualquer distribuição afetada — colocando uma corrida contra o tempo em andamento: de um lado, administradores de sistemas ao redor do mundo tentando aplicar patches o mais rápido possível; do outro, agentes maliciosos com uma ferramenta pronta para uso nas mãos.

O setor de hospedagem de sites foi um dos mais atingidos, dado que servidores compartilhados concentram múltiplos clientes no mesmo kernel vulnerável.

O que é a Copy Fail?

A Copy Fail é uma falha no nível do kernel do sistema operacional Linux — a camada mais profunda e privilegiada do sistema. Especificamente, o problema está no módulo algif_aead, parte da API criptográfica do kernel (AF_ALG), introduzido por uma otimização de código feita em 2017.

O que torna essa vulnerabilidade excepcional é sua combinação devastadora de características:

• Universal: afeta todos os kernels Linux desde a versão 4.14 (lançada em 2017) até versões recentes não corrigidas — praticamente todo servidor Linux ativo no mundo estava vulnerável.
• Confiável: diferente de outras falhas históricas como a Dirty Cow (CVE-2016-5195) ou a Dirty Pipe (CVE-2022-0847), a Copy Fail não depende de condições de corrida, tentativas múltiplas ou configurações específicas. Ela funciona de forma determinística — sempre.
• Minúscula: o exploit completo cabe em 732 bytes de Python. Qualquer usuário sem privilégios pode executá-lo com facilidade.
• Furtiva: a escrita maliciosa bypassa o caminho normal do sistema de arquivos, sem deixar rastros convencionais nos logs.

Em termos práticos: qualquer usuário comum com acesso a um servidor vulnerável consegue escalar seus privilégios para root — o nível máximo de controle do sistema — em questão de segundos.

Por que isso afeta servidores de hospedagem de sites?

Todo servidor de hospedagem web profissional roda Linux. Sem exceção.

Sistemas como Ubuntu, Amazon Linux, Red Hat Enterprise Linux (RHEL), Debian, SUSE e CentOS — todos foram confirmados como vulneráveis. Isso significa que virtualmente 100% dos servidores de hospedagem compartilhada no mundo estavam expostos.

O cenário mais crítico em hospedagem é o de ambientes multi-tenant — ou seja, servidores onde múltiplos clientes compartilham a mesma máquina. Nesse contexto, a Copy Fail abre a possibilidade de:

• Um usuário de um site acessar arquivos e dados de outros clientes no mesmo servidor
• Obter controle total sobre o servidor, incluindo senhas, bancos de dados e e-mails
• Escapar de contêineres e ambientes isolados
• Comprometer toda a cadeia de clientes hospedados na mesma infraestrutura

A gravidade foi reconhecida globalmente: a vulnerabilidade recebeu pontuação CVSS 7.8 (Alta) e foi adicionada ao catálogo de vulnerabilidades exploradas conhecidas da CISA (agência americana de segurança cibernética). O Microsoft Defender Security, o CERT-EU e a Ubuntu Security Team emitiram alertas imediatos.

Como a HomeHost respondeu

Assim que a vulnerabilidade foi divulgada, nossa equipe técnica entrou em ação imediatamente.

Em poucas horas após a divulgação pública, a HomeHost:

1. Identificou todos os servidores afetados em nossa infraestrutura, mapeando as versões de kernel em execução.
2. Aplicou a mitigação emergencial — desabilitando o módulo algif_aead nos servidores, fechando o vetor de ataque enquanto os patches definitivos ainda estavam sendo preparados pelos fornecedores de distribuição.
3. Monitorou ativamente sinais de exploração, utilizando regras de detecção específicas para a Copy Fail.
4. Realizou a atualização completa do kernel assim que os patches de produção foram disponibilizados pelas distribuições, com reinicialização controlada dos servidores.
5. Verificou a integridade dos sistemas pós-atualização para confirmar a correção efetiva.

Nosso compromisso sempre foi — e continuará sendo — agir antes que nossos clientes precisem se preocupar. Segurança não é opcional: é a fundação de tudo o que fazemos.

O que administradores de servidores devem fazer agora

Se você administra servidores Linux, independentemente da distribuição, a ação é urgente.

Passo 1 — Verifique se seu servidor está vulnerável

Execute no terminal:

uname -r

Kernels entre 4.14 e 6.18.21 (ou 6.19.11) são vulneráveis. Consulte o tracker de segurança da sua distribuição para a versão corrigida exata.

Passo 2 — Aplique a mitigação imediata (se ainda não atualizou)

Desabilite o módulo afetado:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || true

Esta mitigação não afeta SSL/TLS, SSH, LUKS, IPsec ou OpenSSL padrão.

Nota – Esta solução só funciona quando o algif_aead foi compilado no kernel como módulo. Para kernels que foram compilados “builtin”, a solução seria diferente. Use o comando a seguir para desativar o módulo:

grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
reboot

Passo 3 — Atualize o kernel

Para sistemas baseados em RHEL/AlmaLinux/CloudLinux:

sudo dnf clean metadata && sudo dnf upgrade 
sudo reboot

Para sistemas baseados em Debian/Ubuntu:

sudo apt update && sudo apt upgrade linux-image-generic 
sudo reboot

Passo 4 — Confirme a correção

Após reiniciar, verifique se o kernel atualizado está em execução:

uname -r

Compare com a versão corrigida indicada pelo fornecedor da sua distribuição.

Conclusão

A Copy Fail é um marco na história da segurança Linux. Uma falha introduzida em 2017, presente em praticamente todos os servidores do mundo, explorável com menos de 800 bytes de código — e encontrada, ironicamente, por uma inteligência artificial em aproximadamente uma hora de análise.

Isso muda o paradigma de segurança em infraestrutura web. A velocidade com que vulnerabilidades podem ser descobertas — e exploradas — exige que provedores de hospedagem tenham processos de resposta imediatos. Na HomeHost, foi exatamente o que aconteceu.

Se você ainda não atualizou seus servidores, faça isso agora. E se preferir contar com uma infraestrutura onde essa responsabilidade já está sendo gerenciada para você, conheça os planos da HomeHost.

Referências técnicas:

• Divulgação original — Xint Code / Theori
• Aviso Ubuntu Security
• Aviso CERT-EU
• Blog Microsoft Defender
• AlmaLinux — Patches liberados
• CloudLinux — Mitigação e patches

A HomeHost monitora continuamente ameaças de segurança e atua proativamente na proteção da infraestrutura de todos os seus clientes. Dúvidas? Entre em contato com nosso suporte técnico.

O post Copy Fail (CVE-2026-31431): A Vulnerabilidade Mais Grave da História do Linux apareceu primeiro em Homehost.