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

SPF, DKIM & DMARC para Salesforce Marketing Cloud.

O Salesforce Marketing Cloud Engagement (antigo ExactTarget) não autentica e-mail da mesma forma que um ESP self-service. Você não cola um registro e clica em "verificar" — em vez disso, você contrata um Sender Authentication Package (SAP) ou o complemento mais leve Private Domain, o Salesforce provisiona um subdomínio de envio dedicado (e normalmente um IP dedicado) para a sua conta, e você delega esse subdomínio para os nameservers do Salesforce ou publica exatamente os registros SPF, DKIM e MX que a equipe de deliverability entrega. Este guia cobre o fluxo de trabalho real do SAP: o mecanismo SPF include:cust-spf.exacttarget.com, a chave DKIM compartilhada 200608 versus a chave dedicada delegada por CNAME que de fato alinha ao seu domínio, delegação de subdomínio vs. auto-hospedagem, Reply Mail Management e o registro DMARC que você mesmo precisa adicionar.

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

Por que autenticar o Salesforce Marketing Cloud?

Desde fevereiro de 2024, o Gmail e o Yahoo exigem que todo remetente em massa passe em SPF, DKIM e em uma política DMARC — falhe neles e os envios do Marketing Cloud são limitados ou vão para o spam exatamente nos provedores de caixa postal onde seu público está. A autenticação SAP correta também remove o indicador de domínio compartilhado / "via", coloca sua própria marca nos links de rastreamento de cliques, imagens, View-as-webpage e CloudPages, e permite que o SFMC envie a partir de um IP dedicado no qual você pode construir uma reputação limpa. Como o SAP envia a partir de um subdomínio do seu próprio domínio, tanto o SPF (envelope/return-path no seu subdomínio) quanto o DKIM (uma chave dedicada no seu subdomínio) podem alinhar ao seu domínio organizacional para o DMARC — uma posição mais forte do que a da maioria dos ESPs, mas só se você assinar com a chave DKIM dedicada em vez do padrão compartilhado 200608 e publicar tudo corretamente.

A realidade do SPF para o Salesforce Marketing Cloud

A autorização SPF do SFMC é um include: genuíno e ativo: include:cust-spf.exacttarget.com. Resolva-o hoje e você obtém um único registro plano de cerca de 50 faixas ip4 terminando em ~all — sem includes aninhados — então ele custa exatamente uma das dez consultas DNS do SPF. Duas coisas tornam o SFMC diferente de um provedor comum de "adicione este include ao seu SPF". Primeiro, o include pertence ao subdomínio de envio SAP dedicado (por exemplo, cloud.yourdomain.com), não ao seu domínio raiz/apex — o SFMC quase nunca envia como seu domínio nu, então colocá-lo na raiz normalmente adiciona uma consulta que não faz nada. Segundo, na configuração recomendada pelo Salesforce você delega todo esse subdomínio ao Salesforce via registros NS e o Salesforce hospeda o registro SPF para você, então você pode nunca tocar diretamente na string SPF. Somente se você auto-hospedar o DNS é que você mesmo publica v=spf1 include:cust-spf.exacttarget.com ~all no subdomínio. De qualquer forma, ele fica no próprio registro SPF do subdomínio, então nunca consome o orçamento de consultas do seu domínio raiz — e é por isso que este include não deve ser acoplado por padrão ao SPF do seu domínio raiz.

Duas maneiras de configurar

Recomendado

Delegue o subdomínio de envio ao Salesforce (recomendado)

  • Adicione registros NS apontando o subdomínio SAP (por exemplo, cloud.yourdomain.com) para os nameservers do Salesforce
  • O Salesforce hospeda o SPF (cust-spf.exacttarget.com), a chave DKIM dedicada, o MX de reply e os registros de rastreamento para você
  • O Salesforce pode rotacionar a chave DKIM dedicada automaticamente — sem coordenação manual de chaves
  • Menor manutenção; menos chances de errar um registro na digitação
  • NÃO publique também SPF/DKIM para esse subdomínio na sua zona pai
Legado

Auto-hospede os registros SAP no seu próprio DNS

  • Mantenha o DNS internamente e publique exatamente os registros que a equipe de deliverability do Salesforce fornece
  • SPF: adicione v=spf1 include:cust-spf.exacttarget.com ~all no subdomínio de envio
  • DKIM: publique o CNAME (ou TXT) específico da conta que o Salesforce fornece — não converta um CNAME em TXT
  • MX: adicione o registro Reply Mail Management no seu subdomínio de reply
  • Você assume a coordenação da rotação da chave DKIM — mais controle, mais manutenção

Passo a passo

