Defaults.Exposed › Correções › Guides

Configurar Email num Domínio Novo: A Lista de Verificação de SPF, DKIM e DMARC em 20 Minutos (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

Um domínio novo precisa de quatro coisas antes do primeiro email: uma verificação de base, um registo SPF nomeando o seu fornecedor real, assinatura DKIM de domínio personalizado, e um registo DMARC com relatórios ativados desde o primeiro dia. A maioria dos domínios nunca lá chega — 46,4% (121.145.609 de 261.086.232 domínios classificados) não têm SPF nenhum, segundo o censo do Defaults.Exposed (a 2026-06-29).

Publicar tudo demora cerca de 20 minutos: verifique para obter uma base, adicione um registo SPF, ative o DKIM de domínio personalizado do seu fornecedor, publique DMARC p=none com um endereço de relatórios, opcionalmente adicione MTA-STS, depois volte a verificar e guarde o relatório. O que demora mais é o que nenhuma lista de verificação consegue apressar — a propagação de DNS e a reputação de envio — e este guia é honesto sobre ambos.

20 minutos chegam mesmo?

Para publicar os registos, sim — cada passo abaixo é uma entrada de DNS mais uns cliques na consola de administração do seu fornecedor. Duas coisas demoram mais, e fingir o contrário é como os domínios novos acabam em spam:

• Propagação. Os registos novos normalmente resolvem em minutos, mas os resolvedores fazem cache conforme o TTL, e um domínio recém-delegado pode demorar horas a responder de forma consistente. Verifique com dig; não edite em pânico enquanto as caches se atualizam.
• Aquecimento. Um domínio novo tem reputação de envio zero, e a autenticação é a pré-condição da reputação, não um substituto. Comece com volume baixo, à escala humana, e aumente gradualmente ao longo de semanas.

A afirmação honesta: 20 minutos compram autenticação publicada corretamente. As semanas seguintes de envio sensato compram entregabilidade.

A lista de verificação de 20 minutos

1. Execute primeiro a verificação gratuita em defaults.exposed. Verifique o domínio novo antes de tocar no DNS. A base classificada de “nada configurado” leva segundos a captar e torna o relatório posterior significativo — vai querer o par de antes-e-depois (passo 6).
2. Publique um registo SPF para o seu fornecedor real. Exatamente um registo TXT começando por v=spf1, contendo o include do seu fornecedor — por exemplo v=spf1 include:_spf.google.com ~all para o Google Workspace, ou include:spf.protection.outlook.com para o Microsoft 365; se o seu DNS vive no painel de um registrador, o guia do GoDaddy cobre as particularidades da interface. Apenas um registo: dois registos v=spf1 são um erro permanente que anula o SPF por completo — o estado em que 1.013.416 domínios estão presos, cerca de um em 138 dos domínios que tentam SPF (censo a 2026-06-29), normalmente um resíduo de migração. Não adicione includes “por precaução”: o SPF limita as consultas de DNS a 10, e pelo menos 797.263 domínios já anularam o seu registo por ultrapassar esse teto. E saiba o que o SPF realmente verifica: os recetores avaliam-no contra o domínio do Return-Path (RFC5321.MailFrom) — o endereço de devolução — não o cabeçalho From que os seus destinatários veem.
3. Ative a assinatura DKIM de domínio personalizado. O seu fornecedor assina o correio de qualquer forma; a questão é que domínio a assinatura nomeia. Até completar este passo, o Google Workspace assina com a sua predefinição gappssmtp.com e o Microsoft 365 com onmicrosoft.com — assinaturas que passam o DKIM mas não alinham com o seu domínio, portanto o DMARC continua a falhar. Gere a chave na consola de administração e publique o que o fornecedor lhe der: um registo TXT de 2048 bits para a Google, dois CNAMEs (selector1/selector2) para o Microsoft 365. Se um registo não couber no seu painel de DNS, veja corrigir o DKIM — chaves longas estropiadas pelas interfaces são um clássico.
4. Publique o DMARC desde o primeiro dia — p=none com um endereço de relatórios. Um registo TXT em _dmarc.oseudominio.com: v=DMARC1; p=none; rua=mailto:[email protected]. Seja claro sobre o que isto faz: p=none ainda não protege nada — é modo de monitorização. Mas não custa nada, e os relatórios agregados passam a cobrir o histórico de envio do seu domínio desde a primeiríssima mensagem. Os domínios estabelecidos gastam semanas de relatórios só para descobrir remetentes que se esqueceram que tinham; você está a comprar essa visibilidade de graça, desde o dia zero. Veja corrigir o DMARC para a anatomia do registo.
5. Opcional mas barato num domínio novo: MTA-STS e TLS-RPT. O MTA-STS diz aos servidores de envio que o seu domínio exige TLS para correio de entrada (um registo DNS mais um pequeno ficheiro de política alojado); o TLS-RPT reporta falhas de encriptação na entrega. Num domínio estabelecido, estes exigem cuidado; num domínio novo com um único fornecedor de correio não há nada para partir, e mode: testing é essencialmente sem risco. Configure-os agora ou salte-os — mas decida, não deixe andar.
6. Volte a verificar e guarde o relatório. Execute a verificação outra vez — SPF, DKIM e DMARC deviam mostrar todos verde. Guarde o relatório classificado: prova datada do estado do domínio no lançamento, e exatamente o que um questionário de seguradora ou de cliente vai pedir.

Quantos domínios completam mesmo esta lista de verificação?

Muito poucos — e a maioria falha logo no primeiro obstáculo. Dos 261.086.232 domínios classificados no censo do Defaults.Exposed (a 2026-06-29):

Os 20 minutos que esta página descreve colocam um domínio novo à frente de cerca de 96% da internet na tríade completa. O modelo de maturidade de adoção do SPF detalha cada degrau dessa escada.

Com que rapidez um domínio novo pode chegar a p=reject?

Semanas, não meses — a vantagem genuína de começar do zero. O que torna a aplicação do DMARC lenta em domínios estabelecidos é o legado: o conector de CRM esquecido, a ferramenta de faturação que alguém ligou em 2019, a plataforma de newsletter que ninguém documentou. Cada um tem de ser encontrado nos relatórios e corrigido antes de a política poder apertar — daí o lançamento normal de meses.

Um domínio novo não tem remetentes de legado: você configurou todas as origens de envio, esta semana, e os relatórios do passo 4 vão confirmá-lo. Corra p=none durante duas a quatro semanas de envio real, verifique que os relatórios cobrem tudo o que realmente usa (caixas de correio, faturas, recibos, o formulário de contacto do site), depois passe a p=quarantine e a p=reject assim que estiverem limpos. A mecânica faseada — rampas de pct, política de subdomínio, o que vigiar — está em de p=none a p=reject; num domínio novo percorrerá esses passos em velocidade, até um sítio a que só 10,59% dos domínios classificados chegaram.

E o domínio antigo que está a substituir?

Se este domínio novo faz parte de um rebranding, o domínio que está a deixar para trás é agora o seu maior risco de email: continua seu, continua a ser confiado por contrapartes, já não é vigiado. Não o abandone — tranque-o explicitamente. É um trabalho curto à parte: aquele domínio antigo do seu rebranding é uma porta que deixou aberta.

Perguntas frequentes

Posso publicar estes registos antes de escolher um fornecedor de correio? DMARC, sim — p=none com rua é independente do fornecedor, portanto publique-o no dia em que registar o domínio. O SPF precisa do include do seu fornecedor; até escolher um, publique v=spf1 -all (nada está autorizado a enviar) e substitua-o no passo 2. Isso é estritamente melhor do que o estado sem registo em que 121.145.609 domínios se encontram (46,4% de 261.086.232 classificados, a 2026-06-29).

Preciso de DKIM se o SPF já passa? Sim. O SPF quebra-se com o reencaminhamento por design, e valida o domínio do Return-Path, que para muitas ferramentas não é o seu — o DKIM alinhado é a verificação que sobrevive a ambos. Só 3,87% dos domínios classificados completam a tríade completa de SPF+DKIM+DMARC aplicado (censo a 2026-06-29); o DKIM é o passo que a maioria dos desistentes salta. Comece em corrigir o DKIM se a verificação o assinalar.

Um domínio novo deve usar ~all ou -all? Num domínio estabelecido, ~all é a escolha cautelosa enquanto encontra remetentes esquecidos. Um domínio novo não tem nenhum para encontrar: assim que o include do seu fornecedor estiver em vigor e o DKIM estiver a assinar, -all é seguro muito mais cedo. Quer cinto e suspensórios? Confirme primeiro com duas semanas limpas de relatórios DMARC.

Os três registos passam — porque é que o meu correio ainda vai para spam? Porque autenticação e reputação são coisas diferentes: registos a passar significam que os recetores conseguem verificar que o correio é seu, não que já confiam em si. Os domínios novos ganham confiança enviando correio consistente, desejado, de baixo volume, e aumentando gradualmente. Se o correio está a falhar verificações em vez de apenas cair em spam, comece em corrigir o SPF e percorra os resultados da verificação.

Envie o relatório ao proprietário

Se está a configurar este domínio para um cliente, feche o trabalho com evidência. Volte a executar a verificação gratuita depois do passo 6 e reencaminhe o relatório classificado ao dono do negócio: SPF, DKIM e DMARC a passar, em linguagem simples, datado no lançamento. É o artefacto de que vão precisar para a renovação do seguro cibernético e o próximo questionário de segurança de fornecedores — e prova que o domínio começou a vida da forma que 96% da internet nunca consegue.

Verifique o seu domínio → · De p=none a p=reject sem perder email legítimo → · Apenas dados agregados. Dados armazenados e processados na UE.