Guide de configuration des protocoles de messagerie Red Sift

Publié le :10 juin 2024
Modifié le :1 avril 2026
Chapitre :21 min de lecture
Guide :81 min de lecture
image
Découvrez notre guide

DNS setup instructions by Email Service Provider

In this chapter, we provide guidance on how to create TXT records, as well as specific DNS setup instructions for some of the most popular ESPs - from Mailbox Providers (MBPs) like Gmail and Microsoft to Shopify and Squarespace, through to CRMs such as Salesforce and Hubspot.

TXT record creation guidance

How to create TXT records for SPF & DMARC with Amazon Route 53

  1. Log in to your Route 53 Console.
  2. In the navigation pane, choose 'Hosted zones'.
  3. Choose the domain that you want to add a TXT or CNAME record to.
  4. Choose 'Create record'.
  5. For 'Routing policy, choose Simple routing, and then choose Next.
  6. Choose Define simple record.
  7. In the Define simple record pane, do the following:
  8. - For Record name, Enter the host name for the TXT record. For example, leave this blank for an SPF record, or enter the value _dmarc for a DMARC record.
  9. - For Value/Route traffic to, paste the value you are setting as the destination of the Host or the text value of the TXT.
  10. - For Record type, choose TXT or CNAME as appropriate.
  11. - For TTL (seconds), type 1800.
  12. - Choose Define simple record.​
  13. Allow up to 24 hours for propagation of the newly created record.​

For more information on adding TXT records to your domain’s Route53 DNS server, click here.

How to create TXT records for SPF & DMARC with Azure DNS

  1. Sign in to the Azure portal with your Azure account.​
  2. Create a DNS zone (If a DNS zone for the domain is already created, skip to step 3.)
  3. At upper left, select Create a resource, then Networking, and then DNS zone.
  4. On the Create DNS zone page, type or select the following values:
  5. Name: Type contoso.xyzcontoso.xyz for this quickstart example. The DNS zone name can be any value that is not already configured on the Azure DNS servers. A real-world value would be a domain that you bought from a domain name registrar.
  6. Resource group: Select Create new, enter MyResourceGroup, and select OK. The resource group name must be unique within the Azure subscription.
  7. Select Create.
  8. Create a DNS record
  9. In the Azure portal, under All resources, open the contoso.xyzcontoso.xyz DNS zone in the MyResourceGroup resource group. You can enter contoso.xyzcontoso.xyz in the Filter by name box to find it more easily.
  10. At the top of the DNS zone page, select + Record set.
  11. On the Add record set page, type or select the following values:
  12. Host: Enter the host name for the TXT record. For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record.
  13. Type: TXT
  14. Value: The value you are setting as the destination of the Host.
  15. TTL: Determine how long the server should cache information.​
  16. Click 'Save' to publish the newly created record.

For more information on creating DNS records using Azure DNS, click here

How to create an SPF record in DNS using Cloudflare

For this scenario, we will use G Suite as the sending service and our domain would be test.ondmarc.com. ​ To authorize G Suite to send emails on behalf of our domain we need to create the following SPF record in DNS.

v=spf1 include:_spf.google.com ~all

How to create the SPF record

Now that we have the value for our SPF record that needs to be created let’s go ahead and add it to the DNS for test.ondmarc.com in Cloudflare.

1. Log in to Cloudflare.

2. Select the account under which your domain exists.

3. Select the domain (ondmarc.com) under which you would like to create the SPF record.

4. Click the DNS app from the row of apps.

5. You will be presented with the following UI. Create and fill in the fields as shown at the beginning of this article.

imageimage
  • The record type is TXT
  • The name of the record in this case would be test.ondmarc.comtest.ondmarc.com
  • The value portion of the record above contains the following:
​v=spf1 include:_spf.google.com ~all

We will leave the TTL set to Automatic and click Add Record.

Please allow some time for the record to propagate and be detected.

