# What DNS records does a business email domain need? > DNS records every business email domain needs: MX to receive mail, plus SPF, DKIM, and DMARC to authenticate it — and the optional records worth adding. Every business email domain needs four DNS records to send and receive mail that lands in the inbox: an **MX record** so other servers know where to deliver your mail, and three authentication records — **SPF**, **DKIM**, and **DMARC** — that prove your mail is genuinely from you. MX makes email work at all; the authentication trio is what Gmail, Yahoo, and Microsoft now require before they trust bulk mail from your domain. Everything else is optional hardening. ## Quick Takeaways - An **MX record** points to the mail servers that accept incoming email for your domain — without it, you cannot receive mail. - An **SPF record** (a TXT record) lists which servers are allowed to send mail using your domain. - A **DKIM record** (a TXT or CNAME record) publishes the public key that verifies your mail's cryptographic signature. - A **DMARC record** (a TXT record at `_dmarc.yourdomain.com`) tells receivers what to do when SPF or DKIM fails and where to send reports. - Gmail and Yahoo require SPF, DKIM, and DMARC for anyone sending bulk mail as of February 2024; Microsoft began enforcing the same in May 2025. - Optional records — MTA-STS, TLS-RPT, BIMI, and PTR — add encryption guarantees, reporting, and brand signals on top of the core four. ## What is the difference between records that carry mail and records that authenticate it? DNS records for email fall into two jobs. The first job is **routing**: telling the internet where your mail lives. The second is **authentication**: proving that a message claiming to be from your domain really is. Only one record does the routing job — the MX record. The rest are authentication and policy records that receiving servers read to decide whether to trust, quarantine, or reject a message. A domain can have a perfectly valid MX record and still have every message marked as spam, because routing and trust are separate questions. This is why "email works" and "email lands in the inbox" are not the same milestone. ## What does the MX record do? The MX (Mail Exchange) record tells other mail servers which hosts accept incoming email for your domain, and in what priority order. When someone emails `you@yourdomain.com`, their server looks up your domain's MX record and delivers to the host with the lowest priority number first. If you use Google Workspace, Microsoft 365, or a hosted provider, they give you the exact MX values to publish. A typical setup points to one or two provider hostnames: - `1 aspmx.l.google.com` (Google Workspace, lowest number = highest priority) - Or `0 yourdomain-com.mail.protection.outlook.com` (Microsoft 365) Get this wrong and inbound mail bounces with a [no MX record found error](/learning/no-mx-record-found-bounce). You can confirm what is published with an [MX record lookup](/tools/mx). For the full mechanics, see [what an MX record is](/learning/what-is-an-mx-record). ## What does the SPF record do? SPF (Sender Policy Framework) is a TXT record that lists the servers authorized to send mail using your domain in the envelope. A receiving server checks the sending IP against this list; if the IP is not authorized, SPF fails. An SPF record is a single TXT record on the root domain that starts with `v=spf1` and ends with an `all` mechanism: ``` v=spf1 include:_spf.google.com ~all ``` The `include` pulls in your provider's authorized senders, and `~all` (soft fail) or `-all` (hard fail) sets what happens to everything else. You may only publish **one** SPF record per domain — a second one breaks both. SPF also has a hard limit of 10 DNS lookups, which is the most common way it quietly fails. See [SPF record syntax explained](/learning/spf-record-syntax-explained-mechanisms-qualifiers) for the mechanisms and qualifiers, and test yours with the [SPF checker](/tools/spf). ## What does the DKIM record do? DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message header. The matching public key is published in DNS so receivers can verify the signature was created by you and that the message was not altered in transit. DKIM lives at a **selector** subdomain — for example `selector1._domainkey.yourdomain.com` — as either a TXT record holding the key or a CNAME that points to a key your provider hosts. Your email platform generates the key pair and tells you exactly what to publish; you rarely type the key by hand. Because the selector is provider-specific, a domain can carry several DKIM records at once (one per sending service). Read [what DKIM is](/learning/what-is-dkim) for the signing flow, and verify a selector with the [DKIM checker](/tools/dkim). ## What does the DMARC record do? DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receivers what to do when a message fails both. It is a TXT record published at `_dmarc.yourdomain.com`: ``` v=DMARC1; p=none; rua=mailto:reports@yourdomain.com ``` The `p` tag is the policy: `none` (monitor only), `quarantine` (send failures to spam), or `reject` (block them). The `rua` tag is where aggregate reports are sent, which is how you discover who is sending as your domain before you tighten the policy. Best practice is to start at `p=none`, read the reports, fix your legitimate senders, then move to `quarantine` and finally `reject`. See [what DMARC is](/learning/what-is-dmarc) for the full tag reference, and generate a record with the [DMARC checker](/tools/dmarc). ## Which optional DNS records are worth adding? Once the core four are in place, these records add real security and visibility for domains that need it: - **PTR (reverse DNS):** maps your sending IP back to a hostname. Providers expect a matching forward and reverse record on any server you send from — missing PTR is a common spam trigger. See [what a PTR record is](/learning/what-is-a-ptr-record). - **MTA-STS:** forces inbound mail to arrive over encrypted TLS and refuses to downgrade, closing a man-in-the-middle gap SMTP leaves open. See [what MTA-STS is](/learning/what-is-mta-sts). - **TLS-RPT:** a TXT record that asks receivers to report failed TLS connections, so you learn when encrypted delivery breaks. Providers like Google [document how to read these reports](/learning/google-mta-sts-tls-reports). - **BIMI:** publishes your verified logo so supporting inboxes show it next to authenticated mail — but it requires DMARC at enforcement first. See [what BIMI is](/learning/what-is-bimi). - **AAAA:** the IPv6 equivalent of an A record, needed if your mail host is reachable over IPv6. See [what an AAAA record is](/learning/what-is-an-aaaa-dns-record-quad-a-explained). ## Common issues with business email DNS records ### Why is my mail still going to spam after I added SPF, DKIM, and DMARC? Publishing the records is not the same as passing them. A record with a typo, an SPF record over the 10-lookup limit, or a DKIM selector that does not match what your platform signs with will all authenticate as *fail* even though the record exists. Run each one through a checker rather than trusting that "the record is there." ### Why do I have two SPF records and which one wins? Neither. A domain may publish only one `v=spf1` TXT record. A second one makes SPF return a permerror, which most receivers treat as a fail. Merge every sender into a single record using `include` mechanisms and delete the duplicate. ### My MX record is correct but mail bounces — what else could it be? Check that the MX hostname itself resolves to an A or AAAA record, and that no leftover MX entry points at a decommissioned server. A high-priority record aimed at a dead host will be tried first and stall delivery before the working record is reached. ### DKIM verified yesterday and fails today Your provider rotated the key, or you republished the record and trimmed a character. DKIM keys are long; DNS interfaces sometimes truncate or wrap them. Re-copy the exact value your platform shows and confirm the selector name matches. ## Frequently asked questions **Do I need all four records if I only send a few emails a day?** You need MX to receive mail and SPF, DKIM, and DMARC to be trusted. Low volume does not exempt you — Gmail and Yahoo apply authentication checks to individual senders too, and DMARC protects your domain from being spoofed regardless of how much you send. **Where do DNS records for email live?** At your domain's DNS host — the registrar or DNS provider that manages your zone (Cloudflare, GoDaddy, Route 53, and so on), not inside your email platform. Your email provider tells you the values; you publish them in DNS. **How long until new email DNS records take effect?** Usually minutes to a couple of hours, bounded by each record's TTL. Allow up to 24–48 hours before assuming a record is wrong, and check it with a [DNS lookup](/tools/dns-lookup) in the meantime. **Can one domain use two email providers at once?** Yes. Add each provider's `include` to the single SPF record, publish each provider's DKIM selector, and keep one DMARC record. MX still points to just one inbound provider. One place teams lose time is discovering which of these records are missing or misconfigured across every domain they manage. Palisade inventories a domain's email DNS, flags the gaps, and automates the path to DMARC enforcement so you are not hand-checking records one registrar at a time. The free [Email Security Score](/tools/email-security-score) shows exactly which of these records your domain is missing today. ## Related reading - [What is SPF? Sender Policy Framework explained](/learning/what-is-spf) - [What is DKIM and how does it work?](/learning/what-is-dkim) - [What is DMARC and why does it matter?](/learning/what-is-dmarc)