Messaging is currently the most widely used IT solution in companies and is and is essential for internal and external communication.

In order to ensure that only the company and its partners can distribute emails via the domain names they own, it is necessary to to upgrade the infrastructure by implementing the following protocols protocols: SPF, DKIM and DMARC. This change must be done in the complex context including : the O365 or google workspace, partners' email infrastructures, service providers (Gmail, Yahoo, Microsoft, etc...) and customers. All or part of these components will be impacted and may have to evolve during the implementation of DMARC.

Today, nearly 88%¹ of organizations claim to be the target of of spear-phishing attacks. This includes the use of spoofing, i.e. sending fake emails to pretend to be a person or a domain. Email remains a vector of choice given the probability that a user will click on a link or download a malicious attachment.

Corporate domains can be used as a proxy to target partners or customers. partners or customers. To reduce this risk, the implementation of SPF and DMARC can address the risks associated with emails. The use of DKIM (email signature) reinforces security by providing a layer of authenticity to emails.

The implementation of these elements on the DNS is an indicator of good cyber hygiene of good cyber hygiene among the general public.

If using Microsoft 365 and Exchange Online, then :

• Your SPF must have the following field Include :spf.protection.outlook.com. There is no need to add the MX record although².

• You must ensure that the hardfail qualifier, -all, is set for your new domains/subdomains

To check your SPF field, there's a few tools available on internet. Here two of them that can help you a lot :

• https://mxtoolbox.com/SuperTool.aspx?action=spf%3adomain.com&run=toolpage

• https://www.spf-record.com/spf-lookup/

Globally, It is important to pay attention of the followings :

• Limit 10 DNS queries per SPF record per domain. If this is not respected, the recipient could timeout during the SPF check and therefore have a failed email.

• Ensure that the DNS records are correctly deployed.

• Limit the number of SaaS providers (Cloud Computing, third party mailing tools, and more) declared in your root domains. This means that your authorize their infrastructures to send on your behalf and therefore the other users of these platforms.

• The creation of dedicated sub-domains for partners should be preferred and the partners and keep the root domain for infrastructure and communications for collaborators.

• A more detailed FAQ is available at open-spf.org : http://www.open-spf.org/FAQ/Common\_mistakes/

DKIM should be enabled in addition to the use of SPF when possible. This adds an additional protection mechanism against spoofing and misuse of your domains.

Office 365 is in charge of DKIM signing of outgoing emails, even from your onpremise SMTP relay if your configured a connector. This is a necessity, as a mail gateway may have to modify the headers or content of mail in transit.

For partners, they must configure the DKIM in their solutions and share with you the DNS record (including the public key) that needs to be published on your DNS.

The keys must be published in a TXT field on a DNS. For each private/public key pair used by the company or its partners, a record linked to a unique selector for each domain must be published.

The sending server must specify the selector in question in the the mail header.

However, some DNS management tools do not allow the addition of a record of more than 256 characters ³ and cutting ⁴ is not possible. To address this problem, you must fill in the record directly in the DNS config file or to set up a CNAME redirection to a DNS supporting the record of more than 256 characters:

selector1.\_domainkey.domain.com CNAME selector1.\_domainkey.domain.fr

On the DNS, we can correctly split the record following RFC1035.

A selector allows to publish several DKIM keys for a specific domain. We can find the information in the DKIM-Signature header of the mail. This header is of the following form:

*v=1; a=rsa; c=relaxed/relaxed; d=domain.com; s=selector1*

The s tag indicates the key associated with the email signature, the receiving server will check for linked subdomains selector1._domainkey.domain.com.

The initial deployment of DMARC starts with a supervision policy materialized by the p=none tag. This step can be implemented even before SPF and DKIM on a new domain because. It allows to receive statistics and information regarding your domains shared by the recipients' infrastructures. This mode of operation will not change as long as the SPF and DKIM are fully and correctly implemented.

By gradually integrating SPF and DKIM records, the supervision offered by DMARC will allow for the correction of your mail flows DNS configurations with the information received. It is possible that a partner migrates its infrastructure without your knowledge and in this case a large number of failed emails, or emails not aligned may show up in the DMARC reports.

As for fraudulent/malicious emails using the domain, it will then be possible to identify the volume and the origin of the latter.

When legitimate flows are protected by SPF and DKIM, it is recommended to deploy a quarantine policy as soon as possible. This policy can be applied on a percentage of mail and gradually increase to 100% when all identified issues are resolved.