How to create TXT records for SPF & DMARC with Fasthosts

  1. Log into your FastHosts account. 
  2. Under the Domain menu click Manage Domains.
  3. Select the domain name from the list that you wish to add the DNS records to.
  4. Click into the Configure Advanced DNS link.
  5. A list of DNS records will be shown.
  6. Scroll Down the list and click on the blue icon "ADD TXT RECORD"
  7. Fill out the fields with the following info: a) Hostname: Enter the host name for the TXT record. For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record. b) Destination TXT Value: The value you are setting as the destination of the Host.
  8. When the information are entered, click Save.

For more information on managing DNS in Fasthosts, click here.

How to create TXT records for SPF & DMARC with Google Domains

  1. Log in to your Google Domains account, select your 'Domain', and go to the 'DNS' section.
  2. Scroll down to the 'Custom resource records' and create the following record(s):
  3. SPF Record:
  4. Name: For the SPF record, enter the host name. Typically, you can use "@" to indicate the root domain.
  5. Type: Select TXT as the record type.
  6. Data: Enter the value for your SPF record. This value specifies which email servers are authorized to send emails on behalf of your domain.
  7. TTL: Determine the Time-to-Live for the record. This dictates how long DNS servers should cache the information.
  8. DMARC Record:
  9. Name: For the DMARC record, use the host name _dmarc.
  10. Type: Select TXT as the record type.
  11. Data: Set the value for your DMARC record. This value defines the DMARC policy and how email receivers should handle emails that fail authentication checks.
  12. TTL: Set the appropriate Time-to-Live value for the DMARC record.
  13. Click 'Add' to publish the new record.

How to create TXT records for SPF & DMARC with Hover

  1. Sign in to your Hover account.
  2. If you have multiple domain names, choose the domain name you want to edit.​
  3. Select the 'DNS' tab.
  4. Select 'Add New' and enter the following:
  5. Host: Enter the host name for the TXT record. For example, leave the host blank for an SPF record, or enter the value _dmarc for a DMARC record.
  6. TXT Value: The value you are setting as the destination of the Host.
  7. TTL: Determine how long the server should cache information.​
  8. Select Save.​

For more information on managing DNS records with Hover, click here.

How to create TXT records for SPF & DMARC with Ionos (Formerly 1&1)

  1. Log in to IONOS.
  2. For the desired domain, click on the gear symbol under Actions and select DNS.
  3. Click Add Record and select TXT under Type.
  4. In the Host name field, specify the desired host, For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record.
  5. In the Value field, paste the value you are setting as the destination of the Host (i.e. the value of the SPF or DMARC record to be used).
  6. Optional: Select the desired TTL (Time to Live). By default, your settings are immediately active.
  7. Click Save. The TXT record has now been added.

For more information on adding TXT records in Ionos, click here.

How to create TXT records for SPF & DMARC with Namecheap

  1. Login to your Namecheap Account, choose 'Domain List' on the left, and click on the 'Manage' button next to your domain.
  2. Navigate to the 'Advanced DNS' tab from the top menu and click on the 'Add new record' button.​
  3. Select TXT Record for 'Type'.
  4. Host: Enter the hostname for the TXT record. For example, leave the host blank for an SPF record, or enter the value _dmarc for a DMARC record.
  5. TXT Value: The value you are setting as the destination of the Host.
  6. TTL: Determine how long the server should cache information.

​NOTE: The domain name itself should not be included in the Host field. It means that if you need to add the record for dmarc.yourdomain.tld, dmarc.yourdomain.tld, only dmarcdmarc is to be added as a Host value. For more information, click here.​

How to create TXT records for SPF & DMARC with Network Solutions

  1. Log in to your Network Solutions Account Manager.​
  2. Enter the username and password you created when you purchased your domain from Network Solutions.
  3. Click Login.
  4. From the Network Solutions Account Manager, under My Domain Names, click 'Edit DNS'.
  5. Click 'Change Where Domain Points'.​
  6. Select 'Advanced DNS' and click 'Continue'.​
  7. Open the instructions for the type of DNS record you want to add for your domain. (TXT steps included below)
  8. Host: Enter the host name for the TXT record. For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record.
  9. TXT Value: The value you are setting as the destination of the Host.
  10. TTL: Determine how long the server should cache information.
  11. Scroll down and click 'Continue'.​
  12. Click 'Save Changes' to publish the record.

