Como enviar e-mails do seu app (e chegar na caixa de entrada)

Para enviar e-mails do seu app de forma confiável, use um provedor de envio de e-mails em vez da sua própria caixa de correio, envie a partir de um endereço do seu próprio domínio e adicione os registros DNS que o provedor fornecer, para que SPF, DKIM e DMARC passem. Mantenha os e-mails transacionais (redefinição de senha, recibos, confirmações) separados dos de marketing, envie cada tipo apenas para quem espera por ele e trate devoluções e descadastros. Acerte a autenticação primeiro: é o motivo mais comum de e-mails de apps caírem no spam.

E-mail transacional x e-mail de marketing

Esses dois tipos de e-mail parecem parecidos no código, mas são tratados de forma muito diferente pelos provedores de caixa de entrada e pela lei.

Mantenha-os separados. Se uma campanha de marketing receber reclamações de spam, você não quer que as redefinições de senha enviadas pelo mesmo fluxo sofram por causa disso. Uma abordagem comum é usar subdomínios separados, por exemplo mail.exemplo.com para e-mails da conta e news.exemplo.com para newsletters. Alguns provedores também separam os dois internamente. A Postmark, por exemplo, descreve os seus “message streams” transacional e de broadcast como rodando em infraestruturas de envio separadas, a partir de setembro de 2026.

Escolhendo um provedor

O seu app não deve enviar e-mails diretamente do próprio servidor. Provedores de envio cuidam da infraestrutura, da reputação de IP, das tentativas de reenvio e do tratamento de devoluções. Opções conhecidas incluem Postmark, Resend, SendGrid, Amazon SES e Mailgun; todas oferecem API HTTP e acesso SMTP. Preços e planos mudam, então compare nos próprios sites.

O que comparar:

• Foco. Alguns provedores se concentram em e-mails transacionais; outros combinam transacional e marketing.
• Experiência do desenvolvedor. API clara, bibliotecas oficiais para a sua linguagem, logs úteis mostrando se cada mensagem foi entregue, devolvida ou marcada como spam.
• Webhooks para devoluções, reclamações e entregas, para que o seu app possa reagir.
• Modelos: armazenados no provedor ou no seu código. Mantê-los no código os torna versionados e testáveis.
• Região e tratamento de dados, se você tiver exigências sobre onde os dados são processados.
• Custo no seu volume, incluindo o que acontece quando você ultrapassa o plano gratuito.

Para newsletters para uma lista, uma ferramenta dedicada de newsletter ou de e-mail marketing costuma ser mais adequada do que construir recursos de campanha dentro do seu app.

Configure o seu domínio de envio

Envie a partir do seu próprio domínio, como oi@exemplo.com, e não de um endereço do Gmail ou do Outlook. E-mails de uma caixa gratuita enviados por um serviço de terceiros falham nas verificações de autenticação e tendem a ser filtrados.

Considere um subdomínio só para envio. O Resend, por exemplo, recomenda enviar a partir de subdomínios como atualizacoes.exemplo.com para isolar a reputação de envio (a partir de setembro de 2026). Isso também mantém os registros DNS de e-mail separados dos do seu site principal.

O provedor então fornece registros DNS para você adicionar onde o DNS do seu domínio é gerenciado. Se DNS é novidade para você, como funcionam domínios e DNS explica os registros antes.

SPF

SPF (Sender Policy Framework) é um registro TXT que lista quais servidores podem enviar e-mails em nome do seu domínio. Os destinatários verificam se o servidor de envio está na lista.

• Um domínio deve ter apenas um registro SPF. Se você adicionar um provedor, inclua-o no registro existente em vez de criar um segundo.
• O SPF permite no máximo 10 consultas DNS na avaliação; cadeias longas de entradas include: podem ultrapassar esse limite e causar falhas.
• Muitos provedores configuram o SPF em um subdomínio de return-path que pedem para você criar, então talvez você nem precise mexer no seu registro SPF principal.

DKIM

DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica a cada mensagem. O provedor assina com uma chave privada; você publica a chave pública correspondente como um registro DNS (TXT ou CNAME, dependendo do provedor). Os destinatários verificam a assinatura para confirmar que a mensagem veio de um remetente autorizado e não foi alterada no caminho.

O passo de “verificar domínio” do seu provedor se refere principalmente ao DKIM. Não pule essa etapa.

DMARC

DMARC une os outros dois. É um registro TXT em _dmarc.seudominio.com que informa aos destinatários:

• Alinhamento: o domínio do endereço visível no campo From precisa coincidir com o domínio que passou no SPF ou no DKIM.
• Política: o que fazer com mensagens que falham: p=none (apenas gerar relatório), p=quarantine (tratar como suspeita, muitas vezes spam) ou p=reject.
• Relatórios: para onde enviar relatórios agregados (rua=), para que você veja quem está enviando em nome do seu domínio.

Um caminho sensato é começar com p=none e um endereço de relatório, confirmar que os seus e-mails legítimos passam, depois migrar para quarantine e, eventualmente, reject. Uma política rigorosa também torna muito mais difícil alguém falsificar o seu domínio.

O que o Gmail exige

A partir de setembro de 2026, as diretrizes de remetentes do Google dizem:

• Todos os remetentes para contas pessoais do Gmail precisam de SPF ou DKIM, DNS direto e reverso válidos para os servidores de envio, TLS, e uma taxa de spam no Postmaster Tools abaixo de 0,3%.
• Remetentes em massa (mais de 5.000 mensagens por dia para o Gmail) precisam de SPF e DKIM, de um registro DMARC (uma política p=none é permitida), de alinhamento do domínio do remetente e de descadastro com um clique, além de um link de descadastro visível em mensagens de marketing e de assinatura.

