To send and receive email on your own domain you need, at minimum, an MX record (and the A or AAAA host it points to) to receive mail, and three authentication records to send trusted mail: an SPF TXT record, a DKIM key, and a DMARC TXT record. Two more records, MTA-STS and BIMI, are optional and improve transport security and brand display. The trick is not just knowing the list. It is adding them in the right order so you never publish a policy that blocks your own mail.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
This guide gives you one authoritative checklist, marks each record mandatory or optional, and walks the safe sequence for turning them on.
The complete email DNS records checklist
Here is every record a normal sending-and-receiving domain uses, top to bottom.
| Record | Type | Purpose | Status |
|---|---|---|---|
| MX | MX | Tells other servers where to deliver inbound mail | Mandatory to receive |
| A / AAAA | A / AAAA | The IP behind the hostname your MX points to | Mandatory to receive |
| SPF | TXT | Lists which servers may send as your domain | Mandatory to send |
| DKIM | CNAME or TXT | Publishes the public key that signs your mail | Mandatory to send |
| DMARC | TXT | Tells receivers what to do when SPF and DKIM fail | Mandatory to send well |
| MTA-STS | TXT + policy | Forces TLS on inbound connections | Optional |
| TLS-RPT | TXT | Reports on TLS delivery failures | Optional |
| BIMI | TXT | Shows your logo next to authenticated mail | Optional |
The first two records are about receiving. The rest are about sending, and about proving that mail claiming to be from you is really from you.
Receiving mail: MX and its A/AAAA target
An MX (Mail Exchanger) record is what makes a domain able to accept email. It names the hostname of the server that handles your inbound mail and a priority number. Lower numbers are tried first.
example.com. IN MX 10 mail.example.com.
example.com. IN MX 20 mail2.example.com.
If you use Google Workspace, Microsoft 365, Zoho, or Fastmail, they give you a set of MX values to publish. You paste those exactly. The hostname in an MX record must itself resolve to an IP address through an A record (IPv4) or AAAA record (IPv6). MX records must never point at a CNAME, and they must never point at a bare IP. That is a common cause of silently lost inbound mail.
mail.example.com. IN A 203.0.113.25
mail.example.com. IN AAAA 2001:db8::25
If you only send email and never receive it on the domain, you can skip MX. But most people want both.
Sending mail: SPF, DKIM, and DMARC
These three records are what modern receivers check before they trust a message. Gmail and Yahoo now require them for bulk senders, and weak setups land in spam. If you want the deeper conceptual version, read SPF, DKIM and DMARC explained.
SPF: who is allowed to send
SPF is a single TXT record at the root of your domain that lists the servers permitted to send mail as you. Receivers check the sending server's IP against this list.
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
Rules that matter: you may have only one SPF record per domain, it is limited to 10 DNS-lookup mechanisms, and you should end it with -all (hard fail) or ~all (soft fail). Never use +all, which authorizes the entire internet to send as you. See how to set up SPF and, if you have many senders, fix SPF too many DNS lookups.
DKIM: a cryptographic signature
DKIM adds a digital signature to every outgoing message. Your sending platform holds a private key and publishes the matching public key in DNS at a selector-specific hostname. Receivers fetch the key and verify the signature, which proves the message was not altered in transit and really came from an authorized system.
Most providers give you a CNAME that points at a key they manage, so rotation happens without you touching DNS:
selector1._domainkey.example.com. IN CNAME selector1.dkim.provider.net.
Some platforms hand you a raw public key as a TXT record instead. Both are valid. The difference is covered in DKIM CNAME versus TXT, and the setup steps are in how to set up DKIM.
DMARC: the policy that ties it together
DMARC tells receivers what to do when a message fails both SPF and DKIM alignment, and where to send reports. It lives at a fixed hostname, _dmarc under your domain.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Start with p=none, which changes nothing about delivery but turns on reporting so you can see who sends as your domain. Once you confirm your legitimate mail passes, move to p=quarantine and then p=reject. That progression is the whole point of how to move DMARC from none to reject. Without DMARC at enforcement, anyone can spoof your exact domain, which is why fixing a missing DMARC record is a security priority, not a nicety.
The safe order to add records
Order matters because DMARC judges SPF and DKIM. If you publish a strict DMARC policy before those two are correct, you can reject your own mail. Do it in this sequence.
- Publish MX and the A/AAAA target first, so mail flows in. Test by sending yourself a message.
- Publish SPF with every legitimate sender included. End with
~allwhile you verify, then tighten to-all. - Enable DKIM in your sending platform and publish the selector record it gives you. Send a test and confirm the signature verifies.
- Only now publish DMARC, and start at
p=none. Collect reports for a week or two. - Raise DMARC to
quarantine, thenreject, once reports show your real mail passing.
Doing SPF and DKIM before DMARC enforcement is the single most important rule here. A domain at p=reject with a broken SPF record and unsigned mail will have its own newsletters and receipts rejected.
Optional records: MTA-STS, TLS-RPT, and BIMI
These add security and polish once the core five are solid.
MTA-STS forces senders to use encrypted TLS connections when delivering to your MX, which blocks downgrade attacks. It uses a _mta-sts TXT record plus a policy file served over HTTPS. Pair it with TLS-RPT so you get reports when TLS delivery fails. Setup is in how to set up MTA-STS and how to set up TLS-RPT.
BIMI displays your brand logo next to authenticated messages in supporting inboxes, but it only works once DMARC is at quarantine or reject. That gate is intentional: mailbox providers will not show a logo for a domain that is not protected against spoofing. See how to set up BIMI and VMC.
Confirm every record with one scan
The fastest way to know your setup is complete and valid is to run the domain through the SPFWise checker at the top of this page. It reports which of these records are present, whether the syntax is correct, whether SPF stays under the 10-lookup limit, whether DKIM keys resolve, and what DMARC policy you are actually publishing. It returns a single grade so you can see at a glance whether anything is missing before you rely on the domain for real mail.
Frequently asked questions
Do I need SPF, DKIM, and DMARC if I only send from Gmail?
Yes. Even with Google Workspace you publish an SPF include, enable DKIM in the admin console, and add a DMARC record yourself. Google hosts the sending infrastructure, but the DNS records live on your domain. The Google Workspace setup guide walks the exact values.
Can a domain send email without an MX record?
Yes. MX only governs receiving. A send-only domain needs SPF, DKIM, and DMARC but no MX. That said, receivers sometimes look for a matching domain on inbound checks, so a send-only domain should still have a DMARC record and ideally a null MX (0 .) if it never accepts mail.
What happens if I add DMARC before SPF and DKIM are correct?
At p=none, nothing bad happens because that policy only requests reports. The danger is jumping straight to p=reject while your mail fails authentication, which tells receivers to bin your own messages. Always fix SPF and DKIM first, then raise the policy.
How many DKIM records can I have?
As many as you have sending platforms, each on its own selector. One domain can carry separate DKIM keys for your mailbox provider, your marketing tool, and your billing system at the same time. See multiple DKIM selectors on one domain.