For more information on managing DNS records with Network Solutions, click here.

How to create TXT records for SPF & DMARC with 123Reg

  1. Login to your 123Reg Control Panel.
  2. Search your Domain Name next to DOMAINS and Click on MANAGE.
  3. Scroll down to Advanced Domain Settings and click on Manage DNS (A, MX, CNAME, TXT, SRV).
  4. Click on the Advanced DNS tab.
  5. Select TXT or CNAME as the Type and fill out the fields with the following info: a) Hostname: Enter the host name for the TXT/CNAME record. For example, enter @ for an SPF record, or enter the value _dmarc for a DMARC record. b) Destination TXT Value: The value you are setting as the destination of the Host.
  6. When the information is entered, select Add.

For more information on managing DNS records in 123Reg, click here.

DNS setup instructions

AppRiver SPF and DKIM set up

SPF

AppRiver was bought by Zix, so your SPF record will depend on which product you have.

For more information on SPF at Zix, please click here.

DKIM

For more information on enabling DKIM, please contact AppRiver support.

Brevo (formerly Sendinblue) SPF and DKIM set up

Increase the deliverability of your Brevo (formerly Sendinblue) emails by correctly configuring SPF and DKIM.

SPF

Adding SPF for Brevo (formerly Sendinblue) for DMARC purposes is not needed because the Return-Path address of the emails is set to their default domain in order to track bounces on your behalf. Therefore, SPF will not pass for Brevo from a DMARC perspective, however, as long as DKIM passes, the emails will be DMARC compliant.

DKIM

To enable DKIM you will have to create a few DNS records. Please follow the instructions using the button below for more information.

Google Workspace SPF and DKIM set up

SPF

To authorize Google to send emails on your behalf you will need to create an SPF record that includes the following value:

include:_spf.google.com <-- this part allows all Gsuite IPs to send emails on your behalf.

If you already have an existing SPF record you will just have to copy the include include:_spf.google.com and append it to your current SPF record, however, it has to be put after the v=spf1 and before the ~all ending mechanism in your record.

If you already have an existing SPF record such as:

v=spf1 include:mail.zendesk.com ~all

and you would like to add Gsuite as an additional sending service, you will have to copy the include include:_spf.google.com and append it to your current SPF record. 

The final SPF record should look like this:

v=spf1 include:mail.zendesk.com include:_spf.google.com ~all

Do not create a second SPF record if you already have one. You should only have one SPF record per domain/subdomain.

To learn more about SPF and how to configure it for Google Workspace please click here.

DKIM

To implement DKIM for your domain you will have to follow the steps below.

  1. Log in as administrator and go to the Admin Console.
  2. Go to Apps --> G Suite
  3. Click on the Gmail app.
  4. Click on Authenticate email
  5. For the key length you can choose between 1024 or 2048. The longer the key the better, however, some DNS providers do not support keys longer than 1024. They should be able to implement 2048 as well but there may be some additional work that needs to be carried out.
  6. Select your prefix selector, you can leave the default of "google" or type in your own. This will be your DKIM selector.
  7. Once the key is generated, you will need to take the information provided and put it in your DNS ie. create the TXT record. It will look like the example below, except that you will have to replace the word "selector" below with the one that you created earlier.

Type

Host

TXT value

TTL

TXT

selector._domainkey

Paste the key generated here

1 hour (default)

NOTE: it may take up to 48 hours for the DNS changes to propagate.

Also, you can't add a custom DKIM selector for 24 hours.

For more information please click here.

Hubspot SPF and DKIM set up

SPF

Adding SPF for Hubspot for DMARC purposes is not needed because the Return-Path address of the emails is set to Hubspot's default domain in order to track bounces on your behalf. Therefore, SPF will not pass for Hubspot from a DMARC's perspective, however, as long as DKIM passes, the emails will be DMARC compliant.

DKIM

For information on how to configure DKIM and add the necessary DNS records please click here.

Kajabi SPF and DKIM set up