O seu provedor cuida das partes do lado do servidor. Os registros DNS e o tratamento do descadastro são com você. Mesmo que você esteja longe de 5.000 por dia, cumprir as regras de envio em massa é a forma mais simples de estar seguro.

Coloque o envio dentro do seu app

Depois que o domínio estiver verificado:

1. Guarde a chave de API como um segredo do lado do servidor, nunca no código do front-end. Veja o que são variáveis de ambiente e segredos.
2. Envie a partir do servidor, depois que a ação que dispara o e-mail for concluída com sucesso.
3. Não faça o usuário esperar pelo e-mail. Para qualquer app além do mais simples, coloque o envio em uma fila e tente de novo em falhas temporárias, para que uma resposta lenta do provedor não atrase o cadastro.
4. Registre o resultado: o ID da mensagem no provedor e o status, sem registrar a chave nem o corpo completo das mensagens com dados pessoais.
5. Trate os webhooks de devoluções e reclamações: pare de enviar para endereços com devolução definitiva ou que marquem você como spam.

Um prompt que cobre o básico:

Envie e-mails transacionais com [PROVEDOR] usando o segredo do servidor [NOME_DA_VARIAVEL], a partir de "Acme oi@mail.acme.com". Envie um e-mail de boas-vindas após o cadastro e uma confirmação de reserva depois que a reserva for salva. Mantenha os modelos no código, com uma versão em texto simples junto do HTML. Coloque os envios em fila e tente de novo falhas temporárias até três vezes. Registre as falhas com o erro do provedor, mas nunca a chave de API. Adicione um endpoint de webhook que marque endereços como não entregáveis em devoluções definitivas e reclamações, e pule esses endereços no futuro.

E-mails da conta, como links de verificação, links mágicos e redefinições de senha, fazem parte do login. Como adicionar login ao seu app mostra como esses fluxos se encaixam; faça esses links de uso único e de curta duração.

Hábitos de entregabilidade

A autenticação faz o seu e-mail ser considerado. O comportamento é o que mantém você na caixa de entrada.

• Envie apenas o que as pessoas esperam. Cadastros confirmados, opt-in claro para marketing, sem listas compradas.
• Facilite o descadastro em tudo que não for estritamente transacional, e respeite-o imediatamente.
• Aqueça domínios novos. Um domínio novo enviando milhares de mensagens no primeiro dia parece suspeito. Comece com os seus e-mails transacionais e aumente o volume gradualmente.
• Mantenha as listas limpas. Remova imediatamente as devoluções definitivas e considere remover quem não abre nada há muito tempo.
• Escreva como uma pessoa. Um assunto claro, um nome de remetente reconhecível, uma parte em texto simples, poucas imagens e links para o seu próprio domínio. Evite encurtadores de link.
• Monitore. Registre o seu domínio no Google Postmaster Tools e leia os relatórios DMARC de vez em quando.
• Use um reply-to real, que alguém leia. Respostas são um bom sinal e um feedback útil.

Testando sem spammar ninguém

• Use o modo de teste ou sandbox do seu provedor, quando ele existir, ou envie para endereços que você controla.
• Em desenvolvimento, envie para uma caixa de teste que recebe tudo em vez de usuários reais; um banco de dados semeado com endereços com cara de reais é uma forma fácil de mandar e-mail para desconhecidos por engano.
• Teste cada modelo em alguns clientes: Gmail na web, um app de e-mail no celular, Outlook, e também no modo escuro.
• Olhe os cabeçalhos de um e-mail de teste: eles mostram se SPF, DKIM e DMARC passaram.

Noções jurídicas básicas

As regras variam de país para país. De modo geral, e-mail de marketing precisa de consentimento em muitos lugares, deve identificar o remetente e precisa oferecer um descadastro que funcione; e-mail transacional é tratado de outra forma, mas não deve ser usado para enfiar marketing no meio. Se você coletar endereços por meio de uma página de lista de espera, diga o que vai enviar e armazenar, quando e como cada pessoa se cadastrou. Na dúvida, verifique as regras do lugar onde estão os seus usuários.

Checklist de e-mail

• Provedor de envio escolhido; chave de API guardada como segredo do servidor
• Envio a partir do seu próprio domínio ou subdomínio, não de uma caixa gratuita
• Registros SPF, DKIM e DMARC adicionados e passando
• E-mails transacionais e de marketing separados
• Envios em fila, com reenvio e resultados registrados
• Webhooks de devolução e reclamação tratados
• Descadastro em e-mails não transacionais, respeitado imediatamente
• Modelos testados em vários clientes; e-mails de teste nunca chegam a usuários reais

Enviando e-mail de um app do Mythex

O Mythex não inclui um serviço de envio de e-mails embutido para os apps que você cria, então você traz um provedor como Resend, SendGrid ou Postmark. Guarde a chave de API dele como um segredo do projeto (o agente pode pedir isso com um cartão de segredos no chat) e peça os e-mails de que você precisa em linguagem simples. A documentação tem um prompt inicial em enviar e-mail do seu app. Se você comprou seu domínio pelo Mythex no plano Pro, pode adicionar os registros TXT e CNAME do provedor nas configurações de DNS do domínio; veja domínios personalizados.

Perguntas