Making sure your email arrives

You can set a mailbox up perfectly and still land in your customer's spam folder. Not because you did something wrong, but because the receiving side — Gmail, Outlook, a corporate mail server — is asking itself whether your mail is really f

Written for: Customer, Reseller, Administrator

Screenshot — Panel → Hosting → Accounts → your account → DNS, button Propose mail records. Screenshots of this page are captured with openwolf designqc into .wolf/designqc-captures/.

The short version

Four kinds of DNS record together make your mail credible. If your DNS zone lives in this panel, one button sets them: go to DNS and click Propose mail records. The panel shows what is still missing, writes nothing until you click it, and does not offer again what is already right.

From the command line:

corectl mail records yoursite.com

That prints all four records, ready to paste, even when your zone lives somewhere else. Copy them across in that case.

What the four records do

MX — "send my post here"

The MX record says which server accepts post for your domain. Without an MX nothing arrives; with the wrong MX it arrives at your previous provider.

yoursite.com.   MX   10 mail.yoursite.com.

The 10 is a priority: lower goes first. One MX is enough.

SPF — "these servers may send on my behalf"

SPF is a list of who may send post with your domain as the sender. It lives in a TXT record on the domain itself.

yoursite.com.   TXT   "v=spf1 a mx ~all"

Read it as: my web server (a) and my mail server (mx) may send; anything else is suspicious (~all).

If you also send through somebody else — a newsletter service, a webshop, your accounting package — they have to be in there, or it is precisely that mail that gets refused. That is what include: is for:

"v=spf1 a mx include:_spf.example-newsletter.com ~all"

Two rules that often go wrong:

One SPF record per domain. Two TXT records that both start with v=spf1 is invalid; add the new party to the existing line.
At most ten include: lookups. Beyond that receivers stop looking and your SPF fails anyway.

DKIM — "and here is my signature"

DKIM puts an invisible signature under every message you send. The receiver fetches the matching public key from your DNS and checks that the message was not changed on the way and really came from your server.

The key is generated the moment you turn on Deliver this domain's mail here on the mail page. The record looks like this (abbreviated):

default._domainkey.yoursite.com.   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBg…"

corectl mail dkim show yoursite.com

If your DNS zone is in this panel the record is written for you and there is nothing to do.

DMARC — "and here is what to do when it does not add up"

DMARC is the instruction you give receivers for the case where SPF and DKIM do not check out: ignore it, spam-folder it, or refuse it. Without DMARC every receiver invents an answer of its own.

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

p= is the policy and there are three values:

	meaning	when
`p=none`	do nothing, just send me reports	the first weeks, to see what breaks
`p=quarantine`	put it in the spam folder	once the reports are clean
`p=reject`	refuse the message	once you are sure everything is right

The path is always the same: start at none, read the reports arriving at the rua= address for a few weeks, then move to quarantine and reject. Starting at reject is how people make their own newsletter undeliverable.

Since 2024 Gmail and Yahoo require anybody sending in volume to have at least a DMARC record. p=none counts for that.

Doing it in the panel

Go to DNS for your domain.
Click Propose mail records.
The panel shows MX, SPF, DKIM and DMARC. Whatever is already right is marked already there and is not offered again.
Click Add per line, or take all of them.

If your zone lives elsewhere (your registrar, Cloudflare) nothing can be written from here; use corectl mail records and paste the lines over there.

Checking that it works

The honest test is a real message. Send one to an address at a big provider and look at the message headers there: you are looking for three passes.

# from the server: what would a receiver see?
dig +short TXT yoursite.com
dig +short TXT default._domainkey.yoursite.com
dig +short TXT _dmarc.yoursite.com
dig +short MX  yoursite.com

In Gmail: open the message, click the three dots and choose Show original. It is right at the top:

SPF:   PASS  with IP 203.0.113.10
DKIM:  'PASS' with domain yoursite.com
DMARC: 'PASS'

Three passes and you are done.

When it goes wrong

What you notice	What it usually is
Everything lands in spam at Gmail	No DKIM, or DMARC missing. Set both.
Only your newsletter fails to arrive	The newsletter service is not in your SPF. Add its `include:`.
Nothing arrives since a change	Two SPF records in the zone. There may only be one.
Colleagues receive it, customers do not	The receiving side is filtering on reputation. Patience and a clean list help; do not buy addresses.
Forwarded mail fails SPF	That is expected: forwarding breaks SPF. DKIM survives it — one more reason to set DKIM.
You changed a record and nothing changed	TTL. An old answer may be remembered until the TTL expires; wait an hour.

For administrators: outbound mail through a smarthost

If the data centre blocks outbound port 25, or you want all mail to run through a reputation service, set a smarthost:

corectl mail smarthost show
printf '%s' "$RELAY_PASSWORD" | corectl mail smarthost set relay.example.net:587 \
  --user postmaster@yoursite.com --pass-stdin
corectl mail smarthost clear      # send directly again

Note that the smarthost then has to be in your SPF as well.