As Kajabi constantly updates its documentation, please click here for the most accurate information.

Klaviyo SPF and DKIM set up

To authorize Klaviyo to send emails on your behalf and customize those emails to match your domain you will have to carry out full domain whitelabeling. During this process, you will be provided with the necessary DNS records that need to be created so your emails start passing SPF and DKIM. 

For more information and instructions on how to complete the full whitelabeling process please click here

Mailerlite SPF and DKIM setup

Mailerlite provides two ways of authenticating your domain. They can either manage the authentication for you or allow you to manage it yourself. If you let Mailerlite authenticate your emails then your receivers would see Mailerlite as the sender of your emails. If you would like your receivers to see your domain only then you will have to choose the option to authenticate emails yourself. 

Configuring SPF and DKIM with Mailerlite for your custom domain is pretty easy. All you have to do is choose Authentication, insert your domain and select Show DNS record.

The necessary SPF and DKIM records will be generated and presented to you which you will then have to add to your DNS. For more information please click here.

Once you have created SPF and DKIM but still showing as inactive in your account, please click here for information on how to troubleshoot this.

Mandrill SPF and DKIM setup

Mandrill is a product created by Mailchimp and is a service used to send transactional emails. To improve your email deliverability, Mandrill requires that every domain of yours is configured with SPF and DKIM.

SPF

To allow Mandrill to send emails on your domain’s behalf, you must include them as part of your SPF record. 

The SPF mechanism used by Mandrill is the following:

include:spf.mandrillapp.com

Mandrill uses their own domain as part of the Return-Path address (used by SPF) and hence SPF alignment would not occur. However, this can be modified as per their help article.

For more information, visit the Mandrill help article.

DKIM

To set up DKIM for Mandrill, you will need to add a new TXT record in your DNS.

The name for the TXT record should be: 

mandrill._domainkey.yourdomain.comReplace “yourdomain.com” above with the domain you are setting up.

The value of the DNS record should be the following:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/IQ/J/mRwSRMAocV/hMB3jXwaHH36d9NaVynQFYV8NaWi69c1veUtRzGt7yAioXqLj7Z4TeEUoOLgrKsn8YnckGs9i3B3tVFB+Ch/4mPhXWiNfNdynHWBcPcbJ8kjEQ2U8y78dHZj1YeRXXVvWob2OaKynO8/lQIDAQAB;

After you have added the required DNS records, you can use the Test the DNS Settings button in your control panel to make sure that everything that you have added has a green checkmark. Please allow 24-48 hrs for the DNS changes to take effect. 

For more information, visit the Mandrill help article.

Mimecast DKIM signing setup

To setup DKIM signing in Mimecast you need to create a definition and a policy.

Setting up a definition

  1. Login to Mimecast
  2. Select Administration console
  3. From the top left select Administration > Gateway > policies
  4. Select definitions drop down select DNS Authentication - Outbound
  5. Select New DNS Authentication - Outbound signing
  6. Set a name for the definition
  7. Tick the checkbox Sign outbound mail with DKIM
  8. Use the lookup option to select domain to DKIM sign
  9. Select generate
  10. Create a TXT record within your DNS with the public key provided save and exit
  11. Verify public key in Mimecast console

Setting up a policy

  1. Login to Mimecast
  2. Select Administration Console
  3. From the top left select Administration > Gateway > policies
  4. Search for DNS authentication outbound
  5. Select New Policy
  6. Name the policy
  7. Under emails from use address based on "Both"
  8. Save and Exit

Microsoft Dynamics 365 SPF and DKIM set up

SPF

To authorize Microsoft Dynamics 365 to send emails on your behalf, you must include it in your SPF record. The SPF record mechanism used for Microsoft Dynamics 365 is shown below. Find more information here.

include:marketing.dynamics.com

​DKIM

Microsoft Dynamics 365 supports DKIM signing for your custom domain. For more information on how to set it up please click on the button below. Find more information here.

Microsoft Office 365 SPF and DKIM set up

Set up your SPF record for Office 365

