SPF na prática: identificar todos os remetentes

Módulo 4: Capacidade de entrega: SPF, DKIM e DMARC na prática · Tempo de leitura: 12 minutos

Objetivo de aprendizagem: Depois desta lição, saberá identificar todos os serviços que enviam correio em nome do seu domínio, reuni-los num único registo SPF, contar as pesquisas recursivamente até ao limite de dez, e escolher conscientemente entre ~all e -all.

Conceitos-chave: inventário de remetentes, remetente do envelope (Return-Path), um único registo SPF, include, redirect, limite de 10 pesquisas DNS (RFC 7208 secção 4.6.4), pesquisas vazias (void lookups, no máximo 2), contagem recursiva, permerror, flattening, SPF para subdomínios, SPF num domínio que não envia correio, ~all e -all

Uma breve recapitulação

Um registo SPF é um registo TXT no seu domínio que começa por v=spf1 e enumera quais os servidores que podem enviar correio em nome do seu domínio. A estrutura, os caracteres + - ~ ? e os três erros mais comuns (dois registos, +all, mais de dez pesquisas) estão explicados no curso de DNS, lição 4.3. Leia essa lição primeiro se o SPF for novidade para si. Esta lição trata da parte mais difícil: na prática, quase ninguém sabe exatamente quem envia correio em nome do seu domínio.

Passo 1: o inventário

O SPF só funciona se todos os remetentes estiverem incluídos. Se se esquecer de um, esse correio acaba no spam ou é rejeitado assim que reforçar o DMARC. Percorra, por isso, esta lista. Numa empresa pequena típica, encontrará rapidamente cinco ou seis:

Duas boas formas de os encontrar:

1. Ler os cabeçalhos. Envie a partir de cada sistema uma mensagem para si próprio (uma fatura, uma recuperação de palavra-passe, uma newsletter de teste) e verifique nos cabeçalhos o Return-Path e o Authentication-Results (lição 1.5). Aí verá através de que domínio e que servidor a mensagem chegou.
2. Relatórios DMARC. Configure o DMARC com p=none e um endereço de relatório (lição 4.4). Ao fim de algumas semanas, verá nos relatórios (lição 4.5) todos os servidores que enviaram correio em nome do seu domínio, incluindo os que tinha esquecido. É o inventário mais fiável.

Nem todos os serviços pertencem ao seu SPF

É aqui que muitas vezes correm mal as coisas. O SPF verifica o remetente do envelope (o Return-Path), não o endereço De. Muitos serviços de newsletter e de envio utilizam um Return-Path no seu próprio domínio, por exemplo bounce-123@mail.mailer.example. O destinatário verifica então o registo SPF de mailer.example, não o seu. Um include desse serviço no seu registo não tem, nesse caso, qualquer efeito, além de custar uma pesquisa.

O que esse serviço realmente precisa para passar no DMARC é uma assinatura DKIM com o seu domínio (lição 4.3), ou um subdomínio de Return-Path seu (por exemplo bounce.example.com como CNAME para o serviço). Leia, por isso, no manual do serviço o que este pede. Se disser "coloque include: no seu SPF", faça-o. Se disser apenas "crie estes registos CNAME para o DKIM e o domínio de bounce", então não é necessário alterar nada no seu registo principal. O módulo 7 aprofunda este tema.

Passo 2: um único registo, e contar bem

Todos os remetentes entram num único registo. Suponha que o seu inventário resulta no seguinte: o servidor de correio da sua empresa de alojamento, Microsoft 365 para alguns colaboradores, o seu programa de contabilidade e um helpdesk. O registo fica então, por exemplo:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Quantas pesquisas são estas? Conte cada a, mx, include, exists, ptr e redirect, e conte depois também tudo o que consta nos registos por detrás de cada include:

A partir de 11, o destinatário devolve um permerror: todo o registo SPF deixa de contar, para nenhum remetente. O seu correio enviado a partir do seu próprio servidor de correio é, assim, avaliado pior porque o helpdesk custa três pesquisas. E o mais traiçoeiro é que o seu registo pode ter hoje 9 e amanhã 11, sem que o próprio altere nada, porque um serviço expandiu o seu próprio registo.

Além disso: no máximo duas pesquisas vazias

A RFC 7208 refere ainda as void lookups: pesquisas que não produzem resultado (o nome não existe, ou não tem registo SPF nem registo de endereço). Mais de duas destas situações também resulta num permerror. Isto acontece sobretudo com includes antigos de serviços que já não utiliza e que retiraram o seu registo, ou com um a: para um servidor que já não existe. Convém, por isso, fazer limpeza.

Passo 3: voltar para baixo de dez

Se estiver acima de dez, há quatro soluções, da melhor para a pior:

