SPF, DKIM & DMARC para Resend.
O Resend é uma API de e-mail que coloca o desenvolvedor em primeiro lugar, e autentica o seu domínio com um pequeno conjunto de registros DNS gerados por domínio — não uma linha SPF compartilhada que você cola. Quando você adiciona um domínio, o Resend exibe três registros: um DKIM TXT em resend._domainkey (uma chave de assinatura que ele gera para você), além de um SPF TXT e um registro MX que vivem em um subdomínio send. atuando como o seu return path. Nos bastidores, o Resend roda sobre o Amazon SES, mas esconde os CNAMEs do Easy-DKIM do SES por trás de sua própria chave DKIM única. Assim que esses três registros resolvem, o Resend assina o e-mail como o seu próprio domínio — o DKIM tem alinhamento estrito com d=yourdomain.com, o SPF tem alinhamento relaxado via o subdomínio send, e o DMARC passa em ambos.
Por que autenticar o Resend?
Autenticar o seu domínio no Resend é a diferença entre a caixa de entrada e a pasta de spam — e, até você fazer isso, só é possível enviar a partir do domínio de teste compartilhado do Resend, onboarding@resend.dev, que não é seu de forma alguma. Desde fevereiro de 2024, o Gmail e o Yahoo passaram a exigir que todo remetente em massa (aproximadamente 5.000+ mensagens por dia) passe em SPF, DKIM e DMARC com alinhamento, e a Microsoft começou a aplicar a mesma regra em e-mails de alto volume enviados ao Outlook/Hotmail em 2025. O Resend costuma ser conectado justamente ao tipo de e-mail que essas regras julgam com mais rigor — redefinições de senha, recibos, códigos de verificação e, cada vez mais, disparos de marketing — em que uma única ida para o spam quebra um fluxo de cadastro. O Resend deixa isso excepcionalmente limpo: como ele coloca o SPF/return path em um subdomínio send. do SEU domínio (em vez de ser dono de um domínio de bounce como o Mailchimp ou a configuração legada do SendGrid fazem), o SPF de fato alinha no modo relaxado, e o seletor DKIM resend assina como o seu próprio domínio, então o DKIM alinha de forma estrita. Publique os registros e um domínio Resend passa no DMARC em ambos os mecanismos — a configuração resiliente que sobrevive ao encaminhamento. Pule essa etapa e o e-mail ou sai como resend.dev ou fica sem autenticação, com a reputação misturada em uma infraestrutura compartilhada.
A realidade do SPF para o Resend
O Resend é um provedor por conta, construído sobre o Amazon SES, então NÃO existe include compartilhado para o seu domínio raiz — e isso é proposital. Quando você adiciona um domínio, o Resend provisiona um subdomínio send. (o MAIL FROM personalizado / domínio de envelope do SES) e coloca o registro SPF ali: send.yourdomain.com recebe v=spf1 include:amazonses.com ~all, e o MX correspondente (feedback-smtp.{region}.amazonses.com) captura bounces e reclamações. O SPF do seu domínio raiz nunca é tocado — o Resend adiciona ZERO consultas de DNS a ele. Duas coisas tornam isso melhor do que a maioria dos ESPs. Primeiro, como o return path é um subdomínio do seu próprio domínio, e não um domínio de bounce pertencente ao Resend, o SPF alinha para o DMARC no modo relaxado (send.yourdomain.com compartilha o domínio organizacional yourdomain.com). Segundo, o Resend não usa os três seletores CNAME do Easy-DKIM do SES — ele gera sua própria chave DKIM e publica um único TXT em resend._domainkey.yourdomain.com, assinando com d=yourdomain.com, então o DKIM alinha de forma estrita. Ou seja, a realidade é: nada vai no seu SPF raiz, o include:amazonses.com que você vê pertence apenas ao subdomínio send, e é o DKIM (não um include na raiz) que carrega o alinhamento mais forte. Se algum tutorial antigo mandar você adicionar include:amazonses.com à sua raiz, ignore — isso não faz nada pelo Resend, queima uma das 10 consultas SPF da sua raiz e autoriza desnecessariamente todo o SES a enviar como o seu apex.
Passo a passo
- 1
Adicione o seu domínio (e escolha uma região)
Faça login em resend.com, abra Domains no menu à esquerda e clique em Add Domain. Insira o seu domínio de envio — seja o seu apex (yourdomain.com) ou, melhor ainda, um subdomínio de envio dedicado como updates.yourdomain.com — e então escolha a região AWS mais próxima dos seus usuários (N. Virginia us-east-1, Irlanda eu-west-1, São Paulo sa-east-1 ou Tóquio ap-northeast-1). A região fica embutida no host MX e não pode ser alterada depois sem excluir e readicionar o domínio, então escolha com cuidado.
- 2
Abra a aba Records
O Resend gera os registros DNS para você e os lista na aba Records/DNS do domínio: um DKIM TXT (resend._domainkey), um SPF TXT no subdomínio send e um MX no subdomínio send. Se você já roda um serviço em send.yourdomain.com, use a opção Custom Return Path para escolher um subdomínio diferente antes de copiar os registros.
- 3
Adicione o registro DKIM TXT
No seu host de DNS, crie um registro TXT com host resend._domainkey e o longo valor de chave pública que o Resend exibe (começando com p=). Este é o registro que alinha estritamente o seu e-mail a d=yourdomain.com, então cole o valor exatamente — uma chave colada parcialmente ou com aspas reinseridas é o motivo mais comum de um domínio com aparência correta ainda falhar no DKIM. Note que ele fica no seletor na sua raiz (ou subdomínio de envio), não sob send.
- 4
Adicione o SPF TXT no subdomínio send
Crie um registro TXT com host send (ou seja, send.yourdomain.com) e valor v=spf1 include:amazonses.com ~all. Isso autoriza o envelope do SES para o return path — deixe o seu SPF raiz em paz e NÃO adicione include:amazonses.com a ele. Se o seu registrador acrescenta o domínio automaticamente, insira apenas send, não send.yourdomain.com.
- 5
Adicione o registro MX no subdomínio send
Crie um registro MX com host send, prioridade 10 e valor feedback-smtp.{region}.amazonses.com correspondente à região que você escolheu (por exemplo, feedback-smtp.us-east-1.amazonses.com). Adicione um ponto final ao valor para que o seu registrador não acrescente o seu domínio a ele. Este MX só recebe o feedback de bounce/reclamação do SES — ele não muda para onde o seu e-mail de entrada normal é entregue.
- 6
Publique um registro DMARC
O Resend recomenda uma política DMARC mas não a cria para você. Adicione um registro TXT com host _dmarc e v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento, então nada muda na entrega enquanto você confirma o alinhamento. Mantenha exatamente um registro _dmarc por domínio.
- 7
Clique em Verify DNS Records
De volta ao Resend, clique em Verify DNS Records. A propagação costuma levar minutos, mas pode demorar até 72 horas; o status muda para Verified assim que os três registros resolvem. Se travar, verifique novamente se há um host duplicado, um MX com região incompatível ou um ponto final faltando e, então, verifique de novo.
- 8
Envie um teste real e leia os cabeçalhos
Verified no painel não é prova de que o e-mail está alinhado. Envie uma mensagem de um endereço no seu domínio verificado (não @resend.dev) para uma conta do Gmail, abra-a e escolha ⋮ → Exibir original. Você quer SPF: PASS (mailed-by um host send.yourdomain.com), DKIM: PASS com signed-by: yourdomain.com e seletor resend, e DMARC: PASS — tudo apontando para o seu domínio, não resend.dev ou amazonses.com.
Registros a adicionar
O Resend gera os valores exatos no seu assistente de configuração — estes mostram o formato do que você vai adicionar no seu provedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | resend._domainkey | p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(long public key from Resend)Chave pública DKIM, seletor resend, no seu domínio raiz/de envio — isso alinha estritamente o e-mail a d=yourdomain.com. Ilustrativo; a chave real de 1024 bits é gerada por domínio e exibida como uma única string p=… (sem prefixo v=DKIM1) — cole-a exatamente como mostrado. |
| TXT | send | v=spf1 include:amazonses.com ~allSPF para o subdomínio send (o envelope / MAIL FROM do SES). Vive em send.yourdomain.com, NÃO na sua raiz — não adicione include:amazonses.com ao SPF do seu apex. |
| MX | send | feedback-smtp.us-east-1.amazonses.comReturn path para bounces/reclamações do SES — prioridade 10, no subdomínio send, com um ponto final. Específico da região: a região corresponde à que você escolheu ao adicionar o domínio (us-east-1 / eu-west-1 / sa-east-1 / ap-northeast-1). |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê adiciona isto por conta própria — o Resend apresenta uma política recomendada, mas nunca a grava no DNS. Um por domínio; comece em p=none e depois aperte. |
Mantenha exatamente um registro TXT de SPF (v=spf1) no seu domínio raiz — combine todos os remetentes nele. Ter dois registros SPF já é, por si só, um erro.
O limite de 10 consultas de DNS
O SPF tem um limite rígido de 10 consultas de DNS — se passar disso, ele retorna um permerror e para de validar em todo lugar. Veja quanto a configuração do Resend consome desse limite.
A configuração recomendada do Resend adiciona 0 consultas — todas as 10 ficam livres para os remetentes que realmente precisam de um include.
DKIM
O DKIM é o registro mais importante em uma configuração Resend, e é onde o Resend silenciosamente diverge do Amazon SES puro. Mesmo o Resend rodando sobre o SES, ele NÃO entrega os três seletores CNAME do Easy-DKIM do SES. Em vez disso, o Resend gera seu próprio par de chaves DKIM por domínio e fornece um único registro TXT: host resend._domainkey.yourdomain.com, valor a chave pública (uma string p=… que ele exibe na aba Records), seletor resend. O Resend mantém a chave privada correspondente e assina cada mensagem com d=yourdomain.com; s=resend. Como esse d= é o seu próprio domínio — não amazonses.com e não um domínio pertencente ao Resend — o DKIM alinha de forma estrita para o DMARC, e continua passando mesmo quando uma mensagem é encaminhada (que é exatamente quando o SPF costuma quebrar). Duas observações práticas. Primeiro, este é um registro TXT que você publica, e não uma delegação CNAME, então o Resend não pode rotacionar a chave silenciosamente como fazem os provedores CNAME — se você algum dia rotacionar, você republica o novo valor. Segundo, cole o valor exatamente como o Resend mostra. Como o Resend assina com uma chave de 1024 bits, o valor p= é uma única string de ~216 caracteres que cabe abaixo do limite de 255 caracteres por string do TXT no DNS — então, ao contrário das chaves mais longas de 2048 bits que alguns provedores entregam, ela NÃO é dividida em várias strings entre aspas; cole-a como um único valor ininterrupto. Uma cópia parcial, um espaço inserido ou um par extra de aspas que o seu painel de DNS coloca em volta da string é a causa número um de um domínio que parece configurado mas ainda falha em uma verificação de DKIM. O registro DKIM fica no seletor na sua raiz (ou no seu subdomínio de envio) — não sob o subdomínio send, onde vivem o SPF e o MX.
DMARC
O DMARC é um registro de política separado que o Resend recomenda mas não cria para você — você o adiciona no seu host de DNS. Publique um registro TXT em _dmarc.yourdomain.com começando com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento: não muda nada na entrega, mas diz aos receptores para lhe enviarem relatórios agregados (rua) por e-mail, para que você possa confirmar que o e-mail do Resend está passando em SPF e DKIM alinhados ao seu domínio. O Resend se comporta bem aqui — você obtém alinhamento SPF relaxado via o subdomínio send E alinhamento DKIM estrito via o seletor resend — então você deve ver passagens de DMARC limpas quase imediatamente, e pode com segurança adicionar adkim=s (alinhamento DKIM estrito) se quiser, já que d=yourdomain.com corresponde exatamente ao seu domínio de From. Acompanhe os relatórios por uma ou duas semanas, certifique-se de que todo remetente legítimo (o Resend mais qualquer host de caixa de correio ou outras ferramentas) esteja autenticando e, então, avance a política de p=none para p=quarantine e, por fim, p=reject. Mantenha exatamente um registro _dmarc para todo o domínio organizacional, não importa quantos remetentes você opere — nunca adicione um segundo registro DMARC só para o Resend.
Confirme que funcionou de verdade
Não confie apenas no selo verde Verified do Resend — ele significa apenas que os três registros resolveram, não que uma mensagem real alinha. Envie um teste de um endereço no seu domínio verificado (por exemplo, no-reply@yourdomain.com, NÃO qualquer coisa @resend.dev) para uma conta do Gmail, abra-o e escolha ⋮ → Exibir original. Você quer SPF: PASS com mailed-by mostrando um host send.yourdomain.com, DKIM: PASS com signed-by: yourdomain.com e seletor resend, e DMARC: PASS — tudo atribuído ao seu domínio, e não a resend.dev ou amazonses.com. Se o DKIM aparecer como o seu domínio mas o SPF mostrar amazonses.com sem alinhar, verifique se os registros do subdomínio send estão no lugar. Você pode checar os registros brutos com dig TXT resend._domainkey.yourdomain.com, dig TXT send.yourdomain.com e dig MX send.yourdomain.com. Por fim, passe o domínio pelo verificador de saúde de domínio da Qualisend para confirmar que todos os registros resolvem e que o seu SPF raiz permanece abaixo do limite de 10 consultas e, assim que os relatórios agregados de DMARC começarem a chegar, jogue um deles no analisador de relatórios DMARC — o Resend/Amazon SES deve aparecer como uma fonte alinhada e aprovada.
Pegadinhas comuns
- Cobertura
Os registros do Resend vivem no subdomínio send, não na sua raiz. Registradores que acrescentam o domínio automaticamente transformam send em send.yourdomain.com.yourdomain.com e resend._domainkey em um host duplicado — insira apenas os rótulos (send, resend._domainkey) e deixe o painel adicionar o domínio.
- Cobertura
O valor do MX é específico da região e precisa corresponder à região que você escolheu ao adicionar o domínio. Um domínio eu-west-1 com um MX feedback-smtp us-east-1 não vai verificar — e você não pode mudar a região de um domínio após criá-lo; exclua e readicione na nova região e, então, atualize o MX.
- Cobertura
Adicione um ponto final ao valor do MX (feedback-smtp.{region}.amazonses.com.) para que o seu registrador não acrescente o seu domínio e produza feedback-smtp.us-east-1.amazonses.com.yourdomain.com.
- Quebra a autenticação
Não adicione include:amazonses.com ao seu SPF RAIZ. O SPF do Resend pertence ao subdomínio send; um include na raiz não faz nada pelo Resend, desperdiça uma das suas 10 consultas SPF da raiz e autoriza todo o Amazon SES a enviar como o seu apex.
- Configuração de DNS
O Resend é construído sobre o SES mas NÃO usa os três CNAMEs do Easy-DKIM do SES — ele publica um único DKIM TXT (seletor resend) que ele gera. Não fique procurando seletores CNAME; cole a chave TXT única exatamente, já que uma chave colada parcialmente ou com aspas reinseridas é a principal razão de o DKIM ainda falhar em um domínio 'configurado'. É uma chave de 1024 bits, então o valor cabe em uma string — não a divida.
- Cobertura
Os endereços compartilhados @resend.dev (onboarding@resend.dev, delivered@resend.dev, etc.) servem apenas para testar a API — eles não são o seu domínio e lhe dão zero alinhamento de SPF/DKIM. Você precisa adicionar e verificar o seu próprio domínio para enviar como você mesmo.
- Configuração de DNS
Estes são registros TXT e MX, não CNAMEs, então não há a armadilha do proxy nuvem-laranja do Cloudflare — mas, se o Cloudflare já criou automaticamente um SPF na sua raiz, deixe-o em paz; o SPF do Resend é separado e vive no subdomínio send.
- Cobertura
Se você já roda e-mail ou um serviço em send.yourdomain.com (um SPF, MX ou subdomínio existente), use o recurso Custom Return Path do Resend para escolher um subdomínio de return path diferente, em vez de colidir com o que já está lá.
Monte seu registro SPF
O Resend não precisa de um include: de SPF no seu domínio raiz — use o gerador para montar um único registro limpo para os seus outros remetentes, e mantenha tudo em uma só linha.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF do Resend — Perguntas frequentes
Leituras relacionadas
Depois de publicado, confirme se tudo resolve corretamente com o verificação de saúde do domínio e, em seguida, veja quem está enviando em seu nome com o analisador de relatórios DMARC. Explore todas as fontes de envio no gerador. A autenticação, porém, é só metade da entregabilidade — um IP ou domínio de envio que esteja listado ainda te joga no spam por mais limpo que seu SPF esteja, então vale a pena acompanhar as blacklists com o monitoramento de blacklists.
Autenticado — agora mantenha a lista limpa
Passar em SPF, DKIM e DMARC te leva à caixa de entrada; uma lista limpa te mantém lá. Verifique a sua — comece grátis com 100 créditos, sem precisar de cartão.