To authorize Microsoft 365 (formerly Office 365) to send emails on behalf of your domain you will have to add it to your SPF record. The SPF record mechanism used for Microsoft 365 is: 

include:spf.protection.outlook.com <-- this part allows all Office 365 IPs to send emails on your behalf.

If Microsoft 365 is your only legitimate source of emails, your SPF record should look like the below example:

v=spf1 include:spf.protection.outlook.com ~all

If you already have an existing SPF record such as:

v=spf1 include:mail.zendesk.com ~all

and you would like to add Office 365 as an additional sending service, you will have to copy the include include:spf.protection.outlook.com and append it to your current SPF record. The final SPF record should look like this:

v=spf1 include:mail.zendesk.com include:spf.protection.outlook.com ~all

However, do not create a second SPF record if you already have one. You should only have one SPF record per domain/subdomain.

I get a warning from Microsoft 365 when using Dynamic SPF

If you are using Dynamic SPF and you also use Microsoft 365 for email, you may have noticed that Microsoft will give you a warning about your SPF include being incorrect.

domain status imagedomain status image

This is expected and you can safely ignore it. Microsoft is looking for the literal string they provide in your DNS and does not know that their IP ranges are already included in Dynamic SPF.

You can test Dynamic SPF is working correctly by sending a test email to the address listed in the Investigate section of the OnDMARC console.

Set up your DKIM for Office 365

In order to DKIM sign your custom domain emails you will need to complete the following steps.

Creating the CNAME records

The CNAME records are used to map an alias name to the true or canonical domain name. In essence, when you provision a new domain name in Microsoft 365 you will need to create two CNAME records for it so that it points to your initial domain. 

We will use example.onmicrosoft.com as our initial domain, also called the tenant domain. But we actually own example.com and after we provision it in Office 365 we need to publish the two CNAME records so that example.com points to example.onmicrosoft.com using the format below.

Please note that if you are a Microsoft 365 US Government Cloud (GCC) customer, the domainGUID method below will not work for you. You will need to use the proper MX value for your domain. Example: 

selector1-<domain-key>._domainkey.<initialDomain> 

Use this article to find the MX record needed for your domain-key value.

Host name: selector1._domainkey.<domain>
Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain>
TTL: 3600
Host name: selector2._domainkey.<domain>
Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain>
TTL: 3600

In our example the CNAME records will look like this:

Host name: selector1._domainkey.example.com
Points to address or value: selector1-example-com._domainkey.example.onmicrosoft.com
TTL: 3600
Host name: selector2._domainkey.example.com
Points to address or value: selector2-example-com._domainkey.example.onmicrosoft.com
TTL: 3600

Please pay close attention to the domainGUID which does not use a full stop "." but a dash "-" instead. This is taken from the MX record of your custom domain, in this case, example.com.example.com.

The reason behind the two CNAME records is that Microsoft rotates the two keys for added security.

Enabling DKIM signing

Once you have added the CNAME records (two per domain) DKIM signing can be enabled through the Microsoft 365 Security admin center at http://security.microsoft.com/dkimv2

For more information on how to configure DKIM in Office 365 please click here

Namecheap Private Email SPF and DKIM set up

SPF

To authorize Namecheap Private Email to send emails on your behalf you will have to include it in your SPF record. The SPF record mechanism used is shown below.

include:spf.privateemail.com 

For more information on SPF set up for Namecheap Private Email please click here

DKIM

For instructions on how to set up DKIM, please click here

Proofpoint Protection Server (PPS) SPF and DKIM setup

SPF

To authorize Proofpoint to send emails on your behalf, you must include it in your SPF record. Refer to your Deployment Information email for the details, as the SPF is unique to each PPS cluster.

It usually follows the format:

 include:spf-{clusterid}.pphosted.com

DKIM

