Skip to content
Comece com 100 créditos de verificação grátis
Qualisend
Guia de configuração de SPF

SPF, DKIM & DMARC para Purelymail.

A Purelymail é um provedor de caixa de correio de baixo custo e focado em privacidade, que autentica o seu domínio com um include SPF genuíno, DKIM delegado por CNAME e — algo incomum — um registro DMARC gerenciado pela Purelymail. No portal Account Admin (purelymail.com/manage) você adiciona o seu domínio e ela lhe entrega uma lista curta e fixa de registros: um TXT de comprovação de propriedade, um MX, um SPF TXT construído em torno de include:_spf.purelymail.com, três CNAMEs de DKIM e um CNAME de DMARC. Publique-os no seu provedor de DNS, clique em "Check DNS records" e a Purelymail envia e recebe como se fosse o seu próprio domínio, com SPF e DKIM ambos alinhados. A única decisão a tomar de forma deliberada é o DMARC: aceitar o CNAME gerenciado com p=reject da Purelymail ou publicar o seu próprio registro para que os relatórios cheguem até você.

SPF include
Your DNSAdd the CNAME / TXT records
PurelymailSigns & sends as your domain
The inboxSPF · DKIM · DMARC pass

Por que autenticar o Purelymail?

Autenticar um domínio na Purelymail não é mera burocracia — é o que decide se o seu e-mail chega à caixa de entrada e se alguém pode se passar por você. Desde fevereiro de 2024, o Gmail e o Yahoo exigem que todo remetente passe em SPF ou DKIM, e que todo remetente em massa (aproximadamente 5.000+ mensagens por dia) também publique DMARC com alinhamento; o Yahoo adotou as mesmas regras no mesmo mês e a Microsoft começou a fazer a aplicação no Outlook.com/Hotmail/Live em 2025. Enquanto os registros não estiverem ativos, o e-mail que você envia pela Purelymail só é fracamente atribuível ao seu domínio, o DMARC não consegue passar e um domínio registrado, mas desprotegido, é trivialmente falsificável. A Purelymail fica em uma posição excepcionalmente forte depois de configurada: como ela envia com o seu próprio domínio como remetente de envelope (Return-Path), o SPF alinha ao seu domínio organizacional e o DKIM assina como d=yourdomain.com, de modo que ambos os mecanismos passam alinhados — não apenas o DKIM, como acontece com a maioria dos ESPs. E o DMARC gerenciado da Purelymail já vem com p=reject, o que bloqueia ativamente e-mails falsificados no momento em que ele é resolvido. O detalhe é que uma política p=reject também rejeita qualquer remetente legítimo que você esqueça de autenticar, então a configuração recompensa quem faz os três registros de forma deliberada.

A realidade do SPF para o Purelymail

A Purelymail é um verdadeiro provedor de "include" — não é um ESP que delega por CNAME (Mailchimp, Klaviyo) e não é um relay que controla o Return-Path. Você adiciona um mecanismo compartilhado, include:_spf.purelymail.com, ao único registro SPF TXT no seu domínio raiz; o registro completo é v=spf1 include:_spf.purelymail.com ~all. Duas coisas dão peso real a esse SPF. Primeiro, o include resolve para um registro plano que contém apenas três endereços ip4 e o seu próprio ~all (verificado ao vivo: v=spf1 ip4:34.202.193.197 ip4:54.89.13.140 ip4:3.231.132.23 ~all) — não há includes aninhados — então ele custa exatamente UMA das suas 10 consultas de DNS do SPF, não as duas ou três que alguns verificadores presumem. Segundo, e ao contrário da maioria das plataformas de envio, a Purelymail usa o seu próprio domínio como remetente de envelope SMTP quando você envia como you@yourdomain.com, então o SPF de fato ALINHA ao seu domínio organizacional e contribui com um passe de DMARC por conta própria, junto com o DKIM. A Purelymail publica ~all (softfail), não -all, que é o padrão sensato enquanto você confirma que todo remetente está listado. As regras de sempre se aplicam: mantenha exatamente um registro SPF TXT na raiz — se você também envia pelo Google Workspace, Microsoft 365 ou um relay transacional, mescle cada include naquela única linha v=spf1 em vez de publicar um segundo registro SPF (dois registros SPF geram um PermError) — e apague qualquer SPF remanescente de um provedor de e-mail anterior.

Duas maneiras de configurar

Recomendado

