Porque existe o Spoofhound
O e-mail foi construído sobre confiança.
A internet não.
O protocolo que transporta as suas faturas, contratos e reposições de palavra-passe foi concebido em 1982 sem qualquer controlo de segurança — porque nenhum parecia necessário. Tudo o que veio depois foi remendo. Esta página explica os problemas que essa história lhe deixou, e exatamente como o Spoofhound os resolve.
Breve história de um protocolo sem segurança
Ninguém previu aquilo em que o e-mail se tornaria.
O Spoofhound ajuda a proteger os seus e-mails.
O SMTP foi escrito para uma pequena rede de instituições que se conheciam entre si. Nenhum dos seus criadores previu milhares de milhões de mensagens por dia entre estranhos — nem o spam, o spoofing e o phishing tornados indústrias de milhares de milhões. Cada salvaguarda que o e-mail tem hoje foi acrescentada décadas depois, e cada uma existe para tapar um buraco específico daquele modelo de confiança original.
-
1978
O primeiro spam
Um comercial envia a cerca de 400 utilizadores da ARPANET um anúncio de produto não solicitado. A reação é furiosa — e não muda nada. Não há mecanismo para travar o seguinte.
-
1982
O SMTP é normalizado (RFC 821)
O protocolo que ainda hoje transporta o e-mail do mundo é escrito para uma rede de algumas centenas de anfitriões de confiança, na sua maioria académicos. Qualquer servidor pode reivindicar qualquer endereço de remetente; a linha From é apenas texto. Sem autenticação, sem cifragem, sem verificação — nada disso considerado necessário entre colegas que se conheciam.
-
1990s
O e-mail ultrapassa os seus pressupostos
A internet abre-se ao público e o e-mail torna-se a sua primeira killer app. O modelo de confiança criado para centenas de anfitriões transporta agora correio entre completos estranhos, e o spam industrializa-se quase de imediato — no início dos anos 2000 já é a maioria de todo o e-mail enviado.
-
1996
O «phishing» ganha o seu nome
Os atacantes descobrem o corolário de uma linha From não autenticada: correio que afirma vir do seu banco, do seu fornecedor, do seu chefe. O termo é cunhado entre os ladrões de contas da AOL; a técnica nunca mais desaparece.
-
2002
STARTTLS (RFC 3207): cifragem, de forma oportunista
O correio de servidor para servidor pode agora ser cifrado — mas apenas se ambas as partes o oferecerem, e a entrega prossegue mesmo que a negociação falhe. Um atacante no caminho pode simplesmente retirar a oferta e ler o correio. Ninguém é avisado quando isso acontece.
-
2003–2007
SPF e DKIM acrescentam autenticação
O SPF publica que servidores podem enviar por um domínio; o DKIM acrescenta uma assinatura criptográfica. Ambos são progresso real — e ambos verificam identificadores técnicos ocultos em vez do endereço From que uma pessoa realmente lê. Uma mensagem pode passar qualquer um deles mostrando o domínio de outra pessoa.
-
2012–2015
O DMARC liga-o à linha From
O DMARC exige que o SPF ou o DKIM se alinhem com o domínio From visível, permite ao proprietário publicar uma política (monitorizar, colocar em quarentena ou rejeitar) e — o que é crucial — obriga os recetores a relatar quem envia em nome do domínio. Pela primeira vez, um proprietário de domínio pode ver o abuso e desligá-lo.
-
2018
MTA-STS e TLS-RPT (RFC 8461/8460) fecham a lacuna de cifragem
O MTA-STS permite a um domínio exigir TLS verificado para o correio de entrada em vez de apenas esperar por ele; o TLS-RPT é o seu ciclo de retorno — relatórios diários dos remetentes sobre cada ligação falhada ou degradada que, de outro modo, falharia em silêncio.
-
2019–2021
BIMI: uma recompensa visível por terminar o trabalho
Os Brand Indicators for Message Identification colocam o logótipo verificado de um domínio ao lado do seu correio no Gmail, Yahoo, Apple Mail e outros — mas apenas para os domínios que levaram o DMARC até à aplicação, com um logótipo SVG validado e, para a maioria dos fornecedores, um Verified Mark Certificate que prova que a marca é sua dona. Pela primeira vez, fazer bem a segurança do e-mail vê-se num sítio que todos podem ver.
-
2026
DMARCbis (RFC 9989) torna-se a norma
O DMARC ascende a Norma Internet plena, com orientações mais nítidas: um caminho comedido e faseado até à aplicação, e uma política escolhida conforme o domínio é realmente utilizado.
Porquê o DMARC
A linha From que o seu leitor vê é a que importa.
O SPF e o DKIM autenticam coisas reais — o servidor emissor, a assinatura da mensagem — mas nenhum deles tem de corresponder ao endereço From que uma pessoa realmente lê. Um phisher pode passar ambos num domínio próprio enquanto mostra o seu. O DMARC fecha essa lacuna: exige que aquilo que passou se alinhe com o domínio From visível, e permite-lhe dizer a cada recetor do planeta o que fazer quando não se alinha — entregá-lo, mandá-lo para o lixo ou recusá-lo de vez.
Igualmente importante, o DMARC relata. Cada grande recetor envia ao proprietário do domínio um relato diário do que alegava ser ele: que fontes, que volumes, o que passou, o que falhou. Esses relatórios são a visibilidade sobre a qual tudo o resto assenta — não pode aplicar em segurança uma política contra remetentes que não identificou, razão pela qual a RFC 9989 prescreve um caminho comedido e faseado: primeiro monitorizar, compreender cada fonte e depois apertar.
Porquê o TLS-RPT
Cifragem que não consegue verificar é cifragem que não tem.
O correio entre servidores só é cifrado de forma oportunista: se o handshake TLS falhar, ou um atacante no caminho retirar sorrateiramente a oferta, a mensagem é enviada na mesma — em claro. O remetente não sabe. Você não sabe. O MTA-STS resolve a metade da política, permitindo que o seu domínio exija TLS verificado em vez de esperar por ele.
O TLS-RPT é a metade de que ninguém se lembra: o ciclo de retorno. Os remetentes relatam-lhe, todos os dias, cada ligação ao seu domínio que falhou ou degradou a sua cifragem — o que é ao mesmo tempo o seu aviso prévio de um ataque em curso e a sua única forma de saber que uma política MTA-STS está a funcionar em vez de rejeitar em silêncio correio legítimo. Sem os relatórios, aplica às cegas.
Porquê o BIMI
O seu logótipo, apenas onde o seu correio é provado autêntico.
O BIMI é a recompensa por tudo o que precede: uma vez aplicado o DMARC, os fornecedores de caixas participantes — Gmail, Yahoo, Apple Mail, Fastmail — mostram o seu logótipo verificado ao lado das suas mensagens. São impressões de marca diárias no único lugar para onde os seus clientes olham de forma fiável, e uma pista visual que um phisher não consegue reproduzir, porque o logótipo aparece apenas no correio que passou a autenticação para o seu domínio em aplicação.
Lá chegar tem arestas afiadas: o logótipo tem de ser um ficheiro SVG Tiny P/S válido, a maioria dos fornecedores exige um Verified Mark Certificate que prove que a marca é sua dona, e tudo — registo, logótipo, validade do certificado — tem de se manter correto ou o logótipo desaparece em silêncio. O Spoofhound monitoriza os três por domínio, e pode alojar por si o logótipo validado e o certificado, para que o BIMI continue a ser uma recompensa e não mais uma coisa para vigiar.
Os problemas que o Spoofhound resolve
Cinco problemas que todo o proprietário de domínio tem.
Quer o saiba, quer não.
Criminosos enviam e-mail em nome do seu domínio
O problema: A fraude de faturas, o desvio de salários e o phishing dirigido aos seus clientes e colaboradores usam habitualmente o seu domínio exato na linha From — porque, enquanto o DMARC não for aplicado, os recetores entregam-no. O comprometimento de e-mail empresarial (BEC) lidera sistematicamente as perdas de cibercrime reportadas ao FBI, ano após ano.
Como o Spoofhound o resolve: O Spoofhound estabelece uma linha de base para cada fonte de envio legítima nos seus relatórios DMARC, de modo que uma fonte totalmente nova que falha o alinhamento — a assinatura clássica do spoofing — aciona um alerta no mesmo dia, com uma linha de runbook a dizer-lhe o que significa e o que fazer. O que o DMARC trava e o que não trava →
O seu correio legítimo cai no spam — ou em lado nenhum
O problema: A Google, a Yahoo e a Microsoft exigem agora autenticação (incluindo DMARC para remetentes em massa) como condição de entrega. Uma plataforma de marketing esquecida ou um registo SPF mal configurado custa-lhe em silêncio a colocação na caixa de entrada, e ninguém lhe diz que mensagem falhou nem porquê.
Como o Spoofhound o resolve: Cada identidade de envio vista nos seus relatórios é inventariada e classificada — legítima, reencaminhador, mal configurada ou maliciosa — para que possa corrigir as mal configuradas e conseguir que cada remetente real passe e fique alinhado antes de apertar a política.
A prova existe, mas ninguém a consegue ler
O problema: Os relatórios DMARC e TLS chegam como anexos XML e JSON comprimidos, por recetor, por dia, a uma caixa de correio. A visibilidade de que precisa já lhe está tecnicamente a ser enviada — numa forma que nenhum ser humano alguma vez lerá.
Como o Spoofhound o resolve: O Spoofhound ingere-os e lê-os a todos, todos os dias, e abre numa fila de triagem de coisas que realmente precisam de uma decisão — não um muro de gráficos. Um resumo de segunda-feira sintetiza a semana em frases.
A aplicação parece arriscada demais para alguma vez terminar
O problema: Passar a quarentena ou rejeição é onde está a proteção — mas um passo em falso manda para o lixo as suas próprias faturas ou salários. Por isso a maioria dos domínios fica encalhada em p=none para sempre, monitorizada mas desprotegida.
Como o Spoofhound o resolve: O assistente de aplicação codifica o caminho seguro: um limiar de 98% de aprovação alinhada numa janela móvel mais uma verificação de «todas as fontes explicadas», com uma recomendação faseada em cada passo — a progressão comedida que a própria RFC 9989 prescreve.
A cifragem do correio falha em silêncio
O problema: O STARTTLS é oportunista: se a negociação TLS falhar — ou um atacante a retirar — o correio é entregue na mesma, em claro, e ninguém é notificado. Sem o MTA-STS e o TLS-RPT não consegue saber que está a acontecer.
Como o Spoofhound o resolve: O Spoofhound classifica cada domínio de A a F na segurança de transporte a partir dos seus relatórios TLS, aloja o seu ficheiro de política MTA-STS (certificado emitido e renovado por si) e alerta sobre padrões de falha com níveis de gravidade.
Veja-o no seu próprio domínio
A verificação de domínio gratuita avalia a sua configuração de SPF, DKIM, DMARC, MTA-STS, TLS-RPT e BIMI em segundos — sem inscrição, sem agente, sem nada instalado.
Como o Spoofhound é construído
Cloud-first, de raiz.
A maioria das ferramentas de monitorização são aplicações tradicionais que por acaso correm num centro de dados — máquinas virtuais e contentores que têm de ser dimensionados, corrigidos e pagos quer alguém os use quer não. O Spoofhound não. Foi construído para a cloud de raiz: sem máquinas virtuais, sem contentores, sem racks de servidores. Corre como código serverless numa rede edge global, perto de onde quer que os seus relatórios cheguem.
Essa escolha nota-se em três sítios que realmente sente. Escala com a procura — um dia que traz dez vezes o volume habitual de relatórios é tratado como qualquer outro, sem capacidade para aprovisionar. É separado por conceção — cada jurisdição é uma implementação autónoma com a sua própria base de dados e região, o que permite que os seus dados fiquem no país que escolher em vez de num único sistema partilhado com uma coluna de país. E porque custa quase nada em repouso, é a razão por que os nossos preços são como são: um preço por domínio baixo com todas as funcionalidades incluídas, em vez de níveis de funcionalidades criados para recuperar o custo de servidores a trabalhar sem uso.