To set up DKIM on PPS, follow these steps:

  1. Navigate to Email Protection tab > Email Authentication > DKIM Signing > Keys
  2. Click Generate Key to create a key for a domain and selector. Each key must have a unique domain and a unique selector within the domain. Proofpoint-generated domain keys are 2048-bits in length.
  3. At the Generate Key Entry dialog box type or specify your domain, the selector, the scope of the key, and the policy routes. ​ For the policy routes, only check Disable processing for selected policy routes… Under Available scroll down and select default_inbound Click the >> to add it to Disable For Any Of:
  4. Click on Add Entry.
  5. Click View in the DNS Text Record column to see the text record for a DKIM key.
  6. A pop-up window displays the DNS text record that contains the public key. Copy the DNS text record for each domain-selector pair to your DNS servers
  7. Once the DNS record has been created, wait a few minutes to ensure the record has time to propagate.
  8. On the PPS Admin Console and click on Test to verify if the DNS record was created correctly.
  9. The feedback for the test will appear above the navigation tabs (System, Email Protection, Information Protection).
  10. Once the DNS record has been validated click the Enabled box and then click Save Changes.
  11. Turn on DKIM Signing by navigating to Email Protection tab > Email Authentication > DKIM Signing > General
  12. Click On next to Enable
  13.  Click Save Changes

For more details or detailed screenshots, refer to the Proofpoint documentation here.

Salesforce Marketing Cloud SPF and DKIM set up

SPF

To authorize Marketing Cloud to send emails on your behalf you will have to include it in your SPF record. The SPF record mechanism used for Marketing Cloud is shown below. Found out more here.

include:cust-spf.exacttarget.com

DKIM

If you have the Sender Authentication Package you will be able to enable DKIM. Please contact your account manager at Marketing Cloud for more information.

Shopify SPF and DKIM record set up

What is the SPF record mechanism and DKIM selectors used by Shopify that I need to configure in DNS?

SPF

To allow Shopify to send emails on your behalf you will have to add it to your SPF record. The SPF record mechanism used for Shopify is shown below.

include:shops.shopify.com

DKIM

To set up DKIM for Shopify, you can authenticate your domain by clicking Authenticate on the Sender email page of your Shopify admin console. A new window will open and provide you with instructions on how to create four new records with your domain provider.

Custom domain settings for Shopify

Squarespace SPF and DKIM set up

SPF

To allow Squarespace to send emails on your behalf, you will have to add them to your SPF record. The SPF mechanism used by Squarespace is shown below.

include:squarespace-mail.com

DKIM

For DKIM support, you need to create a CNAME record in your DNS. It should have the following properties:

Host: squarespace._domainkeyValue: squarespace-domainkey.squarespace-mail.com​For more information please click here. 
email set up imageemail set up image
Email set up correctly? Find out free in under a minute

Questions fréquemment posées : Guide de configuration des protocoles de messagerie

Quelle est la différence entre l’échec SPF strict (-all) et l’échec doux (~all), et lequel devrais-je utiliser en 2026 ?

Avant l’apparition de DMARC, les enregistrements SPF utilisaient couramment le mécanisme « -all » pour appliquer strictement les politiques d’expéditeur. Cependant, les recommandations de l’industrie en 2026 privilégient désormais « ~all » afin d’équilibrer sécurité et délivrabilité, évitant ainsi le rejet inutile d’e-mails valides qui pourraient échouer à SPF mais réussir DKIM et DMARC.

Le principe est que « ~all », combiné à DMARC (avec la politique p=reject), rejettera quand même les messages non authentifiés si SPF et DKIM échouent, sans pour autant bloquer les courriels légitimes, ce qui améliore la délivrabilité globale.

La spécification DMARC (RFC 7489) précise qu’un préfixe « - » sur le mécanisme SPF d’un expéditeur, tel que « -all », peut activer le rejet de messages plus tôt dans le traitement, avant toute intervention de DMARC. Il est donc conseillé de n’utiliser « -all » que pour les domaines inactifs qui n’envoient aucun e-mail. DMARC ne prend pas en compte la nuance entre l’échec doux et strict de SPF, les considérant tous les deux comme des échecs SPF.

Comment fonctionne l’alignement DMARC et quelle est la différence entre l’alignement strict et relâché ?

