Envio nativo

Observação: O envio nativo está disponível em todos os planos, incluindo o Free — é medido pelo volume mensal, não bloqueado atrás de um upgrade. Veja os preços para o limite de cada nível.

Além do seu próprio relay SMTP, o MailInApp pode enviar diretamente de um domínio que você verificar com a gente — sem ESP, sem credenciais SMTP para gerar e rotacionar. A entrega ocorre em nossa infraestrutura (Amazon SES) usando seu próprio domínio de envio, de forma que os destinatários veem e-mails de [email protected], não um endereço compartilhado do MailInApp.

Verificar um domínio

Em Configurações → Domínios, a página guia você pelo processo:

1. Digite seu domínio e clique em Verificar domínio. Por padrão, o MailInApp cria uma identidade de envio para mail.<seudominio> e um subdomínio de tratamento de bounce (bounce.mail.<seudominio>) — um subdomínio dedicado que coexiste com segurança com qualquer outro e-mail que você já use no domínio raiz. Se preferir enviar diretamente do domínio raiz ([email protected], e não [email protected]), marque Usar o domínio raiz em vez de um subdomínio — só faça isso se o domínio não for usado para nenhum outro e-mail; veja Receber e-mail no seu domínio para entender por que isso importa ainda mais quando o recebimento de entrada está envolvido.
2. Adicione os registros DNS exibidos — alguns registros CNAME de DKIM, um registro MX e um TXT para o subdomínio de bounce, e um registro TXT inicial de DMARC — no seu provedor de DNS. Isso comprova que você controla o domínio e permite que o e-mail enviado por ele passe pelas verificações de DKIM/SPF.
3. Clique em Verificar agora depois de adicioná-los, ou apenas espere — o MailInApp verifica automaticamente a cada 15–30 minutos.
4. Quando o domínio e o subdomínio MAIL FROM mostrarem Verificado, um alternador aparece para trocar o método de envio da sua conta para o envio nativo.

Voltar para o SMTP está sempre disponível e é instantâneo — isso não desconecta o domínio, então você pode alternar entre os dois sem precisar verificar de novo.

DMARC

O DMARC informa às caixas de entrada o que fazer com mensagens que alegam vir do seu domínio, mas falham em SPF/DKIM — rejeitar, enviar para o spam ou (o padrão que geramos) apenas monitorar. É o único registro aqui que o MailInApp não consegue verificar automaticamente da forma como verifica o status do DKIM e do MAIL FROM — não existe uma API para isso, então ele é exibido para você adicionar, mas nunca mostra um selo de Verificado/Pendente.

O registro que geramos vem deliberadamente como p=none (apenas monitoramento) — ele não afeta a entrega por si só. Depois de confirmar que nada legítimo está falhando, aperte a política para p=quarantine e, eventualmente, p=reject no seu provedor de DNS. A maioria dos provedores de DNS, incluindo a Cloudflare, mostra relatórios agregados de DMARC se você adicionar seu próprio endereço rua=mailto: ao registro.

O que não muda

Envios manuais, envios agendados, e-mails de ciclo de vida (avisos de pedido/chamado) e a Send API transacional passam pelo método de envio configurado na sua conta — não há configuração separada por recurso. Supressão, histórico de envio, rastreamento de interação e respostas funcionam de forma idêntica, independentemente de qual método entregou o e-mail.

Modo sandbox

Enquanto sua conta estiver no sandbox do SES, o envio nativo só alcança endereços que você tenha verificado separadamente com a gente — isso serve para testar sua própria entrega antes de solicitarmos acesso de produção em seu nome. O cartão de Configurações sempre mostra um aviso em linguagem simples enquanto o modo sandbox estiver em vigor.