SPF, DKIM & DMARC para Salesforce.
O Salesforce (Sales, Service e Platform Cloud) autentica seu domínio em três partes distintas e, a partir do Spring '26, ele se recusa a enviar e-mails de um domínio que você não tenha verificado. O SPF é um include compartilhado genuíno (include:_spf.salesforce.com) que você mescla no seu único registro SPF raiz. O DKIM é um par de registros CNAME "selector" que você gera em Setup - DKIM Keys e depois ativa (Activate) - e criar uma chave DKIM ativa também é a forma recomendada de atender ao novo requisito de verificação do domínio de envio do Salesforce. O DMARC é um quarto registro, separado, que o Salesforce nunca cria para você. A pegadinha que derruba quase todo mundo: o Salesforce envia os bounces a partir do próprio domínio de return-path, então o SPF não fica alinhado ao seu endereço From - o DKIM é o mecanismo que de fato sustenta o DMARC.
Por que autenticar o Salesforce?
Autenticar o e-mail do Salesforce deixou de ser uma tarefa opcional de manutenção - desde o Spring '26 (o enforcement começou em 9 de março de 2026 e foi implantado até o fim de abril de 2026) o Salesforce bloqueia qualquer e-mail criado por usuário ou automatizado enviado a partir de um domínio não verificado. Envios manuais falham no Email Composer com "Not allowed to send from an unauthorized domain" e os fluxos automatizados falham silenciosamente, exibindo "550 5.7.1 Delivery not authorized, message discarded" apenas nos seus Email Logs. Além disso, desde fevereiro de 2024 o Gmail e o Yahoo exigem que todo remetente em massa (aproximadamente 5.000+ mensagens por dia) passe em SPF, DKIM e DMARC com alinhamento, e a Microsoft começou a exigir o mesmo para e-mails de alto volume enviados ao Outlook.com em 2025. O comportamento padrão do Salesforce quebra o DMARC de forma silenciosa: ele carimba um return-path no próprio domínio de bounce, então o SPF autentica mas não fica alinhado ao seu endereço From, e, de fábrica, não há assinatura DKIM alguma no seu domínio - o que significa que um e-mail do Salesforce que parece perfeito ainda pode falhar no DMARC em todos os lugares. Configurar uma chave DKIM resolve os dois problemas de uma vez: atende ao requisito de verificação de domínio e lhe dá uma assinatura alinhada que faz o DMARC passar, de modo que a reputação que você constrói se acumula no seu próprio domínio em vez de escapar pela infraestrutura compartilhada do Salesforce.
A realidade do SPF para o Salesforce
O núcleo do Salesforce é um provedor de "include" verdadeiro: existe um mecanismo compartilhado real, include:_spf.salesforce.com, que você adiciona ao único registro SPF TXT no seu domínio raiz, por exemplo v=spf1 include:_spf.salesforce.com ~all. Mas seja claro sobre o que ele faz. O include resolve para v=spf1 exists:%{i}._spf.mta.salesforce.com -all - um registro com macro exists que autoriza os IPs de envio atuais do Salesforce - e ele custa DOIS dos seus 10 lookups DNS de SPF (um para o próprio include, outro para o mecanismo exists aninhado). A nuance importante: adicionar esse include autoriza o Salesforce para SPF, mas NÃO faz o SPF alinhar. Por padrão o Salesforce usa o próprio domínio como envelope-from / Return-Path (seu domínio de tratamento de bounces), então a verificação de SPF roda contra o domínio do Salesforce, não o seu - o que significa que o SPF passa mas não fica alinhado ao seu endereço From visível, e o DMARC não recebe nada disso. É por isso que o DKIM não é opcional aqui: o DMARC precisa de pelo menos um mecanismo alinhado e, no Salesforce, esse mecanismo é o DKIM. Publique o include mesmo assim (é a recomendação documentada do Salesforce e ele autoriza os IPs de envio de forma limpa), mas trate o DKIM - não o SPF - como aquilo que sustenta a aprovação do seu DMARC.
Duas maneiras de configurar
Chave DKIM (recomendado)
- Delegada por CNAME para custdkim.salesforce.com, então o Salesforce mantém e rotaciona as chaves privadas
- Dá a você uma assinatura DKIM alinhada - o mecanismo que de fato faz o DMARC passar
- Uma chave DKIM ativa também atende ao requisito de verificação do domínio de envio do Spring '26
- Uma única chave pode cobrir múltiplos domínios de endereço From por meio do seu Domain Match Pattern
Authorized Email Domains - TXT (apenas verificação)
- Um único registro TXT em _sfdv.yourdomain.com (ou no apex) prova que você é dono do domínio
- Atende ao requisito de verificação do Spring '26 para que os envios não sejam bloqueados
- NÃO assina seu e-mail - sem assinatura DKIM, sem alinhamento DMARC vindo dele
- Use apenas como paliativo; você ainda precisa de uma chave DKIM para entregabilidade
Passo a passo
- 1
Defina seu nível de acesso de Deliverability
Em Setup, use o Quick Find para abrir Email - Deliverability. Defina "Access to Send Email" (Access level) como "All email" para que o Salesforce realmente envie e-mail de saída - sandboxes e algumas orgs têm o padrão "System email only" ou "No access", que descarta silenciosamente suas mensagens de teste antes mesmo de a autenticação importar.
- 2
Crie uma chave DKIM
Em Setup, pesquise "DKIM Keys" no Quick Find e clique em Create New Key. Escolha 2048-bit para o tamanho da chave RSA. Informe um Selector único (por exemplo example-sf-a) e um Alternate Selector único (por exemplo example-sf-b). Informe o Domain a partir do qual você envia e um Domain Match Pattern (por exemplo example.com para cobrir esse domínio, ou um padrão mais amplo para subdomínios), depois clique em Save. Observação: o campo Domain é permanente depois de salvo.
- 3
Publique os dois registros CNAME de DKIM
Abra a página DKIM Key Details - o Salesforce mostra um CNAME e um Alternate CNAME. No seu provedor de DNS, crie ambos como registros CNAME: o host example-sf-a._domainkey.yourdomain.com apontando para o target que o Salesforce mostra, como example-sf-a.k4tyd2.custdkim.salesforce.com (e o selector -b para o próprio target custdkim.salesforce.com dele). Copie os targets exatos - um único caractere errado quebra a assinatura. Se o seu DNS estiver atrás do Cloudflare, defina-os como DNS-only (nuvem cinza).
- 4
Ative a chave DKIM
Depois que os CNAMEs se propagarem (minutos, até 48-72 horas), volte a Setup - DKIM Keys, abra a chave e clique em Activate. O Salesforce não deixa você ativar até que ambos os CNAMEs resolvam no DNS público. Uma vez ativa, o Salesforce assina o e-mail de saída com d=yourdomain.com e seu domínio conta como verificado para o requisito do Spring '26.
- 5
Adicione ou mescle o include de SPF
No seu provedor de DNS, publique UM registro SPF TXT na raiz (host @): v=spf1 include:_spf.salesforce.com ~all. Se você já envia via Google Workspace, Microsoft 365, uma ferramenta de marketing etc., mescle include:_spf.salesforce.com nessa única linha v=spf1 existente - nunca crie um segundo registro SPF. Isso autoriza os IPs do Salesforce (custa 2 lookups), mas lembre-se de que ele não vai alinhar sozinho.
- 6
Verifique o domínio se você ainda não estiver usando DKIM
Se você precisa desbloquear o envio antes de o DKIM estar ativo, use a alternativa via TXT: Setup - Quick Find "Authorized Email Domains" - Add, informe seu domínio e o Salesforce gera uma chave de verificação. Publique-a como um registro TXT (host _sfdv.yourdomain.com ou o apex), aguarde a propagação, depois faça Edit no domínio e ative "Verify domain ownership". Isso prova a propriedade, mas não assina o e-mail - uma chave DKIM continua sendo o objetivo.
- 7
Aponte seu Org-Wide Address para o domínio verificado
Todo endereço From precisa estar em um domínio verificado. Em Setup, abra Quick Find - "Organization-Wide Addresses" e garanta que os endereços a partir dos quais seus usuários, fluxos e alertas de e-mail enviam (por exemplo no-reply@yourdomain.com) estejam no domínio que você acabou de autenticar. Org-Wide Addresses não verificados são a causa mais comum de envios automatizados bloqueados.
- 8
Publique seu registro DMARC
O Salesforce nunca cria o DMARC. Adicione um registro TXT em _dmarc.yourdomain.com: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento - não muda nada na entrega enquanto você confirma que o e-mail do Salesforce passa no DKIM alinhado ao seu domínio. Mantenha exatamente um registro _dmarc para todo o domínio.
- 9
Envie um teste e leia os cabeçalhos
Envie uma mensagem real de um Org-Wide Address do Salesforce para uma caixa de entrada do Gmail, abra-a e escolha o menu de três pontos - Show original. Você quer DKIM: PASS com signed-by / d=yourdomain.com (não salesforce.com) e DMARC: PASS. O SPF normalmente vai mostrar o domínio de return-path do Salesforce - isso é esperado; o DKIM é o que deve estar sustentando a aprovação do DMARC.
Registros a adicionar
O Salesforce 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 | @ | v=spf1 include:_spf.salesforce.com ~allSPF raiz - mantenha exatamente UM registro SPF; mescle este include na sua linha v=spf1 existente, se você tiver uma. Custa ~2 lookups DNS (include + exists aninhado). Autoriza o Salesforce, mas não alinha. |
| CNAME | example-sf-a._domainkey | example-sf-a.k4tyd2.custdkim.salesforce.comDKIM selector 1 - ilustrativo. Copie o target exato da sua página DKIM Key Details; a string de partição k4tyd2 é única para a sua chave. |
| CNAME | example-sf-b._domainkey | example-sf-b.e6mxu6.custdkim.salesforce.comDKIM selector alternativo - ilustrativo. O segundo selector permite que o Salesforce rotacione as chaves sem você mexer no DNS de novo. Use o valor exato que o Salesforce mostra. |
| TXT | _sfdv | 00D000000000P18=1AB00000000000BChave de verificação de Authorized Email Domains - ilustrativa e específica de cada org. Só é necessária se você usar o método de propriedade via TXT em vez de (ou antes de) uma chave DKIM ativa; o apex também funciona como host. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê mesmo adiciona isso - o Salesforce nunca cria. Um por domínio; comece em p=none e endureça depois. |
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 consome desse limite.
O Salesforce usa 2 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.
DKIM
O DKIM é a peça central da autenticação do Salesforce, porque é o único mecanismo que fica alinhado ao seu domínio - e, desde o Spring '26, uma chave DKIM ativa é a forma recomendada pelo Salesforce de verificar a propriedade do domínio para que seus envios não sejam bloqueados. Crie-a em Setup - Quick Find - "DKIM Keys" - Create New Key: escolha 2048-bit, informe um Selector único e um Alternate Selector único (o Salesforce usa dois selectors para poder rotacionar as chaves), especifique o Domain e defina um Domain Match Pattern que controla quais domínios de endereço From esta chave assina. Depois de clicar em Save, a página DKIM Key Details exibe um CNAME e um Alternate CNAME - por exemplo example-sf-a._domainkey.yourdomain.com para example-sf-a.k4tyd2.custdkim.salesforce.com e example-sf-b._domainkey.yourdomain.com para example-sf-b.e6mxu6.custdkim.salesforce.com. Como esses são CNAMEs delegados para custdkim.salesforce.com (não registros TXT que você cola), o Salesforce mantém as chaves privadas e rotaciona as chaves publicadas por trás dos dois selectors sem que você precise reeditar o DNS. Duas coisas que as pessoas deixam passar: o campo Domain é permanente depois de salvo (você teria que criar uma nova chave para mudá-lo), e você não pode clicar em Activate até que ambos os CNAMEs efetivamente resolvam no DNS público. Publique os dois registros, aguarde a propagação, depois volte a DKIM Keys e clique em Activate - só então o Salesforce começa a assinar o e-mail de saída com d=yourdomain.com. As chaves DKIM mais antigas do Salesforce eram chaves TXT autogerenciadas que você gerava e colava; a chave DKIM "segura" moderna é a versão delegada por CNAME descrita aqui e é a que você deve usar.
DMARC
O DMARC é um registro TXT de política separado no seu domínio que o Salesforce não cria - você mesmo o publica em _dmarc.yourdomain.com, começando por v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento: não muda nada na entrega enquanto você observa os relatórios agregados (rua) para confirmar que o e-mail do Salesforce está passando no DKIM alinhado ao seu domínio. Esta é a etapa em que a peculiaridade de alinhamento do Salesforce mais importa: como o Salesforce envia os bounces a partir do próprio domínio de return-path, o SPF autentica mas não fica alinhado, então, no e-mail do Salesforce, o DMARC passa apenas pelo alinhamento do DKIM. Isso é aceitável - o DMARC só exige um mecanismo alinhado - mas significa que sua chave DKIM precisa estar ativa e assinando antes de você endurecer a política, ou o e-mail legítimo do Salesforce vai falhar. Acompanhe os relatórios por uma ou duas semanas, garanta que o Salesforce (e todos os outros remetentes - Google Workspace, Microsoft 365, ferramentas de marketing) apareça com uma aprovação alinhada, depois avance para p=quarantine e, por fim, p=reject. Mantenha exatamente um registro _dmarc para todo o domínio organizacional; nunca adicione um segundo só para o Salesforce.
Confirme que funcionou de verdade
Não confie apenas no status exibido na página DKIM Keys do Salesforce - confirme em uma mensagem real. Envie de um dos seus Org-Wide Addresses para uma caixa de entrada do Gmail, abra a mensagem e escolha o menu de três pontos - Show original. Você quer DKIM: PASS com signed-by / d=yourdomain.com (se aparecer salesforce.com, sua chave não está ativa ou seu Org-Wide Address está no domínio errado) e DMARC: PASS. O SPF normalmente vai listar um domínio de return-path do Salesforce em vez do seu - isso é esperado, porque quem está alinhando é o DKIM, não o SPF. No Salesforce, a página DKIM Key Details deve marcar Active. Depois passe seu domínio pela verificação de saúde de domínio da Qualisend para confirmar que o registro SPF, os dois CNAMEs de selector DKIM e o registro DMARC resolvem todos de forma limpa e que o SPF se mantém abaixo do limite de 10 lookups; assim que os relatórios agregados de DMARC começarem a chegar, jogue um deles no analisador de relatórios DMARC para confirmar que o Salesforce aparece como uma fonte alinhada e aprovada.
Pegadinhas comuns
- Cobertura
Enforcement do Spring '26: o Salesforce agora bloqueia e-mail de domínios não verificados - envios manuais falham com "Not allowed to send from an unauthorized domain" e fluxos automatizados falham silenciosamente, registrando "550 5.7.1 Delivery not authorized, message discarded" nos Email Logs. Ative uma chave DKIM (ou verifique via Authorized Email Domains) para cada domínio que seus Org-Wide Addresses usam.
- Cobertura
O SPF não alinha no Salesforce. Ele envia os bounces a partir do próprio domínio de return-path, então o include de SPF autoriza mas nunca fica alinhado ao seu endereço From - o DMARC se apoia inteiramente no DKIM. Adicionar o include sem uma chave DKIM ativa NÃO vai lhe dar uma aprovação de DMARC.
- Cobertura
O campo Domain da chave DKIM é permanente. Depois de clicar em Save, você não pode editar o domínio (nem os selectors) - teria que criar uma nova chave. Acerte de primeira e use o Domain Match Pattern para cobrir os domínios de que você realmente envia.
- Configuração de DNS
Você não pode ativar (Activate) o DKIM até que ambos os CNAMEs resolvam. O botão Activate não funciona enquanto o DNS ainda está propagando; aguarde (até 48-72 horas) e reveja com um lookup DNS antes de tentar de novo.
- Cobertura
O nível de acesso de Deliverability bloqueia envios silenciosamente. Se "Access to Send Email" estiver definido como "System email only" ou "No access" (comum em sandboxes), o Salesforce descarta seu e-mail de saída independentemente do DNS - defina-o como "All email" em Setup - Deliverability.
- Cobertura
O Email Relay ignora a assinatura DKIM do Salesforce. Se você roteia a saída pelo seu próprio servidor SMTP via Setup - Email Relay, o Salesforce não assina o e-mail - seu relay é responsável por SPF e DKIM, e estes registros do Salesforce não se aplicam a esse caminho.
- Configuração de DNS
Isto cobre o núcleo do Salesforce (Sales/Service/Platform), não o Marketing Cloud nem o Pardot. O Marketing Cloud Engagement usa seu próprio Sender Authentication Package (SAP) com CNAMEs diferentes, e o Account Engagement (Pardot) tem sua própria configuração - cada família de produto autentica separadamente.
- Quebra a autenticação
Mantenha um registro SPF. Mescle include:_spf.salesforce.com na sua única linha v=spf1 - dois registros SPF TXT no mesmo domínio são um PermError que quebra o SPF para todos os remetentes.
Monte seu registro SPF
O Salesforce já vem pré-selecionado abaixo. Adicione as outras plataformas pelas quais você envia e publique o registro único e combinado.
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).
- 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 Salesforce — 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.