DMARC n’exige pas seulement que SPF ou DKIM soient PASS, mais impose aussi qu’au moins un des domaines utilisés par SPF ou DKIM s’aligne sur le domaine figurant dans l’en-tête From. Un bon alignement est essentiel pour la délivrabilité en 2026 car les principaux fournisseurs de messagerie appliquent ces exigences.

Pour SPF, l’alignement de l’identifiant signifie que le contrôle MAIL FROM/Return-PATH doit réussir et que la partie domaine du MAIL FROM/Return-PATH doit s’aligner sur le domaine utilisé dans l’adresse From. En mode strict, les domaines doivent correspondre exactement, tandis qu’en mode relâché, les sous-domaines sont également tolérés à condition qu’ils appartiennent au même domaine organisationnel.

Par exemple, si le MAIL-FROM/RETURN-PATH est @ondmarc.com et que l’en-tête From est @knowledge.ondmarc.com, ils ne sont pas alignés en mode strict. Mais en mode relâché, DMARC considèrera l’alignement comme valide.

Que sont les rapports agrégés DMARC et les rapports judiciaires, et comment diffèrent-ils ?

Un rapport agrégé DMARC fournit des informations sur le statut d’authentification des messages envoyés au nom d’un domaine. Il s’agit d’un rapport de rétroaction XML destiné à donner de la visibilité sur les e-mails ayant réussi ou échoué aux vérifications SPF et DKIM. Ce rapport donne au propriétaire du domaine une vision précise des sources qui envoient en son nom et des actions appliquées à ces e-mails (la politique appliquée par le destinataire).

Les destinataires examinent la balise 'rua' de votre enregistrement DMARC et envoient les rapports à cette adresse. Vous pouvez spécifier l’intervalle d’envoi des rapports agrégés grâce à la balise ri (par défaut à 86 400 secondes soit 24 heures). Les rapports judiciaires contiennent des informations détaillées sur chaque échec d’authentification. Les informations personnelles identifiables (PII) sont retirées, mais tout ce qui peut aider à diagnostiquer l’échec DMARC reste, comme les détails du rejet SPF et DKIM, l’adresse From complète et l’objet du message.

L’adresse de réception des rapports judiciaires DMARC est spécifiée par la balise 'ruf' dans votre enregistrement DMARC. Tous les systèmes de réception ne prennent pas en charge l’envoi de rapports judiciaires. Red Sift OnDMARC fait partie des rares applications DMARC du marché qui reçoivent ces rapports grâce à son partenariat avec Yahoo.

Que sont les macros SPF et pourquoi pourraient-elles poser des problèmes de délivrabilité ?

Une macro SPF correspond à un mécanisme utilisé dans les enregistrements SPF pour définir des ensembles d’adresses IP réutilisables. Les macros SPF augmentent la flexibilité et la maintenance des enregistrements SPF en permettant de définir des ensembles complexes d’IP dans un seul mécanisme, qui peut être appelé dans plusieurs enregistrements SPF. Par exemple, au lieu de lister chaque adresse IP autorisée, on peut définir une macro telle que « %{i} » qui appelle l’IP de l’expéditeur du message. Gérer les SPF ainsi permet de contrôler une grande liste d’IP sans dépasser la limite de recherches SPF, et d’obscurcir les adresses IP autorisées pour les requêtes publiques.

Cependant, selon la structure de l’enregistrement SPF utilisant des macros, l’absence de développement des macros peut entraîner des erreurs SPF ou des résultats « Neutral » (indiqués par le mécanisme ?all). Si les macros SPF sont essentielles pour autoriser certains serveurs expéditeurs légitimes, les e-mails pourraient échouer les contrôles SPF ou être considérés comme suspects par les serveurs destinataires qui s’appuient sur SPF pour l’authentification.

Qu’est-ce que MTA-STS et comment le déployer sans bloquer la livraison des e-mails ?

Mail Transfer Agent Strict Transport Security (MTA-STS) est une norme qui permet de chiffrer les messages envoyés entre deux serveurs de messagerie. Elle indique aux serveurs expéditeurs que les e-mails doivent obligatoirement être transférés via une connexion chiffrée TLS, ce qui empêche leur interception par des cybercriminels.

