Rapport DMARC agrégé (RUA) : lire le fichier google.com!domaine.zip

Des administrateurs reçoivent parfois une pièce jointe nommée google.com!votredomaine.com!1739059200!1739145599.zip, envoyée par noreply-dmarc-support@google.com. Ce n’est ni un virus ni une plainte utilisateur : c’est un rapport DMARC agrégé (RUA) qui résume comment Gmail a traité des messages prétendant venir de votre domaine.

Ce que DMARC vérifie

DMARC pose une question précise : SPF ou DKIM a-t-il réussi avec alignement sur le domaine visible dans l’en-tête From: ?

SPF (vue DMARC) : le domaine MAIL FROM de l’enveloppe doit autoriser l’IP et s’aligner avec le domaine du From: (strict ou relaxed, selon _dmarc).
DKIM : une signature valide doit s’aligner avec le domaine du From:.

Si l’un des deux passe avec alignement, DMARC passe. La politique publiée (p=none, quarantine, reject) s’applique surtout quand DMARC échoue.

Décoder le nom du ZIP

Format courant :

<org-rapporteur>!<domaine-politique>!<debut-unix>!<fin-unix>.zip

Partie	Signification
`google.com`	Émetteur du rapport (Gmail côté réception)
`votredomaine.com`	Domaine dont la politique DMARC est évaluée
Horodatages Unix	Fenêtre UTC (souvent une journée)

Le XML à l’intérieur reprend le même nom. Les outils de supervision DMARC ingèrent ces fichiers ; lire un rapport à la main aide à comprendre les alertes.

Trois blocs utiles dans le XML

policy_published — contenu public de _dmarc (p=, sp=, pct=, mode d’alignement).
record → row — volume par IP source et policy_evaluated (dkim, spf, disposition).
auth_results — résultats bruts SPF/DKIM (quels domaines ont été vérifiés).

Le SPF peut passer sur le domaine d’enveloppe du prestataire alors que policy_evaluated → spf vaut fail faute d’alignement avec From: votredomaine.com. C’est fréquent avec un ESP (marketing ou transactionnel).

Exemple : SPF fail, DKIM pass, disposition none

Envoi ESP légitime typique :

header_from : votre domaine
DKIM pass sur votre domaine (sélecteur mail, s1, etc.)
SPF pass sur le domaine d’enveloppe du prestataire
policy_evaluated : spf fail, dkim pass
disposition : none (pas de quarantaine : DMARC passe via DKIM)

Seul, ce motif ne prouve pas une usurpation : mail signé chez vous, enveloppe chez le tiers.

Quand cela devient une vraie difficulté

Considérez une investigation si vous observez par exemple :

DKIM fail et SPF fail depuis des IP inconnues ;
pic de volume sans nouvel expéditeur déclaré ;
quarantaine/rejet sur du trafic que vous croyez production ;
passage à p=quarantine / reject et baisse soudaine du trafic légitime après changement DNS ou ESP.

Étapes suivantes : SPF autorisés, sélecteurs DKIM chez l’ESP, IP sources vs relais connus, corrélation avec logs SMTP ou fournisseur sur la même fenêtre.

Ce que cette preuve permet et n’autorise pas de conclure

Le XML RUA prouve comment les récepteurs ont évalué SPF/DKIM pour le trafic revendiquant votre domaine sur la fenêtre du rapport. Il ne prouve pas qu’un message précis a été livré, lu ou mis en quarantaine pour un utilisateur. disposition: none avec DMARC pass signifie que la politique d’échec n’a pas été appliquée à cette ligne agrégée—pas « chaque message de la ligne est en boîte de réception ».

Si le message n’apparaît jamais chez Google

Les RUA ne listent pas les Message-ID individuels. Pour un incident « un envoi relais absent d’Email Log Search », le DMARC est un contexte (sources inattendues, échecs d’auth), pas un substitut aux logs Workspace ou applicatifs.

Différence avec un outil ponctuel ou un rapport DMARC

Ce fichier est un rapport DMARC agrégé—distinct des traces par message (Email Log Search, relais, tableaux de bord ESP) et des analyseurs sur un seul .eml. Des plateformes comme dmarcian ou Valimail ingèrent et visualisent les RUA ; elles ne reconstruisent pas seules un échec relais applicatif. Voir plateformes DMARC agrégées et Email Log Search.

Limites

Les RUA agrégés n’incluent pas sujets, corps ni destinataires—seulement des statistiques et résultats d’authentification.
Ce guide décrit surtout le format Gmail ; Microsoft, Yahoo et d’autres envoient leurs propres RUA avec les mêmes concepts RFC.
PunchOp n’a pas mesuré votre domaine ; les exemples s’appuient sur la RFC et la documentation Google.
Un jour avec SPF non aligné et DKIM pass est souvent normal avec un ESP ; ce n’est pas automatiquement un incident sans preuves complémentaires.