Como configurar SPF, DKIM e DMARC na Hostinger (guia DNS)

*# Como configurar SPF, DKIM e DMARC na Hostinger (guia DNS)

Meta descrição: Aprenda como configurar SPF, DKIM e DMARC na Hostinger para autenticar e proteger seus e-mails, melhorar entregabilidade e evitar spam.*

Configurar autenticação de e-mail no DNS parece chato (e um pouco intimidador) até você entender o objetivo: provar para o mundo que o seu domínio é realmente autorizado a enviar e-mails. É isso que SPF, DKIM e DMARC fazem juntos.

Quando você pesquisa como configurar SPF, DKIM e DMARC na Hostinger, normalmente a dor é uma destas:

• seus e-mails estão caindo no spam (ou nem chegam);
• ferramentas como Gmail, Outlook e Yahoo exibem avisos de “mensagem suspeita”;
• você quer proteger sua marca contra spoofing (alguém se passando pelo seu domínio);
• você está integrando serviços (Google Workspace, Zoho, RD Station, Mailchimp, n8n etc.) e precisa “autorizar” os envios.

A Hostinger facilita bastante porque o gerenciamento de zona DNS fica centralizado no hPanel. Ainda assim, é comum errar detalhes pequenos: colocar dois registros SPF, esquecer aspas, publicar DKIM no lugar errado, ou criar um DMARC “agressivo” sem monitorar antes.

Neste guia, você vai aprender:

• o que muda na prática ao autenticar e-mails;
• quais pré-requisitos checar antes de mexer no DNS;
• como criar e manter um registro SPF Hostinger correto;
• como ativar DKIM na Hostinger (dependendo do serviço de e-mail que você usa) e validar se está OK;
• como publicar DMARC com foco em segurança, incluindo a política DMARC p=reject Hostinger com boas práticas.

Importante: SPF/DKIM/DMARC não são “configurações do e-mail” apenas, são registros DNS do seu domínio. Depois de publicar, pode levar um tempo para “propagar” (minutos a algumas horas, dependendo do TTL e de cache).

Por que autenticar e-mails usando SPF, DKIM e DMARC na Hostinger

Autenticar e-mails é o que separa um domínio “qualquer” de um domínio que os provedores confiam. Em termos práticos, SPF, DKIM e DMARC são como um trio de segurança:

SPF (Sender Policy Framework) diz: “quais servidores estão autorizados a enviar e-mail por este domínio?”. Ele funciona por meio de um registro TXT no DNS. Quando você envia um e-mail, o servidor de destino verifica se o IP/serviço usado para envio está na lista permitida.

DKIM (DomainKeys Identified Mail) diz: “esta mensagem saiu mesmo daqui e não foi alterada no caminho”. Ele usa uma assinatura criptográfica colocada no cabeçalho do e-mail e uma chave pública publicada no DNS. Se o conteúdo for alterado (por exemplo, por um intermediário malicioso), a verificação falha.

DMARC (Domain-based Message Authentication, Reporting and Conformance) é o “gerente” dos dois: ele define o que fazer quando SPF e/ou DKIM falham e ainda habilita relatórios (úteis para você enxergar tentativas de fraude e falhas de configuração).

Na Hostinger, isso faz diferença mesmo se você só “manda e-mail de contato do site”. Um formulário de contato, uma automação de marketing, um sistema de cobrança ou um CRM podem estar enviando mensagens em seu nome. Sem autenticação:

• a entregabilidade cai (mais spam e bloqueios);
• você perde reputação do domínio (e recuperar é lento);
• fica mais fácil alguém praticar spoofing com seu domínio.

Outra vantagem muito concreta: quando você configura corretamente, alguns provedores passam a “confiar” mais na sua identidade, e isso melhora a chance de cair na caixa de entrada, principalmente em campanhas e e-mails transacionais.

Um detalhe que pega iniciantes: SPF não criptografa, DKIM não “autoriza” servidor, e DMARC não funciona sozinho. É a combinação que fecha o ciclo:

