Mail DNS records

Each domain on a mail service has its own list of records. To see it, open the service from Mail Services, go to the Domains tab and select the domain. The DNS records card lists every record with the exact value for that domain. This page explains each one.

In the names and values below, example.com stands for your domain and <base> for your service's mail host (see Placeholders).

The JMAP and CardDAV records name port 8443, where the mail server answers the apps that sign in with them. If your DNS is elsewhere and you published these two records with port 443, change their port to 8443.

The card groups the records by what they are for:

• Needed to receive mail, on Mail Hosting: the ownership record and the MX records.
• Needed to send mail: the SPF record and the DKIM records. On SMTP Relay, the ownership record is here too.
• Recommended: everything else, such as DMARC, the backup MX record and the records mail apps set themselves up from. The list starts folded.

The first two groups hold the records that decide whether the domain is verified (see When a domain is verified). Publish the recommended records too: they add a backup mail server, let mail apps set themselves up, make the domain harder to fake and tell other mail servers to use TLS.

An SMTP Relay domain gets only the ownership, SPF, DKIM and DMARC records. It gets no MX record, so the domain's inbox stays wherever it is now.

A domain whose mail leaves through our delivery partner lists one more DKIM record with the note A second signing key for the mail this domain sends. Publish it as shown. The domain's SPF record then also carries a second include: for the delivery partner, and the domain is not verified until both are in place.

example.com

Your domain, exactly as you added it. A subdomain such as send.example.com gets records under its own name, such as _dmarc.send.example.com.

<base>

The mail host of your service's region, such as mail-fra.coritan.com. The records on a domain's DNS records card already hold yours, such as include:_spf.mail-fra.coritan.com in its SPF record.

<token>

A random value we make for the domain when you add it. It never changes while the domain is on the service.

<selector>

The name of a DKIM key, such as cor202609r for the RSA key and cor202609e for the Ed25519 key. Every domain has two keys, so it lists two DKIM records.

<key>

The public half of the DKIM key. Copy the whole value from the dashboard.

<id>

A label for the domain's MTA-STS policy. It changes when the policy does, and the dashboard shows the current one.

We ask your domain's own nameservers first, so a record counts as soon as your DNS provider serves it. A problem the check finds shows in the Last problem row of the domain's page, under the domain's name on the Domains tab, and in the toast after Verify now.

Ownership

A TXT record at _mailverify.example.com whose value is exactly mail-verify=<token>. A domain whose records we publish into your zone passes without it. Keep the record in place: a later check that cannot find it sets the domain back to pending.

MX

At least one MX record at the domain names one of the mx hosts the dashboard lists. When the domain has MX records and none of them is ours, the check reports MX points to followed by the hosts it found.

SPF

Exactly one TXT record at the domain that starts with v=spf1 and contains _spf.<base>. When the domain's mail leaves through our delivery partner, the same record must also contain the delivery partner's include: entry. Other mechanisms in the same record are fine. Two records report Two SPF records are published at example.com; only one may exist, and a record that needs more than 10 DNS lookups reports The SPF record needs 12 DNS lookups; the limit is 10, because receiving servers then treat the record as broken. A missing include reports The SPF record at example.com is missing include: followed by the entry.

DKIM

The TXT record at each selector contains the key the dashboard shows. A missing or different key reports DKIM selector <selector> not published. Until the keys exist, the check reports No DKIM keys yet: the mail engine has not made them. When mail leaves through our delivery partner, its key must be published at the name the second DKIM record shows, or the check reports Our delivery partner's DKIM key is not published at followed by that name.

DMARC

Exactly one TXT record at _dmarc.example.com that starts with v=DMARC1, whose p= value is the domain's current stage. A different value reports DMARC publishes p=none, expected p=quarantine (with the values found), and two records report Two DMARC records are published at _dmarc.example.com; only one may exist. See DMARC for the stages.

CNAME at a sending name

A name that holds a CNAME cannot hold a TXT record. A CNAME at the domain, at _dmarc.example.com, at a DKIM selector or at the delivery partner's key name makes that record fail with A CNAME at followed by the name, blocks the record there. Delete the CNAME, then publish the record we show.