Seu próprio registro DMARC (TXT) — controle + relatórios

  • Você publica v=DMARC1; p=none; rua=mailto:you@yourdomain.com e recebe os relatórios agregados você mesmo
  • Permite avançar de p=none → quarantine → reject depois de confirmar que todo remetente alinha
  • Seguro quando você também envia de uma ferramenta de newsletter, CRM ou formulário de site — você os vê nos relatórios antes de aplicar
  • Obrigatório se você usa qualquer remetente além da Purelymail, ou se quer visibilidade sobre quem envia como se fosse o seu domínio
Legado

DMARC gerenciado pela Purelymail (CNAME) — sem manutenção

  • Um único CNAME (_dmarc → dmarcroot.purelymail.com) dá um p=reject aplicado e instantâneo, sem manutenção
  • A Purelymail mantém a política atualizada para você; você nunca edita o registro
  • Os relatórios de falha vão para dmarc@purelymail.com, não para você — sem visibilidade agregada (rua) do seu próprio domínio
  • O p=reject é aplicado imediatamente, então QUALQUER remetente que você não tenha autenticado é rejeitado de imediato, não apenas a Purelymail

Passo a passo

Na Purelymail
  1. 1

    Abra a página Add Domain

    Faça login no portal Account Admin em purelymail.com/manage, clique em Domains na navegação superior, depois em Add New Domain e informe o seu domínio (ex.: yourdomain.com).

  2. 2

    Copie a lista de registros que a Purelymail mostra

    A página de configuração lista tudo o que você precisa para esta conta: o valor do TXT purelymail_ownership_proof, um MX (mailserver.purelymail.com), o SPF TXT, três CNAMEs de DKIM (purelymail1/2/3._domainkey) e o CNAME de DMARC. Copie o valor de propriedade exatamente — ele é exclusivo do seu domínio.

No seu DNS
  1. 3

    Adicione o TXT de propriedade e limpe registros antigos

    No seu registrador/provedor de DNS, adicione um registro TXT na raiz (Host @ ou em branco) com o valor purelymail_ownership_proof=…. Já que você está lá, apague qualquer registro MX e SPF remanescente de um provedor de e-mail anterior para que não haja conflito.

  2. 4

    Adicione o registro MX

    Crie um registro MX: Host @ (ou em branco), valor mailserver.purelymail.com, prioridade 50. Este é o único MX de que a Purelymail precisa — remova quaisquer outros para que o e-mail recebido não seja dividido entre provedores.

  3. 5

    Adicione ou mescle o SPF TXT

    Adicione um registro TXT na raiz: v=spf1 include:_spf.purelymail.com ~all. Se já existir um registro v=spf1 para outro remetente, mescle o include naquele único registro em vez de criar um segundo SPF TXT.

  4. 6

    Adicione os três CNAMEs de DKIM

    Crie três registros CNAME: purelymail1._domainkey → key1.dkimroot.purelymail.com, purelymail2._domainkey → key2.dkimroot.purelymail.com e purelymail3._domainkey → key3.dkimroot.purelymail.com. Mantenha-os como CNAME (não troque para TXT) e, no Cloudflare, deixe cada um como DNS only (nuvem cinza).

  5. 7

    Adicione o DMARC — escolha o gerenciado ou o seu próprio

    Para a opção sem esforço, adicione um CNAME _dmarc → dmarcroot.purelymail.com (a política gerenciada p=reject da Purelymail). Se você envia de qualquer lugar além da Purelymail ou quer os seus próprios relatórios, pule o CNAME e, em vez disso, adicione um TXT em _dmarc como v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Você pode ter um ou o outro, nunca os dois.

Na Purelymail
  1. 8

    Clique em Check DNS records e finalize a configuração

    De volta à página de configuração da Purelymail, clique em Check DNS records. Aguarde cerca de 15 minutos (até 24–48 horas) para a propagação. Assim que tudo validar, defina Deliver Mail To = Purelymail, opcionalmente deixe Allow Account Reset habilitado para recuperação, clique em Save e depois crie as caixas de correio dos usuários do domínio.

Verificar
  1. 9

    Envie um teste e leia os cabeçalhos

    Envie uma mensagem do seu novo endereço da Purelymail para uma conta do Gmail, abra-a e escolha ⋮ → Mostrar original. Você quer ver SPF: PASS, DKIM: PASS com d=yourdomain.com e DMARC: PASS — todos alinhados ao seu domínio.

Registros a adicionar

O Purelymail gera os valores exatos no seu assistente de configuração — estes mostram o formato do que você vai adicionar no seu provedor de DNS.

