MX: where mail goes

An MX record says which server accepts mail for a domain. Setting it to ours is what makes anything@example.com arrive here.

It is the only one of the four that routes anything. Get it wrong and nothing arrives at all, which at least fails loudly.

SPF: which servers may send

A TXT record listing the servers allowed to send mail claiming to be from your domain. Receiving providers check it.

Without it, forwarded mail from your domain looks like mail from a server nobody authorised, and filters treat it accordingly. This is the record whose absence shows up as "everything goes to spam" rather than as an error.

DKIM: a signature that survives the trip

A key, published in DNS as a CNAME pointing at ours, that lets us sign each message as your domain. The receiving provider verifies the signature against what is published.

A signature travels with the message, so it survives forwarding in a way that a check on the connecting server does not. This is what makes forwarded mail believable.

The verification record

A TXT record with a value unique to your account. It proves you control the domain before we start accepting mail for it.

Without this step anybody could add your domain here and receive mail intended for you, provided they could get your MX changed. Two proofs are better than one.

DMARC, which we do not require

DMARC tells receiving providers what to do when SPF and DKIM disagree with the visible sender, and where to send reports. It is not required here, and it is worth adding to a domain you use for mail: it is the record that turns the other two from advisory into enforced.

Start with p=none and read the reports before enforcing anything, because a policy set too eagerly on a domain that sends from several places is the classic way to lose your own mail.