Everything you need to know about email authentication

What is authentication?

Authentication is actually a collective name for several technical settings by which you, as a sender, can prove that the email you send:

• is genuine,
• and that the mail server by which it is sent, is actually allowed to do so.

How do mail servers determine whether they are permitted to allow your email access to the inbox?

When receiving your email, the receiving mail server will check these technical settings, the content of your message, any previous messages you have sent, and the way in which your users treated your message.

In this way, the receiving server will try to assess what has to be done with the message.

In fact, the mail server will wonder:

‘Is this email from a sender who actually is who he says he is?’
‘How can I verify this?’
‘What should I do if an email was not authenticated correctly?’

On the basis of the answers to these questions, the server will decide what should happen to this message: placing it in the inbox, banishing it to the spam folder, or rejecting the message altogether.

Why is this so important?

Since email is still often used for undesired messages and increasingly for messages with bad intentions (such as phishing), the major email providers (like Gmail, Yahoo, Hotmail, etc.) always look for ways to keep out this type of email to the best of their ability.

When you, as an authentic sender, do not apply any authentication at all to sending your emails, there is a bigger chance that those emails will be considered spam or undesired or, in the worst case, that they will not reach your recipient in the first place.

Gmail rejects non-authenticated emails completely

Google is one of the major players that has been advocating authentication in the past few years.

In the distant past, they were rather reluctant to block emails, as a result of which the spam folders of Gmail accounts were quite full.

Little by little, they have grown stricter in their policy, and currently they block emails that have some issues, such as failed authentication checks, email headers that are not compliant with the web standards, etc. It is likely that they will keep out bad or poorly configured emails in the future if they find other valid reasons to do so.

In other words, it is currently more important than ever that your email systems are properly configured.

How can I authenticate my emails?

The most frequently used ways of authenticating emails are the Sender PolicyFramework and DomainKeys Identified Mail.

To this end, both make use of DNS records in the domain of your website, but each focuses on a different part of the email.


Your domain administrator (or you) will have to add records via the portal of your webhosting or the location of your domain name.

SPF is a mechanism that allows you to indicate from which IP addresses (servers) it is permitted to send emails in the name of your domain.

DKIM allows you to sign an email digitally to ensure authenticity, so that the recipients can verify that nothing was adjusted while the email was on its way to them.

Additionally, there is DMARC, an overarching whole for the SPF and DKIM tests, which performs an extra test on whether the domain of addresses in the header of your email is consistent (further details are provided later in this article).

As a sender you can indicate via your DMARC policy what the receiving mail server has to do with the message if the DMARC test for an email would fail.


In the sections below, we discuss each of these records in further detail.

1. SPF – Sender Policy Framework

What does an SPF record do exactly?

Sender Policy Framework is a verification mechanism that was developed to counter forgery of sender addresses when an email is delivered and to increase the reliability of email in one go.

The protocol we use to send emails to one another, SMTP, makes it possible for any computer to send messages and pose as any sender imaginable while doing so. This is not what you would like to happen in practice.

An SPF record is in the DNS records of your domain and includes a list with all IP addresses that are authorised to send emails in the name of the respective domain.

When somebody with bad intentions would send an email in your name – by mimicking your normal sender email address – then without SPF the receiving party could not tell the origin of this email from an authentic email that was sent by you.

With SPF records it is easy for the receiving mail server to verify that the email that initially seems to come from your sender address was indeed sent from an IP address that has been authorised for this.

If this is the case, the authentication on the basis of SPF will succeed.

When you send your marketing campaigns via Flexmail, it is therefore important that you add our IP addresses to your SPF record, thus giving us permission to send emails in the name of your domain.

What does an SPF record look like?

Every SPF record has to comply with specific guidelines, so that the mail server can interpret the content correctly.

Here is an example, to make it more visual:

v=spf1 ip4:185.18.8.192/26 include:spf.flexmail.eu
include:spf.protection.outlook.com -all

In this example, the server indicates which type of DNS record is involved, which IP addresses are admitted, which third parties have permission for this domain and what should happen in the event of emails that do not fit in.

For clearness’ sake, we subdivide the record further:

• The part v=spf1 indicates the record is an SPF record. Every valid SPF record has to begin with this part.
• Next, there is a list of all parties admitted.
  Several mechanisms can be used for this, ranging from (sequences of) specific IP addresses, such as ip4:185.18.8.192/26 to including a completely different third-party SPF record, such as Flexmail include:spf.flexmail.eu or Microsoft include:spf.protection.outlook.com
