BrowserTools
Início / Geradores / Gerador de SPF e DMARC

Gerador de SPF e DMARC

Cria os registos DNS que impedem outros de enviar email em teu nome, ou verifica um que já tenhas.

Mantido por BrowserTools · Última atualização 2026-09-29

A carregar Gerador de SPF e DMARC… Se nada acontecer, ativa o JavaScript.

Qualquer pessoa pode pôr o teu endereço na linha De de um email. O SPF e o DMARC são os dois registos DNS que permitem aos servidores de correio distinguir o email verdadeiro das falsificações. O SPF (Sender Policy Framework) é um registo TXT no teu domínio que lista os servidores autorizados a enviar em nome dele: o teu fornecedor de email, o serviço de newsletters, o teu próprio servidor. O DMARC assenta nele, em _dmarc.oteudominio, e diz aos destinatários o que fazer com o correio que falha as verificações (entregar, mandar para o spam ou rejeitar) e para onde enviar relatórios sobre isso. O Gmail, o Yahoo e a Microsoft já exigem ambos a quem envia em grande volume, e sem eles o teu correio legítimo tem mais probabilidade de cair no spam enquanto o falsificado passa.

Perguntas frequentes

Onde adiciono estes registos?
Nas definições DNS da empresa que aloja o DNS do teu domínio, normalmente o registador ou um serviço como a Cloudflare. Cria um registo TXT. Para o SPF, o host é o próprio domínio, muitas vezes escrito como @. Para o DMARC, o host é _dmarc, que alguns painéis querem como _dmarc.exemplo.com e outros apenas como _dmarc, porque acrescentam o domínio sozinhos. As alterações costumam entrar em vigor entre alguns minutos e algumas horas, conforme o TTL.
Qual é a diferença entre ~all e -all?
Ambos fecham a lista de remetentes autorizados. Com ~all (falha suave), o correio de servidores não listados é aceite mas tratado como suspeito, o que normalmente significa a pasta de spam. Com -all (falha definitiva), os destinatários podem rejeitá-lo logo. O ~all é o início mais seguro enquanto ainda estás a descobrir todos os serviços que enviam por ti. Depois de teres DKIM e DMARC, o -all é uma boa escolha, e a Microsoft recomenda-o para domínios do Microsoft 365. O ?all não dá proteção nenhuma e o +all autoriza a internet inteira, por isso evita ambos.
Porque é que o SPF tem um limite de 10 consultas DNS?
Verificar um registo SPF pode obrigar o destinatário a consultar o DNS vezes sem conta, por isso o RFC 7208 limita a 10 por verificação os mecanismos que precisam de uma consulta (include, a, mx, ptr, exists e redirect), contando também tudo o que está dentro de includes encadeados. Ultrapassar o limite é um erro permanente e o SPF falha para todo o teu correio. Esta ferramenta conta as consultas escritas diretamente no teu registo. Não consegue ver o interior dos registos incluídos sem consultas DNS reais, e alguns usam várias consultas sozinhos, por isso deixa margem. Se ficares sem espaço, passa um serviço para um subdomínio ou troca um include pelos intervalos de IP publicados.
Posso ter dois registos SPF?
Não. Um domínio ou subdomínio tem de publicar exatamente um registo TXT que comece por v=spf1. Se houver dois, os destinatários devolvem um erro permanente e o SPF falha para tudo, um engano comum depois de adicionar um serviço novo. Junta-os: mantém um único v=spf1 no início, coloca todos os termos ip4, ip6 e include no meio e termina com um só all.
E o DKIM?
O DKIM acrescenta uma assinatura criptográfica a cada mensagem enviada, e a chave pública correspondente é publicada no DNS sob um seletor, como selector1._domainkey.exemplo.com. O par de chaves é criado por quem assina o teu correio, por isso não consegues gerar sozinho um registo DKIM útil: ativa o DKIM na consola de administração do teu fornecedor (Google Workspace, Microsoft 365, SendGrid e outros) e publica os registos TXT ou CNAME que ele te der. O DKIM é importante porque sobrevive ao reencaminhamento, onde o SPF costuma falhar, e o DMARC passa se qualquer um dos dois estiver alinhado com o teu domínio De.
Com que política DMARC devo começar?
Começa com p=none e um endereço rua. Nada muda para o teu correio, mas os destinatários passam a enviar relatórios agregados diários com todos os servidores que enviam em nome do teu domínio e se passaram ou não. Ao fim de duas a quatro semanas, corrige o SPF ou o DKIM de qualquer remetente legítimo que falhe, passa a p=quarantine e mais tarde a p=reject. Ficar em p=none para sempre não protege nada: apenas observa.
O que mudou com o RFC 9989?
Em maio de 2026 o IETF publicou o RFC 9989, que substitui o RFC 7489 como norma DMARC, juntamente com os RFC 9990 e 9991 para os relatórios. Remove as etiquetas pct, ri e rf, acrescenta t=y como modo de teste simples e np para subdomínios que não existem, e integra a etiqueta psd usada pelos operadores de sufixos públicos. Os registos existentes continuam a funcionar e muitos destinatários ainda respeitam o pct, por isso esta ferramenta mantém pct e ri como opções antigas facultativas.
Porque é que os relatórios enviados para outro domínio precisam de um registo extra?
Para impedir que alguém aponte relatórios DMARC para uma caixa de correio que não é sua, os destinatários verificam se o destino aceita recebê-los. Se o teu registo de exemplo.com envia relatórios para reports@dmarc-service.net, esse serviço tem de publicar um registo TXT em exemplo.com._report._dmarc.dmarc-service.net com v=DMARC1. Os serviços de relatórios tratam disto quando adicionas o teu domínio, mas uma caixa noutro domínio teu também precisa dele.
Esta ferramenta consulta o meu domínio?
Não. Os registos são criados e verificados inteiramente no teu navegador e nada do que escreves é enviado para lado nenhum. Isso também significa que não consegue ver o que está publicado neste momento nem resolver includes encadeados. Usa a ferramenta DNS Lookup para obter os registos TXT reais do teu domínio e de _dmarc.oteudominio e depois cola-os no verificador.

