SPF: quem tem o direito de enviar
O RFC 7208 parte de uma constatação: nada, no protocolo de correio eletrónico, impede um servidor de anunciar qualquer endereço de envio. O SPF permite ao proprietário de um domínio publicar no DNS a lista dos servidores autorizados a enviar em seu nome, e ao servidor que recebe verificar essa autorização.
Duas precisões mudam tudo:
- O SPF verifica o endereço de envelope (o do diálogo entre servidores, dito «MAIL FROM») e o nome anunciado pelo servidor, não o endereço que o destinatário lê em «De».
- O SPF avalia o último servidor que entregou a mensagem. Quando uma mensagem é reencaminhada por outro servidor, já não é um servidor autorizado pelo domínio de origem que a entrega: a verificação pode falhar quando a mensagem é legítima.
Um domínio só publica um registo SPF. Todas as fontes de envio têm de constar dele: correio eletrónico, programa de faturação, ferramenta de newsletters, CRM, fotocopiadora que digitaliza para o e-mail.
DKIM: a mensagem é assinada
Segundo o RFC 6376, o DKIM permite ao proprietário de um domínio signatário assumir uma parte da responsabilidade por uma mensagem, através de uma assinatura criptográfica. A chave pública está no DNS. Verificar a assinatura estabelece que as partes assinadas não mudaram desde a assinatura.
A assinatura viaja com a mensagem. Resiste, portanto, melhor do que o SPF a um reencaminhamento ou a uma retransmissão, desde que esse intermediário não altere o assunto ou o corpo. Uma lista de distribuição que acrescenta uma nota no fim da mensagem quebra-a.
O que o DKIM não faz, segundo o mesmo RFC: não encripta a mensagem, uma falha não obriga a rejeitá-la e o domínio que assina não tem de ser o que é apresentado em «De». É precisamente essa lacuna que o DMARC preenche.
DMARC: o alinhamento e a política
O RFC 7489 define o DMARC como um meio, para o proprietário de um domínio, de exprimir uma política ao nível do domínio. O mecanismo assenta no alinhamento: o domínio do endereço apresentado em «De» tem de corresponder ao domínio validado pelo SPF ou pelo DKIM. Se nenhum dos dois estiver alinhado, o DMARC falha.
O domínio publica então o que pretende:
- none: nenhuma ação pedida, apenas se observa;
- quarantine: tratar a mensagem como suspeita;
- reject: rejeitar a mensagem.
O DMARC prevê também relatórios: relatórios agregados, que resumem que servidores enviaram em nome do domínio e com que resultado, e relatórios de falha, mensagem a mensagem. São eles que permitem descobrir uma ferramenta esquecida que envia por si, ou alguém que usurpa o seu domínio.
| Mecanismo | O que verifica | O que não analisa |
|---|
| SPF | O servidor que entrega a mensagem está autorizado para o domínio de envelope | O endereço apresentado, o conteúdo |
| DKIM | A mensagem assinada não foi alterada; um domínio assume a responsabilidade por ela | O endereço apresentado, a honestidade do conteúdo |
| DMARC | O domínio apresentado está alinhado com o SPF ou o DKIM; política em caso de falha | Os domínios semelhantes, o nome de apresentação, o texto |
O DMARC bloqueia o phishing?
Bloqueia uma parte da usurpação do domínio, não o phishing em geral. O RFC 7489 di-lo explicitamente: o DMARC não trata os nomes de domínio visualmente próximos nem o abuso do nome de apresentação, e a análise do conteúdo está fora do seu âmbito. Não procura resolver todos os problemas do correio fraudulento.
Concretamente, o DMARC não vê:
- um domínio parecido: o burlão autentica perfeitamente o seu próprio domínio, que se parece com o seu;
- um nome de apresentação usurpado: «Serviço de contabilidade» a escrever a partir de um endereço sem relação;
- uma conta comprometida que assina corretamente, uma vez que é o verdadeiro servidor que envia;
- uma mensagem sem relação com o seu domínio: um falso alerta de uma transportadora chega de um domínio que nada tem a ver com o seu;
- um domínio sem política: se o domínio imitado publicar «none», o destinatário não tem instrução de rejeição.
Estes casos cabem a outras análises: semelhança dos domínios, reputação, conteúdo, comportamento. Ver spam, phishing, malware e conta comprometida.
Reencaminhamentos e listas de distribuição: ARC
Um reencaminhamento quebra muitas vezes o SPF, uma lista que altera a mensagem quebra o DKIM, e o DMARC falha então numa mensagem legítima. O ARC, descrito no RFC 8617 (estatuto experimental), permite a cada intermediário atestar o resultado de autenticação que constatou. O servidor final pode optar por tê-lo em conta.
Proteger o seu domínio, filtrar o que chega
São dois temas que se confundem com frequência.
- Proteger o domínio que envia: publicar SPF, DKIM e DMARC para o seu domínio, para que os outros possam recusar as mensagens que o usurpam. Quem publica é a sua empresa; quem aplica são os destinatários.
- Filtrar o que chega: verificar os registos dos outros domínios no correio que recebe e, depois, aplicar todas as outras análises.
Implementação gradual
- Inventário de tudo o que envia em nome do domínio.
- Um registo SPF único que os autorize; uma assinatura DKIM para cada serviço capaz de assinar.
- DMARC em «none», com um endereço de receção dos relatórios.
- Leitura dos relatórios durante várias semanas; correção das fontes esquecidas.
- Passagem para «quarantine» e depois para «reject» quando todos os envios legítimos estiverem alinhados.
Exemplo, a título ilustrativo. Um escritório publica o DMARC em «none» e lê os seus primeiros relatórios. Descobre três fontes: o seu correio eletrónico, bem alinhado; o seu programa de faturação, que envia as faturas com o domínio do escritório sem assinatura DKIM; e um servidor desconhecido no estrangeiro que envia centenas de mensagens em seu nome. Corrige o programa de faturação, espera por um ciclo de relatórios limpo e passa para «quarantine»: os destinatários que aplicam o DMARC passam a tratar as mensagens do servidor desconhecido como suspeitas.
No dia em que se muda de correio eletrónico, estes registos preparam-se antes da alteração do MX. O guia migrar um correio eletrónico sem interrupção descreve esse momento; não é repetido aqui.
Perguntas frequentes
Uma política DMARC «none» protege?
Não. Permite observar graças aos relatórios. A proteção começa com «quarantine» ou «reject».
Porque é que uma mensagem legítima falha o DMARC?
Na maioria dos casos: um reencaminhamento, uma lista de distribuição, ou um serviço que envia por si sem estar declarado no SPF nem assinar em DKIM.
O nosso correio eletrónico não assina em DKIM: o que fazer?
Um gateway colocado no percurso dos envios pode assinar em seu lugar. Ver Proteger o correio eletrónico que já tem.
Onde ler o resultado destes controlos numa mensagem recebida?
Nos cabeçalhos da mensagem. Para o Klytic MTA, ver Ler e exportar uma decisão do filtro.
Onde se posiciona a Klytic
O Klytic MTA trata os dois temas, à frente de qualquer correio eletrónico:
- Essential e Advanced: controlo DKIM, SPF e MX; verificação DMARC, incluindo para as mensagens reencaminhadas graças ao ARC; assinatura DKIM dos envios, mesmo que o seu correio eletrónico não o faça.
- Advanced: consola DMARC, com os relatórios dos seus domínios, alertas e pistas de correção, para conduzir a passagem gradual para «reject».
O DMARC é apenas uma camada: o Klytic MTA acrescenta a deteção dos domínios semelhantes, do nome de apresentação e dos cenários de fraude, descrita em usurpação e fraude do CEO.
Se utilizar o Klytic Mail, o SPF, o DKIM e o DMARC estão configurados para o seu domínio: é a proteção do domínio que envia. O Klytic MTA, por sua vez, subscreve-se com ou sem Klytic Mail.
Fontes
Consultadas em outubro de 2026.
- RFC 7208, SPF: o proprietário de um domínio publica os anfitriões autorizados a utilizar o seu domínio na identidade «MAIL FROM» ou «HELO», e o recetor verifica essa autorização. rfc-editor.org
- RFC 6376, DKIM: um domínio assume a responsabilidade por uma mensagem através de uma assinatura criptográfica; sem encriptação, sem rejeição imposta, domínio signatário possivelmente distinto do autor apresentado. rfc-editor.org
- RFC 7489, DMARC: alinhamento do domínio de «From» com o SPF ou o DKIM, políticas none, quarantine e reject, relatórios agregados e de falha; domínios visualmente próximos, nome de apresentação e análise do conteúdo fora do âmbito. rfc-editor.org
- RFC 9989 (maio de 2026), que substitui o RFC 7489: os mesmos valores de política e as mesmas exclusões (domínios semelhantes, nome de apresentação). rfc-editor.org
- RFC 8617, ARC (experimental): cadeia de transmissão autenticada; um recetor DMARC pode aceitar as avaliações transportadas por uma cadeia ARC válida. rfc-editor.org
- Klytic, página Klytic MTA: controlos de autenticação, assinatura DKIM de saída e consola DMARC das ofertas Essential e Advanced, opções, modos de implementação, ativação através do MX. klytic.com
