O plano gratuito do SendGrid acabou: guia de migração em 30 minutos

O fim do plano gratuito para sempre

Se você dependia do plano gratuito do SendGrid para um projeto paralelo de baixo volume ou um produto novo, provavelmente notou a mudança: o plano gratuito agora é um teste de 60 dias. Quando o teste expira, você precisa passar para um plano pago, com o Essentials a partir de 19.95 USD por mês (SendGrid Pricing). Para migrar, você precisa exportar suas supressões, atualizar seus registros DNS e trocar a integração de API. O processo leva cerca de 30 minutos se seus templates forem simples.

Avaliando as alternativas

Ao escolher um substituto, diferencie a aceitação pelo provedor (a API aceitar sua requisição), a entrega (o servidor receptor aceitar o e-mail) e a chegada à caixa de entrada (o e-mail não cair na pasta de spam). Nenhum provedor consegue garantir esta última, porque ela depende da reputação do remetente e do conteúdo.

O cenário de custos (setembro de 2026)

Para e-mails transacionais de baixo volume, a diferença de preço é significativa. Enviar 50.000 e-mails custa cerca de 5 USD no Amazon SES na modalidade avulsa, contra aproximadamente 66 USD nos planos do Postmark.

• Amazon SES: custa 0.10 USD por 1.000 e-mails na modalidade avulsa (AWS SES Pricing). Os novos planos em níveis, lançados em 21 de julho de 2026, incluem Essentials (0.16 USD por 1.000), Pro (0.22 USD por 1.000 mais 105 USD por mês por região) e Enterprise (0.23 USD por 1.000 mais 500 USD por mês).
• Resend: oferece um plano gratuito de 3.000 e-mails por mês, limitado a 100 por dia. O plano Pro custa 20 USD por mês para 50.000 e-mails, com excedente de 0.90 USD por 1.000 (Resend Pricing).
• Mailgun: a partir de 15 USD por mês para 10.000 e-mails, com excedente de 1.80 a 1.10 USD por 1.000 (Mailgun Pricing).
• Postmark: a partir de 15 USD por mês para 10.000 e-mails, com excedente de 1.80 a 1.20 USD por 1.000 (Postmark Pricing).
• SendHQ: uma alternativa moderna para equipes de produto e agentes de IA, com foco em telemetria minimizada para privacidade e hospedada apenas na UE, além de chaves de API com escopo por workspace.

Passo 1: exportação de dados e listas de supressão

Não migre sua lista sem exportar suas supressões. Se você enviar para um endereço que já deu bounce ou se descadastrou, corre o risco de prejudicar sua reputação no novo provedor.

O SendGrid permite exportar sua lista de supressão pela interface ou pela API. Você receberá um CSV com os e-mails que não devem ser contatados. Ao importá-los em um novo provedor, mapeie corretamente o "motivo" (bounce ou descadastro) para continuar em conformidade com leis como a GDPR ou a CAN-SPAM.

Passo 2: DNS e autenticação

É aqui que a maioria das migrações falha. Não basta trocar a chave de API; você precisa provar ao novo provedor que é o dono do domínio.

DKIM, SPF e DMARC

Você vai precisar adicionar novos registros CNAME ou TXT no seu provedor de DNS. Se estiver migrando para o SendHQ, pode usar o Verificador de DNS de e-mail para conferir a configuração atual antes de fazer mudanças.

1. SPF: atualize seu registro SPF para incluir o novo provedor. Se você usa vários provedores, lembre-se de que não é possível ter vários registros TXT de SPF. É preciso combiná-los em um só (por exemplo, v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all). Para se aprofundar, consulte o verbete de SPF no glossário.
2. DKIM: gere novas chaves DKIM no painel do novo provedor e adicione os registros CNAME resultantes ao seu DNS. Isso garante que o servidor receptor consiga verificar que o e-mail não foi adulterado no caminho.
3. DMARC: sua política DMARC continua a mesma, independentemente do provedor, porque é uma política no nível do domínio. Mesmo assim, garanta que o novo provedor esteja alinhado à sua política DMARC para evitar que os e-mails sejam rejeitados. Consulte o guia de DKIM, SPF e DMARC para os detalhes de implementação.

Passo 3: migração do código

A maioria dos provedores usa uma API REST. Se você usava os templates dinâmicos do SendGrid, vai precisar migrar esses layouts HTML/CSS para o mecanismo de templates do novo provedor.

Exemplo: do SendGrid para uma API REST genérica

O SendGrid usa uma estrutura JSON específica para personalizations. A maioria das APIs modernas, incluindo o SendHQ, prefere uma estrutura mais plana, que é mais fácil de ler.

Payload do SendGrid:

