Quando organizações europeias implementam DMARC para proteger seus domínios de e-mail, a escolha do provedor de DMARC não é apenas uma decisão técnica.
Também pode se tornar uma decisão de governança de dados, risco de fornecedores e transferência internacional.
Relatórios DMARC podem revelar mais do que o status de autenticação. Eles podem mostrar quais sistemas enviam e-mails em nome de um domínio, quais fornecedores estão envolvidos, onde a autenticação falha, quais endereços IP estão ativos, como o e-mail flui entre regiões e onde tentativas de envio não autorizadas podem estar ocorrendo.
Para organizações da UE, essas informações podem ser relevantes sob a GDPR, obrigações contratuais de proteção de dados, regulamentações específicas do setor e políticas internas de residência de dados.
A Lei CLOUD dos EUA adiciona outra camada a essa avaliação.
A Lei CLOUD pode exigir que provedores de serviços dos EUA cobertos preservem, façam backup ou divulguem determinados dados sob sua posse, custódia ou controle, mesmo quando os dados estão armazenados fora dos Estados Unidos. Para organizações da UE que usam provedores de tecnologia baseados ou controlados pelos EUA, isso pode criar questões legais e jurisdicionais que devem ser avaliadas antes de rotear telemetria de segurança para uma plataforma de terceiros.
Isso não significa que empresas da UE não possam usar provedores baseados nos EUA.
Significa que elas devem entender quais dados estão sendo processados, onde são armazenados, qual mecanismo legal de transferência se aplica, quais salvaguardas estão em vigor e como solicitações de acesso governamental são tratadas.
Proteção DMARC e proteção de dados não devem ser tratadas como conversas separadas.
Ambas fazem parte da mesma arquitetura de confiança.
Aviso Legal: Este artigo fornece informações gerais e não deve ser considerado aconselhamento jurídico. As organizações devem consultar advogados qualificados para requisitos específicos de conformidade, avaliações de transferência e obrigações regulatórias.
I. O Que a Lei CLOUD Significa Neste Contexto
A Lei CLOUD dos EUA, promulgada em 2018, esclareceu que certos provedores de serviços dos EUA podem ser obrigados a divulgar dados sob sua posse, custódia ou controle, independentemente de esses dados estarem armazenados dentro ou fora dos Estados Unidos.
Para serviços DMARC, a questão relevante não é apenas se o provedor armazena dados na Europa.
A questão mais profunda é:
Quem controla o serviço, quem pode acessar os dados e quais regimes legais podem se aplicar ao provedor?
Isso importa porque provedores de DMARC podem processar telemetria de segurança operacional que é útil tanto para defensores quanto para invasores.
Dependendo da implementação, um provedor de DMARC pode processar:
- Relatórios agregados DMARC
- Relatórios de falha ou forenses DMARC, se habilitados
- Endereços IP de envio
- Resultados de autenticação
- Dados de alinhamento SPF, DKIM e DMARC
- Padrões de volume de e-mail
- Informações de remetentes terceiros
- Configurações de domínio
- Dados de contas de usuário e administrador
- Análises de segurança derivadas de relatórios
- Dados históricos de aplicação e política
Essas informações podem nem sempre conter conteúdo de mensagens, especialmente em relatórios agregados. Mas ainda podem revelar detalhes operacionais sensíveis sobre a infraestrutura de e-mail de uma organização.
É por isso que a seleção de provedor deve ser avaliada através de uma perspectiva tanto de segurança quanto de privacidade.
II. Por Que os Dados de Relatórios DMARC Podem Ser Sensíveis
Relatórios DMARC são frequentemente descritos como registros técnicos.
Essa descrição está incompleta.
Dados DMARC podem revelar como uma organização envia e-mails, quais plataformas são autorizadas, quais fornecedores estão configurados incorretamente, quais domínios não estão totalmente protegidos e onde tentativas de spoofing estão ocorrendo.
Por exemplo, dados agregados DMARC podem mostrar:
- Quais endereços IP estão enviando em nome do domínio
- Quais provedores são usados para e-mail transacional
- Quais plataformas de marketing estão ativas
- Quais sistemas internos enviam e-mail
- Quais fontes falham no alinhamento SPF ou DKIM
- Quais terceiros não estão configurados adequadamente
- Quais subdomínios estão expostos
- Quais provedores de recebimento estão vendo falhas de autenticação
Essas informações são valiosas para equipes de segurança.
Também podem ser valiosas para invasores.
Um programa DMARC maduro deve, portanto, evitar tratar dados de relatório como metadados inofensivos. Eles devem ser governados como telemetria de segurança.
III. GDPR e Transferências Internacionais de Dados
Para organizações da UE, a GDPR se torna relevante quando dados pessoais são processados ou transferidos para fora do Espaço Econômico Europeu.
O Capítulo V da GDPR restringe transferências de dados pessoais para países terceiros, a menos que um mecanismo de transferência válido se aplique. Esses mecanismos podem incluir uma decisão de adequação, Cláusulas Contratuais Padrão com quaisquer medidas suplementares necessárias, Regras Corporativas Vinculativas ou outro mecanismo permitido pela GDPR.
A decisão Schrems II aumentou o escrutínio sobre transferências para provedores sujeitos a vigilância de países terceiros ou regimes de acesso legal. Desde então, espera-se que as organizações avaliem não apenas o contrato, mas também o ambiente legal e as salvaguardas práticas em torno da transferência.
A Estrutura de Privacidade de Dados UE-EUA, adotada em 2023, fornece um mecanismo de adequação para organizações dos EUA certificadas. No entanto, as organizações ainda precisam confirmar se um provedor está certificado, se o processamento relevante está coberto e se salvaguardas contratuais ou técnicas adicionais são necessárias para seu caso de uso específico.
Para seleção de provedor DMARC, a avaliação prática deve incluir:
- Dados de relatório DMARC são dados pessoais, telemetria de segurança ou ambos?
- Onde os dados são armazenados?
- Onde os dados são processados?
- Quais entidades podem acessá-los?
- O provedor é baseado na UE, nos EUA ou parte de um grupo corporativo mais amplo?
- Uma transferência internacional está ocorrendo?
- Qual mecanismo de transferência se aplica?
- Cláusulas Contratuais Padrão ou outro mecanismo estão em vigor?
- Medidas suplementares são necessárias?
- Qual período de retenção se aplica?
- Relatórios forenses são desabilitados por padrão?
- Como o provedor lida com solicitações de acesso governamental?
Esta avaliação deve ser documentada, especialmente para organizações regulamentadas ou empresas com obrigações estritas de residência de dados.
IV. A Lei CLOUD Não Significa Automaticamente Não Conformidade
É importante evitar simplificar demais a questão.
Usar um provedor baseado nos EUA não significa automaticamente não conformidade com a GDPR.
Usar um data center na UE não elimina automaticamente todo risco jurisdicional.
A questão de conformidade depende do contexto completo:
- Estrutura legal do provedor
- Local de processamento de dados
- Controles de acesso a dados
- Modelo de criptografia
- Salvaguardas contratuais
- Mecanismo de transferência
- Política de acesso governamental
- Relatórios de transparência
- Práticas de minimização de dados
- Limites de retenção
- Controle do cliente sobre dados
- Se o acesso de suporte ou engenharia ocorre fora da UE
Uma avaliação séria analisa o modelo operacional completo, não apenas o país onde o servidor está hospedado.
V. Áreas de Risco de Provedores DMARC Que Empresas da UE Devem Revisar
Ao selecionar ou revisar um provedor de DMARC, organizações da UE devem avaliar várias áreas.
VI. 1. Estrutura Legal
Entenda quem é a entidade contratante.
Um fornecedor baseado na UE, um fornecedor baseado nos EUA e uma subsidiária da UE de um grupo dos EUA podem apresentar diferentes considerações legais e operacionais.
Perguntas a fazer:
- Qual entidade legal fornece o serviço?
- Qual entidade assina o Acordo de Processamento de Dados?
- Quais entidades têm acesso aos dados do cliente?
- Suporte, engenharia ou operações de segurança são realizados fora da UE?
- O provedor está sujeito às regras de acesso legal dos EUA?
- Subprocessadores estão envolvidos?
A resposta deve ser documentada na revisão de risco de fornecedor.
VII. 2. Residência de Dados e Local de Processamento
Residência de dados é importante, mas deve ser entendida precisamente.
Um provedor pode armazenar dados na UE enquanto o acesso de suporte ou análise ocorre em outro lugar. Outro provedor pode processar relatórios fora da UE enquanto oferece faturamento ou contratação na UE.
Perguntas a fazer:
- Onde os relatórios DMARC são armazenados?
- Onde os relatórios são analisados e processados?
- Onde os backups são mantidos?
- Onde os logs são armazenados?
- Os administradores podem restringir o processamento de dados à UE?
- O provedor usa subprocessadores fora da UE?
- O acesso de suporte requer acesso transfronteiriço?
O objetivo é entender o caminho real dos dados, não apenas a alegação de marketing.
VIII. 3. Tipos de Relatórios DMARC
Nem todos os dados DMARC têm a mesma sensibilidade.
Relatórios agregados são geralmente menos invasivos do que relatórios forenses ou de falha. Relatórios agregados geralmente contêm resultados de autenticação e informações de fonte de envio. Relatórios de falha podem conter dados em nível de mensagem, dependendo da implementação do receptor.
Para organizações da UE, o padrão mais seguro é:
- Use relatórios agregados através de
rua=para monitoramento. - Evite relatórios forenses através de
ruf=, a menos que equipes de privacidade, jurídica e segurança os aprovem. - Aplique limites de minimização e retenção de dados.
- Evite coletar mais do que o necessário para autenticação e aplicação.
Relatórios de falha têm adoção limitada entre os principais receptores e podem criar obrigações adicionais de privacidade e retenção. Não devem ser habilitados casualmente.
IX. 4. Controles de Acesso
Plataformas DMARC podem expor telemetria sensível a usuários internos.
As organizações devem revisar:
- Controles de acesso baseados em função
- Permissões de administrador
- Requisitos de MFA
- Logs de auditoria
- Controles de acesso à API
- Controles de sessão
- Permissões de exportação
- Procedimentos de acesso de suporte
- Separação entre clientes
Telemetria de segurança não deve ser amplamente acessível sem governança.
X. 5. Acesso Governamental e Transparência
Organizações da UE devem entender como o provedor lida com solicitações de acesso legal.
Perguntas a fazer:
- O provedor publica relatórios de transparência?
- O provedor notifica clientes quando legalmente permitido?
- O provedor contesta solicitações excessivamente amplas ou ilegais?
- O provedor divulga subprocessadores?
- O provedor explica como lida com solicitações que afetam dados de clientes da UE?
- Obrigações contratuais de notificação estão incluídas?
Isso não elimina todo o risco, mas melhora a transparência e a responsabilidade.
XI. 6. Retenção e Exclusão
Quanto mais tempo a telemetria DMARC for retida, maior se torna a superfície de exposição.
As organizações devem confirmar:
- Período de retenção padrão
- Retenção configurável pelo cliente
- Cronogramas de exclusão de backup
- Direitos de exportação e exclusão
- Políticas de retenção de log
- Processo de exclusão de encerramento de conta
A retenção deve corresponder à necessidade operacional.
Para muitas organizações, o armazenamento indefinido de telemetria DMARC bruta é desnecessário.
XII. DPIA e Avaliação de Impacto de Transferência
Organizações da UE devem considerar se uma Avaliação de Impacto de Proteção de Dados ou Avaliação de Impacto de Transferência é apropriada ao implementar um provedor DMARC.
Isso é especialmente relevante se:
- Dados DMARC são roteados para um provedor de país terceiro.
- A organização opera em um setor regulamentado.
- O provedor processa dados fora do EEE.
- Relatórios de falha estão habilitados.
- O domínio é usado para comunicações sensíveis.
- O provedor tem acesso a telemetria detalhada de segurança operacional.
- Padrões de comunicação de clientes ou funcionários podem ser inferidos.
Uma avaliação prática deve cobrir:
- Quais dados são coletados
- Por que os dados são necessários
- Se os dados incluem dados pessoais
- Qual mecanismo de transferência se aplica
- Quais salvaguardas estão em vigor
- Quais subprocessadores estão envolvidos
- Por quanto tempo os dados são retidos
- Quem pode acessar os dados
- Como solicitações de acesso governamental são tratadas
- Se alternativas menos intrusivas estão disponíveis
O objetivo não é criar papelada por si só.
O objetivo é tornar o fluxo de dados defensável.
XIII. Salvaguardas Técnicas Que Reduzem o Risco
Salvaguardas legais importam, mas salvaguardas técnicas são igualmente importantes.
Organizações da UE devem procurar provedores DMARC que suportem:
- Opções de residência de dados na UE
- Minimização de dados
- Criptografia em trânsito e em repouso
- Controles de acesso fortes
- Aplicação de MFA
- Registro de auditoria
- Retenção controlada pelo cliente
- Acesso de suporte limitado
- Transparência de subprocessadores
- Ingestão segura de relatórios
- Separação entre inquilinos
- Procedimentos claros de exclusão
- Controles de segurança de API
Essas salvaguardas reduzem a exposição e melhoram a defensibilidade.
Nenhuma salvaguarda única resolve a questão da Lei CLOUD ou transferência GDPR por si só. A força vem da combinação de controles contratuais, técnicos, organizacionais e de governança.
XIV. Governança Operacional para Dados DMARC
DMARC não deve ser tratado como um projeto DNS único.
Deve fazer parte de um programa de governança contínuo.
As organizações devem manter:
- Inventário de domínio
- Inventário de remetente
- Registros de destino de relatórios DMARC
- Avaliações de risco de provedor
- Acordos de Processamento de Dados
- Avaliações de transferência onde aplicável
- Revisões de subprocessadores
- Decisões de retenção
- Revisões de controle de acesso
- Procedimentos de resposta a incidentes
- Registros de gestão de mudanças
- Evidências de monitoramento e remediação
Esta documentação ajuda a provar que dados DMARC são gerenciados ativamente, não simplesmente terceirizados.
XV. Perguntas a Fazer a um Provedor DMARC
Antes de escolher ou renovar com um provedor DMARC, organizações da UE devem perguntar:
- Qual entidade legal fornece o serviço?
- Onde os dados de relatório DMARC são armazenados?
- Onde os dados de relatório DMARC são processados?
- Quais subprocessadores são usados?
- O processamento pode ser restrito à UE?
- Dados do cliente são acessados por equipes de suporte ou engenharia fora da UE?
- Qual mecanismo de transferência se aplica se os dados saírem do EEE?
- Cláusulas Contratuais Padrão estão disponíveis onde necessário?
- O provedor está certificado pela Estrutura de Privacidade de Dados UE-EUA, se aplicável?
- Relatórios forenses são desabilitados por padrão?
- Qual é o período de retenção de dados padrão?
- A retenção pode ser reduzida?
- Quais controles de acesso estão disponíveis?
- Logs de auditoria estão disponíveis?
- O provedor publica relatórios de transparência?
- O provedor notifica clientes de solicitações de acesso governamental quando legalmente permitido?
- Como os dados são excluídos após o término?
- Os clientes podem exportar seus dados?
- Como os backups são tratados?
- O provedor suporta requisitos de implantação focados na UE?
Essas perguntas ajudam a transformar uma discussão vaga sobre residência de dados em uma avaliação prática de fornecedor.
XVI. Verifique Se Seu Provedor DMARC É da UE ou Não-UE
Muitas empresas da UE não sabem para onde seus relatórios DMARC estão sendo enviados.
Um domínio pode ter DMARC habilitado, mas o destino de relatórios pode apontar para um provedor não-UE, um fornecedor antigo, uma caixa de correio não gerenciada ou um processador terceiro que nunca foi revisado por equipes jurídicas, de segurança ou de conformidade.
Isso importa porque muitos provedores DMARC não são baseados na UE.
Para organizações da UE, a localização e estrutura legal do provedor DMARC devem fazer parte da revisão de risco de fornecedor.
Relatórios DMARC podem revelar:
- Remetentes autorizados
- Fluxos de e-mail
- Falhas de autenticação
- Fornecedores terceiros
- Lacunas de proteção de domínio
- Tentativas de envio não autorizadas
Esses dados não devem ser roteados cegamente.
Use o scanner da Skysnag para verificar se seu destino de relatórios DMARC aponta para um provedor da UE ou não-UE:
O scanner ajuda a identificar seu registro DMARC atual e destino de relatórios para que sua equipe possa revisar se seu provedor corresponde às suas expectativas de GDPR, residência de dados e conformidade interna.
Uma verificação pública não pode substituir uma avaliação legal ou de transferência completa. Mas pode mostrar rapidamente se sua configuração DMARC merece uma revisão mais profunda.
XVII. Como o Skysnag Protect Ajuda
O Skysnag Protect ajuda organizações a implementar DMARC mantendo visibilidade e controle sobre dados de autenticação de e-mail.
Para organizações da UE, o Skysnag Protect pode apoiar a implementação DMARC com controles focados em conformidade, como:
- Monitoramento DMARC
- Identificação de remetente
- Detecção de fonte não autorizada
- Visibilidade de alinhamento SPF e DKIM
- Rastreamento de prontidão para aplicação
- Suporte MTA-STS e TLS-RPT
- Relatórios para equipes de segurança e conformidade
- Suporte de governança de dados para telemetria DMARC
- Opções de residência de dados europeia, quando necessário
O objetivo não é apenas publicar um registro DMARC.
O objetivo é construir um programa controlado de autenticação de e-mail que suporte expectativas de segurança, privacidade e conformidade.
As organizações podem saber mais sobre o Skysnag Protect aqui:
XVIII. Principais Conclusões
A Lei CLOUD dos EUA não é uma lei DMARC e não cria requisitos DMARC específicos.
No entanto, pode ser relevante quando organizações da UE usam provedores de tecnologia baseados ou controlados pelos EUA para processar dados de relatório DMARC.
Relatórios DMARC podem revelar telemetria de segurança operacional sensível, incluindo remetentes, fornecedores, falhas de autenticação, fluxos de e-mail e lacunas de proteção de domínio.
Organizações da UE devem avaliar provedores DMARC através de uma perspectiva de GDPR, risco de fornecedor, transferência e governança de dados.
Áreas de revisão importantes incluem:
- Estrutura legal
- Residência de dados
- Local de processamento
- Subprocessadores
- Mecanismos de transferência
- Controles de acesso
- Retenção
- Relatórios forenses
- Políticas de acesso governamental
Relatórios agregados DMARC geralmente devem ser o padrão. Relatórios forenses devem ser habilitados apenas após revisão jurídica, de privacidade e segurança.
Usar um provedor baseado nos EUA não significa automaticamente não conformidade, e usar um data center na UE não elimina automaticamente todo risco. O modelo operacional completo importa.
Um programa DMARC maduro deve proteger o domínio enquanto também controla os dados criados por essa proteção.
Para organizações da UE, a pergunta certa não é apenas:
“Temos DMARC?”
A pergunta mais forte é:
“Sabemos para onde nossos dados DMARC vão, quem pode acessá-los e se esse processamento é defensável sob nossas obrigações legais e de conformidade?”
Se você é uma empresa da UE, comece verificando para onde seus relatórios DMARC estão indo. Use o scanner da Skysnag para ver se seu provedor DMARC atual parece ser da UE ou não-UE:
