How to Configure a Secure Email System to Protect Deliverability and Prevent Identity Spoofing

Properly configuring an email system is essential to ensure email deliverability, prevent identity spoofing, and protect against cybercriminals. At the beginning of the year, Google and Yahoo strengthened their technical controls on emails, while Microsoft continues to refine its EOP and Defender systems, offering even deeper analysis of message content. So, what are the key points to watch to secure your email communications?

The History of Email and the Evolution of Online Threats

While the concept of electronic message exchange emerged in 1961, it was in 1982 that email based on the SMTP protocol, as we know it today, appeared. At that time, messages were sent via the ARPANET network, which connected university researchers, research institutes, and American military laboratories. The SMTP protocol, designed with a certain naivety, did not incorporate today’s security concerns since it was intended for a restricted network used mainly for exchanging scientific data. Thus, the sender was responsible for declaring their identity, and no authority existed to verify it. In other words, the sender could easily impersonate bill.gates@microsoft.com or bill.clinton@whitehouse.com without any mechanism for the recipient to verify the information.

With the emergence of the Internet in the 1990s and its widespread adoption by the public and businesses, the situation changed radically. As a global network accessible to everyone, the Internet quickly became fertile ground for online criminal activities. While cybercrime, once virtually non-existent, has exploded exponentially, the SMTP protocol has not evolved accordingly. At the time of writing, the sender remains solely responsible for declaring their identity, and no centralized authority has been established to help recipients verify sender authenticity.

To address this issue, engineers and private companies have developed additional mechanisms to enhance email security. Among these, the SPF, DKIM, and DMARC standards have become essential protocols to ensure the protection and integrity of email systems.

What is SPF and How Do You Configure It for Your Domain?

The Sender Policy Framework (SPF) is a mechanism that allows the receiving server to verify that the sending SMTP server has been authorized by the domain owner to send emails. In other words, a domain owner like microsoft.com must declare the IP addresses of the SMTP servers authorized to send emails.

Technical explanation of the mechanism: when an SMTP server receives an email, it queries the sender’s domain DNS to locate the SPF record. It then checks that the IP address of the SMTP server that transmitted the email is listed in that record.

How do I configure the SPF for my domain? Log in to your registrar or DNS server and edit your DNS zones. If a TXT record starting with v=spf1 exists, edit it; otherwise, create it. Make sure there is only one SPF record for the domain.

If you want to authorize a dedicated server to send emails, add its IP as follows:

v=spf1 ip4:211.85.89.12 ~all

If you want to authorize an IP range:

v=spf1 ip4:211.85.89.0/24 ~all

To authorize multiple IPs, simply list them consecutively:

v=spf1 ip4:211.85.89.12 ip4:197.53.25.16 ip4:88.85.15.251 ~all

Authorize an IPv6 address:

v=spf1 ip6:3ffe:8007:0000:2201:0200:f8df:fe75:50df ~all

If you use Google, Microsoft, or another product to send your emails, SPF records are generally provided and include all the IPs to authorize. Here is how to add them:

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

Check the SPF server list of the most popular online services.

To authorize the IPs from your A and MX records to send emails, you can add the following arguments:

v=spf1 ip4:211.85.89.12 a mx ~all

An SPF record can combine multiple products and servers authorized to send emails for your domain:

v=spf1 ip4:211.85.89.0/24 ip4:88.45.85.67 include:_spf.google.com a mx ~all

Warning: to avoid harming your domain’s online reputation, it is recommended not to exceed 10 different IPs/ranges/SPF records. In fact, a domain that multiplies email sending methods could be perceived as an organization dedicated to SPAM.

Note that this mechanism has a significant weakness. Indeed, when you authorize the servers of an email tool like Google or an email marketing tool like Mailjet to send emails for your domain, cybercriminals can simply use the same systems to impersonate your identity and carry out phishing and spoofing operations. This weakness is what led to the creation of DKIM.

What is DKIM and How Does It Protect Your Emails?

DomainKeys Identified Mail (DKIM) is a mechanism that allows the receiving server to ensure that the email it has just received is indeed authorized by the domain owner. Specifically, the sending server inserts a cryptographic signature generated with a private key. The receiving server checks that a DNS record contains the corresponding public key and uses it to decrypt the signature. If the key successfully verifies the signature, it confirms that the sending system has been properly configured by the domain owner. Note that it is not possible to derive the private key from the public key.

How do I configure DKIM for my domain? Start by generating a private key from the system you wish to authorize to send emails.

If it is a mail server on Linux, use OpenSSL to generate the private and public keys with the following commands.

openssl genrsa -out private.key 1024
openssl rsa -in private.key -pubout -out public.key

For more information, you can consult the official OpenSSL documentation

Then install the private key found in the file private.key in the product responsible for sending emails.

If it is a product like Google Workspace or Microsoft Office365, generate the key using the tool.

In either case, log in to your registrar or DNS server and add a TXT record with the selector associated with the tool.

google._domainkey.yourdomain.com

Check the DKIM server list of the most popular online services.

Then copy the value of the public key contained in the file public.key or provided by the tool.

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB4QUAA4GNADCBiQKBgQDL6joZwa33IP8oFEQW3d1oAZxKFYXlyoXWUbSExWH8L1J
soGIhwmR30M6WM+F7U8QeYZ9PwikvccjNDtBIZK/XjfIznmOVEKFlygm/33fVpTSMI7n2P8laUcxu4G93i1J9IO0Ekmx8lhPFXJ0e
O24amjN6jlSlRsAf0/SNMJZeSwIDAQAB

Unlike SPF, it is necessary to add a DKIM record for each system authorized to send emails.

Warning: some registrars do not accept keys larger than 1024 bits and, at the same time, some email providers like Yahoo penalize keys smaller than 1024 bits. It therefore appears that 1024 bits is the most appropriate configuration.

This mechanism appears more robust than SPF, but it cannot replace it. Indeed, if a hacker were to steal your private key, without the SPF mechanism they could use it from any server for their criminal activities. The strength of an email system lies in the combination of these two mechanisms and the difficulty for a cybercriminal to compromise both.

What is DMARC?

Domain-based Message Authentication, Reporting & Conformance (DMARC) can be defined as the email policy desired by the domain owner. This mechanism serves a dual purpose:

The first is to monitor emails received by all email systems in which the sender presents as part of your domain. This way, you will receive daily reports from each system that has received your emails.

The second is to provide directives to systems that receive emails with a sender from your domain but with improper configuration. For example, it is possible to recommend the rejection of emails from your domain if they do not match the DKIM or SPF records.

Technical explanation of the mechanism: when an SMTP server receives an email, it checks its SPF and DKIM compliance as described earlier, then queries the DNS servers again to retrieve the DMARC record and learn about the domain owner’s email policy. On one hand, the receiving server will send a report on the email to the address you specified in the record. On the other, it will enforce the domain’s rules if the email does not fully comply.

Example configuration:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=r

Here, p designates the action to be taken on the email if it does not meet the restrictions defined with adkim and aspf. The possible values are reject, quarantine, none

rua allows you to specify the email address that will receive the reports. These reports are sent in batches every 24 hours and can be read using specific analysis tools.

adkim specifies the expected level of DKIM compliance. The possible values are "r" (relaxed) and "s" (strict). In relaxed mode, a DKIM signature is valid if the sender's subdomain matches the signed DKIM domain. In strict mode, only an exact match of the domain is accepted.

aspf specifies the expected level of SPF compliance. The possible values are "r" (relaxed) and "s" (strict). In relaxed mode, an email is considered compliant if the sender belongs to the same primary domain. In strict mode, only an SPF record with an exact domain match is accepted.

Warning: although DMARC provides guidelines set by domain owners, they are not mandatory to enforce. The receiving server may decide to apply rules that are either stricter or more lenient than those defined in the DNS.

Does the Email Content Play a Role in Security?

To actively combat cybercrime, new mechanisms are emerging. For example, Microsoft is developing tools such as Exchange Online Protection (EOP) and Defender, which perform an additional layer of checks focused on email content. Thus, links contained in emails and attachments are scanned to detect malicious content.

Similarly, semantic analysis is becoming widespread to detect spam and scam attempts. It is therefore recommended to avoid the lexicon that a malicious organization might use such as: 'Free', 'Make Money', 'Urgent', 'Click Here', 'Special Offer', and excessive symbols like strings of exclamation points or all capital letters to grab attention, e.g. 'FREE!!!'.

In Conclusion

In conclusion, the email protocol was born in a time of carefree innovation and was not equipped with effective mechanisms to identify the sender. These mechanisms have been added over time in layers with SPF, DKIM, and DMARC, which aim to ensure message authenticity and reduce phishing and spam.

SPF allows you to define the servers authorized to send emails for a domain, DKIM ensures the integrity of the message through a cryptographic signature, and DMARC orchestrates these two protocols by providing validation rules and compliance reports.

However, their implementation and management require a rigorous configuration to avoid false positives or legitimate delivery failures. In a context where cyberattacks are increasingly sophisticated, these technologies have become essential for any organization concerned with the security and reliability of its electronic communications.

Learn More

SPF (Sender Policy Framework)
Initiative: Meng Weng Wong is credited with developing SPF in 2000. Wong is an entrepreneur and computer security expert who created SPF to combat email identity spoofing (phishing) and spam.
Organization: SPF was initially developed by Pobox.com, an email service provider founded by Meng Weng Wong. It was later supported by a community of developers and standardized via RFC4408 in 2006. In 2014, an update was published under the RFC7208.

DKIM (DomainKeys Identified Mail)
Initiative: DKIM emerged from the merger of two earlier technologies:
DomainKeys, developed by Yahoo! in 2004.
Identified Internet Mail, developed by Cisco Systems.
Organization: DKIM was designed to digitally sign emails, ensuring that the email originates from the declared domain and has not been altered in transit. In 2007, the DKIM standard was published under RFC 4871 and adopted by the Internet Engineering Task Force (IETF). An initial update was published in 2009 under RFC5672, followed in 2011 by the publication of RFC6376.

DMARC (Domain-based Message Authentication, Reporting & Conformance)
Initiative: DMARC was developed by a consortium of companies including:
> Google
> Yahoo!
> AOL
> Microsoft
> Facebook
> PayPal (in particular, Brett McDowell, a PayPal security expert, who played a key role in its initial development).
Organization: The development of DMARC began in 2011, and it was officially published in January 2012. Its goal was to improve the compatibility of SPF and DKIM and to provide a reporting mechanism that allows domain owners to instruct receiving servers on how to handle emails that fail authentication checks. DMARC is a standard published in RFC7489 and on the official site DMARC.org

This destabilizing situation can happen to any honest organization. First, remain calm and gradually analyze the causes of these rejections. Here is the approach to follow:
> Google
> Yahoo!
> AOL
> Microsoft

There are two simple methods to verify the SPF, DKIM, and DMARC configuration.


Method 1: Send an email from the system under test to a Google address (a simple free Gmail account is sufficient).
From the received email, click on the three dots in the upper right corner and then on "Show original"

Then, verify that the SPF, DKIM, and DMARC lines are all marked as "PASS"


Method 2: The Mail Tester website allows you to test your configuration by sending an email to an alias created on the fly. Visit the following link and follow the instructions: Mail Tester

Our experts will analyze your system and provide the necessary support to bring it into compliance and help your organization out of a crisis situation.

Need help configuring your email system?

Syskeo Staff

The Syskeo team is composed of passionate and experienced professionals. Our multidisciplinary team works in synergy to provide high-quality solutions based on the latest technological advances and the best industry practices.