SPF, DKIM & DMARC para Rackspace Email.
O Rackspace Email é a parte de caixas de correio hospedadas do Rackspace Cloud Office (você também vai vê-lo chamado de Rackspace Hosted Email), e você o autentica com três registros DNS mais um botão dentro do Cloud Office Control Panel: um registro SPF TXT que adiciona o include compartilhado do Rackspace (include:emailsrvr.com), uma chave DKIM que você ativa no painel de controle e publica como um registro TXT, e uma política DMARC que você mesmo adiciona. O detalhe específico do Rackspace que molda toda a configuração: seu SPF pode passar de forma bruta, mas não consegue se alinhar ao seu domínio, então o DKIM é o único mecanismo que faz o DMARC passar. No Rackspace, ativar o DKIM não é um "seria bom ter" — é o passo que sustenta tudo.
Por que autenticar o Rackspace Email?
Autenticar um domínio do Rackspace Email decide se sua mensagem chega à caixa de entrada, e o Rackspace tem uma peculiaridade estrutural que silenciosamente quebra o DMARC se você parar no SPF. 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, a Microsoft começou a exigir o mesmo em 2025 para mensagens de alto volume enviadas ao Outlook/Hotmail/Live, e até remetentes de baixo volume são cada vez mais avaliados por terem autenticação válida. O problema específico do Rackspace: o Rackspace envia sua mensagem de saída com o remetente do envelope (Return-Path / endereço de bounce) em um de seus próprios domínios, e não oferece nenhuma forma de definir um Return-Path ou domínio de bounce personalizado. Isso significa que include:emailsrvr.com pode fazer a verificação bruta do SPF passar, mas o SPF nunca se alinha com o seu domínio do From — então o DMARC não recebe nada do SPF. O único mecanismo alinhado que resta é o DKIM assinado como o seu domínio. Ative o DKIM e o DMARC passa pelo alinhamento de DKIM; a reputação de envio que você constrói é creditada ao seu próprio domínio em vez de ser agrupada com todo remetente Rackspace não autenticado. Pule esse passo e você não terá nenhuma autenticação alinhada.
A realidade do SPF para o Rackspace Email
O Rackspace é um provedor "include" genuíno: você adiciona um mecanismo compartilhado, include:emailsrvr.com, ao único registro SPF TXT no seu domínio raiz — o registro completo é v=spf1 include:emailsrvr.com ~all, e o Rackspace recomenda o qualificador ~all (softfail). É um include real e bem-comportado: o registro SPF de emailsrvr.com ao vivo é uma única lista plana de faixas ip4: terminada por ~all, sem sub-includes aninhados, então ele custa exatamente UMA das suas 10 consultas DNS de SPF. Mas aqui está a parte que quase todo tutorial de Rackspace pula: publicar esse include NÃO faz o DMARC passar. O Rackspace envia toda mensagem com o remetente do envelope / Return-Path em um de seus próprios domínios (não o seu), e não oferece nenhuma opção de Return-Path ou domínio de bounce personalizado. O SPF é sempre avaliado contra aquele domínio do envelope, então include:emailsrvr.com pode "passar" de forma bruta, mas nunca consegue se ALINHAR com o seu domínio organizacional do From — e o DMARC só conta o SPF quando ele está alinhado. Então você ainda deve publicar include:emailsrvr.com (ele autoriza os IPs de envio do Rackspace e satisfaz receptores que verificam uma passagem bruta de SPF), mas trate-o como necessário, não suficiente: o DKIM assinado como d=yourdomain.com é o único e exclusivo mecanismo que carrega a sua passagem de DMARC aqui. E mantenha exatamente um registro SPF — se você também envia via Google Workspace, Microsoft 365 ou um ESP, mescle todos os mecanismos naquela única linha v=spf1 em vez de publicar um segundo SPF TXT (dois registros SPF é um PermError).
Passo a passo
- 1
Faça login no Cloud Office Control Panel
Entre no Rackspace Cloud Office Control Panel (cp.rackspace.com, acessado a partir de rackspace.com/login) como administrador. É aqui que você ativa o DKIM; os registros SPF e DMARC são adicionados em qualquer provedor de DNS que hospede a zona do seu domínio — que pode ou não ser o Rackspace.
- 2
Publique ou mescle o registro SPF
No seu provedor de DNS, adicione UM registro TXT na raiz (host @ ou em branco) com v=spf1 include:emailsrvr.com ~all. Se um registro v=spf1 já existir (Google Workspace, Microsoft 365, uma ferramenta de marketing, etc.), não crie um segundo — mescle include:emailsrvr.com naquele único registro. O Rackspace recomenda terminar com ~all em vez de -all.
- 3
Abra Sender Authentication (DKIM)
Na página inicial (Home) do Cloud Office Control Panel, na seção Domains, clique no link Sender Authentication (DKIM). Este é o fluxo de DKIM específico do Rackspace Email — não o confunda com o artigo genérico de Cloud DNS do Rackspace 'create a DKIM TXT record', em que você escolhe o seu próprio selector.
- 4
Ative o DKIM para o seu domínio
Selecione o domínio que você quer autenticar e clique em Enable DKIM. O Rackspace gera um par de chaves DKIM (mantendo a chave privada do lado dele) e produz o registro DNS de chave pública que você vai publicar. Ele atribui o selector para você e o mostra como parte do nome do registro — você não inventa um como faria no fluxo genérico de Cloud DNS.
- 5
Copie a TXT Record Key e o Value (ou deixe o Rackspace publicar automaticamente)
Se o DNS do seu domínio for hospedado no Rackspace, o DKIM é publicado automaticamente — você pode pular o passo manual de DNS. Se o seu DNS estiver em outro lugar, o Rackspace exibe uma TXT Record Key (o host, no formato <selector>._domainkey.yourdomain.com) e um TXT Record Value (v=DKIM1; k=rsa; p=<chave pública>). Copie ambos exatamente.
- 6
Adicione o registro DKIM TXT
No seu provedor de DNS, crie um registro TXT: host = a TXT Record Key que o Rackspace lhe deu (<selector>._domainkey), value = o TXT Record Value (v=DKIM1; k=rsa; p=…). Mantenha-o como um registro TXT — o Rackspace lhe entrega a chave pública embutida, não uma delegação por CNAME. Se o seu registrador acrescentar o domínio automaticamente, digite apenas o rótulo <selector>._domainkey para que ele não fique duplicado.
- 7
Clique em Verify TXT Record
De volta à página Sender Authentication (DKIM), aguarde o registro propagar (geralmente minutos, até 24–48 horas), depois clique em Verify TXT Record. O Rackspace verifica o registro publicado e só então começa a assinar sua mensagem de saída com d=yourdomain.com. Uma chave gerada mas não verificada não faz nada.
- 8
Adicione o registro DMARC
O Rackspace não cria o DMARC para você. Adicione um registro TXT no host _dmarc com v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Comece em p=none (apenas monitoramento) para que nada seja afetado enquanto você confirma que o DKIM está alinhando — crítico aqui, porque o SPF não consegue resgatar a mensagem do Rackspace se você endurecer cedo demais.
- 9
Envie um teste e leia os cabeçalhos
A partir de uma caixa de correio Rackspace no domínio, envie um e-mail para si mesmo no Gmail, abra a mensagem e escolha ⋮ → Show original. Você quer DKIM: PASS com d=yourdomain.com e DMARC: PASS. O SPF pode mostrar passagem-mas-não-alinhada (envelope em um domínio emailsrvr/Rackspace) — isso é esperado no Rackspace; o alinhamento de DKIM é o que carrega a passagem do DMARC.
Registros a adicionar
O Rackspace Email 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:emailsrvr.com ~allSPF raiz — mantenha exatamente UM registro SPF; mescle este include se você já tiver uma linha v=spf1. include:emailsrvr.com custa 1 consulta DNS (um registro ip4 plano). Observação: isso autoriza os IPs do Rackspace mas NÃO alinha — o DKIM carrega o DMARC. |
| TXT | <selector>._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(public key from the Control Panel)Ilustrativo — o Rackspace gera o selector e a chave pública exatos quando você clica em Enable DKIM. Publicado como um registro TXT (não um CNAME). Este é o único mecanismo que alinha com o DMARC no Rackspace. Adicionado automaticamente se o Rackspace hospedar o seu DNS. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVocê mesmo adiciona isto — o Rackspace nunca o cria. Um por domínio; comece em p=none e não endureça até que o DKIM esteja ativado e verificado. |
| MX | @ | mx1.emailsrvr.com (priority 10), mx2.emailsrvr.com (priority 20)Ilustrativo — roteia a mensagem de entrada para o Rackspace. São registros de recebimento, não de autenticação, mas fazem parte de uma configuração completa do Rackspace Email. |
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 Rackspace Email consome desse limite.
O Rackspace Email usa 1 das suas 10 consultas; os mecanismos ip4: e ip6: são gratuitos.
DKIM
O DKIM é o jogo todo no Rackspace, porque é o único mecanismo que pode se alinhar ao seu domínio (o SPF não consegue — veja a realidade do SPF acima). Você o ativa no Cloud Office Control Panel, não no seu provedor de DNS: página inicial (Home) → Domains → Sender Authentication (DKIM) → selecione seu domínio → Enable DKIM. O Rackspace então gera um par de chaves DKIM, mantém a chave privada do lado dele, atribui um selector e produz o registro de chave pública para você publicar. A partir daí, há dois caminhos. Se o DNS do seu domínio for hospedado no Rackspace, o registro é publicado automaticamente e você termina assim que verificar. Se o seu DNS estiver em outro lugar (um registrador, Cloudflare, etc.), o Rackspace exibe uma 'TXT Record Key' (o host, no formato <selector>._domainkey.yourdomain.com) e um 'TXT Record Value' (v=DKIM1; k=rsa; p=<sua chave pública>); você adiciona isso como um registro TXT no seu provedor de DNS, depois retorna ao painel e clica em Verify TXT Record para que o Rackspace confirme que está no ar e comece a assinar. Duas coisas tornam o DKIM do Rackspace diferente dos grandes provedores de delegação por CNAME. Primeiro, é um registro TXT estático com a chave pública embutida — ao contrário do Microsoft 365 ou da maioria dos ESPs (SendGrid, Mailchimp e similares), que lhe entregam CNAMEs que os deixam rotacionar chaves silenciosamente nos bastidores, o Rackspace lhe dá o valor real da chave, então se você algum dia regerá-la no painel, precisa republicar o novo TXT. (O Google Workspace também usa uma chave TXT como o Rackspace, então são os provedores de CNAME que se comportam de forma diferente.) Segundo, publicar o registro não é suficiente: a assinatura só começa depois que você clica em Verify TXT Record. As chaves têm sido historicamente de 1024 bits; seja o que for que o painel gerar, publique exatamente como mostrado.
DMARC
O DMARC é um registro TXT de política separado que você mesmo publica — o Rackspace não o cria. Adicione-o 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 você observa os relatórios agregados (rua) para confirmar que sua mensagem do Rackspace está passando no DKIM alinhado ao seu domínio. Isso importa mais no Rackspace do que na maioria dos provedores por causa da autenticação de uma perna só: o SPF não consegue se alinhar aqui, então o DMARC depende inteiramente do DKIM. Isso tem uma consequência dura — NÃO avance além de p=none até que o DKIM esteja ativado e verificado no Control Panel. Se você endurecer para p=quarantine ou p=reject enquanto o DKIM estiver desligado (ou não verificado), sua própria mensagem legítima do Rackspace não terá nenhum mecanismo alinhado e será colocada em quarentena ou rejeitada, porque a passagem bruta do SPF não consegue resgatá-la. Assim que o Show original confirmar DKIM: PASS com d=yourdomain.com em mensagens reais do Rackspace, observe os relatórios por uma ou duas semanas, depois avance para p=quarantine e por fim p=reject. Mantenha exatamente um registro _dmarc para todo o domínio organizacional; os subdomínios o herdam (sobrescreva um específico com o próprio registro _dmarc ou a tag sp=).
Confirme que funcionou de verdade
Não confie apenas no selo de DKIM 'verificado' do Control Panel — confirme-o em uma mensagem real. Envie a si mesmo um teste a partir de uma caixa de correio Rackspace no domínio, abra-o no Gmail e escolha ⋮ → Show original. Você quer DKIM: PASS com d=yourdomain.com e DMARC: PASS. Espere que o SPF mostre uma passagem que NÃO está alinhada (o envelope/Return-Path fica em um domínio de propriedade do Rackspace) — isso é normal no Rackspace e é exatamente por isso que o DKIM tem que carregar a passagem do DMARC; o sinal revelador de sucesso é DMARC: PASS atribuído ao DKIM. No Control Panel, Sender Authentication (DKIM) deve mostrar o domínio como ativado e o registro TXT verificado. Depois passe seu domínio pelo {healthCheck} da Qualisend para confirmar que o SPF, o DKIM selector TXT e o registro DMARC resolvem todos de forma limpa e que o SPF permanece abaixo do limite de 10 consultas, e assim que os relatórios agregados de DMARC começarem a chegar, jogue um deles no {dmarcAnalyzer} — Rackspace / emailsrvr.com deve aparecer como uma fonte passando no alinhamento de DKIM.
Pegadinhas comuns
- Cobertura
A armadilha nº 1 do Rackspace: o SPF NUNCA pode alinhar. O Rackspace coloca o Return-Path/envelope no próprio domínio e não oferece domínio de bounce personalizado, então include:emailsrvr.com passa de forma bruta mas não dá nada ao DMARC. O DKIM assinado como d=yourdomain.com é o único mecanismo alinhado — ativá-lo é obrigatório, não opcional.
- Configuração de DNS
Ativar o DKIM são duas ações, não uma: clique em Enable DKIM para gerar a chave, publique o registro TXT, DEPOIS clique em Verify TXT Record. O Rackspace só começa a assinar após a verificação — uma chave gerada mas não verificada (ou não publicada) ainda falha em todas as verificações.
- Configuração de DNS
Se o Rackspace hospedar o seu DNS (seus nameservers apontam para o Rackspace), o painel publica o registro DKIM para você — não o adicione também manualmente, ou você criará uma duplicata/conflito. Se o seu DNS estiver em outro lugar, você mesmo precisa copiar a TXT Record Key/Value para a sua própria zona.
- Cobertura
Não endureça o DMARC além de p=none até que o DKIM esteja verificado. Como o SPF não consegue alinhar no Rackspace, uma política p=quarantine ou p=reject com o DKIM ainda desligado colocará em quarentena ou rejeitará sua própria mensagem legítima.
- Configuração de DNS
O DKIM do Rackspace é um registro TXT estático com a chave pública embutida — não um CNAME delegado ao Rackspace como funcionam o Microsoft 365 e a maioria dos ESPs (SendGrid, Mailchimp, etc.). O Rackspace não consegue rotacioná-lo silenciosamente, então se você algum dia regerá-la no painel, precisa republicar o novo valor TXT.
- Quebra a autenticação
Mantenha exatamente UM registro SPF TXT no domínio. Se você também envia via Google Workspace, Microsoft 365 ou um ESP, mescle include:emailsrvr.com naquela única linha v=spf1 — dois registros SPF são, por si só, um PermError.
- Cobertura
Use ~all, não -all — a própria recomendação do Rackspace — porque você também pode enviar legitimamente por outras ferramentas. Só passe para -all quando todo remetente estiver listado no seu único registro SPF.
- Configuração de DNS
Não siga o artigo genérico de Cloud DNS do Rackspace 'create a DKIM TXT record' (em que você inventa o seu próprio selector) para uma caixa de correio — usuários de Cloud Office/Rackspace Email usam o fluxo Sender Authentication (DKIM) → Enable DKIM do Control Panel, que gera o selector e a chave para você.
Monte seu registro SPF
O Rackspace Email 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 Rackspace Email — 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.