Sobre Gerador de SPF e DMARC

O construtor de SPF deixa-te marcar os serviços que usas (Google Workspace, Microsoft 365, Zoho Mail, Amazon SES, SendGrid, Mailgun e Mailchimp Transactional, com os valores include retirados da documentação de cada fornecedor), juntar os teus endereços IPv4 e IPv6 e escolher quão rigoroso deve ser o all final. Vai contando as consultas DNS, porque o SPF deixa de funcionar acima de 10, e divide o valor em cadeias de 255 caracteres quando um registo longo o exige. O verificador pega num registo existente e explica cada termo em linguagem simples. Assinala erros de sintaxe como include= em vez de include:, um espaço depois dos dois pontos ou ipv4: em vez de ip4:, e avisa sobre um segundo registo SPF no mesmo domínio, o mecanismo ptr obsoleto, o perigoso +all, termos colocados depois do all e registos tão longos que falham por UDP.

O construtor de DMARC segue a implementação gradual que evita perder correio: começa com p=none e um endereço para relatórios, lê os relatórios durante algumas semanas para encontrar todos os serviços que enviam em teu nome, depois passa a quarantine e por fim a reject. Cobre as políticas para subdomínios e para subdomínios inexistentes, o alinhamento estrito ou flexível, as opções de relatórios de falhas e o modo de teste do RFC 9989, a norma DMARC atualizada publicada em maio de 2026, e mantém as etiquetas antigas pct e ri para os destinatários que ainda as usam. Os dois separadores mostram o nome de host exato e o valor TXT com botões para copiar. Tudo é calculado no teu navegador e não são feitas consultas DNS, por isso, para comparar com o que um domínio publica hoje, obtém os registos TXT com a ferramenta DNS Lookup e cola-os no verificador.

O SPF nasceu para travar o spam devolvido

No início dos anos 2000, os spammers falsificavam por rotina o remetente de envelope das mensagens, e as devoluções de milhões de spams impossíveis de entregar iam parar às caixas de donos de domínios inocentes. Várias propostas tentaram resolver isto, incluindo o Reverse MX e o Designated Mailers Protocol, e em 2003 Meng Weng Wong juntou ideias delas no Sender Permitted From, pouco depois rebatizado Sender Policy Framework. A Microsoft promoveu um rival chamado Sender ID, e os dois foram publicados lado a lado como experiências em 2006. O SPF venceu: tornou-se norma proposta como RFC 7208 em 2014, enquanto o Sender ID e os seus registos spf2.0 caíram no esquecimento.

Sozinho, o SPF tinha uma falha, porque verifica o endereço de envelope escondido e não a linha De que as pessoas realmente veem. Em 2012 um grupo que incluía o PayPal, a Google, a Microsoft e o Yahoo publicou o DMARC, que liga os resultados de SPF e DKIM ao domínio De visível e acrescenta relatórios. O PayPal tinha boas razões para isso: era uma das marcas mais usadas em phishing na internet. O DMARC passou anos como documento informativo, o RFC 7489, até que o RFC 9989 o colocou no caminho de normas do IETF em 2026.

Ferramentas relacionadas

Consulta DNS

Vê os registos DNS de qualquer domínio, como o endereço IP, os servidores de e-mail e os registos TXT.

Pesquisa WHOIS

Vê quem registou um domínio, quando expira e que registrador usa.

Analisador de URL

Divide um endereço web nas suas partes: domínio, caminho, parâmetros e mais.

Gerador de UUID

Cria identificadores únicos (UUID), um a um ou em lote.
Apoiar