L’adoption de MTA-STS a fortement augmenté, les organisations en 2026 considérant la sécurité de la couche de transport comme essentielle pour protéger les e-mails en transit. Pour permettre l’activation de MTA-STS sur un domaine destinataire, il faut annoncer la prise en charge de MTA-STS dans le DNS du domaine et publier un fichier de politique sur le site web associé.

L’activation de MTA-STS doit être réalisée avec précaution pour éviter de bloquer la livraison. Il est conseillé de déployer d’abord MTA-STS en mode test, afin d’analyser les rapports TLS et corriger les éventuels problèmes avant de passer à une politique d’application stricte. Cette démarche progressive devrait devenir la norme en 2026 pour les organisations souhaitant mettre en œuvre la sécurité du transport.

Qu’est-ce que TLS-RPT et comment fonctionne-t-il avec MTA-STS ?

Le SMTP TLS Reporting (ou TLS-RPT) permet de signaler les problèmes de connectivité TLS rencontrés par les MTAs expéditeurs, et il est défini dans le RFC8460. Comme pour DMARC, TLS-RPT envoie des rapports par e-mail pour avertir les propriétaires de domaine lorsqu’une livraison échoue en raison d’un incident TLS. Ces rapports incluent la politique MTA-STS détectée, des statistiques de trafic, les connexions ayant échoué et les raisons des échecs.

Avec la fonctionnalité MTA-STS de Red Sift OnDMARC, vous n’avez pas à craindre une mise en place complexe. Il suffit d’ajouter les Smart Records MTA-STS fournis par OnDMARC dans votre DNS, puis Red Sift héberge le fichier de politique MTA-STS, maintient le certificat SSL et signale toute violation de politique à travers les rapports TLS. Les plateformes DMARC modernes incluent en 2026 MTA-STS hébergé comme un standard, facilitant ainsi le déploiement de la sécurité de la couche de transport.

Qu’est-ce que DANE et quelle est la différence avec MTA-STS ?

Publiée dans le RFC 7671, DANE (DNS-based Authentication of Named Entities) introduit un nouveau standard Internet pour configurer la communication TLS entre un client et un serveur, sans dépendre des autorités de certification traditionnelles (CA).

Le modèle classique de TLS par CA permet à n’importe quelle CA d’émettre un certificat pour n’importe quel domaine. DANE s’appuie sur l’infrastructure DNSSEC (Domain Name System Security Extensions) pour lier un nom de domaine à un certificat. Le protocole DNSSEC déjà existant garantit que les données reçues sont authentiques et n’ont pas été altérées.

DANE introduit également un nouveau type de RR DNS appelé TLSA, signalant au client qu’un serveur prend en charge TLS. Il est recommandé de configurer MTA-STS et DANE ensemble. DANE est obligatoire pour de nombreux gouvernements, et les organismes publics de l’UE doivent généralement l’implémenter.

DANE et MTA-STS sont efficaces uniquement si l’expéditeur les prend en charge. Or, la plupart des expéditeurs ne prennent en charge qu’un seul des deux, donc les utiliser ensemble renforce la sécurité. En 2026, les organisations déploient souvent d’abord MTA-STS pour une compatibilité plus large, puis ajoutent DANE pour une sécurité accrue là où c’est nécessaire.

Quel est le but de la politique de sous-domaine DMARC (balise sp) et comment l’utiliser ?

La politique de sous-domaine permet aux administrateurs de protéger différents domaines et sous-domaines selon leur niveau d’avancement DMARC. Par exemple, si tous vos services émetteurs configurés pour votre domaine principal utilisent SPF et DKIM, vous pouvez appliquer une politique DMARC de p=reject au domaine principal tout en laissant les sous-domaines en p=none, ou inversement.

Ainsi, si un service d’envoi d’e-mails n’est pas compatible DMARC (ne supporte pas SPF ou DKIM), il est possible de lui attribuer un sous-domaine distinct et de lui assigner une autre politique DMARC, sans empêcher la protection des autres domaines. Cela permet de répartir le trafic sur plusieurs sous-domaines, chacun étant protégé indépendamment.