Como Enviar Emails a Partir da Sua App (e Chegar à Caixa de Entrada)

Para enviar emails da sua app de forma fiável, use um fornecedor de envio de emails em vez da sua própria caixa de correio, envie a partir de um endereço do seu próprio domínio e acrescente os registos DNS que o fornecedor lhe indicar, para que SPF, DKIM e DMARC passem todos. Mantenha o email transacional — redefinições de palavra-passe, recibos, confirmações — separado do email de marketing, envie cada um apenas a pessoas que o esperam e trate devoluções e cancelamentos de subscrição. Acerte primeiro na autenticação; é a razão mais comum para os emails da app acabarem no spam.

Email transacional vs. de marketing

Estes dois tipos de email parecem semelhantes no código, mas são tratados de forma muito diferente pelos fornecedores de caixas de entrada e pela lei.

Mantenha-os separados. Se uma campanha de marketing receber queixas de spam, não quer que as redefinições de palavra-passe do mesmo fluxo sofram por causa disso. Uma abordagem comum é usar subdomínios separados — por exemplo mail.exemplo.com para emails de conta e news.exemplo.com para newsletters — e alguns fornecedores separam os dois internamente. A Postmark, por exemplo, descreve os seus "fluxos de mensagens" transacionais e de difusão como funcionando em infraestruturas de envio separadas, a partir de setembro de 2026.

Escolher um fornecedor

A sua app não deve enviar emails diretamente a partir do próprio servidor. Os fornecedores de envio tratam da infraestrutura, da reputação dos IP, das novas tentativas e do processamento de devoluções. Opções conhecidas incluem Postmark, Resend, SendGrid, Amazon SES e Mailgun; todas têm uma API HTTP e acesso SMTP, e os preços e planos mudam, por isso compare-os nos respetivos sites.

O que comparar:

• Foco. Alguns fornecedores concentram-se no email transacional; outros combinam transacional e marketing.
• Experiência de programação. API clara, bibliotecas oficiais para a sua linguagem, registos úteis que mostrem se cada mensagem foi entregue, devolvida ou marcada como spam.
• Webhooks para devoluções, queixas e entregas, para que a sua app possa reagir.
• Modelos — guardados no fornecedor ou no seu próprio código. Mantê-los no código torna-os versionados e testáveis.
• Região e tratamento de dados, se tiver requisitos sobre onde os dados são processados.
• Custo ao seu volume, incluindo o que acontece quando ultrapassa um plano gratuito.

Para newsletters para uma lista, uma ferramenta dedicada de newsletter ou de email marketing costuma encaixar melhor do que criar funcionalidades de campanha dentro da sua app.

Configurar o seu domínio de envio

Envie a partir do seu próprio domínio — ola@exemplo.com, e não um endereço Gmail ou Outlook. O correio de um endereço gratuito enviado através de um serviço de terceiros falha as verificações de autenticação e tem grandes probabilidades de ser filtrado.

Considere um subdomínio apenas para envio. A 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. Também mantém os registos DNS de email separados dos do seu site principal.

O fornecedor depois dá-lhe os registos DNS a acrescentar onde quer que o DNS do seu domínio seja gerido. Se o DNS for novidade para si, como funcionam os domínios e o DNS explica primeiro os registos.

SPF

O SPF (Sender Policy Framework) é um registo TXT que indica quais os servidores autorizados a enviar email em nome do seu domínio. Os destinatários verificam se o servidor que envia está nessa lista.

• Um domínio deve ter apenas um registo SPF. Se acrescentar um fornecedor, junte-o ao registo 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 fornecedores configuram o SPF num subdomínio de caminho de retorno que lhe pedem para criar, por isso pode nem precisar de tocar no seu registo SPF principal.

DKIM

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

O passo de "verificar domínio" do fornecedor trata sobretudo do DKIM. Não o salte.

DMARC

O DMARC junta os outros dois. É um registo TXT em _dmarc.seudominio.com que indica aos destinatários:

• Alinhamento: o domínio do endereço De visível tem de corresponder ao domínio que passou no SPF ou no DKIM.
• Política: o que fazer com o correio que falha — p=none (apenas reportar), p=quarantine (tratar como suspeito, muitas vezes spam) ou p=reject.
• Relatórios: para onde enviar os relatórios agregados (rua=), para ver quem envia em nome do seu domínio.

Um caminho sensato é começar com p=none e um endereço de relatórios, confirmar que o seu correio legítimo passa, e depois passar para quarantine e, eventualmente, reject. Uma política rigorosa também torna muito mais difícil que terceiros falsifiquem o seu domínio.

O que o Gmail exige

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

• Todos os remetentes de contas Gmail pessoais precisam de SPF ou DKIM, de DNS direto e inverso válidos para os servidores de envio, de TLS e de uma taxa de spam no Postmaster Tools inferior a 0,3%.
• Remetentes em massa (mais de 5.000 mensagens por dia para o Gmail) precisam de SPF e DKIM, de um registo DMARC (é permitida uma política p=none), de alinhamento do domínio De e de cancelamento de subscrição com um clique, além de uma ligação visível de cancelamento nas mensagens de marketing e nas de subscrição.

