Sua caixa de entrada não é apenas onde o trabalho acontece. Ela é a chave mestra de todo o resto. Redefinir a senha do banco? Por e-mail. Redefinir o CRM? Por e-mail. Recuperar a conta da infraestrutura em nuvem? Por e-mail. Se um invasor controlar uma única caixa de entrada, poderá controlar toda a empresa.
A má notícia: na maioria das empresas que usam e-mail empresarial, pelo menos metade das configurações abaixo está incorreta ou simplesmente ausente. A boa notícia: corrigi-las não exige uma equipe de segurança nem um contrato corporativo de $50,000. Exige cerca de duas horas e disposição para realmente fazer o trabalho.
Esta é a base. Não é um estado ideal para o futuro, mas o mínimo. Se você não consegue marcar todos os itens desta lista, há pontos de exposição.
Como as empresas são comprometidas na prática
Esqueça agentes estatais e explorações de vulnerabilidades de dia zero. A menos que sua empresa trabalhe com algo sigiloso, ninguém vai gastar um ataque sofisticado contra ela. Os três riscos responsáveis por 90% dos incidentes de e-mail em pequenas e médias empresas são extremamente comuns.
Credential stuffing: invasores compram bancos de senhas vazadas, como LinkedIn 2012, Adobe 2013 ou qualquer uma das centenas de violações posteriores, e executam scripts contra seu servidor de e-mail. Se a sua senha apareceu em algum desses vazamentos e não foi alterada, eles podem entrar. Não é preciso invadir tecnicamente o sistema.
Regras silenciosas de encaminhamento: depois de entrar, um invasor habilidoso não vasculha tudo de imediato. Ele cria uma regra discreta: "Se o assunto contiver 'fatura' ou 'transferência bancária', enviar cópia para attacker@gmail.com e marcar como lida." Depois, observa por meses. Quando você percebe, talvez ele já tenha interceptado um pagamento.
Spoofing: alguém escreve para a contabilidade usando ceo@yourcompany.com e pede uma transferência urgente. A mensagem parece legítima. Se o DNS não estiver configurado corretamente, o servidor que recebe a mensagem não terá como saber que ela é falsa e talvez nem a sinalize.
Esses três ataques podem ser evitados. Veja como.
E-mail seguro para empresas: proteção básica das contas
Este é o seu perímetro. Se essa camada falhar, nenhuma configuração de DNS poderá salvar você.
1. Exija MFA resistente a phishing, sem exceções
Senhas não bastam como segurança. Elas servem para identificação. Uma senha sozinha apenas mostra que alguém conhece uma sequência de caracteres, não que essa pessoa realmente trabalha na empresa. A autenticação multifator é o que acrescenta uma verificação efetiva.
Use um aplicativo autenticador (Google Authenticator, Microsoft Authenticator, Authy) ou uma chave física (YubiKey). Ambas as opções são adequadas. O que não serve como método principal é a 2FA por SMS. Ela funciona, mas está sujeita a ataques de troca de SIM, nos quais o invasor usa engenharia social para convencer a operadora a transferir seu número para outro aparelho. Use SMS apenas como alternativa de recuperação.
Exija MFA no nível administrativo. Não deixe como opcional. Um único usuário que não a adota é o elo mais fraco.
A TrekMail oferece 2FA em todas as contas de administrador. Ative-a nas configurações de segurança da conta. Consulte o passo a passo completo no guia de autenticação de dois fatores.
2. Desative imediatamente a autenticação legada
Esta é uma das vulnerabilidades mais ignoradas em 2026. "Autenticação legada" significa protocolos como o SMTP AUTH básico, que não aceitam fluxos modernos de MFA. Eles pedem apenas nome de usuário e senha.
O problema é que, mesmo com a 2FA ativada em todas as contas, um invasor pode contorná-la completamente ao se conectar por um protocolo legado. Sua nova configuração de MFA não faz diferença para um cliente que nunca solicita o segundo fator.
Bloqueie a autenticação legada no nível do tenant. A única exceção: se uma impressora, um scanner ou um equipamento antigo precisar enviar e-mails, isole-o. Crie para ele uma conta de serviço exclusiva, com uma senha longa, complexa e renovada periodicamente. Não exponha contas comuns de usuários a protocolos legados só porque a copiadora precisa digitalizar e enviar por e-mail.
Observação: a TrekMail deliberadamente não oferece suporte a POP3. Essa decisão de arquitetura evita o armazenamento de e-mails apenas no dispositivo, que não permite recuperação caso ele seja perdido. O IMAP é compatível e obrigatório em todas as conexões de clientes.
3. Não compartilhe credenciais
A conta info@company.com, usada por três pessoas que enviam a senha umas às outras, não é um pequeno inconveniente. É um incidente de segurança prestes a acontecer. Quando alguém sai da empresa, vocês alteram a senha? Em geral, não. Sabem quem fez o último acesso? Não.
A solução é usar acesso delegado ou caixas compartilhadas: cada usuário se autentica com as próprias credenciais e recebe acesso à pasta comum. Há uma trilha de auditoria completa. O acesso pode ser revogado individualmente. Não é necessário compartilhar senhas.
O modelo de preços por usuário incentiva justamente o contrário. Quando cada licença custa de $15 a $30 por mês, as equipes começam a compartilhar credenciais para reduzir custos. No modelo de preço fixo da TrekMail, o que conta é o armazenamento compartilhado, não o número de usuários. Portanto, o valor é o mesmo com 5 ou 50 usuários. Dê uma conta a cada pessoa. Não compartilhe senhas para economizar $6 por mês.
Administração e controle de acesso
A conta de emergência
Se o seu telefone cair no mar ou se o provedor de identidade principal ficar indisponível, você precisará de uma forma de voltar que não dependa do sistema que acabou de falhar. Crie uma única conta de administrador de recuperação exclusiva da nuvem, como admin-recovery@yourdomain.com, com uma senha aleatória de 30 caracteres. Escreva-a em papel e guarde o papel em um cofre físico.
Depois, configure um alerta: se essa conta fizer login, todos os outros administradores serão notificados imediatamente. Ela quase nunca deve ser usada. Se houver um login inesperado, algo está muito errado.
Separação de funções
Sua conta de e-mail cotidiana, usada para navegar na web, abrir links e ler newsletters, não deve ser uma conta de administrador global. Se você abrir um link de phishing enquanto estiver conectado como superadministrador, poderá entregar ao invasor as chaves de tudo.
Crie uma conta de administrador separada. Acesse-a apenas quando precisar alterar configurações. Para todas as outras tarefas, trabalhe como usuário comum. Isso não é paranoia, mas uma prática operacional básica que qualquer administrador de sistemas recomendaria desde o primeiro dia.
E-mail seguro para empresas: proteção básica da autenticidade (SPF, DKIM, DMARC)
Esses três registros DNS formam a base técnica que impede o spoofing. Desde 2024, Google e Yahoo os exigem de remetentes em massa, e eles são cada vez mais esperados em todos os e-mails empresariais. Se você ainda não os configurou, faça isso agora.
Para conhecer cada camada em detalhes, o guia de configuração de domínio de e-mail apresenta toda a sequência de implementação.
SPF: a lista de remetentes autorizados
Sender Policy Framework é um registro DNS TXT que indica explicitamente quais endereços IP podem enviar e-mails pelo seu domínio. Qualquer servidor fora da lista falha na verificação.
v=spf1 include:_spf.trekmail.net -all
Há dois pontos importantes:
Primeiro, termine com -all (falha definitiva), não com ~all (falha branda). A falha branda transmite esta ideia: "Não sei ao certo quem envia meus e-mails, então talvez seja melhor deixá-los passar." Isso não é uma política de segurança, mas um convite. Use a falha definitiva depois de confirmar todos os remetentes legítimos.
Segundo, o SPF tem um limite de 10 consultas ao DNS. Se você incluir Google Workspace, Mailchimp, Salesforce e Zendesk no mesmo registro, provavelmente ultrapassará esse limite, e o SPF deixará de funcionar sem aviso evidente. Use uma ferramenta de SPF flattening se precisar coordenar vários serviços de envio.
DKIM: o selo que evidencia alterações
DomainKeys Identified Mail adiciona uma assinatura criptográfica a cada mensagem enviada. Seu servidor de e-mail, que mantém a chave privada, assina o e-mail. O servidor do destinatário confere a assinatura usando a chave pública que você publicou no DNS.
Por que o DKIM é necessário mesmo com SPF: o encaminhamento interrompe o SPF. Quando uma mensagem é encaminhada, o endereço IP remetente muda, e o SPF falha. O DKIM acompanha os cabeçalhos da mensagem e permanece intacto durante o encaminhamento. Você precisa dos dois.
A TrekMail gerencia automaticamente a criação e a rotação de chaves DKIM nos planos pagos. A chave pública é publicada no seu DNS, e todas as mensagens enviadas são assinadas. Não há nada para configurar manualmente. O guia de registros DNS obrigatórios mostra exatamente o que é adicionado e onde.
DMARC: a camada que aplica a política
O DMARC informa aos servidores destinatários o que fazer quando o SPF ou o DKIM falha. Ele também envia relatórios sobre quem está remetendo mensagens em nome do seu domínio. É assim que você descobre, por exemplo, que uma ferramenta de marketing esquecida ainda envia mensagens em seu nome.
Comece no modo de monitoramento. Não pule essa etapa.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Esse registro diz, em essência: "Avise quem está enviando em meu nome, mas ainda não bloqueie nada." Colete relatórios por duas a quatro semanas. Audite cada fonte de envio. Só passe para a aplicação da política depois de confirmar que todos os remetentes legítimos são aprovados na autenticação:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com
Depois, por fim:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
Se você passar diretamente para p=reject sem fazer uma auditoria, bloqueará suas próprias faturas, seus próprios e-mails de marketing e tudo o que não estiver configurado perfeitamente. Avance aos poucos. A documentação do DMARC explica todo o processo de adoção gradual.
Segurança no encaminhamento e no catch-all
Bloqueie o encaminhamento externo automático
Essa única regra ajuda a impedir o ataque de exfiltração silenciosa descrito anteriormente. Configure seu servidor de e-mail para proibir o encaminhamento automático a domínios externos.
Quase não existe motivo empresarial legítimo para um funcionário encaminhar automaticamente todos os e-mails corporativos para uma conta pessoal do Gmail. Se alguém precisar de acesso em vários lugares, ofereça acesso IMAP em vários dispositivos. É para isso que o IMAP existe. Regras que copiam silenciosamente todas as mensagens para um endereço externo constituem, por definição, um vazamento de dados.
O problema do catch-all
Um endereço catch-all aceita tudo o que for enviado para qualquer endereço do seu domínio, mesmo que ele não exista. Parece conveniente. Na prática, os spammers adoram esse recurso. Eles bombardeiam seu domínio com ataques de dicionário, como a@yourdomain.com, aa@yourdomain.com, ab@yourdomain.com. Se você responder a alguma dessas mensagens, ou se um dos endereços for uma armadilha de spam, seu domínio poderá ser sinalizado.
Desative o catch-all, a menos que exista uma necessidade operacional específica. Se precisar dele, monitore diariamente e aplique filtros rigorosos. O plano Pro da TrekMail permite o roteamento de catch-all externo com filtro de spam integrado. No entanto, o guia de configuração do catch-all deixa claro que o recurso exige gestão ativa, não uma configuração que possa ser esquecida.
Checklist básico de segurança com 12 itens
Se você conseguir marcar todos os itens abaixo, estará mais protegido do que a maioria das organizações, inclusive muitas empresas com equipes próprias de TI que simplesmente ainda não cuidaram disso.
| # | Controle | O que ele evita |
|---|---|---|
| 1 | MFA obrigatória em todas as contas | Credential stuffing, vazamento de senhas |
| 2 | Autenticação legada bloqueada (sem SMTP AUTH básico para usuários) | Contorno da MFA por protocolos antigos |
| 3 | Nenhuma credencial compartilhada, apenas acesso delegado | Acesso não rastreado, exposição por ex-funcionários |
| 4 | Conta de administrador exclusiva e separada do uso diário | Cadeia entre phishing e comprometimento administrativo |
| 5 | Conta de recuperação de emergência criada + armazenada offline | Bloqueio sem possibilidade de recuperação |
| 6 | Registro SPF existente, terminado em -all, com menos de 10 consultas |
Spoofing baseado em IP |
| 7 | DKIM ativo, chaves renovadas anualmente | Adulteração de mensagens, falhas de autenticação no encaminhamento |
| 8 | DMARC no mínimo como p=none, com endereço RUA |
Spoofing sem detecção, falta de visibilidade dos remetentes |
| 9 | Encaminhamento externo automático bloqueado no servidor | Exfiltração silenciosa de dados por regras da caixa de entrada |
| 10 | Catch-all desativado ou sujeito a filtros rigorosos | Ataques de dicionário, exposição a armadilhas de spam |
| 11 | Checklist de desligamento existente (redefinir senha → revogar sessões → apagar dispositivo) | Acesso persistente após o desligamento |
| 12 | Remetentes externos auditados (CRM, faturamento, marketing) | Fontes desconhecidas com falha no DMARC, bloqueio de mensagens legítimas |
Imprima esta lista. Coloque-a no manual de integração. Revise-a a cada seis meses.
Por que o preço por usuário é um problema de segurança
É preciso dizer com clareza: a cobrança por usuário, no modelo comum de $6 a $30 por usuário, cria uma pressão financeira direta para economizar na segurança. Quando cada usuário custa dinheiro, as equipes compartilham a senha de info@ em vez de criar contas individuais. Prestadores não recebem credenciais próprias. Contas de ex-funcionários continuam ativas porque a migração parece cara.
E-mail seguro para empresas exige isolamento. Cada pessoa precisa de uma identidade própria. Cada bot de serviço precisa de uma conta própria. Sem isso, não há trilha de auditoria.
O modelo de preço fixo da TrekMail cobra pelo espaço de armazenamento compartilhado, não pelo número de pessoas. Não importa se você opera cinco ou quinhentas caixas postais: o preço não muda conforme a quantidade de usuários. Assim, todos podem ter credenciais próprias e isoladas, sejam funcionários, prestadores ou contas de serviço, sem uma nova discussão orçamentária sempre que alguém entrar.
Os planos começam em $3.50 por mês para até 50 domínios e 100 usuários por domínio. Para uma equipe de tamanho comum, o cálculo resulta em bem menos de um dólar por usuário. Todos os planos pagos oferecem um período gratuito de 14 dias. É necessário informar um cartão.
O que fazer agora
Revise o checklist acima. Seja realista sobre o que falta. A maioria das empresas encontra pelo menos três ou quatro lacunas na primeira revisão. Isso é normal e pode ser corrigido.
As medidas de maior impacto, ordenadas pela relação entre esforço e resultado, são:
- Ative MFA em todos os lugares. Faça isso hoje.
- Audite seus relatórios DMARC, se já os tiver. Caso contrário, comece a coletá-los.
- Confirme que seu SPF termina em
-alle não excede o limite de consultas. - Bloqueie o encaminhamento externo automático no servidor.
- Crie a conta de emergência antes de precisar dela.
Segurança não consiste em comprar um produto mágico. É preciso configurar corretamente a base e evitar desvios posteriores. Configure o DNS, exija MFA e pare de compartilhar senhas. Essa combinação bloqueia a grande maioria dos meios pelos quais as empresas realmente são atacadas.
Se você estiver começando do zero, a TrekMail configura DKIM e SPF automaticamente pelo assistente de DNS, bloqueia POP3 por decisão de projeto e oferece o modelo de preço fixo que torna viável o isolamento correto dos usuários. Experimente grátis por 14 dias.