Como crio um registro SPF para um domínio personalizado?

O que um registro SPF contém?

Um registro SPF é um registro TXT que começa com v=spf1 e continua com mecanismos, cada um com um qualificador opcional. A RFC 7208 define os mecanismos all, include, a, mx, ip4, ip6, exists e ptr, e o modificador redirect. O qualificador decide o resultado quando um mecanismo corresponde: + pass (o padrão), - fail, ~ softfail e ? neutral.

Para um domínio que usa um provedor de e-mail, um mecanismo faz quase todo o trabalho: include. Ele diz ao destinatário para avaliar o registro SPF do domínio do provedor e tratar uma correspondência ali como uma correspondência para o seu. Você nunca copia endereços IP à mão, então o provedor pode trocar seus servidores sem que você mexa no seu DNS. Se você envia de um servidor próprio, ip4 e ip6 listam os endereços dele e não custam nenhuma consulta.

O SPF é publicado como um registro TXT. Uma única string TXT é limitada a 255 octetos, e um registro mais longo é dividido em várias strings que o destinatário junta sem espaço. A maioria dos editores de DNS faz a divisão por você.

Por que um domínio pode ter apenas um registro SPF?

Se dois registros TXT começam com v=spf1, o destinatário não consegue escolher e retorna um erro permanente, então toda mensagem falha no SPF. A RFC 7208 afirma que um domínio não deve ter mais de um registro SPF. Proton, Mailbox.org e Mailfence dão o mesmo conselho: ao adicionar um serviço, coloque o include dele no registro que já existe.

A causa habitual é uma troca de provedor. Você publica o registro do novo provedor e esquece o antigo. Abra a lista de TXT, junte as duas linhas em uma e exclua a sobra. Quando você troca de provedor definitivamente, substitua o include antigo em vez de adicionar ao registro. A própria troca é descrita em como mover o e-mail para um novo provedor sem perder mensagens.

O que é o limite de 10 consultas do SPF?

A avaliação do SPF para com um erro permanente após 10 termos que consultam o DNS, então um registro que precisa de 11 falha para todos os remetentes. Os termos que contam são include, a, mx, ptr, exists e o modificador redirect. Os mecanismos all, ip4 e ip6 não contam. A RFC 7208 também diz que as implementações devem parar após duas consultas vazias, que não retornam nada ou um domínio inexistente.

Um include conta como uma consulta mais todas as consultas dentro do registro incluído. Um provedor de caixa de e-mail é portanto barato, mas uma pilha com um host de e-mail, um serviço de newsletter, um help desk e um formulário do site vai somando. Remova primeiro os serviços que você não usa mais. Quando uma ferramenta publica endereços IP fixos, as faixas ip4 e ip6 não custam nada. A contagem aninhada exata de cada provedor não foi medida por Postelva, então teste seu registro final com uma consulta antes de confiar nele, como mostrado em como verificar registros MX, SPF, DKIM e DMARC.

Devo terminar meu registro SPF com ~all ou -all?

Use ~all a menos que você controle todos os remetentes: ele marca outros servidores como suspeitos sem pedir aos destinatários que recusem a mensagem de imediato. O qualificador em all é o veredicto para qualquer servidor que não correspondeu a nada antes. -all significa fail, ~all significa softfail, ?all significa neutral.

Um -all rígido é mais estrito, mas a RFC 9989 alerta que ele pode fazer um destinatário rejeitar uma mensagem antes mesmo de o DMARC rodar, o que esconde uma mensagem encaminhada que o DKIM teria salvado. Por isso o registro que Proton e Mailbox.org mostram termina em ~all. Segundo a comparação de Postelva de 12 de novembro de 2026, os três provedores com um valor SPF completo em suas páginas de ajuda (Proton Mail, Mailbox.org, Fastmail) usam cada um exatamente 1 include, então um registro de um único provedor custa 1 consulta, e dois deles terminam em ~all enquanto o valor do Fastmail termina em ?all.

Seja qual for o final, é o DMARC que faz a aplicação. Defina a política lá, como explicado no guia de configuração do DMARC. Os três registros são comparados em SPF vs DKIM vs DMARC.

O que o SPF verifica e o que não verifica?

O SPF verifica o servidor por trás do remetente do envelope e o nome HELO, não o endereço From da mensagem que o leitor vê. Uma mensagem pode passar no SPF para um domínio que ninguém nota e ainda mostrar seu domínio na linha From. O DMARC fecha essa brecha exigindo o alinhamento entre os dois.

O SPF também não sobrevive ao encaminhamento simples, porque quem encaminha entrega a partir do próprio endereço IP. Uma regra prática citável: o SPF autoriza servidores, um registro por domínio, no máximo 10 consultas. Para um domínio que não envia nada, publique v=spf1 -all e o modelo "sem e-mail" de Postelva; para um domínio que envia e recebe, modelos de DNS com um clique para Proton Mail, Fastmail, Zoho Mail, Google Workspace e Microsoft 365, além de um modelo SPF + DMARC e um modelo "sem e-mail" para um domínio que não envia nada.