TipoHostValor
TXT@purelymail_ownership_proof=xxxxxxxxxxxxxxxxxxxxIlustrativo — copie o valor exato por domínio da página Add Domain. Obrigatório antes que a Purelymail adicione o domínio.
MX@mailserver.purelymail.comPrioridade 50 — o único MX que a Purelymail usa. Apague primeiro quaisquer registros MX do provedor anterior.
TXT@v=spf1 include:_spf.purelymail.com ~allSPF na raiz — mantenha exatamente um registro SPF; mescle outros remetentes nele. O include resolve para um registro plano de 3 IPs = 1 consulta de DNS, e alinha porque o seu domínio é o remetente de envelope.
CNAMEpurelymail1._domainkeykey1.dkimroot.purelymail.comChave rotativa 1 de DKIM (gerenciada pela Purelymail). Delegação por CNAME — mantenha como CNAME, DNS only no Cloudflare.
CNAMEpurelymail2._domainkeykey2.dkimroot.purelymail.comChave rotativa 2 de DKIM — todas as três são obrigatórias porque a Purelymail assina com uma de três chaves que ela roda em rodízio.
CNAMEpurelymail3._domainkeykey3.dkimroot.purelymail.comChave rotativa 3 de DKIM.
CNAME_dmarcdmarcroot.purelymail.comDMARC gerenciado pela Purelymail (atualmente resolve para v=DMARC1; p=reject; ruf=mailto:dmarc@purelymail.com). Use este OU o seu próprio TXT _dmarc — um nome não pode ser ao mesmo tempo um CNAME e um TXT.

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 Purelymail consome desse limite.

SPF 10-lookup budget1 used · 9 free

O Purelymail usa 1 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.

DKIM

O DKIM da Purelymail é delegado por CNAME entre três chaves rotativas, e é por isso que você publica três registros em vez de um. Crie purelymail1._domainkey, purelymail2._domainkey e purelymail3._domainkey como CNAMEs apontando para key1.dkimroot.purelymail.com, key2.dkimroot.purelymail.com e key3.dkimroot.purelymail.com, respectivamente. Como são CNAMEs — e não registros TXT que você cola —, a Purelymail mantém as chaves privadas e publica as chaves públicas por trás desses hostnames dkimroot (cada um resolve para um TXT v=DKIM1; k=rsa; p=… do lado da Purelymail), e ela pode fazer o rodízio entre as três chaves no seu próprio cronograma sem que você jamais precise editar o DNS de novo. Esse é justamente o propósito da abordagem por CNAME e o motivo de todos os três serem obrigatórios: qualquer mensagem é assinada com uma das três chaves, então, se você publicar apenas um CNAME, cerca de dois terços do seu e-mail vão falhar no DKIM. As assinaturas são feitas como d=yourdomain.com, então o DKIM alinha ao seu domínio organizacional e satisfaz o DMARC. Duas observações práticas: não converta esses registros para TXT (isso quebra o rodízio da Purelymail) e, se o seu DNS estiver atrás do Cloudflare, deixe cada um dos três CNAMEs como "DNS only" (nuvem cinza), ou o proxy vai mascarar o destino e o DKIM não vai validar.

DMARC

O DMARC é onde a Purelymail faz algo que a maioria dos provedores não faz: ela oferece uma política totalmente gerenciada, entregue por CNAME. Se você adicionar _dmarc → dmarcroot.purelymail.com, esse CNAME atualmente resolve para v=DMARC1; p=reject; ruf=mailto:dmarc@purelymail.com — uma política de reject aplicada que a Purelymail mantém para você. Para um domínio que envia somente pela Purelymail, isso é uma vantagem genuinamente boa e sem manutenção: você obtém uma forte proteção antifalsificação instantaneamente e nunca precisa mexer no registro. Mas entenda os prós e contras antes de escolhê-lo. Primeiro, os relatórios de falha/forense (ruf) vão para a caixa de correio da própria Purelymail, e não há nenhum relatório agregado rua enviado para você — então você fica com zero visibilidade sobre quem está enviando como se fosse o seu domínio ou se alguma fonte legítima está falhando. Segundo, o p=reject é aplicado no momento em que é resolvido, então qualquer outro remetente que você use — uma ferramenta de newsletter, um CRM, um relay de formulário de contato de site, uma plataforma de marketing — terá o e-mail rejeitado de imediato, a menos que já esteja autenticado e alinhado ao seu domínio. Se você envia de qualquer lugar além da Purelymail, ou se quer os seus próprios relatórios e uma transição segura, publique o seu próprio registro: um TXT em _dmarc como v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, acompanhe os relatórios agregados por uma ou duas semanas até que todo remetente legítimo passe alinhado, depois aperte para p=quarantine e, por fim, p=reject. Você não pode usar os dois — um hostname pode ser um CNAME ou conter registros TXT, nunca ambos (RFC 1034) — então é um caminho ou o outro. Mantenha exatamente um registro _dmarc para todo o domínio organizacional, de qualquer forma.

