An email domain is the part of an email address after the @ sign, such as example.com in [email protected]. Email domains work through DNS (the Domain Name System): an MX record tells the world which servers accept mail for the domain, and three more records, SPF, DKIM and DMARC, tell receiving servers how to verify that mail claiming to come from the domain is genuine. The mailbox itself can live with any provider, but whoever controls the domain’s DNS controls where its email goes. That single fact explains how email domains work, why they break when DNS changes, and why the domain behind your email is one of the most valuable targets an attacker can take.
The Email Domain and the Email Provider Are Separate
An address on a free service such as Gmail or Outlook.com uses the provider’s domain, and the provider controls everything. An address on your own domain splits the job in two. The domain is registered at a registrar, and its DNS records are hosted by a DNS provider. The mailboxes are hosted by an email provider, such as Google Workspace, Microsoft 365, Zoho Mail, or the mail service bundled with a hosting plan. DNS records connect the two.
That separation is useful. You can change email providers without changing anyone’s address, because you only update the DNS records. It also means the domain registration and the DNS account sit upstream of every mailbox you own. If either one is lost, every address on the domain goes with it.
How a Message Reaches an Address on Your Domain
When someone sends a message to [email protected], the sender’s mail server first looks up the MX (mail exchanger) records for example.com. Each MX record names a mail server and a priority number; the sending server tries the lowest number first and falls back to the others if it cannot connect. If a domain publishes no MX record at all, the standard tells senders to try the domain’s own address instead, which is why a domain that should never receive mail is better off publishing a “null MX” record that says so explicitly.
Next, the sending server looks up the IP address of the chosen mail server and opens an SMTP (Simple Mail Transfer Protocol) connection, usually encrypted with TLS. Before accepting the message, the receiving server checks who sent it. It looks up the sending domain’s SPF record, verifies any DKIM signature, and applies the domain’s DMARC policy. A message that passes is delivered to the mailbox. A message that fails may be sent to spam, quarantined or rejected outright. The recipient then reads it through a mail app over IMAP or the provider’s web interface.
Every one of those steps depends on DNS lookups for the domain. Our guide to how DNS translates domain names walks through how those lookups resolve.
The DNS Records Behind Email on a Domain
| Record | Where it lives | What it does |
|---|---|---|
| MX | The domain itself | Names the servers that accept incoming mail, in priority order |
| SPF | A TXT record on the domain | Lists the servers allowed to send mail for the domain |
| DKIM | A TXT record at selector._domainkey | Publishes the public key used to check message signatures |
| DMARC | A TXT record at _dmarc | Tells receivers what to do when SPF and DKIM fail, and where to send reports |
MX Records Route Incoming Mail
MX records are the delivery address for the domain. Your email provider tells you what to publish; Microsoft 365 and Google Workspace each give you their own host names. The most common MX problem we see is a migration where the new provider is set up but the old MX records are left in place, so some mail continues to arrive at a system nobody checks.
SPF Lists Who May Send
SPF (Sender Policy Framework) is a TXT record that starts with v=spf1 and lists the servers and services allowed to send mail using your domain in the envelope sender address. It ends with a qualifier such as -all (reject anything not listed) or ~all (treat it as suspicious). A domain should publish only one SPF record, and the standard limits evaluation to ten DNS lookups, so a record that includes too many third-party services can fail for everyone. Marketing platforms, billing systems and help-desk tools all send mail on your behalf, and each one needs to be accounted for.
DKIM Signs Each Message
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. The sending service holds a private key; you publish the matching public key in DNS under a selector name, such as selector1._domainkey.example.com. The receiving server fetches the key and checks that the signature matches, which proves the message was sent by a system the domain authorized and was not altered in transit. Keys should be rotated periodically, and services you stop using should have their selectors removed.
DMARC Sets the Policy and Reports Back
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two together. It requires that a message pass SPF or DKIM using a domain that aligns with the visible From address, which is the part a person actually sees. The DMARC record also states a policy: p=none (monitor only), p=quarantine (treat failures as suspicious) or p=reject (refuse them). Receivers send aggregate reports to the address in the record, which show every service sending mail as your domain, legitimate or not.
DMARC has become a baseline expectation. CSC found that 71% of Forbes Global 2000 companies had adopted DMARC, up from 39% in 2020, according to the CSC 2024 Domain Security Report. Since 2024, Google and Yahoo have also required bulk senders to authenticate with SPF, DKIM and DMARC, so a domain without these records is more likely to have its mail filtered as spam.
Setting Up Email on Your Own Domain
Setting up email on a domain follows the same order with almost every provider. First, the provider asks you to prove you control the domain, usually by adding a TXT record it supplies. Then you add the MX records it specifies and remove any old ones. Next you publish an SPF record that includes the provider and every other service that sends mail for you, and turn on DKIM signing in the provider’s console, which gives you the public key to publish. Finally, you publish a DMARC record at p=none, read the reports for a few weeks to find every legitimate sender, and then move to quarantine and eventually to reject.
Domains that do not send email need protection too, because attackers spoof idle domains precisely because nobody watches them. For a domain that never sends or receives mail, publish a null MX record, an SPF record of v=spf1 -all, and a DMARC record at p=reject. That combination tells every receiver to refuse mail claiming to come from the domain. Our guide to nameservers and DNS records explains how to add and edit these entries.
Why the Email Domain Is a Theft Target
Control of an email domain is control of identity. Almost every online account, from banking and payroll to cloud storage and the registrar account itself, uses email for password resets. An attacker who changes your MX records, or who takes the domain and points it at their own mail server, receives those reset messages and can take over account after account. The domain is the master key, which is why stolen domain cases so often begin with, or lead to, a compromised mailbox.
Attackers have done exactly this at scale. In the January 2019 campaign described by Packet Clearing House at the ICANN DNS Symposium, a stolen registrar credential was used to change a domain’s nameserver records for one-hour windows; the attackers then obtained a certificate and used mail-proxying infrastructure to harvest credentials from government targets, according to Bill Woodcock’s briefing. Because the mail was proxied rather than blocked, users had little reason to suspect anything.
Email domains are also abused from the outside. Business email compromise (fraud in which a criminal impersonates an executive or vendor by email to redirect payments) accounted for 21,442 complaints and about $2.77 billion in reported losses in 2024, according to the FBI Internet Crime Complaint Center. Much of it relies on lookalike domains that differ from a real one by a character. CSC reported that 42% of third-party lookalike domains resembling major brands had MX records in 2024, meaning they were configured to send or receive email, according to the same CSC report.
Finally, an expired domain keeps receiving mail for whoever registers it next. Researchers who re-registered 201 expired domains for about $7.29 each received more than 650 million requests in four months from systems that still trusted the old names, according to Squarcina and colleagues at IEEE S&P 2022. Letting a domain that once carried email lapse hands its inbound mail, and the password resets attached to it, to a stranger, which is why domain expiration monitoring matters as much for email as for websites.
Mistakes We See in Email Domain Cases
In the cases we handle, three mistakes come up again and again. The first is a circular dependency: the registrar account’s login email is an address on the same domain. When the domain expires or is hijacked, that email stops working, and so does the only route to reset the registrar password. Use an address on a different domain for the registrar account, and protect the account with multi-factor authentication, as our guide to registrar account security explains.
The second is a former IT contractor or employee who still controls the DNS account, so nobody in the business can update records or notice changes. The third is an unmonitored domain, whether a parked brand name or an old company name, that has no SPF or DMARC record and is spoofed freely in phishing campaigns. Each of these is invisible until it fails, and then every mailbox on the domain fails at once.
How DNAccess Helps
We treat the email domain as critical infrastructure. Our DNShield domain name monitoring service watches your registration, nameservers and DNS records, including MX, and alerts you when they change, so a redirection of your mail is caught early. If an attacker has already taken the domain and with it your email, our stolen domain name recovery team works with registrars to restore control. The Domain Name Basics series explains the rest of the system in plain English.