SPF, DKIM & DMARC para Mailtrap.
O Mailtrap autentica seu domínio por meio de verificação de domínio baseada em CNAME, e não fazendo você colar uma linha SPF compartilhada. No produto Email Sending, você adiciona um domínio de envio e o Mailtrap entrega cinco registros DNS na página Domain Verification: um CNAME de Domain Verification (que também cobre SPF/return-path), dois CNAMEs de DKIM nos seletores rwmt1._domainkey e rwmt2._domainkey, um CNAME opcional de Custom Tracking Domain para rastreamento de abertura/clique com sua marca e um registro TXT de DMARC. Assim que eles resolverem, o Mailtrap assina e envia como se fosse seu próprio domínio, o DMARC passa com DKIM alinhado (e com SPF via seu próprio return-path) e você nunca precisa publicar nem manter um include SPF bruto. Um detalhe pega as pessoas de primeira: isso só se aplica ao Mailtrap Email Sending — o sandbox separado de Email Testing captura mensagens em uma caixa de entrada falsa e não precisa de nenhum DNS.
Por que autenticar o Mailtrap?
Verificar seu domínio de envio no Mailtrap é o portão entre a caixa de entrada e a pasta de spam — e o Mailtrap exige isso antes de enviar qualquer e-mail de produção. Enquanto um domínio não está verificado, o Mailtrap restringe um stream de Email Sending a mensagens de teste endereçadas ao e-mail da sua própria conta; destinatários reais ficam bloqueados. Além disso, o timing importa: 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 em 2025 a Microsoft começou a aplicar a mesma exigência para Outlook/Hotmail/Live — primeiro roteando e-mail em massa não conforme para a pasta lixo e depois avançando para a rejeição direta. Como o Mailtrap é um remetente transacional/API, um stream não verificado significa que seu e-mail ou não sai ou sai fracamente atribuível ao seu domínio — sem DKIM alinhado, sem passar no DMARC e com a reputação misturada à infraestrutura compartilhada do Mailtrap em vez da sua própria. Concluir a verificação de domínio resolve tudo isso de uma vez: os dois seletores DKIM rwmt assinam como d=yourdomain.com para que o DKIM alinhe, o CNAME de Domain Verification coloca o return-path do Mailtrap no seu próprio domínio para que o SPF passe e também alinhe, o DMARC passa em ambos os mecanismos e a reputação de envio que você constrói é acumulada para o seu domínio.
A realidade do SPF para o Mailtrap
O Mailtrap é um provedor de verificação de domínio baseada em CNAME, então para o seu domínio raiz NÃO há include SPF a adicionar — e a própria documentação do Mailtrap diz isso com todas as letras: "The SPF check for your mail is covered by the domain verification record. There is no need to add a separate SPF record on your sending domain." Eis o mecanismo. Quando você verifica um domínio de envio, um dos CNAMEs que o Mailtrap fornece é o registro Domain Verification, que serve também como host de return-path/bounce no seu próprio domínio e delega a consulta SPF para a infraestrutura de envio do Mailtrap. O registro SPF real e ativo do Mailtrap fica em _spf.smtp.mailtrap.live (v=spf1 ip4:45.158.83.0/24 ip4:5.181.200.0/24 … ~all) — mas você nunca publica isso por conta própria; o CNAME de Domain Verification resolve nele por você. Como esse host de return-path fica sob seu próprio domínio verificado, o SPF passa e alinha ao seu domínio organizacional sob alinhamento relaxado, o que é uma vantagem genuína sobre os remetentes CNAME puramente DKIM (Mailchimp, Klaviyo), nos quais o SPF nunca consegue alinhar. Duas coisas para saber. Primeiro, ignore qualquer orientação antiga para adicionar include:_spf.mailtrap.io — esse hostname não resolve como registro SPF de forma alguma, e mesmo o host de infraestrutura correto (_spf.smtp.mailtrap.live) não é algo que você cole na sua raiz; adicioná-lo manualmente apenas queimaria uma das suas 10 consultas DNS de SPF à toa. Segundo, se seu DNS estiver no Google Cloud DNS, o console dele ainda oferece um tipo de registro "SPF" legado — o Mailtrap diz explicitamente para você ignorá-lo (está obsoleto) e adicionar os quatro CNAMEs mais o TXT de DMARC normalmente. Efeito líquido no seu SPF raiz: o Mailtrap adiciona zero consultas DNS, então ele se acumula de forma limpa com o Google Workspace, o Microsoft 365 ou qualquer outro remetente que você já liste.
Duas maneiras de configurar
Verifique um subdomínio de envio dedicado (ex.: mail.yourdomain.com)
- Isola a reputação transacional/do Mailtrap do e-mail humano no seu domínio raiz, para que um erro de envio não consiga derrubar seu domínio principal.
- O DKIM assina como d=mail.yourdomain.com e, sob alinhamento relaxado do DMARC, ainda alinha ao seu domínio organizacional — então o DMARC passa.
- O CNAME de Domain Verification coloca o return-path no subdomínio, então o SPF também passa e alinha ali.
- Você ainda adiciona os quatro CNAMEs mais um TXT de DMARC; seu SPF raiz permanece intocado, adicionando zero consultas DNS.
Verifique o domínio raiz/organizacional (yourdomain.com)
- Mais simples se o Mailtrap for seu único ou principal remetente e você quiser que o e-mail apareça visivelmente do domínio nu.
- O DKIM e o return-path ficam diretamente no domínio organizacional, então o alinhamento é exato em vez de depender do modo relaxado.
- A reputação é compartilhada com tudo o mais que você envia da raiz — pondere isso se o e-mail humano do Google Workspace ou do Microsoft 365 também morar ali.
- Ainda zero consultas adicionadas ao seu SPF raiz, já que o Mailtrap usa o CNAME de Domain Verification, não um include na raiz.
Passo a passo
- 1
Abra o Email Sending, não o Email Testing
Faça login em mailtrap.io e certifique-se de estar no produto Email Sending (a seção da barra lateral para e-mail de saída real), não no Email Testing (o sandbox que captura mensagens para QA e não precisa de DNS). A verificação de domínio só existe para o Email Sending.
- 2
Adicione seu domínio de envio
Na navegação à esquerda, vá em Sending Domains e clique em Add Domain. Insira o domínio de onde você vai enviar (ex.: yourdomain.com, ou um subdomínio como mail.yourdomain.com se quiser isolar o e-mail transacional). O Mailtrap gera os registros DNS para esse nome exato.
- 3
Abra a página Domain Verification
Selecione o novo domínio para abrir sua página Domain Verification. Você verá os registros a publicar, cada um rotulado por finalidade: Domain Verification (CNAME), DKIM (dois CNAMEs), Custom Tracking / Domain Tracking (CNAME) e DMARC (TXT). Observe as colunas Type, Name e Value — o Name e o Value são gerados para a sua conta.
- 4
Adicione o CNAME de Domain Verification
Crie o registro Domain Verification como um CNAME usando o Name e o Value exatos que o Mailtrap mostra. Esse único registro comprova a titularidade e cobre SPF/return-path — é por isso que você não publica um registro SPF separado. Mantenha o tipo como CNAME; não o converta em TXT ou A.
- 5
Adicione os dois CNAMEs de DKIM
Crie dois registros CNAME: Name rwmt1._domainkey → Value rwmt1.dkim.mailtrap.io, e Name rwmt2._domainkey → Value rwmt2.dkim.mailtrap.io (use os valores exatos do seu dashboard). Dois seletores permitem que o Mailtrap rotacione as chaves DKIM sem que você precise mexer no DNS novamente. Esses CNAMEs são o que assina seu e-mail como d=yourdomain.com e carrega a aprovação do DMARC.
- 6
Adicione o CNAME de Custom Tracking Domain
Crie o CNAME de rastreamento (o Mailtrap normalmente mostra um Name como mt-link) apontando para o Value que ele fornece. Isso serve o rastreamento de abertura/clique e os links de descadastro a partir do seu próprio domínio em vez de um host do Mailtrap. É o único registro que você pode pular se não usar rastreamento de links, mas adicioná-lo mantém os links rastreados com a sua marca e evita a reputação de domínio compartilhado de um host genérico de rastreamento do Mailtrap.
- 7
Adicione o registro TXT de DMARC
Crie um único registro TXT no Name _dmarc com o valor que o Mailtrap mostra (uma política v=DMARC1; p=none; … ). Se o seu domínio já tiver um registro _dmarc, NÃO adicione um segundo — um domínio deve ter exatamente um registro DMARC; mantenha o existente em vez disso.
- 8
Corrija a duplicação de host e desative o proxy do Cloudflare
Muitos registradores anexam seu domínio automaticamente, então insira apenas o rótulo (rwmt1._domainkey, não rwmt1._domainkey.yourdomain.com) para evitar a duplicação — embora alguns painéis queiram a forma completa com sufixo, então combine com o que seu host espera. No Cloudflare, configure cada CNAME como DNS only (nuvem cinza); o Cloudflare ativa o proxy por padrão, e um CNAME com proxy (nuvem laranja) não resolve no Mailtrap, então a verificação falha.
- 9
Re-verifique o DNS no Mailtrap
De volta à página Domain Verification, clique em Re-check DNS Records. O Mailtrap também verifica automaticamente de tempos em tempos, então os registros mudam de Missing (vermelho) para Verified (verde) conforme se propagam — normalmente minutos, mas reserve de 15 minutos a 24–48 horas. Alguns registros verificam antes de outros; aguarde até que todos estejam verdes.
- 10
Envie um teste e leia os cabeçalhos
Envie uma mensagem de um endereço no domínio verificado, abra no Gmail e escolha ⋮ → Show original. Confirme DKIM: PASS assinado por yourdomain.com (seletor rwmt1 ou rwmt2), SPF: PASS e DMARC: PASS — todos alinhados ao seu domínio, não a um host mailtrap.io.
Registros a adicionar
O Mailtrap 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 |
|---|---|---|
| CNAME | (Mailtrap-generated verification host) | (per-account target, e.g. under smtp.mailtrap.live)Registro de Domain Verification — ilustrativo. O Mailtrap mostra o Name e o Value exatos por conta na página Domain Verification. Esse CNAME também cobre SPF/return-path, e é por isso que nenhum registro SPF separado é necessário. |
| CNAME | rwmt1._domainkey | rwmt1.dkim.mailtrap.ioChave DKIM 1 (rotacionada automaticamente). Copie o valor exato do seu dashboard; alguns hosts DNS precisam da forma com sufixo rwmt1._domainkey.yourdomain.com. |
| CNAME | rwmt2._domainkey | rwmt2.dkim.mailtrap.ioChave DKIM 2 — o segundo seletor permite que o Mailtrap rotacione as chaves. Use o alvo exato exibido no seu dashboard. |
| CNAME | mt-link | (per-account tracking target)Custom Tracking Domain — host/alvo ilustrativo. Habilita o rastreamento de abertura/clique com sua marca e os links de descadastro no seu domínio. Opcional, mas recomendado; o Name/Value exato é exibido por conta. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comPolítica DMARC — uma por domínio. O Mailtrap pré-preenche um valor p=none; mantenha apenas um registro _dmarc e aperte para quarantine/reject mais tarde. |
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 Mailtrap consome desse limite.
A configuração recomendada do Mailtrap adiciona 0 consultas — todas as 10 ficam livres para os remetentes que realmente precisam de um include.
DKIM
O DKIM é tratado por dois registros CNAME — rwmt1._domainkey e rwmt2._domainkey — que o Mailtrap gera para o seu domínio, apontando para rwmt1.dkim.mailtrap.io e rwmt2.dkim.mailtrap.io respectivamente (copie os valores exatos da página Domain Verification). Como esses são CNAMEs delegados ao Mailtrap — e não registros TXT que você cola — o Mailtrap mantém as chaves privadas e usa os dois seletores para rotacionar as chaves publicadas por trás deles sem que você precise editar o DNS novamente. Não há chave pública DKIM para copiar nem seletor para inventar. O DKIM é o mecanismo que faz o trabalho pesado do DMARC aqui: assim que os CNAMEs resolvem, o Mailtrap assina o e-mail de saída como d=yourdomain.com, de modo que a assinatura alinha ao seu domínio organizacional e satisfaz o DMARC por conta própria — independentemente de encaminhamento, que pode quebrar o SPF. Alguns detalhes práticos: mantenha o tipo do registro como CNAME (um TXT onde se espera um CNAME quebra a validação); insira apenas o rótulo (rwmt1._domainkey) se o seu painel anexa o domínio automaticamente, ou o rwmt1._domainkey.yourdomain.com completo se não anexa; e no Cloudflare configure ambos como DNS only (nuvem cinza) para que resolvam nos alvos mailtrap.io. Você adiciona os dois CNAMEs, clica em Re-check DNS Records e as linhas de DKIM ficam verdes.
DMARC
O DMARC é um registro de política separado no seu domínio, e o Mailtrap o inclui no conjunto de registros na página Domain Verification — normalmente pré-preenchido como v=DMARC1; p=none; … . Publique-o como um registro TXT em _dmarc.yourdomain.com. p=none é apenas monitoramento: não muda nada na entrega enquanto você confirma, pelos relatórios agregados (rua), que o e-mail do Mailtrap está passando em DKIM (e SPF) alinhado ao seu domínio. Como o Mailtrap fornece tanto DKIM alinhado (os seletores rwmt) quanto um return-path alinhado (o CNAME de Domain Verification), um domínio corretamente verificado passa no DMARC em ambos os mecanismos — a configuração resiliente que sobrevive ao encaminhamento. Acompanhe os relatórios por uma ou duas semanas, certifique-se de que todo remetente legítimo autentica e então aperte para p=quarantine e, por fim, p=reject. Duas regras: mantenha exatamente um registro _dmarc para todo o domínio, não importa quantos remetentes você use — se você já tiver um, não adicione a segunda cópia do Mailtrap, apenas mantenha o seu — e aponte o rua para uma caixa de correio (ou um serviço de relatórios DMARC) que você realmente monitore, ou p=none não estará fazendo nada por você.
Confirme que funcionou de verdade
Não confie apenas no selo verde "Verified" na página Domain Verification — isso só confirma que os registros resolvem, não que uma mensagem real autentica. Envie a si mesmo um teste de um endereço no domínio verificado, abra no Gmail e escolha ⋮ → Show original: você quer DKIM: PASS assinado por yourdomain.com com o seletor rwmt1 ou rwmt2, SPF: PASS e DMARC: PASS, todos exibindo o seu domínio em vez de um host mailtrap.io. No Mailtrap, use o botão Re-check DNS Records para forçar uma verificação em vez de esperar pela checagem periódica. Você pode conferir os registros brutos com dig CNAME rwmt1._domainkey.yourdomain.com e dig TXT _dmarc.yourdomain.com. Depois, passe seu domínio pelo {healthCheck} da Qualisend para confirmar que o CNAME de Domain Verification, ambos os seletores DKIM, o CNAME de rastreamento e o registro DMARC resolvem todos sem problemas e que 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 {dmarcAnalyzer}, onde o Mailtrap deve aparecer como uma fonte alinhada e aprovada.
Pegadinhas comuns
- Cobertura
Email Testing vs Email Sending: a verificação de domínio só existe para o produto Email Sending. O sandbox de Email Testing captura mensagens em uma caixa de entrada falsa para QA e não precisa de nenhum registro DNS — se você está procurando uma configuração de DNS no Email Testing, está no lugar errado.
- Configuração de DNS
Não há registro SPF a adicionar. O CNAME de Domain Verification do Mailtrap já cobre SPF/return-path, então não cole include:_spf.mailtrap.io (não resolve) nem include:_spf.smtp.mailtrap.live (host de infraestrutura interno do Mailtrap) na sua raiz — fazer isso desperdiça uma consulta SPF e a documentação do Mailtrap diz explicitamente que um registro SPF separado não é necessário.
- Configuração de DNS
O proxy do Cloudflare quebra a verificação: configure cada CNAME do Mailtrap como DNS only (nuvem cinza). O Cloudflare ativa o proxy de nuvem laranja por padrão, e um CNAME com proxy não resolve nos alvos mailtrap.io / mailtrap.live, então os registros nunca verificam.
- Configuração de DNS
Duplicação no campo de host: muitos registradores anexam seu domínio automaticamente, então rwmt1._domainkey pode virar rwmt1._domainkey.yourdomain.com.yourdomain.com. Insira apenas o rótulo se o painel adiciona o domínio; por outro lado, alguns hosts (certos painéis no estilo Squarespace) querem a forma completa com sufixo — combine com o que seu provedor espera.
- Configuração de DNS
Todo registro é um CNAME, exceto o DMARC (TXT) — não troque os tipos. No Google Cloud DNS especificamente, ignore o tipo de registro 'SPF' legado do console; o Mailtrap observa que ele está obsoleto. Adicione os quatro CNAMEs e o único TXT de DMARC.
- Cobertura
Enquanto o domínio não está Verified, o Mailtrap só deixa um stream de Email Sending entregar mensagens de teste ao endereço de e-mail da sua própria conta. Os envios de produção para destinatários reais permanecem bloqueados, então conclua a verificação antes de conectar o Mailtrap ao tráfego ativo do seu app.
- Configuração de DNS
Mantenha um DMARC e um SPF. Se você também envia via Google Workspace, Microsoft 365, SendGrid etc., não adicione um segundo _dmarc nem um segundo TXT de SPF — o Mailtrap adiciona zero ao seu SPF raiz, então apenas mantenha seus registros únicos existentes.
- Cobertura
A verificação não é instantânea: a propagação pode levar de 15 minutos a 24–48 horas, e o Mailtrap re-verifica no seu próprio cronograma. Use o Re-check DNS Records para forçar uma verificação e espere que alguns registros fiquem verdes antes de outros.
Monte seu registro SPF
O Mailtrap 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.
Fontes de envio
Pesquise cada plataforma pela qual você envia e-mail e marque-a.
Pesquise sua plataforma de e-mail acima ou .
Os servidores próprios deste domínio
Autorize o próprio domínio, se ele envia e-mail diretamente (não por uma plataforma acima).
Outros remetentes e IPs
Qualquer coisa fora da lista — o host SPF de outro provedor ou endereços IP específicos.
Nós adicionamos o prefixo include: — informe o nome de host que seu provedor documenta.
Política para todos os demais
O que os destinatários devem fazer com e-mails de qualquer servidor não listado acima (o mecanismo all).
Ainda não há remetentes, então cada mensagem seria tratada pela política ~all. Adicione na etapa 1 as plataformas pelas quais você envia.
- Publique-o como um registro TXT no seu domínio raiz — host @ (o domínio puro), valor a string completa acima.
- Mantenha apenas um registro SPF por domínio. Mescle toda fonte de envio nesta única linha — um segundo registro TXT começando com v=spf1 invalida os dois.
- Fique em 10 consultas DNS ou menos. Cada include:, a e mx conta, e um include pode disparar mais consultas dentro de si — ip4: e ip6: são gratuitos.
Autenticação publicada? O próximo passo é enviar para uma lista limpa e verificada.
Verificar uma listaSPF do Mailtrap — 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.