After testing a quarantine policy, it will then be possible to integrate a reject policy. This will have the effect that emails received that failed SPF and DKIM checks will be rejected by the servers. Similar to the quarantine deployment, this policy can be applied to a small percentage of failed mail initially and gradually increased to 100% through

Mail flows can be categorized in three ways:

• DMARC Correct -- The flows are properly declared in your DNS and are are therefore compliant.

  • SPF aligned

  • DKIM aligned

  • Compliant

• Authenticated (Third party emailing platform like sendgrid, aws, etc.) -- These solutions can be used by the business, but are not declared in DNS so emails can be considered as not DMARC Compliant by recipients. Nevertheless, these platforms, although legitimate, can be used for malicious purposes (phishing, spoofing, etc.). Indicators to consider for legitimate partners or a poorly configured business solution are a high volume and the periodicity/repetition of the mailings. This point can nevertheless be validated by a forensic report and an audit of the available the mail flow in Exchange Online. For example

  • SPF validated, but not aligned

  • DKIM validated, but not aligned

  • DKIM/SPF validated, but not aligned

• Invalid mail flow -- usually servers or computers sending directly. They are often the source of fraudulent emails.

As of mid-February, Microsoft started rolling-out DMARC Agregate reports for domains whose MX points to O365.
It is also possible to audit your domains DMARC failure from external sender with an Exchange Online transport rule:

• Audit external email DMARC failure on Exchange Online :

if the message...

sender's address domain portion belongs to any of these domains: 'domain.com' or 'domain.co.uk' or 'domaine.fr'
and 'Authentication-results' header matches the following patterns: 'dmarc=fail action=none header.from=domain.co.uk' or 'dmarc=fail action=none header.from=domain.com' or 'dmarc=fail action=none header.from=domaine.fr'
and Is received from 'Outside the organization'

Do the following...

Set audit severity level to 'High'
and Set the spam confidence level (SCL) to '9'
and Send the incident report to [mailbox], include these message properties in the report: sender, sender override information, matching rules, matching content, original mail

Except if...

sender ip addresses belong to one of these ranges: [IP Range] or [IP Range] or [IP Range]
or Includes these words in the sender's address: [sender]

To send DMARC reports from one domain to another domain, two possibilities exist:

• A CNAME pointer to the DMARC record

• You can send DMARC reports to another domain via the mailto field.

  • If the domain organisation.fr has to send reports to the domain report.fr, the the domain report.fr, the subdomain organisation.fr._report._dmarc.rapport.fr must contain the TXT record v=DMARC1.

  • You should avoid using a wildcard for reports like ._report._dmarc.report.fr. This allows any domains to send DMARC reports on the domain rapport.fr

Sending emails from shared infrastructures, such as the cloud, poses infrastructure, such as the cloud, pose authorization issues at the SPF level. If a shared shared platform is to be used, the use of a dedicated sub-domain for a dedicated subdomain for sending and use SPF and DKIM.

To protect domains that do not send email and despite an active DMARC policy DMARC policy, SPF & DKIM records are required to protect against possible to protect against possible exploitation of subdomains or unconfigured or inactive domains^5,6.

For an inactive domain and its associated subdomains, SPF and DKIM records must be the following SPF and DKIM records must be set up:

• SPF

  • Domain: parked-domain.com TXT v=spf1 -all

  • Subdomain: parked-domain.com TXT v=spf1 -all

• DKIM

  • *._domainkey.parked-domain.com TXT "v=DKIM1: p="

• DMARC

  • _dmarc.parked-domain.com TXT "v=DMARC1; p=reject;" It is not There is no need to set up aggregate reporting or aggregation or forensics.

Company owned or former domains should be protected in this way. This should be done once DMARC has been implemented on the active domains.

To revoke a DKIM key, following the end of a contract with a partner for example, you just have to take the selector associated with the partner's emails of the partner and remove the public key from the DNS field. By For example: *selector1.\

selector1._domainkey.sub.domain.com. TXT ''*v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK5iAj+54lsAg4qRvkf0WEOIqaspaG/A5IGxieiWer+wBX8lW2tE4NHTE0PLhqL0uD2sif2pKoPR3Wr6n/rbiihGYCIzvuY4/U5GigNUGls/QUbCPRyzho30wIDAQAB

will become :

selector1._ domainkey.sub.domain.com. TXT ''v=DKIM1; p=''

The mail sent using this selector will therefore be considered as not signed by the DKIM and therefore failing to authenticate it. authentication.