Executivo de conta Salesforce / Marketing Cloud Engagement Setup
  1. 1

    Confirme que você tem SAP ou um Private Domain

    A autenticação do SFMC não é self-service. Para autenticar no seu próprio domínio você precisa do Sender Authentication Package pago (ou do complemento mais leve Private Domain); o Salesforce o posiciona para remetentes acima de ~250.000 e-mails/mês. Sem ele, você envia a partir de um domínio compartilhado exacttarget.com para o qual não pode publicar registros. O provisionamento passa pela sua equipe de conta — a parte de DNS/config costuma levar cerca de cinco dias úteis assim que seu formulário de solicitação é enviado, embora contratação e alocação de IP adicionem tempo de espera, então comece por aqui.

Com sua equipe de implementação / deliverability do SFMC
  1. 2

    Defina seu subdomínio de envio dedicado

    O SAP provisiona um domínio privado que é um subdomínio da sua marca — normalmente cloud.yourdomain.com, email.yourdomain.com ou mkt.yourdomain.com. Todo endereço From, URL de rastreamento de link/imagem, link View-as-webpage e CloudPage na conta vão usá-lo, então escolha um subdomínio com o qual você fique satisfeito de ver em caixas de entrada e navegadores a longo prazo.

Seu provedor de DNS (registrador / Cloudflare / Route 53) + Salesforce
  1. 3

    Escolha entre delegação e auto-hospedagem do DNS

    Preferível: delegue o subdomínio de envio aos nameservers do Salesforce via registros NS para que o Salesforce hospede os registros de SPF, DKIM, rastreamento e reply a partir de um arquivo de zona que ele gerencia, e possa rotacionar as chaves DKIM para você. Alternativa: mantenha o DNS internamente e publique os registros exatos que o Salesforce fornece. A delegação tem menor manutenção; a auto-hospedagem mantém o controle, mas significa que você assume a coordenação da rotação de chaves.

Seu provedor de DNS (registros NS no subdomínio filho)
  1. 4

    Caminho da delegação — adicione registros NS para o subdomínio

    Crie registros NS para o subdomínio de envio apontando para os nameservers do Salesforce/ExactTarget que sua equipe fornecer (por exemplo, cloud.yourdomain.com NS -> os hosts no arquivo de zona do Salesforce). Não publique também SPF ou DKIM para esse subdomínio na sua zona pai — a zona filha delegada torna-se autoritativa e os registros da zona pai são ignorados.

Seu provedor de DNS (TXT em cloud.yourdomain.com)
  1. 5

    Caminho da auto-hospedagem — publique o registro SPF no subdomínio

    Se você não for delegar, adicione um registro TXT no subdomínio de envio: v=spf1 include:cust-spf.exacttarget.com ~all. Esse é o valor documentado do Salesforce; aperte de ~all para -all somente depois de confirmar que nada mais envia como esse subdomínio. Mantenha um único registro SPF TXT — nunca dois.

Seu provedor de DNS (CNAME ou TXT no seletor específico da conta), ou auto-hospedado se delegado
  1. 6

    Publique a chave DKIM

    O SAP provisiona uma chave DKIM dedicada que o Salesforce normalmente delega como um CNAME no seu subdomínio de envio — um seletor específico da conta/stack como [stack]dkim1._domainkey.cloud.yourdomain.com apontando para [stack]dkim1._domainkey.sNN.exacttarget.com — de modo que o Salesforce mantém e rotaciona a chave privada e a assinatura alinha ao seu domínio. Configurações mais antigas entregam uma chave pública TXT bruta para você publicar. O seletor compartilhado 200608 é a chave legada em exacttarget.com e NÃO alinha ao seu domínio. Publique exatamente o que o Salesforce fornecer — você nunca gera a chave por conta própria (ao contrário do Setup > DKIM Keys do core Salesforce).

Marketing Cloud Setup > Reply Mail Management
  1. 7

    Configure o Reply Mail Management

    Configure o domínio de reply autenticado para que as respostas dos assinantes, bounces de ausência do escritório e pedidos manuais de descadastro sejam roteados de volta pelo SFMC. Isso publica um registro MX em um subdomínio de reply (e em um subdomínio de bounce paralelo) apontando para a infraestrutura de entrada do Salesforce. Pule esta etapa e as respostas às suas campanhas não chegam a lugar nenhum útil.

Seu provedor de DNS (TXT _dmarc) + SFMC Setup + um verificador de DNS/cabeçalhos
  1. 8

    Adicione o DMARC, depois verifique e ative

    O SAP não cria DMARC — adicione você mesmo o TXT em _dmarc.yourdomain.com, começando em v=DMARC1; p=none com uma caixa postal rua. Confirme que o domínio privado aparece como Active/autenticado no SFMC Setup, envie um e-mail de seed e verifique se os cabeçalhos mostram spf=pass e dkim=pass com os domínios d= e do envelope alinhados ao seu subdomínio (não exacttarget.com). Assim que os relatórios agregados estiverem limpos, mova a política para quarantine e depois reject.

