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.
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 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.