Email on your own domainSet the MX record, SPF, DKIM and DMARC correctly

Published on October 20, 2026

What has to happen for a mail to arrive

When someone sends a mail to contact@yourcompany.com, the sending server asks DNS for your domain's MX record. It names the responsible mail server, and the mail is delivered there.

For the reverse route - your mails to others - something else counts: recipients check via SPF, DKIM and DMARC whether the mail really comes from you. If these records are missing, even correctly sent mails land in spam with large providers or are rejected.

MX: the receiving route

@   MX   10 mail.yourcompany.com.

The number in front of the host name is the priority. It only matters if there are several MX records: then lower values are tried first. In our web interface, you enter @ as the subdomain and the mail server as the target - it sets the priority automatically, and one MX record per name is provided. For web hosting mailboxes, Google Workspace or Microsoft 365, exactly one is enough.

• An MX must point to a host name, never to an IP address.
• This host name needs its own A record - otherwise the record points nowhere.
• The dot at the end belongs to it, otherwise the nameserver appends the zone again.

If you use an external mail provider, it specifies the matching MX values - enter them exactly as given and remove the old ones. The concrete values for the two big providers are in Google Workspace & Microsoft 365.

SPF: who may send for you

An SPF record is a TXT record on the domain itself and lists the servers that may send on your behalf:

@   TXT   "v=spf1 mx -all"

The building blocks:

• mx - all servers entered as MX may send.
• ip4:85.214.12.7 - additionally allow a specific IP, such as your VPS.
• include:_spf.provider.com - adopt a service provider's authorization, for example for newsletters.
• -all - reject everything else. The softer variant ~all only marks as suspicious.

There may be only one SPF record per domain. Several make the check invalid - enter additional senders in the same record instead.

DKIM: the signature

With DKIM, your mail server signs every outgoing mail cryptographically. You store the matching public key as a TXT record on a special subdomain - the selector:

default._domainkey   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

You get selector and key from your mail provider or generate them on your own server. All that matters is that the value ends up in DNS completely and without line breaks - truncated keys are a common source of errors.

DMARC: what should happen to forgeries

DMARC combines SPF and DKIM into a policy and tells recipients what to do with mails that fail:

_dmarc   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com"

• p=none - only observe. The right start for seeing via the reports who sends on your behalf.
• p=quarantine - suspicious mails into spam.
• p=reject - reject. The goal once you are sure all legitimate senders are covered.
• rua= - the address for the aggregate reports.

In practice: start with p=none, evaluate the reports for a few weeks, add missing senders to SPF and DKIM, then tighten. Large providers now expect at least an existing DMARC record.

The order when moving

When switching mail providers, the order decides whether mails get lost:

1. Create the mailboxes at the new provider and transfer existing mails via IMAP.
2. Switch the MX and remove the old records. If the domain is with us, a fixed TTL of 24 hours applies - mails can still arrive at the old provider for that long. If DNS is still elsewhere, lower the TTL there a day or two beforehand.
3. Adjust SPF and DKIM - the new provider needs its own authorizations.
4. Keep the old mailbox for another one to two weeks until nothing more arrives there.

If you switch the nameservers at the same time, a forgotten MX record is by far the most common cause of mails suddenly not arriving.

Typical delivery problems

• Mails land in spam: SPF, DKIM or DMARC are missing or do not match the actual sender.
• An external service cannot send: its include: is missing from the SPF record - typical for newsletter tools and shop systems.
• No mails arrive at all: the MX is missing, points to a name without an A record or to an IP address.
• Nothing goes out to some recipients only: a missing or wrong PTR record for your own mail server.
• Problems again after a change: two SPF records side by side - exactly one is allowed.

How to create the mailboxes themselves on our web hosting is described in Set up email accounts.

Frequently asked questions