• SPF valida a origem (servidor/IP)
• DKIM valida integridade/autoria
• DMARC aplica política e dá visibilidade (relatórios)

Se você está começando agora, pense assim: SPF e DKIM são as provas; DMARC é a regra do jogo para quando alguém tentar mandar e-mail fingindo ser você.

🤖 Se você curte automação: onde SPF/DKIM/DMARC ajudam (muito) em projetos com n8n e agentes de IA

Um lugar onde essas configurações de DNS aparecem o tempo todo é em automações: envio de e-mails de alerta, confirmação, follow-up de leads, relatórios diários, etc. Se você faz isso com n8n (ou quer começar), acertar SPF/DKIM/DMARC evita que seus fluxos “funcionem” mas as mensagens simplesmente não cheguem no usuário final.

Nessa pegada, eu achei bem pé no chão a Formação Agentes de IA (n8n) da Hora de Codar: é bem prática, feita para iniciantes e vai do básico até projetos mais completos (são 11+ cursos, 221+ aulas, 20h+, com 21+ projetos, e uma comunidade grande com 8100+ alunos). Um ponto que gosto é que ela cobre também a parte de colocar o n8n em produção com domínio, SSL e boas práticas — o tipo de coisa que se conecta diretamente com o que você viu neste guia.

Se quiser dar uma olhada no conteúdo e ver se faz sentido para o seu objetivo, o link é este (vale abrir e conferir a grade): https://app.horadecodar.com.br/lp/formacao-agentes-de-ia-n8n?utm_source=blog

Pré-requisitos para configurar SPF, DKIM e DMARC na sua conta Hostinger

Antes de sair criando registros no hPanel, vale organizar duas coisas: onde seu DNS está apontado e qual serviço realmente envia seus e-mails. Isso evita o erro mais comum: publicar registros corretos, mas no lugar errado (ou no domínio errado).

1) Confirme onde o DNS do domínio está gerenciado

Se o seu domínio está usando os nameservers da Hostinger, você vai editar tudo no hPanel → Domínios → Editor de Zona DNS. Se você usa Cloudflare (ou outro provedor) para DNS, então é lá que você precisa criar os registros.

Dica rápida: se você já altera um registro no hPanel e nada muda no mundo, quase sempre é porque o DNS não está na Hostinger.

2) Identifique o(s) remetente(s)

Você precisa saber quem envia e-mail com o seu domínio. Exemplos:

• Hostinger Email / Titan / e-mail do próprio plano (dependendo do que você contratou);
• Google Workspace;
• Microsoft 365;
• Serviços de disparo (Mailchimp, RD Station, SendGrid, Amazon SES etc.);
• Seu site/servidor (PHP mail, SMTP, plugin do WordPress, aplicação própria);
• Ferramentas de automação (por exemplo, um n8n enviando via SMTP).

Isso é essencial para SPF e DMARC, porque você vai incluir no SPF apenas o que realmente envia.

3) Cheque se já existe SPF

SPF deve ser um único registro TXT por domínio (no root “@”). Se você tiver dois registros SPF, muitos provedores consideram “permerror” e isso pode piorar a entregabilidade.

4) Entenda o tempo de propagação (TTL)

Quando você altera DNS, existe cache. Então, mesmo que você “salve”, a validação pode levar um tempo. Para mudanças de e-mail, isso é normal.

5) Tenha uma ferramenta de verificação pronta

Depois de publicar, você vai querer validar. Você pode:

• enviar e-mail para você mesmo (Gmail/Outlook) e olhar “Mostrar original”/headers;
• usar um checker de SPF/DKIM/DMARC (existem vários gratuitos).

Por fim, um cuidado importante: não copie registros de outra pessoa sem adaptar. SPF especialmente é sensível: incluir serviços demais (ou errados) pode causar falhas e ainda abrir brechas para envios indevidos.

Com esses pré-requisitos em ordem, o resto vira só “publicar o TXT correto no lugar certo” — e aí sim faz sentido partir para o passo a passo.

Vídeo recomendado: instalar n8n na VPS (útil se você vai automatizar envios e precisa de domínio e DNS bem configurados)