{ "personalizations": [ { "to": [{"email": "user@example.com"}], "dynamic_template_data": { "first_name": "Alice" } } ], "from": {"email": "noreply@yourdomain.com"}, "template_id": "d-12345" }

Payload de uma API moderna (por exemplo, SendHQ):

{ "to": "user@example.com", "from": "noreply@yourdomain.com", "template_id": "welcome-email", "variables": { "first_name": "Alice" } }

Como conduzir a migração no código

Para evitar downtime, implemente um wrapper ou o padrão Strategy. Assim você alterna entre provedores usando uma variável de ambiente.

interface EmailProvider { send(payload: EmailPayload): Promise<void>; } class SendGridProvider implements EmailProvider { async send(payload: EmailPayload) { // SendGrid specific implementation } } class SendHQProvider implements EmailProvider { async send(payload: EmailPayload) { // SendHQ specific implementation } } const provider = process.env.EMAIL_PROVIDER === 'sendhq' ? new SendHQProvider() : new SendGridProvider();

Passo 4: agentes de IA e idempotência

Se você usa agentes de IA para disparar e-mails, enfrenta um risco específico: o agente pode entrar em loop ou repetir uma requisição várias vezes por causa de um timeout, e o usuário acaba recebendo dez e-mails idênticos.

Enviar um e-mail é um efeito colateral externo. Você precisa implementar idempotência. Uma chave de idempotência é um identificador único enviado no cabeçalho que diz à API: "Se você já viu esta chave, não envie o e-mail de novo; apenas retorne a resposta de sucesso original."

Implementação pronta para agentes:

{ "headers": { "Idempotency-Key": "order_123_welcome_email" }, "body": { "to": "customer@example.com", "template_id": "order-confirmation" } }

Além disso, para ações de agentes de alto risco (como enviar uma redefinição de senha ou um alerta de cobrança), implemente uma etapa de aprovação com humano no circuito ou um limite de taxa rígido por ID de usuário, para evitar que alucinações do agente inundem seus clientes de spam.

Passo 5: testes e validação

Antes de apontar a variável de ambiente para o novo provedor, percorra este checklist:

• Propagação de DNS: use uma ferramenta como o dig ou um verificador na web para confirmar que seus novos registros DKIM e SPF estão ativos.
• Verificação de webhooks: se você depende de eventos de entrega (delivered, opened, clicked), atualize seus endpoints de webhook. O formato de eventos do SendGrid é diferente dos demais. Garanta que seu endpoint consiga lidar com o novo schema JSON sem quebrar.
• Tratamento de erros: teste como sua aplicação lida com erros específicos do provedor. Por exemplo, um 429 (Too Many Requests) deve acionar uma estratégia de backoff, enquanto um 400 (Bad Request) geralmente indica um endereço de e-mail malformado, que deve ser marcado como bounce no seu banco de dados.

Casos de erro comuns para testar

1. Formato de e-mail inválido: garanta que a API retorne um erro claro e que seu código não tente de novo indefinidamente.
2. Limite de taxa: simule uma rajada de e-mails para ver se sua fila respeita os limites do provedor.
3. Anexos grandes: verifique o tamanho máximo de payload do novo provedor. Alguns limitam a 10MB, outros a 25MB.

Checklist-resumo da migração

• Exportar supressões: Exportação CSV do SendGrid.
• Configurar registros DNS: Alinhamento de SPF, DKIM e DMARC.
• Migrar templates: Converta HTML/CSS para o novo formato.
• Atualizar a lógica da API: Implemente um wrapper de provedor.
• Adicionar idempotência: Essencial para gatilhos de agentes de IA.
• Testar webhooks: Verifique a entrega e o parsing de eventos.
• Alternar tráfego: Atualize a variável ENV e monitore os logs.

Considerações finais sobre entregabilidade

Trocar de provedor é um ótimo momento para auditar seus hábitos de envio. Lembre-se de que a aceitação pelo provedor é só o primeiro obstáculo. A entrega depende de o ISP receptor (Gmail, Outlook etc.) aceitar a conexão. A chegada à caixa de entrada é o obstáculo final, determinado pela reputação de longo prazo do seu domínio e pelas taxas de engajamento dos destinatários.

Resista à tentação de usar essas APIs para e-mails em massa não solicitados. Além de muitas vezes ser ilegal, isso vai levar à suspensão da sua conta, seja qual for o provedor escolhido. Limite-se a comunicações transacionais e com opt-in para manter uma boa pontuação de remetente.

Para equipes que constroem aplicações nativas de IA, procure provedores com recursos para agentes, como servidores MCP e arquivos llms.txt, que deixam a integração fluida. O SendHQ foi projetado exatamente para esse fluxo e oferece a infraestrutura de que as equipes de produto modernas precisam.

Saiba mais sobre como construir sistemas de e-mail confiáveis em https://sendhq.cc.