• Finally, there is the qualifier -all which indicates that all addresses not included in the record are not authorised to send emails in your name and have to be rejected.
• Alternatively, there is also the qualifier ~all, which indicates that all addresses not included in the record should be considered unsafe or SPAM, but they can be accepted. You could use this if you also use DMARC with ‘quarantine’ or ‘reject’ as a policy.

How to set this correctly?

To include Flexmail as an authorised sender in your SPF record, adding include:spf.flexmail.eu to your existing record will suffice. In this way, the IP addresses of all of our mail servers are included in your SPF record automatically.

In this way, your SPF record will remain up to date even if all of our IP addresses change.

If you do not have an SPF record yet, you could create one that should include at least the following:

v=spf1 include:spf.flexmail.eu -all

Using SPF properly

To ensure that your SPF record can do its work properly, you should keep the following into account:

• There can only be one SPF record in the domain. If you have an SPF record already, you have to change your existing record so that it can include the reference to Flexmail.
• Every subdomain has its own SPF record. You could use subdomains to keep various email flows separated from each other.
• The record has to be in the domain from which you send, for example the domain flexmail.be when you send from info@flexmail.be.
• The record should always end with the all part, preceded by a valid qualifier.
• An SPF record has to consist of only 10 lookups in total across all mechanisms, such as include: and mx:. If an external SPF record includes a reference to other external records, these also count as lookups of your record. In the case of doubt, check your SPF record with one of the free SPF validation tools that are available online.

2. DKIM – DomainKeys Identified Mail

What does DKIM do exactly?

Due to the way in which email works in the background, an SPF record will not survive when the message is forwarded between multiple (internal) mail servers, and for this reason the SPF record in itself does not suffice for authentication.

The second part of email authentication we therefore look at is DomainKeys Identified Mail.

You can regard DKIM as a digital signature that is added to the email by the sender. Part of this signature, the private key, is only known to the sender.

Since certain parts and the complete content of the message are used when digital signing is used (which will be discussed in more detail later on in this article), this is a way to guarantee that between sending and receiving the email nothing was changed to any part used for signing.

The recipient can check the sender’s digital signature by means of a public key in the DNS records of your domain.

If the signature is correct, the recipient knows for certain that the sender is who he says he is and that the received message is genuine.

What does a DKIM record consist of?

Like the SPF record a DKIM record is just a DNS TXT record that has to meet certain guidelines.

Look at the following example:

flexmail._domainkey.flexmail.be. IN TXT
v=DKIM1;g=*;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs/Gs/1IM67pWCo4Q37eLNEz+rhqQJO/B0tXPlApbdPi8gq4kxbXlq3MFbRsni5VDm/ivrueebOqzytM/
MYDcDx6izyYHfqwzW6PX3RRvRoASROq6oAM1jFde1CMtIwKYviSq5XLJ3mIeIt6mKW5pDOZdr9PLlj2YjdXY9ZeLDS2BiHkIJsFQ23t2wkwXwRQzxitTZUwEeWgnZll4kFClO6TzBmr9MFajEgnLPCdsKnkVCrVf36ahNZbZna2Q0dVBuoC+6N+3iYi25VdioqxNy6uc5Ubp9bAm9cNBi6tE8Te2sSU4gvmZCjI1Ak2jYBKr1iWFfK314gcIpUMunv7icwIDAQAB

Name of the record

Contrary to most normal TXT records, DKIM records are saved under a specific name in your domain and not just under the domain itself.

The naming of DKIM records has the following format:

[selector]._domainkey.[jouwdomein.be]

The selector is a specific value that indicates which key the sender used for signing the email, so that the recipient can request the correct public key.

Thanks to this specific naming, it is also possible to use multiple DKIM keys in the same domain, for example a separate selector for every service provider you use or to rotate used DKIM keys for extra security.

In the example above, we send our email from a @flexmail.be address and use the flexmail selector.

Content of the record

Now that you know where the record should be, we should discuss the content of the record. This is actually the public key the recipient uses to verify the signature of the message.

Let us look at the parts in detail:

• The part v=DKIM1; in the example indicates the record is a DKIM record.
• g=*; indicates the granularity of the public key and could be used to restrict the use of this key to one specific sender.
  For this value we use an asterisk, so that the key can be used for every validated sender of the domain.
• The part k=rsa; indicates that RSA is the encryption method used.
• Everything behind p= is the actual public key and has, in our case, a length of 2048 bits.

How does signing work?

The sending server composes the signature by using email headers, the content of the message and a private key. This signature is added to the message as part of the DKIM header.

This DKIM header is one of many email headers an email has. These headers are technical by nature and are therefore hidden to the user by most email programs.

These headers can be made visible by recipients via the settings of their email program.

