> For the complete documentation index, see [llms.txt](https://docs.glesys.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.glesys.com/products/other/email/how-tos/configure-the-dns-for-glesys-email.md).

# Configure the DNS for Glesys email

***

There are several DNS records to set up for the email service. The most important records are the MX records; without them, you can't receive any emails.

## MX records

To be able to receive emails with the Glesys email service for a domain, you need to add two records to the domain's DNS. These are so-called *MX* records—*Mail eXchanger*—which inform the sending server where to deliver incoming emails for the domain.

<table><thead><tr><th width="135">Type</th><th width="115">Host</th><th width="140">Priority</th><th>Data</th></tr></thead><tbody><tr><td>MX</td><td>@</td><td>10</td><td>mx01.glesys.se.</td></tr><tr><td>MX</td><td>@</td><td>10</td><td>mx02.glesys.se.</td></tr></tbody></table>

If you are using the *bind* DNS server, the rows will look like this:

{% code title="Bind example for Glesys email service" %}

```
@     IN MX  10 mx01.glesys.se.
@     IN MX  10 mx02.glesys.se.
```

{% endcode %}

If you use the Glesys DNS service, the records will look like this:

<figure><img src="/files/KJc8EHpl5SoqBRSwO6yF" alt=""><figcaption></figcaption></figure>

## SPF record

In addition to the MX records, it is also a good idea to add an SPF record in a TXT record. SPF stands for *Sender Policy Framework* and is designed to prevent other email servers from sending emails on behalf of your domain. This is a way to reduce spam being sent from your domain.

By itself, it's not a foolproof protection since it's up to the recipient server to decide what happens to an email that was not sent from one of the approved servers. However, combined with a DKIM and a DMARC record, the protection is increased.

Create a record for the domain with the following data:

<table><thead><tr><th width="154">Type</th><th width="137">Host</th><th>Data</th></tr></thead><tbody><tr><td>TXT</td><td>@</td><td>"v=spf1 include:_mail.glesys.com -all"</td></tr></tbody></table>

If you use the *bind* DNS server, the record will look like this:

{% code title="Bind example, TXT record for SPF" %}

```
@     IN TXT "v=spf1 include:_mail.glesys.com -all"
```

{% endcode %}

If you use Glesys DNS service, the record will look like this:

<figure><img src="/files/t3gBzFZiBFyibzFAD48U" alt=""><figcaption></figcaption></figure>

## DKIM record

DKIM stands for *DomainKeys Identified Mail*. This is a mechanism that uses encryption keys to sign outgoing email from a server. If the receiving server sees that the email is signed, it knows that it wasn't modified and it was sent from an authorized server. This can help prevent both spam and phishing attempts.

Glesys uses a common key through a CNAME record.

<table><thead><tr><th width="149">Type</th><th width="213">Host</th><th>Data</th></tr></thead><tbody><tr><td>CNAME</td><td>glesys-smtp._domainkey</td><td>key.438b0bc3e63b.dkim.mail.glesys.com.</td></tr></tbody></table>

If you use a *bind* DNS server, the record you need to add will look like this:

{% code title="Bind example, CNAME record for Glesys DKIM" %}

```
glesys-smtp._domainkey  IN CNAME key.438b0bc3e63b.dkim.mail.glesys.com.
```

{% endcode %}

If you use Glesys DNS service, there is a ready-made template you can use. Start by clicking the green **+ Add record** button on the DNS page in the control panel. Select **CNAME record** to create a new CNAME record. Then, scroll down to the new record, click **Templates**, and select **Glesys DKIM**. This will create a record that looks like this:

<figure><img src="/files/qibKUDWaNYsJymlScyVw" alt=""><figcaption></figcaption></figure>

Finally, click the green **Save changes** button in the lower right corner.

## DMARC record

DMARC and DKIM are closely related. DMARC stands for *Domain-based Message Authentication, Reporting and Conformance*. Its purpose is to allow the administrator of a domain to specify how a receiving email server should handle an email that fails SPF or DKIM.

In its most basic form, DMARC sets a policy for what should happen to an email that fails DKIM and/or SPF. This policy (the `p=` tag) can be set to either `none` (take no action, let the email pass), `quarantine` (send the email to the recipient's spam folder), or `reject` (reject the email completely, i.e., don't deliver it at all).

DMARC records are created using the DNS record type TXT. The ***host*** field should be `_dmarc`, and the ***value*** is the policy and other tags. The following DMARC record is a good starting point.

<table><thead><tr><th width="137">Type</th><th width="213">Host</th><th>Data</th></tr></thead><tbody><tr><td>TXT</td><td>_dmarc</td><td>"v=DMARC1; p=quarantine;"</td></tr></tbody></table>

If you use a *bind* DNS server:

{% code title="Bind example of a basic DMARC record" %}

```
_dmarc  IN TXT  "v=DMARC1; p=quarantine;"
```

{% endcode %}

If you use Glesys DNS service, the record looks like this (the record marked in red):

<figure><img src="/files/tJ1AWvuhyVmTL1meYfJr" alt=""><figcaption></figcaption></figure>

Change the policy to suit you and your organization's needs.

### Alignment

It's also possible to set something referred to as *alignment* for both SPF and DKIM.

A *strict* SPF alignment forces the domain part of the email's *Return-Path* and *From* header to match exactly, i.e., no subdomains are allowed. A *relaxed* alignment still forces the domain part to match, but subdomains are allowed. If no SPF alignment is specified, the default is *relaxed*.

SPF alignment is specified by setting `aspf=` to either `r` for *relaxed* or `s` for *strict*.

A *strict* DKIM alignment forces the domain part of the *DKIM signature* and the *From* header to match exactly, i.e., no subdomains are allowed. Even in relaxed mode, the domain part must match, but subdomains are allowed. If no DKIM alignment is specified, the default is *relaxed*.

DKIM alignment is specified by setting `adkim=` to either `r` for *relaxed* or `s` for *strict*.

For example, a DMARC record with the policy set to *reject*, SPF alignment set to *strict*, and DKIM alignment set to *strict* will look like the following:&#x20;

<table><thead><tr><th width="137">Type</th><th width="213">Host</th><th>Data</th></tr></thead><tbody><tr><td>TXT</td><td>_dmarc</td><td>"v=DMARC1; p=reject; aspf=s; adkim=s;"</td></tr></tbody></table>

For a *bind* DNS server, it will look like this:

{% code title="Bind example of a DMARC record with alignment" %}

```
_dmarc  IN TXT  "v=DMARC1; p=reject; aspf=s; adkim=s;"
```

{% endcode %}

And in Glesys DNS service, it will look like this:

<figure><img src="/files/8PIQ50FYhwaKSgGdOekO" alt=""><figcaption></figcaption></figure>

### Reports

To be able to know how many emails from your domain are allowed, rejected, and quarantined, it's possible to add a `rua=` tag (aggregate reports). This makes the receiving servers send you an email each day with a summary of allowed and rejected emails. In the report itself, you look for the disposition tag to tell if a mail was allowed or not. A disposition of *none* means that no action was taken and that the email was allowed.

Let's continue with the example above and add the `rua=` tag. Remember to change the email address to your own. Also, note that the email address must be prepended by `mailto:`.

<table><thead><tr><th width="96">Type</th><th width="98">Host</th><th>Data</th></tr></thead><tbody><tr><td>TXT</td><td>_dmarc</td><td>"v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:reports@example.com;"</td></tr></tbody></table>

For a *bind* DNS server, the record will now look like this:

{% code title="Bind example of a DMARC record with alignment and report tags" %}

```
_dmarc  IN TXT  "v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:reports@example.com;"
```

{% endcode %}

And for Glesys DNS service, the record will now look like this:

<figure><img src="/files/HnM9yhEFtEMki3kEUxV4" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.glesys.com/products/other/email/how-tos/configure-the-dns-for-glesys-email.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.