Confirme que funcionou de verdade

Não confie apenas no visto verde do "Check DNS records" da Purelymail — confirme em uma mensagem real. Envie um teste do seu endereço da Purelymail para uma conta do Gmail, abra-o e escolha ⋮ → Mostrar original: você quer ver SPF: PASS (alinhado a yourdomain.com, já que a Purelymail usa o seu domínio como remetente de envelope), DKIM: PASS com d=yourdomain.com e DMARC: PASS. Você também pode conferir os registros brutos por amostragem em um terminal: dig TXT _spf.purelymail.com deve mostrar os três endereços ip4, dig CNAME purelymail1._domainkey.yourdomain.com deve apontar para key1.dkimroot.purelymail.com e dig TXT _dmarc.yourdomain.com deve retornar a sua política DMARC (seguindo o CNAME se você usou o gerenciado). Depois, passe o seu domínio pela verificação de saúde de domínio da Qualisend para confirmar que o SPF permanece em uma consulta, que os três CNAMEs de DKIM resolvem e que o DMARC está presente. Se você optou pelo CNAME gerenciado, lembre-se de que os relatórios dele vão para a Purelymail — no momento em que quiser a sua própria visibilidade, troque pelo seu próprio registro DMARC com um rua apontando para você e alimente os relatórios agregados no analisador de relatórios DMARC.

Pegadinhas comuns

  • Configuração de DNS

    O DMARC aqui é um CNAME, não um TXT — e você não pode ter os dois. Se você quer os seus próprios relatórios rua ou uma transição de p=none para reject, NÃO adicione o CNAME _dmarc da Purelymail; publique um TXT _dmarc em vez disso. Um hostname pode ser um CNAME ou conter registros TXT, nunca ambos (RFC 1034), então misturá-los é um erro de configuração que o seu provedor de DNS vai rejeitar.

  • Cobertura

    O DMARC gerenciado é p=reject e aplicado imediatamente. Ele vai rejeitar e-mail legítimo de qualquer remetente que você não tenha autenticado — uma ferramenta de newsletter, CRM, plugin de formulário ou relay transacional — não apenas a Purelymail. Autentique todo remetente primeiro, ou rode o seu próprio registro p=none enquanto faz a transição.

  • Configuração de DNS

    Os relatórios do DMARC gerenciado vão para dmarc@purelymail.com, e nenhum relatório agregado (rua) é enviado para você. Você não tem visibilidade sobre quem envia como se fosse o seu domínio. Publique o seu próprio DMARC com rua= se quiser os relatórios.

  • Configuração de DNS

    Todos os três CNAMEs de DKIM são obrigatórios. A Purelymail assina cada mensagem com uma de três chaves rotativas, então publicar apenas purelymail1._domainkey significa que as mensagens assinadas com as chaves 2 e 3 falham no DKIM. Adicione todos os purelymail1/2/3._domainkey.

  • Quebra a autenticação

    Apague o MX e o SPF antigos de qualquer provedor anterior. Um MX remanescente divide o seu e-mail recebido entre provedores, e um segundo registro SPF TXT é um PermError. Mantenha exatamente um MX (mailserver.purelymail.com, prioridade 50) e um SPF TXT.

  • Configuração de DNS

    O proxy do Cloudflare quebra os CNAMEs. Defina os três CNAMEs de DKIM e (se usado) o CNAME de DMARC como 'DNS only' (nuvem cinza). Um CNAME com proxy de nuvem laranja não vai resolver para os hosts dkimroot/dmarcroot da Purelymail e a validação falha.

  • Configuração de DNS

    Copie a comprovação de propriedade exatamente. A Purelymail não adiciona o domínio até que o TXT purelymail_ownership_proof resolva; um valor truncado ou editado falha silenciosamente na etapa 'Check DNS records'.

  • Configuração de DNS

    Duplicação no campo Host: muitos registradores anexam automaticamente o seu domínio, então informar purelymail1._domainkey.yourdomain.com vira purelymail1._domainkey.yourdomain.com.yourdomain.com. Informe apenas o rótulo (purelymail1._domainkey, _dmarc, @) quando o painel adiciona o domínio para você.

Monte seu registro SPF

O Purelymail já vem pré-selecionado abaixo. Adicione as outras plataformas pelas quais você envia e publique o registro único e combinado.

1

Sending sources

Search for each platform you send email through and tick it.

Selected
Guide →
2

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

3

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.

4

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

Your SPF record1/10 DNS lookups
v=spf1 include:_spf.purelymail.com ~all
  • 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 list

SPF do Purelymail — 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.

Começar a verificar