Email on your own domain, set up so it actually arrives

Mail from a company address is a basic credibility signal, and configuring it is a small job. The part that is not small is deliverability: whether the message reaches an inbox, a spam folder, or nothing at all.

Three DNS records decide most of it.

SPF — who may send as you

A TXT record listing the servers authorised to send mail using your domain. Receiving servers check it and treat mail from anywhere else with suspicion.

Two rules. List every service that sends on your behalf — mail provider, marketing platform, transactional sender, helpdesk, the application itself — because a forgotten one fails silently. And keep it tight: a permissive record that authorises unrelated machines defeats the purpose entirely.

DKIM — a signature on each message

Your mail provider signs outgoing messages cryptographically; a DNS record publishes the key so receivers can verify the signature. This proves the message really came from you and was not altered in transit.

Your provider generates the key and tells you what to publish. There is nothing to design, only to configure — and to configure for every sending service separately.

DMARC — what to do when the first two fail

A policy record telling receivers how to treat mail that fails SPF and DKIM: monitor it, quarantine it, or reject it outright. It also asks for reports, which is how you discover what is actually being sent using your domain.

Start in monitoring mode. Read the reports for a few weeks, fix the legitimate senders that are failing, then tighten the policy. Going straight to reject reliably blocks something important that nobody remembered was sending mail.

Warming up a new domain

A domain with no sending history is treated cautiously by receiving systems. Sending a large volume from a brand-new name is the fastest way to be filtered.

Build volume gradually over weeks. Ordinary correspondence to people who expect it first, bulk sending later.

Check the history before you send anything

A domain previously used for spam carries that history into your mailbox. Check the common blocklists before you build anything on the name — delisting is slow and, until it completes, mail simply does not arrive.

This belongs in your pre-purchase checks, not after the first complaint.

The Vietnamese-specific point

Mail must not pass through a proxying CDN. If your domain sits behind a proxy service, the mail-related records — the host your MX points at, and the address record for that host — must be excluded from proxying, or mail silently fails while the website works perfectly.

This produces one of the most confusing symptoms in domain administration: everything looks fine, and email vanishes. If mail stops after a DNS or CDN change, check the proxy setting on the mail records first.

Verify by sending, not by reading configuration

Configuration that looks correct and mail that arrives are different claims. Send real messages to accounts on the major providers and check where they land. Then read the DMARC reports, which will tell you about senders you had forgotten existed.