Here is a (simplified) example of a DKIM header:

v=1;
a=rsa-sha1;
s=flexmail;
d=flexmail.be;
h=Date:To:From:Subject;
i=support@flexmail.be;
bh=PQqKzsjcrGzED4VQPw+9jhU9dP4=;
b=eruM0kNDvSH/+/7cK+FItpViMi+7iwRAwRWGAinTgNZZpIB6achCj4GzBLwod9nsqiMTjlvKbzPkgaK/EskZC4tQ599eAitNbeamq4AIMkqiqdOzvL4Nc9POm6Ftxdy8ns6c9aj8q13cOAtboGjc+q39QyClLe62UJgnu6jAcPHNRh21MsemW5UpioC57QLRT0fD5LIau5ZKNkkSvTJZqtEKJI9wa6y3PPWNcTJgAds2T5Z88uOBAUxUql52HQkkVJPy4VaSAaTxUK0X5nYnYOyGk4dYW6ICyPGdVvIHt/wcDw77EHvdjgR9FqNIWrDDJ+4d4b8wdhU0ko+1s8UKOw==

• v= indicates the DKIM version used. In practice, this is always 1.
• s= indicates which selector has to be used for retrieving the related DNS record.
• d= refers to the domain that will be used for retrieving the related DNS record, and it reflects the sender’s domain.
• h= lists all header fields used for composing the digital signature, b=. The order of these parts also plays a role in the verification.
  In this simplified example, we use the email headers date,to, from and subject.
• bh= is a calculated value, or hash, for the content of the email. A specific mathematical function is used for calculating a hash.
  This hash is then added to the message, so that the receiving email server can calculate the signature before the complete message is loaded. In this way, time can be saved, because emails can have an indefinite length.
• a= indicates the algorithm used for calculating the digital signature, b=, and the hash of the email content, bh=. In this example, RSA-SHA1 is used.
• b= is the digital signature, generated with the values from h= and bh=.

This digital signature ensures that the receiving server can authenticate the sending mail server on the one hand and can be certain that the email has not been tampered with on the other hand.

The receiving server does this by combining the same content (that is mentioned in h=) and the body hash (bh=) and testing it against the public key of the DKIM record. Only if the related private key was used and if the content has not been adjusted (both headers and content), this verification will be successful and the email will pass the DKIM test.

3. DMARC - Domain-based Message Authentication Reporting and Conformance

What is DMARC?

Domain-based Message Authentication Reporting and Conformance (DMARC) is an overarching whole for the SPF and DKIM tests. The related DMARC policy indicates what the receiving mail server has to do with the message if an email fails the DMARC test.

How does DMARC work?

DMARC can only function when you have set at least an SPF record or a DKIM record. In the best case, you have set both of course.

In this context, you should note that an email message is also in an envelope, just like a hardcopy letter sent by post. On this envelope, there are some extra data about the sending mail server, such as the sender’s address. The address on the envelope will be used to send a response to the sending mail server, if the email cannot be delivered.

When an email is received, the receiving mail server will check whether there is a DMARC record for the sending domain, and next it will perform the usual SPF/DKIM tests referred to above.

Additionally, a so-called DMARC alignment test will be conducted to check if:

• in the event of SPF, the domain of the sender address of the email is consistent with that of the return address stated on the envelope;
• in the event of DKIM, the domain in the d= part of the DKIM header is consistent with the domain of the sender address.

You can also indicate whether this alignment test has to be ‘strict’ (the domains should be exactly identical) or, as usual, ‘relaxed’ (the main domain has to be identical, but the use of a subdomain is permitted).

The DMARC test will be passed in the following cases:

• If only one authentication method has been set (SPF or DKIM), the authentication check has to succeed and the domains have to be aligned with each other.
• If both authentication methods have been set, only one of both tests has to be passed, including the related alignment test.

One image says more than a thousand words, so we provide a clear diagram below:

What does a DMARC record consist of?

Just like all records discussed above, a DMARC record is a TXT record that is in the DNS records of your domain. A practical example of this type of record:

v=DMARC1; p=reject; rua=mailto:55465eddd9f1@report.example.com;
ruf=mailto:5b0ddsfd54d9f1@report.example.com; sp=none;

This record, too, begins with v=, which refers to the version; for DMARC this is v=DMARC1;

If the DMARC test is unsuccessful for whatever reason, the policy set in p= will be looked at.

There are three options:

• p=none;the email has to be treated as it would be if there were no DMARC record. You mostly use this when you want to identify your email flows without influencing the deliverability.
• p=quarantine; allows the receiving mail server to accept the email, but it would not be allowed to end up in the inbox. In many cases, the message will end up in the SPAM folder right away.
• p=reject; the message has to be rejected altogether. This will result in a bounce.

