Why do you need SPF, DKIM and DMARC records? Print

SPF, DKIM and DMARC are three TXT records that tell receiving mail servers whether a message claiming to come from your domain really did. Without them, mail from your own server is increasingly likely to be filtered as spam or rejected outright, and your domain is easy for anyone else to forge.

Check what your domain already has with a tool such as MXToolbox.

If your mail is handled by one of our control panels, most of this is done for you: the panel can generate the DKIM key and create the records itself — see Creating a mail domain in ISPmanager or the mail settings of your panel. Configure these records by hand only if your DNS is hosted elsewhere or the panel does not manage the domain.

SPF — which servers may send for your domain

Some DNS interfaces expect the host field to be left empty or to contain the domain name instead of @; they substitute it automatically.

The mechanisms

• v=spf1 — the version. Required, and always spf1.
• a — allows the address in the domain's A record.
• mx — allows the servers in the domain's MX records.
• ip4 / ip6 — allows a specific address or range.
• include — allows whatever another domain's SPF record allows. This is what external senders give you: a newsletter service, a CRM, Microsoft 365.
• all — matches everything not listed above, and must come last.
• redirect — use another domain's SPF record instead of this one.
• exists — checks whether a name resolves at all. Rarely needed.
• ptr — do not use. Deprecated by RFC 7208, and some receivers ignore records containing it.

Qualifiers

A qualifier before a mechanism says what to do when it matches: + pass (the default, so it can be omitted), - fail, ~ soft fail, ? neutral.

Applied to all, this is the important choice:

• ~all — mail from other servers is accepted but marked. Start here.
• -all — mail from other servers is rejected. Move to this once you are certain every legitimate sender is listed.

Two rules that catch people out.

Only one SPF record per domain. Two TXT records both beginning v=spf1 make the check fail entirely — the effect is worse than having none. When you add an external sender, merge its include into the existing record rather than creating a second one.

At most 10 DNS lookups. Each include, a, mx and redirect costs a lookup, and nested includes count too. Exceeding the limit makes the record fail, and it happens quietly once a few services have been added.

DKIM — a signature on your outgoing mail

DKIM signs each message with a private key held on the mail server; the matching public key is published in DNS, so receivers can verify the message really came from you and was not altered.

Let your panel or mail server generate the key pair if it can. If you need to do it by hand, use a 2048-bit key — 1024-bit keys are no longer considered adequate:

openssl genrsa -out dkim_private.pem 2048
openssl rsa -pubout -in dkim_private.pem -out dkim_public.pem

The selector is any name you choose — mail, default, a date. It lets you publish several keys at once, which is how you rotate a key without interrupting delivery. Paste the public key as one continuous string, without the BEGIN and END lines and without line breaks.

The private key stays on the mail server and is never published. Treat it as you would any other private key.

DMARC — what receivers should do when a check fails

DMARC ties the other two together and tells receivers how to treat mail that fails them. It also gives you reports, which is its most useful feature.

The tags

• v — always DMARC1. Required.
• p — the policy. Required. none takes no action beyond reporting, quarantine sends failures to spam, reject refuses them.
• sp — the policy for subdomains; same values as p.
• rua — where to send daily aggregate reports. This is the tag worth setting.
• ruf — where to send per-message failure reports. Few receivers send these any more; do not rely on it.
• aspf / adkim — how strictly alignment is checked: r relaxed, s strict.
• pct — the percentage of mail the policy applies to, useful when tightening gradually.
• fo — when failure reports are generated: 0 only if everything fails, 1 if any check fails, d on DKIM failure, s on SPF failure.

A domain has one DMARC record. Subdomains can have their own, at _dmarc.subdomain.example.com.

The order to do this in

Going straight to p=reject is the classic mistake: any legitimate sender you have overlooked — a newsletter platform, a CRM, an invoicing system, a website contact form — starts having its mail rejected, and you find out from customers rather than from a report.

1. Publish SPF with ~all, listing every service that sends mail as your domain.
2. Set up DKIM signing and publish the key.
3. Publish DMARC with p=none and an rua address.
4. Read the aggregate reports for a few weeks. They show every source sending as your domain, including the ones you forgot.
5. Fix or authorise what the reports reveal, then move to p=quarantine, and later to p=reject and -all.

One more record

Reverse DNS matters as well: a mail server whose IP address has no matching PTR record is treated with suspicion regardless of these three records — see How to configure a PTR (reverse DNS) record for your server.

If mail is still being rejected with all of this in place, open a ticket from your client area with the domain name and the rejection message you received — its wording usually identifies which check failed.