DMARC (EN)

DMARC records are published in DNS with a subdomain label _dmarc, for example _dmarc.example.com. Compare this to SPF at example.com, and DKIM at selector._domainkey.example.com.

The content of the TXT resource record consists of name=value tags, separated by semicolons, similar to SPF and DKIM. For example:

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"

Here, v is the version, p is the policy, sp the subdomain policy, pct is the percent of "bad" emails on which to apply the policy, and rua is the URI to send aggregate reports to. In this example, the entity controlling the example.com DNS domain intends to monitor SPF and/or DKIM failure rates and doesn't expect emails to be sent from subdomains of example.com. Note that a subdomain can publish its own DMARC record; receivers must check it out before falling back to the organizational domain record.

Syntaxe (FR)

Exemple :

"v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@example.org;ruf=mailto:forensik@example.org;adkim=s;aspf=r"

Voici par exemple l'enregistrement SPF d' ietf.org via la commande "dig TXT ietf.org" :

ietf.org. 720 IN TXT "v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56 ip4:64.170.98.0/24 ip6:2001:1890:126c::/56 ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64 ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64 ip4:72.167.123.204 -all"

Seuls les blocs d'adresses IPv4 et IPv6 indiqués sont habilités à envoyer du courrier avec un expéditeur du domaine ietf.org. Un serveur de courrier participant à SPF peut donc rejeter un mail provenant d'autres blocs d'adresses que ceux-ci.

Il n’est pas obligatoire de publier un enregistrement SPF, ni de faire usage de ceux existants. Les sites qui ne participent pas à cette initiative ne sont donc pas affectés par celle-ci. SPF ne garantit pas que la partie locale de l'adresse de courrier électronique (à gauche du signe @) est authentique.

Mécanismes

Il existe huit mécanismes possibles dans un enregistrement DNS SPF :

