Email DNS Setup: MX, SPF, DKIM, and DMARC to Stay Out of Spam

When you send and receive mail on your own domain (say example.com), the receiving server relies on a handful of DNS records to answer four questions: where should this message be delivered, was it really sent with your permission, has it been tampered with, and what to do if someone forges it. Getting MX, SPF, DKIM, and DMARC right is the foundation of landing in the inbox instead of the spam folder.

MX: Where to Deliver Incoming Mail

An MX (Mail Exchanger) record names the servers responsible for receiving mail for your domain. It governs inbound routing and has nothing to do with sending reputation — but if it's missing, you simply won't receive mail. A lower number means higher priority.

example.com.   IN  MX  10  mx1.mailprovider.com.
example.com.   IN  MX  20  mx2.mailprovider.com.

• Point to the hostnames your mail provider gives you, never to a bare IP address.
• One primary and one backup is plenty: 10 is primary, 20 is the fallback.

SPF: Declare Who May Send on Your Behalf

SPF (Sender Policy Framework) is a single TXT record that lists the servers authorized to send mail using your domain. The receiver checks whether the sending IP appears on that list.

example.com.   IN  TXT  "v=spf1 include:_spf.mailprovider.com ~all"

• include: pulls in your provider's authorized range; for a self-hosted server, list addresses directly with ip4: / ip6:.
• The trailing all means "soft fail" (treat anything else as suspicious but still accept), while -all is a "hard fail" (reject outright) — stricter, but only switch to it once every sending source is accounted for.
• A domain may have only one SPF record; merge all sources into it, and keep the total number of DNS lookups triggered by include at 10 or fewer.

DKIM: A Tamper-Proof Signature on Every Message

DKIM (DomainKeys Identified Mail) signs the message body and headers with a private key. The receiver verifies that signature against a public key you publish in DNS, proving the content wasn't altered in transit. The public key is another TXT record, placed under a <selector>.domainkey subdomain.

s1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

• The selector (s1 here) is generated by your provider; just paste the public-key string they hand you.
• The private key stays on the sending server and never goes into DNS.

DMARC: Set the Policy, Collect the Reports

DMARC builds on top of SPF and DKIM. When neither passes with proper domain alignment, DMARC decides how the message is handled and emails you a summary of the results. It's a TXT record that always lives at the dmarc subdomain.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s"

• The p= policy ranges from lenient to strict: none (observe and report only) → quarantine (send to spam) → reject (refuse delivery).
• Start with p=none. Use the rua reports for a few weeks to confirm your legitimate mail passes, then tighten toward quarantine and eventually reject.
• They work as a team: SPF and DKIM do the verifying, DMARC decides what happens on failure and gives you visibility. Skip any one and you're easy to spoof or to misjudge.

Verifying That It Took Effect

After editing records, DNS changes take time to propagate — usually minutes to a few hours, depending on the TTL. Check with the dig command line or an online tool such as MXToolbox:

dig +short MX    example.com
dig +short TXT   example.com          # SPF
dig +short TXT   s1._domainkey.example.com   # DKIM
dig +short TXT   _dmarc.example.com    # DMARC

On Windows, use nslookup -type=TXT example.com. Finally, send a test message to yourself or to a Gmail/Outlook account and open the header: the Authentication-Results line should read spf=pass, dkim=pass, and dmarc=pass.

Summary

MX handles receiving; SPF, DKIM, and DMARC make your sending trustworthy. Configure them in order: point MX at your mail servers, list your authorized senders in one SPF TXT record, publish a DKIM public key to sign every message, and roll out DMARC starting at p=none before tightening. Verify everything with dig or an online checker, and read the authentication results of one real test message. With all four in place, your domain's mail lands reliably in the inbox — not in spam.