Se você pretende usar automações (como n8n) para enviar alertas, relatórios ou e-mails transacionais, é bem comum precisar ajustar DNS, SSL e autenticação de e-mail do domínio. Este vídeo é um bom complemento para quem quer colocar o n8n no ar de forma rápida em VPS e depois cuidar das configurações do domínio com calma.

Assista aqui:

Quer seguir no embalo? Abra o vídeo e já deixa separado o hPanel da Hostinger para ir conferindo o DNS em paralelo.

Passo a passo para criar e gerenciar o registro SPF Hostinger

O objetivo do SPF é declarar, no DNS do seu domínio, quem pode enviar e-mail usando @seudominio.com. Na Hostinger, você faz isso criando (ou ajustando) um registro TXT na zona DNS.

Onde editar no hPanel

Entre no hPanel e siga um caminho parecido com:

Domínios → [seu domínio] → DNS / Editor de Zona DNS → Registros TXT

A interface pode mudar um pouco com o tempo, mas você sempre estará procurando o editor da zona DNS.

Regra de ouro: apenas 1 SPF

O SPF é um registro TXT que começa com:

v=spf1 ...

Você deve ter somente um registro TXT com v=spf1 no root do domínio (geralmente o nome/host é @). Se houver mais de um, a validação pode falhar.

Exemplo de SPF (modelo)

O SPF sempre depende do serviço que envia. A estrutura mais comum é:

v=spf1 include:SERVICO -all

• include: autoriza um provedor (que publica os IPs dele);
• -all diz “qualquer outra origem deve falhar” (mais seguro).

Se você usa mais de um serviço (ex.: Google Workspace + uma ferramenta de disparo), você combina includes no mesmo registro, por exemplo:

v=spf1 include:_spf.google.com include:outroservico.com -all

Como criar/editar na Hostinger (passo a passo)

1. No Editor de Zona DNS, encontre o registro TXT do domínio.
2. Se já existir um TXT com v=spf1, edite esse (não crie outro).
3. Preencha:

• Nome/Host: @ (ou deixe em branco, dependendo da UI)
• Tipo: TXT
• Valor: seu SPF completo (sem aspas)

1. Salve e aguarde a propagação.

Boas práticas para “manter saudável”

• Evite ultrapassar o limite de consultas DNS do SPF (muito include pode estourar o limite e gerar falhas).
• Se você parar de usar um serviço, remova o include correspondente.
• Prefira -all quando você já tem certeza dos remetentes. Se estiver migrando e quer um período de adaptação, você pode começar com ~all (softfail) e depois endurecer.

Um detalhe que ajuda muito iniciantes: SPF não resolve tudo sozinho. Se seus e-mails ainda caem no spam mesmo com SPF, normalmente falta DKIM e/ou DMARC, ou o conteúdo e reputação do domínio ainda estão “crus”. Por isso, trate SPF como a primeira peça do quebra-cabeça — importante, mas não única.

Como ativar DKIM na Hostinger e verificar a autenticação de e-mails

O DKIM é a parte “criptográfica” da autenticação: ele assina suas mensagens e permite que o destinatário verifique se aquela mensagem realmente foi emitida pelo seu domínio e se não foi alterada no caminho.

Aqui existe um ponto-chave: DKIM não é “um padrão único de registro” que você inventa. Quem gera a chave DKIM é o seu provedor de e-mail (Hostinger Email/Titan, Google Workspace, Microsoft 365, SendGrid etc.). Você pega os registros (geralmente TXT ou CNAME) fornecidos por esse serviço e publica no DNS (na Hostinger, se o DNS estiver lá).

Passo a passo (visão prática)

1) Descubra quem está enviando
Se o envio é por um provedor (ex.: Google Workspace), é ele que vai fornecer o DKIM. Se você envia por SMTP do próprio e-mail da Hostinger, o painel do e-mail costuma indicar o DKIM.

2) Gere/ative a chave DKIM no provedor
Em geral, você vai encontrar uma opção do tipo “Authenticate domain / DKIM / Domain verification”. O provedor então mostra:

• um selector (ex.: default, google, s1)
• o nome do registro (ex.: default._domainkey.seudominio.com)
• o valor (uma chave longa)

3) Publique no DNS da Hostinger
No hPanel → Editor de Zona DNS:

• crie um registro TXT (ou CNAME, dependendo do provedor)
• use exatamente o Host/Nome informado (normalmente algo como selector._domainkey)
• cole o valor do DKIM

4) Espere propagar e valide
Depois que o registro existe no DNS, volte ao provedor e clique em “Verify/Check”.

Como verificar se o DKIM está funcionando (jeito simples)

O método mais fácil é enviar um e-mail para um Gmail seu e abrir:

• Mais opções → Mostrar original

Procure por:

• DKIM: PASS

Se aparecer FAIL, geralmente é:

• DKIM publicado no DNS errado (domínio não usa nameservers da Hostinger);
• selector errado (ex.: publicou default mas o provedor assina com s1);
• registro truncado (colou incompleto) ou com caracteres extras.

“E se eu uso WordPress/site para enviar e-mail?”

Muita gente usa plugins de SMTP. Nesse caso, o DKIM vem do provedor SMTP que você configurou (por exemplo, Google Workspace ou um serviço de e-mail transacional). Vale a pena evitar envio “direto do servidor” sem autenticação, porque é uma receita comum para spam.

Quando o DKIM está correto, você costuma ver melhora rápida em entregabilidade e menos bloqueios. E, mais importante: DKIM é uma das bases para o DMARC funcionar bem, porque o DMARC depende de alinhamento e de pelo menos SPF ou DKIM passarem com consistência.

💻 VPS da Hostinger para n8n (e por que isso combina com DNS bem configurado)

Se a sua intenção é rodar automações com n8n (ou até outros serviços internos) com mais controle do que plataformas SaaS, uma VPS costuma ser o caminho natural. O legal é que a VPS da Hostinger já permite colocar o n8n no ar com instalador e depois você fica com liberdade total para integrar com SMTP, webhooks e rotinas — e aí DNS bem feito (incluindo SPF/DKIM/DMARC quando o domínio entra na história) vira parte do kit básico.

Eu iria direto na VPS da Hostinger por custo/benefício e praticidade de gerenciamento no painel (e tem 30 dias de garantia). Se quiser conferir os planos e já aplicar desconto, use este link de indicação: https://www.hostinger.com.br/horadecodar

Na hora de contratar, aplique o cupom HORADECODAR para garantir o desconto.

Configurando DMARC na Hostinger: usando política p=reject e boas práticas

DMARC é onde você decide o “nível de proteção” do seu domínio. Ele diz aos provedores: o que fazer quando uma mensagem falhar na autenticação e, de quebra, te manda relatórios.

O registro DMARC é um TXT publicado em:

_dmarc.seudominio.com

Na Hostinger, você cria isso no Editor de Zona DNS, como um registro TXT com host/nome _dmarc.

Entendendo as políticas (p=)

• p=none: só monitora (não bloqueia nem coloca em quarentena).
• p=quarantine: tende a mandar para spam/quarentena.
• p=reject: rejeita (bloqueia) a mensagem que falhar.

Quando alguém procura por política DMARC p=reject Hostinger, normalmente quer o máximo de proteção contra spoofing. Faz sentido, mas tem uma pegadinha: se SPF/DKIM não estiverem alinhados para todos os seus remetentes legítimos, você pode bloquear e-mails reais.

Uma configuração recomendada (com segurança e visibilidade)

Se você quer chegar no p=reject, o caminho mais seguro é:

1) começar com p=none por alguns dias, recebendo relatórios;
2) ajustar SPF/DKIM de todos os serviços legítimos;
3) subir para p=quarantine;
4) só então ir para p=reject.

Como você pediu foco no p=reject, aqui vai um modelo comum (ajuste os e-mails):

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100

O que cada pedaço significa, em linguagem de gente:

