SPF, DKIM & DMARC para SparkPost.
O SparkPost (agora parte da Bird, antiga MessageBird) autentica seu domínio em Configuration → Sending Domains, onde gera uma chave DKIM que você publica como um registro TXT no seu domínio de envio. Essa assinatura DKIM — assinada como d=yourdomain.com — é o mecanismo que de fato garante a aprovação do DMARC. O SPF é a pegadinha específica do SparkPost: por padrão, o SparkPost envia o bounce/envelope a partir do seu próprio domínio compartilhado (sparkpostmail.com), então uma verificação SPF simples passa no domínio do SparkPost, mas nunca alinha ao seu. A solução é um Bounce Domain personalizado — um CNAME que aponta um subdomínio seu para sparkpostmail.com e se torna o seu Return-Path, de modo que o SPF também alinhe. Adicione um registro de política DMARC e você terá os três, alinhados, sem adicionar nada ao seu SPF raiz.
Por que autenticar o SparkPost?
Autenticar seu domínio no SparkPost não é mera formalidade — é o que decide se seu e-mail transacional e de marketing de alto volume vai chegar à caixa de entrada. Desde fevereiro de 2024, Gmail e Yahoo passaram a exigir 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 impor o mesmo nas caixas de entrada de consumidores do Outlook/Hotmail/Live em 2025 — exatamente os volumes para os quais o SparkPost foi construído. Até você autenticar, o SparkPost assina seu e-mail com uma chave compartilhada e faz o bounce a partir de sparkpostmail.com: seu endereço From não é criptograficamente seu, o DMARC não passa, e sua reputação fica misturada com a de todos os outros remetentes não autenticados naquela infraestrutura. Há uma peculiaridade específica do SparkPost que torna o DKIM inegociável: como o SparkPost detém o Return-Path por padrão, o SPF passa mas não alinha ao seu domínio, então o DKIM é o único mecanismo que garante a aprovação do DMARC até você também configurar um bounce domain personalizado. Fazer o DKIM mais um bounce domain alinha ambos os mecanismos a você, elimina a dúvida dos destinatários sobre sua identidade, permite que o DMARC passe e constrói reputação de envio em seu próprio nome, em vez de no pool compartilhado.
A realidade do SPF para o SparkPost
O SparkPost é nominalmente um provedor de "include" — include:sparkpostmail.com (e include:_spf.sparkpostmail.com, que resolve para o registro idêntico) ambos existem e passam na verificação de DNS — mas adicionar esse include ao seu SPF raiz é legado e NÃO faz o DMARC passar. Eis o porquê. O registro ativo é v=spf1 exists:%{i}._spf.sparkpostmail.com ~all — uma macro exists: que autoriza os IPs de saída do SparkPost por IP (%{i} é o IP de envio, verificado contra uma zona curinga) em vez de listar faixas ip4: fixas. O SPF é sempre avaliado contra o domínio do envelope MAIL FROM / Return-Path, e por padrão esse domínio é sparkpostmail.com, que pertence ao SparkPost. Então o SPF resolve e passa no domínio do SparkPost, mas nunca alinha com o seu domínio organizacional do From — e o DMARC só considera o SPF quando ele alinha. Publicar include:sparkpostmail.com no seu próprio domínio raiz não muda isso, porque seu domínio raiz nunca é o domínio do envelope; isso só queima duas das suas dez consultas de SPF (o próprio include mais o mecanismo exists aninhado dentro do registro do sparkpostmail.com) sem nenhum benefício de alinhamento. O caminho de SPF alinhado é um Bounce Domain personalizado: você aponta um subdomínio seu (por exemplo, bounces.yourdomain.com) para sparkpostmail.com com um CNAME, o SparkPost usa esse subdomínio como Return-Path, e agora a verificação SPF roda contra o seu subdomínio (com alinhamento relaxado ao seu domínio organizacional) ao mesmo tempo em que ainda herda o SPF do sparkpostmail.com por meio do CNAME. É por isso que o próprio fluxo do SparkPost fornece um registro TXT DKIM e um CNAME de bounce domain, e não uma linha de SPF para colar no seu apex. Reserve seu registro SPF raiz para remetentes que realmente colocam seu domínio no Return-Path (Google Workspace, Microsoft 365, um relay que você controla), e deixe o CNAME de bounce + DKIM fazerem o trabalho do SparkPost.
Duas maneiras de configurar
Bounce domain personalizado + DKIM (recomendado, alinhado)
- O TXT DKIM com um seletor scph assina o e-mail como d=yourdomain.com — o mecanismo que de fato passa no DMARC
- Um CNAME de bounce domain personalizado (por exemplo, bounces.yourdomain.com → sparkpostmail.com) faz o SPF alinhar ao seu domínio também
- Adiciona zero consultas de DNS ao seu SPF raiz — o registro de bounce vive no seu próprio subdomínio, não no seu apex
- Funciona da mesma forma no SparkPost US e EU (o EU apenas aponta o CNAME para eu.sparkpostmail.com)
Include no SPF raiz (legado, não alinha)
- Você adiciona v=spf1 include:sparkpostmail.com ~all ao seu SPF raiz por conta própria
- O SparkPost detém o envelope (bounce padrão = sparkpostmail.com), então esse SPF nunca alinha ao seu domínio
- Não faz nada pelo DMARC — o DKIM e o bounce domain continuam fazendo todo o trabalho
- Custa duas das suas 10 consultas de SPF (o include mais o mecanismo exists aninhado) sem nenhum benefício de alinhamento; pode deixar de fora tranquilamente
Passo a passo
- 1
Abra Sending Domains e adicione seu domínio
Entre no SparkPost (app.sparkpost.com, ou app.eu.sparkpost.com para contas na EU) e vá em Configuration → Sending Domains → Add Domain. Informe o domínio ou subdomínio de onde você enviará (um subdomínio como mail.yourdomain.com é comum e mantém a reputação de envio separada) e salve.
- 2
Copie o registro DKIM que o SparkPost gera
Na tela de configuração do domínio, o SparkPost mostra um registro DKIM em 'Set up for DKIM signing'. É um registro TXT: o host é um seletor gerado automaticamente como scph0421._domainkey.yourdomain.com e o valor começa com v=DKIM1; k=rsa; h=sha256; p=… seguido pela sua chave pública. O SparkPost usa por padrão uma chave de 2048 bits, então o valor é longo — copie tudo exatamente.
- 3
Publique o registro TXT DKIM
No seu provedor de DNS, crie um registro TXT com host scph0421._domainkey (sob seu domínio/subdomínio de envio) e cole o valor completo v=DKIM1… Mantenha-o como registro TXT — o DKIM do SparkPost não é um CNAME. Por ser uma chave de 2048 bits, alguns painéis limitam uma string TXT a 255 caracteres e exigem que você a divida em várias strings entre aspas — divida-a, não descarte caracteres. Se o seu painel anexa o domínio automaticamente, informe apenas o rótulo (scph0421._domainkey) para evitar duplicá-lo.
- 4
Verifique o domínio de envio
De volta à tela Sending Domains, marque a caixa confirmando que você adicionou o registro e clique em Verify Domain. Assim que resolver, o domínio aparecerá como verificado e 'DKIM Signing' ficará pronto — o SparkPost não assinará com sua chave até que isso mude. A propagação normalmente leva minutos, mas pode levar até 24–48 horas.
- 5
Adicione um Bounce Domain personalizado
Vá em Configuration → Bounce Domains (ou escolha a opção Bounce Domain ao adicionar um domínio) e adicione um subdomínio para deter o Return-Path — por exemplo, bounces.yourdomain.com para alinhamento relaxado, ou reutilize seu subdomínio de envio exato (mail.yourdomain.com) para alinhamento estrito. Esta é a etapa que lhe dá o alinhamento de SPF.
- 6
Publique o CNAME do bounce domain
Crie um registro CNAME: host = seu subdomínio de bounce (bounces), valor = sparkpostmail.com (para o SparkPost EU, aponte para eu.sparkpostmail.com em vez disso). No Cloudflare, defina o registro como 'DNS only' (nuvem cinza) — um CNAME proxiado com nuvem laranja não resolverá para o SparkPost e a verificação falhará.
- 7
Verifique o bounce domain
Volte a Bounce Domains e clique para verificar. Uma vez verde, o SparkPost usa seu subdomínio como o MAIL FROM do envelope, então o SPF agora passa E alinha ao seu domínio organizacional — um segundo mecanismo alinhado ao lado do DKIM.
- 8
Adicione um registro de política DMARC
O SparkPost não cria o DMARC para você. Adicione um registro TXT no host _dmarc com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento, então nada muda na entrega enquanto você confirma que o SparkPost passa em SPF e DKIM alinhados; você o apertará depois.
- 9
Envie um teste e leia os cabeçalhos
Envie para si mesmo uma mensagem pelo SparkPost a partir de um endereço no domínio autenticado, abra-a no Gmail e escolha ⋮ → Mostrar original. Você quer DKIM: PASS assinado por yourdomain.com (seletor scph…), SPF: PASS com o mailfrom no seu subdomínio de bounce (não sparkpostmail.com), e DMARC: PASS. Depois, confirme que cada registro resolve com um teste de saúde de domínio.
Registros a adicionar
O SparkPost 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 | scph0421._domainkey | v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from SparkPost)DKIM — o mecanismo alinhado que passa no DMARC. O seletor scph é gerado automaticamente por conta (por exemplo, scph0421, scph0717); valor ilustrativo — copie o registro exato em Configuration → Sending Domains. O SparkPost usa por padrão uma chave de 2048 bits, então divida-a em várias strings entre aspas se o seu painel limitar o TXT a 255 caracteres. Publique sob seu domínio/subdomínio de envio, por exemplo, scph0421._domainkey.mail.yourdomain.com. |
| CNAME | bounces | sparkpostmail.comBounce Domain personalizado (Return-Path) — é isso que faz o SPF ALINHAR ao seu domínio. Use um subdomínio, não o seu apex. O SparkPost EU aponta isso para eu.sparkpostmail.com. Defina 'DNS only' (nuvem cinza) no Cloudflare. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê adiciona isso por conta própria — o SparkPost nunca o cria. Um por domínio; comece em p=none, depois avance para quarantine/reject. |
| TXT | @ | v=spf1 include:sparkpostmail.com ~allLEGADO / OPCIONAL — NÃO cria alinhamento de DMARC porque o SparkPost detém o envelope. O CNAME de bounce acima é o caminho de SPF alinhado; só adicione isso se quiser que seu SPF bruto referencie o SparkPost, e, se fizer, mescle-o no seu único registro SPF raiz. Custa duas consultas — o include mais a macro exists aninhada dentro do registro do sparkpostmail.com. |
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 SparkPost consome desse limite.
A configuração recomendada do SparkPost adiciona 0 consultas — todas as 10 ficam livres para os remetentes que realmente precisam de um include.
DKIM
O DKIM é o registro que sustenta tudo no SparkPost, porque é o mecanismo que alinha por padrão. Quando você adiciona um domínio de envio, o SparkPost gera um par de chaves RSA (2048 bits por padrão) e mostra um registro TXT para você publicar: o host é um seletor gerado automaticamente no formato scphNNNN._domainkey.yourdomain.com (por exemplo, scph0421._domainkey — os quatro dígitos são atribuídos por conta/chave), e o valor é v=DKIM1; k=rsa; h=sha256; p=<sua chave pública>. Você publica esse TXT no seu provedor de DNS; o SparkPost guarda a chave privada correspondente e assina cada mensagem de saída com ela, de modo que a assinatura DKIM carrega d=yourdomain.com e alinha ao seu endereço From. Duas coisas diferenciam o DKIM do SparkPost dos provedores de delegação por CNAME (SendGrid, Mailchimp, Klaviyo). Primeiro, é um registro TXT que você cola — não um CNAME — então publicar um CNAME onde o TXT scph é esperado quebrará a assinatura; mantenha o tipo de registro como TXT. Segundo, como você detém a chave publicada em vez de delegá-la, não há rotação automática de chave: se algum dia precisar rotacionar, você gera uma chave nova no SparkPost e republica o novo TXT scph por conta própria. Uma questão prática do padrão de 2048 bits: a chave pública excede o limite de 255 caracteres de uma única string TXT, então muitos painéis de DNS exigem que você a divida em várias strings entre aspas (o SparkPost pode emitir uma chave de 1024 bits caso seu provedor não lide com TXT de múltiplas strings). Publicar o registro não basta por si só — você precisa voltar a Configuration → Sending Domains e clicar em Verify Domain para que o domínio apareça como verificado e 'DKIM Signing' fique pronto; o SparkPost não assinará com sua chave até que isso mude.
DMARC
O DMARC é um registro de política à parte que você adiciona por conta própria — o SparkPost não o cria. Publique um registro TXT em _dmarc.yourdomain.com começando com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none é apenas monitoramento: não muda nada na entrega enquanto os destinatários enviam a você relatórios agregados (rua) para que você possa confirmar que o e-mail do SparkPost está passando em SPF e DKIM alinhados ao seu domínio. É aqui que a configuração em duas partes do SparkPost compensa — assim que seu registro DKIM scph for verificado, você obtém alinhamento de DKIM, e assim que seu bounce domain personalizado for verificado, você obtém alinhamento de SPF também, então um domínio SparkPost bem configurado passa no DMARC por ambos os mecanismos, em vez de depender só do DKIM. Acompanhe os relatórios por uma ou duas semanas, certifique-se de que todo remetente legítimo (SparkPost mais qualquer outro que você use) está autenticando, e então aperte para p=quarantine e, por fim, p=reject. Mantenha exatamente um registro _dmarc para todo o domínio organizacional, não importa quantos remetentes você opere — nunca publique um segundo registro DMARC específico para o SparkPost.
Confirme que funcionou de verdade
Não confie apenas nos ticks verdes do painel — confirme em uma mensagem real. Envie para si mesmo um teste pelo SparkPost a partir de um endereço no domínio autenticado, abra-o no Gmail e escolha ⋮ → Mostrar original. Você quer DKIM: PASS assinado por yourdomain.com com o seletor scph (não um domínio compartilhado do SparkPost), SPF: PASS onde o mailfrom/Return-Path mostra seu subdomínio de bounce (bounces.yourdomain.com — a falha reveladora é um mailfrom ainda em sparkpostmail.com, o que significa que seu bounce domain personalizado não está configurado), e DMARC: PASS. No SparkPost, Configuration → Sending Domains deve mostrar o domínio verificado com DKIM Signing pronto, e Bounce Domains deve mostrar seu subdomínio de bounce verificado. Depois, passe seu domínio pelo teste de saúde de domínio da Qualisend para confirmar que o TXT DKIM, o CNAME de bounce e o registro DMARC resolvem todos corretamente, e assim que os relatórios agregados de DMARC começarem a chegar, jogue um deles no analisador de relatórios DMARC — o SparkPost deve aparecer como uma fonte alinhada e aprovada.
Pegadinhas comuns
- Configuração de DNS
A grande armadilha: adicionar include:sparkpostmail.com ao seu SPF raiz NÃO faz o DMARC passar. O SparkPost detém o envelope (bounce domain padrão = sparkpostmail.com), então seu SPF raiz nunca é consultado para o e-mail do SparkPost. O alinhamento vem do TXT DKIM scph mais um CNAME de bounce domain personalizado — não de um include no SPF.
- Cobertura
Com o bounce domain padrão, o SPF passa em sparkpostmail.com mas não alinha a você, então o DMARC se apoia inteiramente no DKIM. Adicione um Bounce Domain personalizado para obter um segundo mecanismo alinhado e sobreviver a destinatários mais rigorosos.
- Configuração de DNS
O DKIM do SparkPost é um registro TXT (seletor scph), não um CNAME. Não mude o tipo — um CNAME onde o TXT scph deveria estar quebra a assinatura DKIM. E não há rotação automática de chave: para rotacionar, gere uma nova chave no SparkPost e republique o TXT.
- Configuração de DNS
O SparkPost usa por padrão uma chave DKIM de 2048 bits, cujo valor é mais longo que o limite de 255 caracteres do TXT. Alguns painéis de DNS obrigam você a dividi-la em várias strings entre aspas — divida-a, não a trunque nem adicione espaços perdidos dentro do valor p=.
- Configuração de DNS
O proxy do Cloudflare quebra o CNAME de bounce. Defina o registro do bounce domain como 'DNS only' (nuvem cinza) — um CNAME proxiado com nuvem laranja não resolverá para sparkpostmail.com e o domínio não será verificado.
- Configuração de DNS
Você não pode usar seu domínio raiz/apex como bounce domain — um CNAME no apex colide com seus outros registros. Use um subdomínio (bounces.yourdomain.com para alinhamento relaxado, ou reutilize seu subdomínio de envio exato para alinhamento estrito).
- Configuração de DNS
O SparkPost EU é uma stack separada: entre em app.eu.sparkpost.com, envie via smtp.eu.sparkpostmail.com / api.eu.sparkpost.com, e aponte o CNAME de bounce para eu.sparkpostmail.com (não sparkpostmail.com). O mesmo domínio no US e na EU são dois registros independentes, cada um com seus próprios registros DNS.
- Quebra a autenticação
Mantenha exatamente um TXT SPF e um TXT _dmarc no seu domínio. Se você mantiver o include legado do SparkPost por algum motivo, mescle-o na sua única linha v=spf1 — dois registros SPF já são, por si só, um PermError.
- Configuração de DNS
Verifique no painel após publicar — o SparkPost não fará a assinatura DKIM até que Configuration → Sending Domains mostre o domínio verificado. A propagação pode levar até 24–48 horas; se a verificação travar, revise o host do registro em busca de um domínio anexado/duplicado.
Monte seu registro SPF
O SparkPost 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 SparkPost — 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.