O seu fornecedor trata das partes do lado do servidor. Os registos DNS e a gestão dos cancelamentos são consigo. Mesmo que esteja longe dos 5.000 por dia, cumprir as regras para remetentes em massa é a forma mais simples de estar seguro.

Integrar o envio na sua app

Depois de o domínio estar verificado:

1. Guarde a chave de API como 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 de a ação que desencadeia o email ter sucesso.
3. Não obrigue o utilizador a esperar pelo email. Numa app que vá além do mais simples, coloque o envio em fila e repita as tentativas em falhas temporárias, para que uma resposta lenta do fornecedor não atrase o registo.
4. Registe o resultado — o ID da mensagem e o estado no fornecedor — sem registar a chave nem o corpo completo das mensagens com dados pessoais.
5. Trate os webhooks de devoluções e queixas: deixe de enviar para endereços com devolução definitiva ou que o marquem como spam.

Um prompt que cobre o básico:

Envie emails transacionais com [FORNECEDOR] usando o segredo do servidor [NOME_DA_VARIÁVEL], a partir de "Acme ola@mail.acme.com". Envie um email de boas-vindas após o registo e uma confirmação de reserva depois de a reserva ser guardada. Mantenha os modelos no código, com uma versão em texto simples ao lado do HTML. Coloque os envios em fila e repita até três vezes as falhas temporárias. Registe as falhas com o erro do fornecedor, mas nunca a chave de API. Adicione um endpoint de webhook que marque os endereços como não entregáveis em caso de devoluções definitivas e queixas, e ignore esses endereços no futuro.

Os emails de conta — links de verificação, links mágicos e redefinições de palavra-passe — fazem parte do início de sessão. Como adicionar início de sessão à sua app explica como esses fluxos se encaixam; torne estes links de utilização única e de curta duração.

Hábitos de entregabilidade

A autenticação faz com que o considerem. O comportamento mantém-no na caixa de entrada.

• Envie apenas o que as pessoas esperam. Registos confirmados, consentimento claro para marketing, nada de listas compradas.
• Facilite o cancelamento em tudo o que não seja estritamente transacional, e respeite-o de imediato.
• Aqueça os domínios novos. Um domínio novo que envie milhares de mensagens no primeiro dia parece suspeito. Comece com o correio transacional e aumente o volume gradualmente.
• Mantenha as listas limpas. Remova as devoluções definitivas de imediato e pondere remover pessoas que não tenham aberto nada há muito tempo.
• Escreva como uma pessoa. Um assunto claro, um nome De reconhecível, uma parte em texto simples, poucas imagens e ligações para o seu próprio domínio. Evite encurtadores de links.
• Monitorize. Registe o seu domínio no Google Postmaster Tools e leia de vez em quando os relatórios DMARC.
• Use um endereço de resposta real que alguém leia. As respostas são um bom sinal e um feedback útil.

Testar sem enviar spam a ninguém

• Use o modo de teste ou sandbox do seu fornecedor, quando existir, ou envie para endereços que lhe pertençam.
• Em desenvolvimento, envie para uma caixa de teste que aceite tudo em vez de utilizadores reais; uma base de dados semeada cheia de endereços com ar real é uma forma fácil de enviar emails a desconhecidos por engano.
• Verifique cada modelo em vários clientes — Gmail na web, a app de email do telemóvel, Outlook — e também em modo escuro.
• Veja os cabeçalhos de uma mensagem de teste: mostram se o SPF, o DKIM e o DMARC passaram.

Noções legais básicas

As regras variam de país para país. Em termos gerais, o email de marketing precisa de consentimento em muitos sítios, tem de identificar o remetente e tem de oferecer um cancelamento que funcione; o email transacional é tratado de forma diferente, mas não deve servir para introduzir marketing. Se recolher endereços através de uma página de lista de espera, diga o que vai enviar e guardar, e quando e como cada pessoa se inscreveu. Na dúvida, verifique as regras do país dos seus utilizadores.

Lista de verificação do email

• Fornecedor 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
• Registos SPF, DKIM e DMARC acrescentados e a passar
• Correio transacional e de marketing separados
• Envios em fila e com novas tentativas; resultados registados
• Webhooks de devoluções e queixas tratados
• Cancelamento disponível no correio não transacional, respeitado de imediato
• Modelos testados em vários clientes; o correio de teste nunca chega a utilizadores reais

Enviar email a partir de uma app Mythex

A Mythex não inclui um serviço de envio de email integrado para as apps que cria, por isso traz o seu próprio fornecedor, como a Resend, a SendGrid ou a Postmark. Guarde a chave de API como segredo do projeto — o agente pode pedi-la com um cartão de segredos no chat — e peça os emails de que precisa em linguagem simples. A documentação tem um prompt inicial em enviar email a partir da sua app. Se comprou o seu domínio através da Mythex no plano Pro, pode acrescentar os registos TXT e CNAME do fornecedor nas definições de DNS do domínio; veja domínios personalizados.

Perguntas