A check that cannot read your DNS

When a lookup times out or is refused, the check says We could not read your DNS just now. We will check again soon. A domain that is already verified stays verified and keeps its checks, and the next check tries again.

A domain whose mail leaves through our delivery partner also needs the delivery partner's DKIM key and SPF include: in place before it is verified.

A domain that has not passed is pending, and the Domains tab shows how many of its checks have passed, such as Pending · 3/5. We check pending domains again about every ten minutes. For a domain in a zone we write, we also publish its records again and check it about once an hour after it is verified, so a record someone deleted or changed comes back. A verified domain whose DNS is elsewhere is checked when you select Verify now.

Until ownership passes, the list has no DKIM records. We make the domain's keys once we find the ownership record, and the DKIM records then appear on the card.

Type

The record type.

Name

The full name to create. Some DNS providers want only the part before your domain, such as _dmarc for _dmarc.example.com.

Priority

The priority of an MX or SRV record.

Value

What the record holds. An SRV value is its weight, port and target, in that order. A note under a value explains a record that needs something from you.

Status

The result of the last check for that record: Verified or Missing. A DMARC record we have not found reads Optional instead, because the domain is verified without it. Only the ownership, inbound MX, SPF, DKIM and DMARC records get one. The other records have none, and neither do a retiring DKIM key or the second signing key.

Name and value each have a copy button.

Each domain signs with two DKIM keys: an RSA key of 2048 bits and an Ed25519 key. We replace both every 90 days on each verified domain.

When we publish into your zone, we add and delete these records ourselves. When your DNS is elsewhere, the switch waits until you publish the new keys.

When you add a domain whose DNS zone is on Coritan DNS in the same account (the domain's own zone or a parent's), we write its records into the zone ourselves. Ownership passes at once, and the card reads We publish these into your DNS zone and keep them up to date. We do the same for a zone on Coritan DNS in another account once that zone holds the domain's ownership record, _mailverify.example.com: whoever holds the zone put it there for your service.

• Each record we write has a TTL of 300 seconds and the comment coritan-mail, followed by its purpose, in the zone's record list.
• We update and delete only records with that comment, and the records we replace as described below.
• Verify now writes any missing records again before it checks.
• Removing the domain from the mail service deletes only our records, and takes our delivery partner's include: out of the SPF record.

By setting up Mail Hosting or SMTP Relay for a domain you agree that the domain's sending records are managed by us. A domain has to carry one correct record at each of those names for its mail to be trusted, so in a zone we write, our records replace anything that clashes.

The sending records are the SPF record, the DKIM keys, the DMARC record and the ownership record. What we do when the zone already has something at one of these names:

Each time we replace or delete a record, the domain's page lists it under We replaced records in your DNS zone, with the name, what it held and the date, such as We replaced a record at _dmarc.example.com that held p=reject (March 3). The API has the same lines (see With the API).

The inbox records are the MX records, the mail app setup records (autoconfig, autodiscover and the SRV records), TLS reporting and MTA-STS. They apply to Mail Hosting.

We never replace an MX record that points somewhere else on our own, because that would move your inbox.

When the domain is inside a zone on this account's DNS but we are not writing into it (for example, you created the zone after adding the domain), the domain's page shows a Publish to your zone card. Its button, which shows the number of records, creates them through your DNS with a TTL of 3600 seconds. A record that is already there counts as present rather than as a failure.

The card then reports how many records it created, how many were already present and how many it could not publish, with the reason for each. When all of them worked, it checks the domain a moment later. These records do not carry the coritan-mail comment, so we do not update them later: publish again after a DKIM rotation or a DMARC stage change.

When the domain has no zone on this account's DNS and is not verified yet, the page shows a Host this domain's DNS with us card instead. Its Add to Domain Management… button starts adding the domain to Coritan DNS; once the zone exists, the Publish to your zone card appears. See Move the DNS to Coritan.

A name you claimed under coritan.gg needs no step at all: we publish its records and check the domain when you add it.