• rua e ruf: para onde vão relatórios agregados e forenses (nem todos os provedores enviam ruf)
• fo=1: pede relatórios quando houver falha
• adkim=s e aspf=s: alinhamento “estrito” (mais seguro)
• pct=100: aplica a política a 100% das mensagens

Se você está começando e quer reduzir risco, você pode usar alinhamento relaxado (omitir adkim/aspf) no início.

Passo a passo na Hostinger (DMARC)

1. Abra o Editor de Zona DNS.
2. Adicione registro TXT.
3. Nome/Host: _dmarc
4. Valor: o seu DMARC (como o exemplo acima)
5. Salve e aguarde a propagação.

Boas práticas para não se complicar

• Garanta que SPF e DKIM estejam corretos antes do p=reject.
• Use um e-mail que você realmente monitora em rua.
• Se você usa subdomínios para disparos (ex.: news.seudominio.com), avalie políticas separadas.

Quando DMARC está bem configurado, você ganha duas coisas ao mesmo tempo: proteção contra fraude e melhora de confiança do domínio. Para negócios, isso é ouro: menos spoofing, menos problemas de reputação e mais consistência na entrega.

O que são SPF, DKIM e DMARC e qual a importância de configurá-los na Hostinger?

SPF, DKIM e DMARC são protocolos de autenticação de e-mail que ajudam a proteger sua conta contra uso indevido e melhoram a entregabilidade das mensagens. • SPF verifica se o servidor que envia o e-mail está autorizado no domínio. • DKIM adiciona uma assinatura digital às mensagens, garantindo sua integridade. • DMARC define regras que instruem servidores de destino sobre como tratar e-mails suspeitos. Configurar esses registros no DNS da Hostinger é essencial para evitar que seus e-mails sejam marcados como spam ou rejeitados.

Como encontrar e adicionar registros SPF, DKIM e DMARC no painel DNS da Hostinger?

No painel da Hostinger, acesse a área de gerenciamento de domínios e selecione ‘Gerenciar DNS’. Lá, você pode adicionar novos registros do tipo TXT. Para cada protocolo: 1) SPF: adicione um registro TXT com o valor fornecido pelo seu provedor de e-mails. 2) DKIM: insira o nome e o valor TXT específico disponibilizado também pelo provedor de e-mails. 3) DMARC: normalmente no formato ‘_dmarc.seudominio.com’ como nome e a política desejada como valor TXT (ex: ‘v=DMARC1; p=quarantine;’). Sempre salve e aguarde até a propagação dos registros.

Após configurar SPF, DKIM e DMARC na Hostinger, como verificar se estão funcionando corretamente?

Após adicionar os registros no DNS da Hostinger, aguarde a propagação, que pode levar algumas horas. Para checar se estão corretos, utilize ferramentas online como MXToolbox ou DNS Checker. Também é possível enviar um e-mail para contas externas (Gmail, Outlook) e verificar os cabeçalhos das mensagens, onde será possível ver se SPF, DKIM e DMARC passaram nas verificações.

Conclusão

Agora você tem um caminho claro de como configurar SPF, DKIM e DMARC na Hostinger sem cair nas armadilhas clássicas (como ter dois SPF ou ativar p=reject antes de validar seus remetentes).

Recapitulando a lógica:

• comece identificando quem envia e-mail com seu domínio;
• publique um registro SPF Hostinger único e coerente com seus serviços;
• gere e publique as chaves para ativar DKIM na Hostinger (via seu provedor de e-mail);
• finalize com DMARC, de preferência evoluindo com segurança até a política DMARC p=reject Hostinger quando tudo estiver validado.

Com isso, você melhora entregabilidade, reduz spam, e protege sua marca contra spoofing — três ganhos enormes para qualquer site, loja ou projeto que depende de e-mail.

Se você fizer as alterações e algo não validar, o melhor próximo passo é: revisar se o DNS está realmente na Hostinger, checar duplicidade de SPF e confirmar se o selector do DKIM bate com o que seu provedor está assinando. Esses três pontos resolvem a maioria dos casos na prática.