1. Retire o que não é necessário. Serviços que já não utiliza. Serviços que enviam com o seu próprio Return-Path (ver acima) e que, por isso, não pertencem ao seu SPF. a se o seu sítio web em si não enviar correio. mx se o seu MX apontar para um serviço que já consta no seu registo através de um include.
2. Utilize um subdomínio. Faça com que um serviço envie a partir de nieuws.example.com ou factuur.example.com. Esse subdomínio recebe um registo SPF próprio apenas com esse serviço, e não conta para o limite de dez do seu domínio principal. O alinhamento no DMARC (lição 4.4) funciona, por norma, também para subdomínios.
3. Utilize ip4: e ip6: para os seus próprios servidores fixos. Estes não custam qualquer pesquisa. Faça isto apenas para endereços que o próprio gere e que não mudam.
4. Flattening (substituir todos os includes pelos endereços IP que atualmente neles constam). Isto reduz o número para 0, mas o registo deixa de estar correto assim que um serviço alterar os seus endereços, e os grandes serviços fazem-no regularmente. Faça isto apenas com uma ferramenta que o atualize automaticamente, ou preferencialmente nunca.

redirect ou include?

redirect= significa: utilize o registo SPF desse outro domínio em vez deste registo. Custa uma pesquisa, tal como um include. É útil se tiver muitos domínios que devem ter exatamente a mesma política: v=spf1 redirect=_spf.example.com em cada domínio, e o registo real num único local. Um registo com redirect= não pode ter all, pois nesse caso o redirect é ignorado. O próprio Gmail utiliza isto: gmail.com tem v=spf1 redirect=_spf.google.com.

Passo 4: ~all ou -all?

A recomendação deste curso, em linha com o curso de DNS:

• Comece com ~all (softfail). O correio de um servidor que não conste no seu registo é considerado suspeito, mas normalmente não é rejeitado de imediato. Se se esquecer de um remetente, o dano é limitado.
• Passe para -all (fail) quando tiver a certeza de que todos os remetentes estão incluídos, por exemplo depois de ter consultado os relatórios DMARC durante algumas semanas e já não existirem fontes desconhecidas.

Com o DMARC incluído, a diferença é menor do que muitas vezes se pensa. O DMARC decide com base em "SPF ou DKIM aprovado e alinhado". Um softfail é, para o DMARC, simplesmente "não aprovado". A verdadeira proteção vem, por isso, de uma política DMARC rigorosa, não do -all. Alguns destinatários rejeitam logo com -all ainda antes da avaliação DMARC; esta é uma razão para só escolher -all quando o seu registo estiver realmente completo.

Um domínio que nunca envia correio

Tem domínios que nunca enviam correio (uma marca antiga, um domínio de erro de digitação)? Proteja-os então contra utilização indevida com:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Aqui, -all está correto desde logo: não há ninguém autorizado a enviar correio. A última linha é um null MX (RFC 7505): "este domínio não recebe correio". O próprio example.com está configurado exatamente assim.

Na prática: como se apresenta num painel

Num pacote de alojamento da WebOké está configurado por omissão v=spf1 a mx include:webawere.nl ~all. Se adicionar um serviço, ajuste esse registo (no DirectAdmin: DNS Management, o lápis junto ao registo SPF, campo Incluir domínio; no O meu WebOké: o assistente de SPF no separador DNS). Mantenha include:webawere.nl enquanto o seu correio ou sítio web passar por esses servidores. Noutros fornecedores, o include predefinido tem outro nome, mas o princípio é o mesmo: completar, não criar um segundo registo.

Resumo

• Comece por fazer um inventário de todos os remetentes; os relatórios DMARC e os cabeçalhos ajudam nessa tarefa.
• Um serviço com o seu próprio Return-Path não pertence ao seu SPF; esse precisa de DKIM com o seu domínio.
• Conte recursivamente: cada include, a, mx, exists, ptr e redirect, também dentro dos includes. Acima de dez, ou mais de duas pesquisas vazias, resulta em permerror.
• Volte para baixo de dez fazendo limpeza e utilizando subdomínios; flattening apenas com manutenção automática.
• Comece com ~all, passe para -all quando tiver a certeza. Domínios que nunca enviam correio: -all, DMARC reject e null MX.

Quiz

Exercício

Exercício Z4.2: Contar recursivamente o SPF do seu domínio. Indique o seu próprio domínio (ou sidn.nl se não tiver domínio próprio). Conte primeiro, por si próprio, quantas pesquisas DNS custa o registo SPF, incluindo tudo o que está dentro dos includes, e introduza o número, juntamente com o final do registo (~all, -all, ?all ou +all). O programa conta em tempo real e verifica, incluindo as pesquisas vazias, e mostra a árvore.

Exercício O4.2: O seu inventário de remetentes. Utilizando a tabela desta lição, elabore uma lista de todos os sistemas que enviam correio em nome do seu domínio. Indique, para cada um: através de que servidor ou serviço, se deve constar no seu SPF (Return-Path próprio ou não), e se assina com DKIM com o seu domínio. Envie, a partir de pelo menos dois sistemas, uma mensagem de teste para si próprio e anote, a partir dos cabeçalhos, o domínio do Return-Path e o domínio do DKIM (d=).

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis da WebOké; noutros fornecedores o funcionamento é semelhante.

• Curso gratuito de DNS 4.3: SPF: quem pode enviar e-mails em nome do seu domínio?
• Manual DirectAdmin 5.7: Configurar e complementar o SPF
• Como funciona o registo SPF no DNS?
• Adicionar ou alterar um registo SPF no DirectAdmin
• Manual do WebOké 5.5: Assistentes de DNS: MX, SPF, DMARC, CAA e SRV
• RFC 7208 (SPF), secção 4.6.4 (limites) e 6.1 (redirect); RFC 7505 (null MX)