We write nothing into a zone we do not host, and nothing into a zone on Coritan DNS that its registrar does not point at, because no resolver would see it. You publish the records yourself, and the DNS records card shows the exact values.

• The SPF value is the final one for your domain. We read the SPF record your DNS serves now and build one record from it: our entries first, your other senders after them while the record stays within 10 DNS lookups. A note under the value says This replaces the SPF record you have: it keeps your senders and adds ours. and shows the record it replaces. If we cannot read your DNS, the value holds only our entries, so add your own senders to it.
• A domain can have only one SPF record. Replace the one you have with the value shown instead of adding a second.
• A name that holds a CNAME cannot hold a TXT record, so delete a CNAME at the domain, at _dmarc.example.com or at a DKIM selector before you publish the record there.
• The DMARC value is ours. A DMARC record of yours at _dmarc.example.com is replaced by it: only one DMARC record may exist.
• The card lists what already sits at these names under Clear these before you publish the records: a second SPF record, a DMARC record that is not ours, or a CNAME.
• When the domain's DKIM keys arrive after we find the ownership record, we email the service's owner once a day at most to say the records changed. The email sends you to the domain's page, which lists the exact records.

• Add a domain to Mail Hosting
• Add a sending domain to SMTP Relay
• DMARC
• Manage DNS records
• Mail troubleshooting

Get a domain's records and its last check:

curl https://api.coritan.com/api/v1/client/mail/4812/domains/311/records \
  -H "Authorization: Bearer $CORITAN_TOKEN"

Use /client/smtp-relay/ in the path for an SMTP Relay service. The response holds the domain and the records to publish:

{
  "domain": {
    "id": 311,
    "domain": "example.com",
    "status": "pending",
    "verification_method": "txt",
    "checks": { "ownership": true, "mx": true, "spf": true, "dkim": false, "dmarc": true },
    "dmarc_policy": "none",
    "dmarc_pinned": false,
    "last_checked_at": "2026-09-16T10:40:12Z",
    "last_error": "DKIM selector cor202609r not published",
    "dns_replaced": [],
    "dns_notes": []
  },
  "records": [
    { "type": "TXT", "name": "_mailverify.example.com", "content": "mail-verify=3kP0vS8x", "purpose": "ownership" },
    { "type": "MX", "name": "example.com", "content": "mx1.mail-fra.coritan.com", "priority": 10, "purpose": "inbound" },
    { "type": "TXT", "name": "example.com", "content": "v=spf1 include:_spf.mail-fra.coritan.com -all", "purpose": "spf" },
    { "type": "TXT", "name": "cor202609r._domainkey.example.com", "content": "v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBg...", "purpose": "dkim", "selector": "cor202609r" },
    { "type": "SRV", "name": "_imaps._tcp.example.com", "content": "imap.mail-fra.coritan.com", "priority": 0, "weight": 1, "port": 993, "purpose": "autoconfig" }
  ],
  "conflicts": []
}

The example is shortened. Each record has these fields:

type, name, content

The record to publish. name is always the full name.

priority, weight, port

Present on MX and SRV records.

note, replaces

On a record for a domain whose zone we do not write. content of the SPF record is the final value, note says what it does and replaces holds the record your DNS serves now when it differs. A DMARC record carries replaces too when yours is there.

purpose

What the record is for: ownership, inbound, inbound_standby, spf, dkim, upstream_dkim, dmarc, autoconfig, autodiscover, jmap, carddav, tlsrpt or mta_sts.

selector, state

On DKIM records. state is pending for a new key to publish now and retiring for an old key to keep for one more week.

conflicts

Lines that name what already sits at our names in a zone we do not write, such as a second SPF record, a DMARC record that is not ours or a CNAME. It is an empty list when nothing clashes and for a zone we write.

domain.dns_replaced

The records we replaced in a zone we write, oldest first, each with name, type, was and the time. domain.dns_notes has one plain sentence for each.

domain.checks holds the result of the last check for ownership, MX, SPF, DKIM and DMARC. To run a check, see Add a domain to Mail Hosting. A domain that is not on the service answers 404 Domain not found.