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.
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
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
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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.
| Tipo | Host | Valor |
|---|---|---|
| TXT | cloud.yourdomain.com | v=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. |
| CNAME | s10dkim1._domainkey.cloud.yourdomain.com | s10dkim1._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.com | v=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. |
| MX | reply.yourdomain.com | reply.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.com | v=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.
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.
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 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.