Registros a adicionar

O Salesforce Marketing Cloud 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
TXTcloud.yourdomain.comv=spf1 include:cust-spf.exacttarget.com ~allSPF no subdomínio de envio SAP (método de auto-hospedagem). No modelo de delegação recomendado o Salesforce hospeda isso para você; mostrado aqui para contas que mantêm o DNS internamente. O nome do subdomínio de envio é provisionado por conta — ilustrativo. Fica no próprio SPF do subdomínio, então nunca toca no orçamento de 10 consultas do seu domínio raiz.
CNAMEs10dkim1._domainkey.cloud.yourdomain.coms10dkim1._domainkey.s10.exacttarget.comChave DKIM SAP dedicada, delegada por CNAME para que o Salesforce possa rotacioná-la — esta é a chave que alinha ao seu domínio para o DMARC. O seletor (por exemplo, [stack]dkim1) e o número da stack (sNN) são específicos da conta; publique exatamente como o Salesforce fornecer. Não converta um CNAME em TXT nem encurte o hostname.
TXT<selector>._domainkey.cloud.yourdomain.comv=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...Formato alternativo de DKIM — algumas configurações SAP entregam uma chave pública TXT bruta em vez de um CNAME. O seletor é específico da conta e fornecido pelo Salesforce (o padrão compartilhado, que não alinha, é 200608 em exacttarget.com, não no seu domínio). Chave ilustrativa — não copie literalmente.
MXreply.yourdomain.comreply.s10.exacttarget.comMX do Reply Mail Management para que respostas de assinantes, OOO e pedidos de descadastro sejam roteados pelo SFMC. Um MX de subdomínio de bounce paralelo (bounce.sNN.exacttarget.com) também é provisionado. Subdomínio de reply, stack (sNN) e host MX são por conta — ilustrativo.
TXT_dmarc.yourdomain.comv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê mesmo adiciona o DMARC — o SAP nunca o cria. Comece em p=none, depois aperte para quarantine/reject assim que os relatórios estiverem limpos.

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 Salesforce Marketing Cloud consome desse limite.

SPF 10-lookup budget1 used · 9 free

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

DKIM

Duas histórias diferentes de DKIM percorrem o Salesforce Marketing Cloud. O padrão legado é uma única chave compartilhada com o seletor 200608 — criada lá em 2006 e usada por toda conta SFMC que não seja de domínio privado. Ela é publicada em exacttarget.com, assina como d=exacttarget.com e, portanto, NÃO alinha ao seu domínio From para o DMARC; por ser um seletor TXT fixo, também é complicada de rotacionar. Quando você provisiona o SAP / um domínio privado, o Salesforce emite uma chave DKIM dedicada e normalmente a delega via um CNAME no seu subdomínio de envio — um seletor específico da conta/stack como s10dkim1._domainkey.cloud.yourdomain.com apontando para s10dkim1._domainkey.s10.exacttarget.com — de modo que o Salesforce mantém e rotaciona a chave privada enquanto a assinatura alinha ao seu domínio organizacional. Algumas configurações ainda entregam uma chave pública TXT bruta para você publicar. De qualquer forma, o Salesforce sempre fornece o registro exato; você nunca gera a chave por conta própria, ao contrário do core Salesforce Sales/Service Cloud, onde você a cria em Setup > DKIM Keys. Como uma chave SAP dedicada assina com um subdomínio do seu próprio domínio, ela é o caminho mais confiável para uma aprovação de DMARC — confirme que seu pacote inclui uma chave dedicada e alinhada ao domínio, em vez de depender do padrão compartilhado 200608.

DMARC

O SAP não cria nem gerencia DMARC — você o publica. Adicione um registro TXT em _dmarc.yourdomain.com: comece com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com para coletar relatórios agregados sem afetar a entrega. Como o SAP envia a partir de um subdomínio do seu domínio, o SPF pode alinhar via o envelope/return-path nesse subdomínio e o DKIM pode alinhar via a chave SAP dedicada — então o DMARC pode passar por qualquer um dos dois, com o DKIM sendo o alinhador mais robusto. A chave compartilhada 200608 sozinha não alinha (ela assina como exacttarget.com), então garanta que sua conta esteja assinando com a chave dedicada antes de aplicar a política. Fique atento à política de subdomínio: se você definir p=reject, adicione sp= de forma deliberada e confirme primeiro que o subdomínio de envio SAP está totalmente autenticado. Passe de p=none -> quarantine -> reject somente depois que os relatórios confirmarem que todo o seu tráfego legítimo do SFMC (e outros) está passando de forma alinhada.