With rua= you indicate to which mailbox the summary reports can be sent. This is actually a compulsory value if you want to be able to benefit from the strength of DMARC and have the possibility of receiving such summary reports.

You receive this summary report as an XML document, and per Email Service Provider information (Gmail, Yahoo, etc.) it includes information about the status of the DMARC, SPF and DKIM tests and the related domains. You can also see the sending IP address in these reports to be able to track the origin of your traffic flows.

As these reports are difficult to read for people, there are many services that convert these XML documents into understandable reports, often with visualisation in diagrams.

With ruf= you can indicate to which mailbox the DMARC forensic reports and reports when a DMARC test has failed, can be sent. For privacy reasons, not every provider will use this setting.

When you have only recently started with DMARC, you should rather opt for the summary reports you get via rua=.

Additionally, for every alignment test you can indicate via your DMARC record by means of adkim= and aspf= whether this has to be done in a ‘strict’ manner (adkim=s; / aspf=s;). In that case, the domains of the compared elements have to be exactly identical.

When you do not indicate anything explicitly, the test will take place in a ‘relaxed’ manner. This means that the main domain has to be identical, but that the use of a subdomain is allowed. You can also indicate this explicitly by entering the value r.


Via sp=, you can optionally indicate a deviating policy for subdomains. If this value is not set and there is no DMARC record in the subdomain itself, the policy of the main domain will be applied automatically.

With pct= you can indicate to which percentage of the email traffic your DMARC policy has to be applied. If you do not set this value, pct=100 will be used, and the policy will be applied to all emails.

How to do this in practice?

Where can the SPF and DKIM records be found in Flexmail?

In your account settings, under Send, you can click Add or delete senders.

On this page, your sender addresses are grouped per domain. Via the Set authentication button, you can view more details about the records of this specific domain.

If you have not done this before, you will first need to choose a selector so as to be able to generate your secret DKIM and your public DKIM.

Once you have generated the DKIM keys, you will notice you can also click the additional Generate report button at the bottom to download the authentication report.

How should I add these records to my DNS?

In many cases, you can forward the authentication report of the previous step to the domain administrator, webmaster or even, if necessary, to your IT department. This file tells them exactly what they should do for you. Very useful indeed. Besides, you can also refer to this article.

No domain administrator, webmaster or IT genius available who can take care of this for you?

In that case, you could contact the support department of your hosting provider or check the manual to find out how to add and adjust TXT records.

Every DNS portal works in a slightly different way, but in great outline it will boil down to this:

• Open the DNS settings of the desired domain.
• SPF:
  • Do you already have an SPF record? Change this existing record with the content from the authentication report.
  • No SPF record yet? Create a new TXT record with the content from the authentication report.
  • The content of your record still begins with v=spf1.
• DKIM:
  • Add a new TXT record and take the special naming and the previously chosen sector into account.
  • The content of your record always begins with v=DKIM1; and can be found in your authentication report.

A good start with DMARC

Have you (already) taken care of your SPF and DKIM? If so, you may consider making this a bit more professional with DMARC.

As a DMARC policy may have serious consequences for your deliverability when your authentication is not fully in order, we recommend that you make your policy stricter in steps, while evaluating the effects as you go along.

Imagine that you do not have a DMARC policy yet and that you would like to begin using it, we recommend that you first create a DMARC record with p=none; and set a rua= address to receive he summary reports.

Add the following TXT record, for example:

v=DMARC1; p=none; rua=mailto:55465eddd9f1@report.example.com;

We further recommend that you also use a tool to convert these reports into a readable format, so that it will be easier for you to do something with the data yielded by DMARC.

Once you have some idea of which email flows there are (thanks to the DMARC reports), you will know what has to be improved in terms of authentication, and you can get started.

Examples include setting DKIM or SPF or aligning all domains. Next, you can adjust the policy from p=none; to p=quarantine;. Begin with a low percentage that has to be tested, for example pct=10;.


If, after some time, you notice that everything is going well, increase the percentage gradually to 100. If you notice that everything is going smoothly at 100% too, you can make the policy stricter yourself from p=quarantine; to p=reject;.

Please note, that with every adjustment or new traffic flow, for instance with a new platform for email marketing, this process may have to be repeated or may have to be relaxed a bit temporarily.

Finally

Now that you have read this article, these DNS records should not hold any major secrets for you, and you should be able to get your authentication in perfect order.

If you still cannot figure it out, or if you cannot see the wood for the trees, contact us so that we can help you to get going!