Segurança e entrega

Cifra em trânsito (TLS)

• Entrada (porta 25): oferecemos STARTTLS com TLS 1.2 ou 1.3 e certificado Let's Encrypt. Como em todo servidor de e-mail, o remetente que não usa TLS ainda consegue entregar.
• Envio (porta 587): STARTTLS é obrigatório antes do login; sem ele, o servidor não aceita a senha.
• Entrega ao destino: usamos STARTTLS sempre que o servidor de destino oferece, o caso do Gmail, do Outlook e dos grandes provedores, e tentamos primeiro conferir o certificado. Se o destino exige TLS pela política MTA-STS, a mensagem só sai cifrada e com certificado válido; sem essa exigência, preferimos a conexão cifrada à em texto puro mesmo com um certificado que não confere. Detalhes em Entrega aos outros domínios.
• Painel e API: só HTTPS.

MTA-STS e TLS-RPT

O MTA-STS diz aos outros servidores que o seu MX aceita TLS com um certificado válido, o que dificulta interceptar a conexão. O nosso domínio publica a política (em modo de teste) e recebe relatórios TLS-RPT. Para o seu domínio, o painel mostra um CNAME mta-sts e dois TXT: nós servimos a política com um certificado emitido só para o seu nome, e os relatórios TLS-RPT vão para um endereço do seu domínio. É opcional.

Entrega aos outros domínios

Ao entregar uma mensagem, conferimos se o domínio de destino publica uma política MTA-STS (RFC 8461). Buscamos a política em https://mta-sts.<domínio>/.well-known/mta-sts.txt, guardamos em cache pelo prazo que ela indica (max_age) e buscamos de novo quando o id do TXT _mta-sts muda.

• Política em modo enforce: só entregamos aos MX que a política lista, com STARTTLS obrigatório e certificado válido (cadeia confiável e o nome do MX). Se não der, a mensagem não sai em texto puro: fica na fila e tentamos de novo; depois de 5 dias sem sucesso, o remetente recebe o aviso de devolução.
• Política em modo testing: entregamos como se não houvesse política e registramos, internamente, quando ela teria falhado. Ainda não enviamos relatórios TLS-RPT ao destino.
• Sem política (a maioria dos domínios): STARTTLS sempre que o destino oferece, tentando primeiro conferir o certificado. Se a conferência falha, entregamos cifrado mesmo assim, sem verificar: é o TLS oportunista, o padrão do e-mail na internet. Em texto puro, só quando o destino não oferece STARTTLS.
• DANE (registros TLSA): ainda não aplicamos.

O log de cada entrega diz se o TLS foi verificado, não verificado ou ausente.

DKIM, com rotação em duas fases

• Cada domínio tem a própria chave RSA de 2048 bits. A privada fica cifrada no banco (XChaCha20-Poly1305) e assina o que você envia pela porta 587.
• Rotação sem perder e-mail: ao rotacionar, a chave nova é criada com outro seletor, mas a atual continua assinando. Só quando o TXT da nova aparece no seu DNS ela passa a assinar; o TXT antigo segue no painel por mais 7 dias, porque uma mensagem já assinada pode estar em nova tentativa.

SPF, DMARC, ARC e SRS

• Na entrada conferimos SPF, DKIM e DMARC de cada mensagem e respeitamos p=reject.
• No seu domínio, o SPF inclui o nosso servidor (include:), e você pode publicar DMARC; o leitor de relatório DMARC é grátis e roda no seu navegador.
• ARC: selamos cada mensagem reencaminhada com a chave da plataforma, para o destino ver que a autenticação original passou.
• SRS: o remetente do envelope é reescrito no reencaminhamento, para o SPF passar no destino e as devoluções voltarem a quem enviou.

Antispam

O rspamd roda no nosso servidor e dá uma pontuação a cada mensagem; cada domínio escolhe o nível:

Também dá para desligar o filtro. Mensagem marcada como spam não vai para os canais (webhook, Telegram).

Limites por plano

Cada plano tem um teto de mensagens por dia (o grátis, por mês), de destinos por endereço e de resumos por hora nos canais (60 por canal). Acima do limite diário, o e-mail que chega recebe um adiamento temporário e o servidor do remetente tenta de novo depois; o envio pela porta 587 é recusado até o dia seguinte. Os limites existem para que uma conta comprometida não prejudique as outras. Os números de cada plano estão na página de planos.

Contas e isolamento

• Senhas do painel em bcrypt; senhas SMTP em argon2, mostradas uma vez só, na criação; tokens de API guardados só como hash. Login em dois fatores opcional.
• Uma credencial SMTP só envia como endereços do próprio domínio.
• Cada time só enxerga os próprios dados, conferido duas vezes: no painel e no servidor de e-mail.

Onde fica o servidor

Num servidor dedicado da Hetzner, na Finlândia (União Europeia): o servidor de e-mail, o banco de dados, a fila e o log ficam nele, com backup diário. As outras empresas que tratam dados (DNS, cobrança, e-mails do painel) estão na lista de subprocessadores da Política de privacidade.

Status e incidentes

A página de status confere a cada minuto o MX, o SMTP de envio, o painel e a política MTA-STS, mostra 90 dias de disponibilidade e o tempo de encaminhamento, e lista os incidentes. As checagens rodam no próprio servidor, então uma queda total dele aparece como falta de dados, não como vermelho; o que descobrirmos de outro jeito vira incidente.

Perguntas frequentes

Quer testar com o seu domínio? O plano grátis não pede cartão. Criar conta grátis