DNS Records for Email: MX, SPF, DKIM, DMARC Explained
Sending email reliably depends on a handful of DNS records: an MX record so mail can be delivered to you, and SPF, DKIM, and DMARC records so the mail you send passes authentication. An A or CNAME record points the domain at a real address. Get these right and receiving servers trust your domain; get them wrong and your mail lands in spam or bounces.
What DNS records do for email
DNS (the Domain Name System) is the lookup layer of the internet. When a server needs to know something about your domain — where to deliver its mail, whether a sender is allowed, what to do with a forged message — it queries your DNS records. Each record type answers a different question.
For email there are five that matter. One handles receiving, three handle authentication, and one handles where the domain itself resolves. Here is the short version before the detail.
| Record | Type | Answers the question |
|---|---|---|
| MX | MX | Where should mail for this domain be delivered? |
| SPF | TXT | Which servers may send mail for this domain? |
| DKIM | TXT or CNAME | Was this message signed by the domain and unaltered? |
| DMARC | TXT | What happens when SPF or DKIM fails? |
| A / CNAME | A / CNAME | What does this hostname point to? |
MX: where mail gets delivered
The MX (Mail Exchanger) record tells the rest of the internet which server accepts mail for your domain. When someone replies to your cold email, their server looks up your domain’s MX record and delivers the reply to whatever host it names — for a Microsoft 365 mailbox, that is Microsoft’s mail servers.
MX is about receiving, not sending. A domain with no MX record can still send, but it cannot accept replies. That looks suspicious to receivers and kills the conversation you are trying to start. See what an MX record is for why every real sending domain should have one.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a TXT record listing the servers permitted to send mail for your domain. A receiving server reads the envelope sender, looks up your SPF record, and checks whether the sending IP is on the list. For a Microsoft 365 setup the record is usually just v=spf1 include:spf.protection.outlook.com -all.
There is exactly one SPF record per domain, and it must stay under ten DNS lookups when evaluated — both common ways to break it. The SPF record guide covers the lookup limit and the -all versus ~all ending in depth.
DKIM: proof the message was not tampered with
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. The receiving server fetches your public key from DNS and verifies the signature, which proves two things: the message really came from your domain, and nobody altered it in transit.
In Microsoft 365, DKIM is typically published as two CNAME records pointing at Microsoft’s keys, so the provider can rotate keys without you touching DNS. Other setups publish the public key directly as a TXT record. Either way, where SPF checks the sending server, DKIM checks the message itself — the two are complementary, not redundant.
DMARC: what to do when checks fail
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receivers what to do with mail that fails them. The TXT record carries a policy: p=none (monitor only), p=quarantine (send to spam), or p=reject (refuse outright). It can also request aggregate reports so you can see who is sending under your domain.
DMARC ties SPF and DKIM into one policy and adds reporting. Many senders start at p=none to watch the reports, then tighten if they want to. The DMARC for cold email guide explains each policy level and the alignment rules that decide whether a pass actually counts.
A and CNAME: where the domain points
An A record maps a hostname to an IP address; a CNAME maps one hostname to another name. Neither authenticates mail, but they matter for cold email in one practical way: a sending domain with no website at all is a weak trust signal. Pointing the root domain at a simple page — even a one-line placeholder — makes the domain look real to both recipients and spam filters.
CNAMEs also do quiet work in email: the DKIM CNAMEs above are one example, and providers often use CNAMEs for tracking or link domains. You don’t need an elaborate site, just a domain that resolves to something rather than nothing.
How the records work together
No single record is enough on its own. SPF can pass while a message is still forged in your name; DKIM can verify a signature on mail you’d rather reject; MX has nothing to say about authentication at all. They cover different gaps.
| If you have only… | What’s still broken |
|---|---|
| MX | You can receive, but your outbound mail isn’t authenticated |
| SPF | Server is authorised, but message integrity is unproven and failures have no policy |
| SPF + DKIM | Both checks exist, but nothing tells receivers what to do when they fail |
| SPF + DKIM + DMARC | Complete authentication; add MX so you can take replies |
Since February 2024, Google and Yahoo require bulk senders to pass SPF and DKIM and to publish DMARC, alongside one-click unsubscribe and a low spam-complaint rate (commonly cited as under roughly 0.3%). For cold email that means all three authentication records are now table stakes, not optional polish. A missing or misconfigured record is one of the most common reasons cold emails go to spam. Our SPF, DKIM, and DMARC setup checklist walks through testing them together rather than one at a time.
How Mailionaire approaches this
Every sending domain Mailionaire provisions gets its MX, SPF, DKIM, and DMARC records written and verified automatically as part of standing up its isolated Microsoft 365 tenant — no DNS editing on your side, no second-SPF-record mistakes. It is part of the flat $50 per active domain per month. See how it works for the full setup flow.
FAQ
Which DNS records do I need to send email?
To receive mail you need an MX record. To send mail that passes modern checks you need SPF, DKIM, and DMARC records (all TXT entries, except DKIM which is often a CNAME). An A or CNAME record for the domain is optional but useful so a sending domain resolves to a real page.
What is the difference between MX and SPF records?
An MX record tells other servers where to deliver mail addressed to your domain — it governs receiving. SPF is a TXT record that lists which servers are allowed to send mail for your domain — it governs sending. They solve opposite problems and you need both for a complete setup.
Is DKIM a TXT record or a CNAME?
It can be either. Microsoft 365 typically publishes DKIM as two CNAME records pointing at Microsoft's keys, which lets the provider rotate keys without you editing DNS. Other setups publish the public key directly as a TXT record. Both are valid; the receiving server resolves whichever you use.
Do correct DNS records make my cold email legal?
No. MX, SPF, DKIM, and DMARC are technical records that affect deliverability, not legal permission. Whether you may send depends on the recipient's jurisdiction — Germany's UWG §7(2) generally requires prior opt-in for advertising email, including B2B. The sender stays responsible. This is not legal advice.
Mailionaire provisions real, isolated Microsoft 365 mailboxes for cold email — built in Switzerland, with optional EU/Swiss data residency — then monitors and replaces them as they wear out. One flat price per domain. See how it works →