ALL Correspond toujours ; utilisé pour un résultat par défaut, ex : -all pour toutes les IP qui ne correspondent pas.
A Correspond si le nom de domaine possède un enregistrement IN A (ou AAAA) qui peut être résolu comme adresse d'expéditeur.
IP4 Correspond si l'expéditeur est dans cette plage IPv4 .
IP6 Correspond si l'expéditeur est dans cette plage IPv6 .
MX Correspond si le nom de domaine contient un enregistrement Mail eXchanger pointant vers l'adresse de l'expéditeur (ex : si le mail provient d'un des serveurs entrants du domaine).
PTR Correspond si le domaine de l'adresse IP ( PTR record ) correspond au domaine spécifié, et que ce dernier pointe vers l'IP en retour ( forward-confirmed reverse DNS   (en) ). Ce mécanisme est toutefois désuet et ne doit plus être utilisé 4 .
EXISTS Correspond si domaine donné existe, c'est-à-dire s'il est résolu en n'importe quelle adresse (peu importe la résolution de cette dernière). Ce mécanisme est rarement utilisé. Avec le macrolangage SPF il offre des correspondances plus complexes, comme les requêtes DNSBL .
INCLUDE Correspond si la règle incluse passe le test. C'est typiquement utilisé pour gérer les règles quand il y a plusieurs FAI .

Qualifieurs

Chaque mécanisme peut être combiné avec un seul des quatre qualifieurs :

+ (plus) pour un résultat favorable. Il peut être omis, ex : +mx est équivalent à mx.
? (point d'interrogation) pour un résultat neutre. Interprété comme NONE (aucune règle).
~ (tilde) pour un léger échec. Intermédiaire entre le neutre et l'échec, il est utilisé pour le débogage. Typiquement, ces messages sont acceptés mais estampillés comme tels.
- (moins) pour un échec total. Le mail doit être rejeté.

Modifieurs

Les modifieurs permettent des extensions au framework. Aujourd'hui seuls deux modifieurs définis par la RFC  4408 5 initiale du 28 avril 2006, ont été déployés dans un certain nombre de domaines :

exp=some.example.com donne le nom du domaine avec un enregistrement TXT (interprété comme utilisant le macrolangage SPF) pour obtenir une explication des résultats en échec. Typiquement, une URL ajoutée au code erreur SMTP.
redirect=some.example.com alternative au mécanisme ALL, pour lier à un enregistrement de règle d'un autre domaine. Il est similaire au mécanisme INCLUDE.
 

SPF :

Syntaxe

Exemples :

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"

Voici par exemple l'enregistrement SPF d' ietf.org via la commande "dig TXT ietf.org" :

ietf.org. 720 IN TXT "v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56 ip4:64.170.98.0/24 ip6:2001:1890:126c::/56 ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64 ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64 ip4:72.167.123.204 -all"

Seuls les blocs d'adresses IPv4 et IPv6 indiqués sont habilités à envoyer du courrier avec un expéditeur du domaine ietf.org. Un serveur de courrier participant à SPF peut donc rejeter un mail provenant d'autres blocs d'adresses que ceux-ci.

Il n’est pas obligatoire de publier un enregistrement SPF, ni de faire usage de ceux existants. Les sites qui ne participent pas à cette initiative ne sont donc pas affectés par celle-ci. SPF ne garantit pas que la partie locale de l'adresse de courrier électronique (à gauche du signe @) est authentique.

Mécanismes

Il existe huit mécanismes possibles dans un enregistrement DNS SPF :

ALL Correspond toujours ; utilisé pour un résultat par défaut, ex : -all pour toutes les IP qui ne correspondent pas.
A Correspond si le nom de domaine possède un enregistrement IN A (ou AAAA) qui peut être résolu comme adresse d'expéditeur.
IP4 Correspond si l'expéditeur est dans cette plage IPv4 .
IP6 Correspond si l'expéditeur est dans cette plage IPv6 .
MX Correspond si le nom de domaine contient un enregistrement Mail eXchanger pointant vers l'adresse de l'expéditeur (ex : si le mail provient d'un des serveurs entrants du domaine).
PTR Correspond si le domaine de l'adresse IP ( PTR record ) correspond au domaine spécifié, et que ce dernier pointe vers l'IP en retour ( forward-confirmed reverse DNS   (en) ). Ce mécanisme est toutefois désuet et ne doit plus être utilisé 4 .
EXISTS Correspond si domaine donné existe, c'est-à-dire s'il est résolu en n'importe quelle adresse (peu importe la résolution de cette dernière). Ce mécanisme est rarement utilisé. Avec le macrolangage SPF il offre des correspondances plus complexes, comme les requêtes DNSBL .
INCLUDE Correspond si la règle incluse passe le test. C'est typiquement utilisé pour gérer les règles quand il y a plusieurs FAI .

Qualifieurs

Chaque mécanisme peut être combiné avec un seul des quatre qualifieurs :

+ (plus) pour un résultat favorable. Il peut être omis, ex : +mx est équivalent à mx.
? (point d'interrogation) pour un résultat neutre. Interprété comme NONE (aucune règle).
~ (tilde) pour un léger échec. Intermédiaire entre le neutre et l'échec, il est utilisé pour le débogage. Typiquement, ces messages sont acceptés mais estampillés comme tels.
- (moins) pour un échec total. Le mail doit être rejeté.

Modifieurs

Les modifieurs permettent des extensions au framework. Aujourd'hui seuls deux modifieurs définis par la RFC  4408 5 initiale du 28 avril 2006, ont été déployés dans un certain nombre de domaines :

exp=some.example.com donne le nom du domaine avec un enregistrement TXT (interprété comme utilisant le macrolangage SPF) pour obtenir une explication des résultats en échec. Typiquement, une URL ajoutée au code erreur SMTP.
redirect=some.example.com alternative au mécanisme ALL, pour lier à un enregistrement de règle d'un autre domaine. Il est similaire au mécanisme INCLUDE.