Setting up SPF, DKIM and DMARC properly

Mail that leaves a domain is judged by three DNS records. They are easy to publish and easy to get out of step with the servers that actually send. When they drift, legitimate mail is treated as untrustworthy, or anyone can send as the domain. This note is the order of work. It is not a promise about whether mail will be accepted.

What each record does

• An SPF record lists the servers allowed to send for the domain. A record that is too wide, and a record that forgets a real sender, both cause trouble.
• DKIM signs a message so a receiver can tell it was not changed in transit. The private key stays with the service that sends. The public key is what you publish in DNS.
• DMARC says what a receiver should do when SPF or DKIM does not align, and where to send reports. The two checks are not interchangeable. Alignment means the visible domain and the authenticated domain agree.

A soft start

Publish an SPF record that matches the servers you actually send from, and nothing broader.

Turn on signing at the service that sends the mail, and publish the matching public key. A key in DNS with no signing, or signing with no key in DNS, does not help.

Start DMARC in a monitoring posture (p=none). Reports arrive before you ask receivers to quarantine or reject. Read them. When your own mail aligns, move the policy towards quarantine, and only then towards reject. Skipping the reports is how a domain blocks itself.

Keep the records somewhere you can edit. A lock you cannot change becomes a problem the day a sender changes.

Check a public domain

The email domain health check reads SPF, DKIM, DMARC, MX and the related records for a public domain, including a .co.za name. It explains each gap in plain language. Nothing is stored.