Confirme que funcionou de verdade

Consulte o SPF do subdomínio de envio (dig +short TXT cloud.yourdomain.com) e confirme que ele resolve para include:cust-spf.exacttarget.com, depois verifique o seletor DKIM que o Salesforce forneceu (por exemplo, dig +short CNAME s10dkim1._domainkey.cloud.yourdomain.com, ou uma consulta TXT se você recebeu uma chave bruta — não o seletor compartilhado 200608). Envie uma campanha de teste/seed para uma caixa postal que você controle e inspecione os cabeçalhos: o Authentication-Results deve mostrar spf=pass e dkim=pass, e tanto o domínio d= do DKIM quanto o domínio do envelope SPF devem ser seu próprio subdomínio (alinhados), não exacttarget.com. Em Marketing Cloud Setup, confirme que o domínio privado / SAP aparece como Active e autenticado (não Pending). Depois, passe o subdomínio de envio e seu registro _dmarc pelo verificador de SPF, DKIM & DMARC e pela verificação de saúde do domínio da Qualisend para pegar erros de digitação, registros com proxy ou uma política DMARC ausente antes de escalar o volume.

Pegadinhas comuns

  • Configuração de DNS

    Não é self-service. Você não pode simplesmente publicar registros e começar a enviar — o SAP / Private Domain é um complemento pago que a equipe do Salesforce provisiona (cerca de cinco dias úteis para o DNS depois que seu formulário entra, mais o tempo de contratação) e é posicionado para remetentes acima de ~250.000 e-mails/mês. Sem SAP você envia a partir de um domínio compartilhado exacttarget.com que não pode autenticar.

  • Configuração de DNS

    Produto certo, registros certos. include:cust-spf.exacttarget.com e o seletor 200608 são EXCLUSIVOS do Marketing Cloud Engagement (ExactTarget). O core Salesforce Sales/Service Cloud usa include:_spf.salesforce.com com chaves que você gera em Setup > DKIM Keys, e o Account Engagement (Pardot) usa seus próprios CNAMEs de tracker — nunca os mescle em um único registro SPF.

  • Quebra a autenticação

    Subdomínio, não raiz. O SAP envia a partir de um subdomínio dedicado (por exemplo, cloud.yourdomain.com), e o include/DKIM/MX ficam ali. Não acople cust-spf.exacttarget.com ao SPF do seu domínio raiz/apex a menos que seu endereço From do SFMC esteja genuinamente no domínio raiz — para a maioria das contas isso apenas adiciona uma consulta que não faz nada.

  • Configuração de DNS

    200608 é a chave compartilhada — e não alinha. O seletor 200608 é a única chave DKIM compartilhada do Marketing Cloud (de 2006), publicada em exacttarget.com; ela assina como exacttarget.com, então não te dá nenhum DKIM alinhado ao domínio para o DMARC, e, por ser um seletor TXT fixo, é difícil de rotacionar. O alinhamento de domínio vem da chave SAP dedicada que o Salesforce delega via CNAME — confirme que seu pacote inclui uma.

  • Configuração de DNS

    Delegação e registros manuais conflitam. Se você delegar o subdomínio via NS para o Salesforce, NÃO publique também SPF/DKIM para esse subdomínio na sua zona pai — a zona filha delegada é autoritativa e seus registros da zona pai são silenciosamente ignorados.

  • Configuração de DNS

    Publique os registros exatamente. Não converta um CNAME do Salesforce em TXT, não encurte hostnames e não coloque os registros atrás de proxy (sem a nuvem laranja do Cloudflare) — qualquer um desses quebra o DKIM, o roteamento de reply ou a resolução do return-path.

  • Configuração de DNS

    Orçamento de SPF e qualificador. cust-spf.exacttarget.com é um único registro plano só de ip4 = uma única consulta (sem aninhamento), mas é grande. O valor documentado do Salesforce termina em ~all; aperte para -all somente quando tiver certeza de que nada mais envia como esse subdomínio.

  • Configuração de DNS

    O DMARC é com você. O SAP não cria o _dmarc — sem uma política DMARC publicada, a fiscalização de remetentes em massa do Gmail e do Yahoo vai limitar ou mandar para o lixo seus envios do Marketing Cloud.

Monte seu registro SPF

O Salesforce Marketing Cloud 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.

1

Sending sources

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

Search for your email platform above, or .

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 record0/10 DNS lookups
v=spf1 ~all

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 list

SPF do Salesforce Marketing Cloud — 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