What Is an Email Domain? And the Three DNS Records That Decide If Mail Arrives

An email domain is the part of an address after the @ symbol. In [email protected], the domain is example.com, and it tells the internet which mail servers are responsible for that address. What is far more consequential, and much less understood, is that three DNS records on that domain decide whether mail claiming to be from you actually reaches inboxes.

Those three records — SPF, DKIM, and DMARC — are the difference between mail that arrives and mail that lands in spam. They are also the difference between a domain anyone can forge and one they cannot. Both matter whether you send a hundred emails a month or a million.

Table of contents

• How mail finds your domain
• SPF: who is allowed to send
• DKIM: proving the message was not altered
• DMARC: the policy and the reporting
• Custom domain against a free address
• Checking what you have
• How this fits the rest of the stack
• FAQ

How mail finds your domain

When someone sends to [email protected], the sending server looks up the MX records for example.com. Those records name the servers that accept mail for the domain, with a priority number where lower is preferred.

dig +short MX example.com

That is the whole routing mechanism. No MX records means no mail delivery, and adding them is the entirety of pointing a domain at a mail provider.

Two things people conflate that are genuinely separate:

• Receiving mail is governed by MX records. They point at whoever hosts your mailboxes.
• Sending mail is governed by SPF, DKIM, and DMARC. They tell other servers which senders are legitimate.

A domain can receive mail through one provider and send through another entirely, which is extremely common — mailboxes with one service, transactional mail from an application through another. The records are independent.

SPF: who is allowed to send

SPF is a TXT record listing the servers permitted to send mail for your domain:

v=spf1 include:_spf.example-provider.com include:_spf.another.com -all

The receiving server checks whether the connecting server is in that list. If not, the mail fails SPF.

The ending matters more than the rest:

• -all — hard fail. Anything not listed should be rejected. This is what you want.
• ~all — soft fail. Suspicious but accept. A reasonable starting point while you confirm everything legitimate is listed.
• +all — allow anything. This makes the record worthless and is occasionally seen from misconfiguration.

The limit that catches people: SPF allows a maximum of ten DNS lookups. Each include: costs one, and includes can nest, so four or five providers can exceed the limit. When that happens the record fails entirely — a permanent error, not a partial one — and mail that would have passed starts failing. Check the count rather than assuming.

SPF also has a real weakness: it breaks on forwarding. When a message is forwarded, the forwarding server is not in your SPF record, so the check fails on mail that is entirely legitimate. This is one of the main reasons DKIM exists.

DKIM: proving the message was not altered

DKIM adds a cryptographic signature to outgoing mail. Your sending provider signs with a private key; the public key is published in DNS. The receiver verifies the signature, which proves two things: the message genuinely came from your domain, and it was not modified in transit.

The record lives at a selector-based hostname, so a domain can have several keys for several senders:

selector1._domainkey.example.com

You do not construct these by hand. Your provider generates the key pair and tells you the exact record to publish.

DKIM’s advantage over SPF is that it survives forwarding — the signature travels with the message rather than depending on the connecting server’s address. That makes it the more reliable of the two, and the reason both are worth having is that each covers the other’s gaps.

DMARC: the policy and the reporting

DMARC ties the other two together. It tells receivers what to do when SPF and DKIM fail, and asks them to send you reports about mail claiming to be from your domain.

v=DMARC1; p=none; rua=mailto:[email protected]

The policy has three values, and they are meant to be adopted in order:

• p=none — take no action, just report. This is where to start. It changes nothing about delivery and gives you visibility into what is being sent in your name.
• p=quarantine — send failing mail to spam.
• p=reject — refuse it outright. The end goal, and the one that actually prevents forgery.

The reason to start at none is that almost every organisation discovers legitimate senders it had forgotten — a newsletter tool, a support system, an internal script. Going straight to reject silently blocks them, and the failure is invisible because the mail is refused at the receiver.

The reports are the point of the exercise. They arrive as XML, they are tedious to read raw, and there are services that parse them. Two to four weeks at p=none usually surfaces everything, at which point moving to quarantine and then reject is safe.

There is also an alignment requirement worth knowing: DMARC passes only if SPF or DKIM passes and the passing domain matches the visible From address. A message can pass SPF for a provider’s own domain and still fail DMARC, which is why setups that seem correct sometimes fail.

Custom domain against a free address

Using a domain you own rather than a free provider’s has effects beyond appearance:

• You control the addresses. Staff changes, aliases, and forwarding are yours to manage.
• It is portable. Change providers and the addresses stay the same, because they belong to the domain.
• You can authenticate it. SPF, DKIM, and DMARC require control of the domain’s DNS. Sending as a free address from an application is not something you can authenticate, and it is increasingly rejected outright.
• Reputation accrues to you. Good sending practice builds your domain’s standing rather than a shared pool’s.

That third point has become decisive. Major providers now reject or heavily filter mail that uses a consumer address in the From field but was sent from an application server, because that is what forgery looks like. Any application sending mail needs a domain it controls.

Checking what you have

All three records are public and checkable in a few seconds:

dig +short TXT example.com | grep spf
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

The most useful test is the practical one: send a message to an address at a major provider, open the received message, and look at the authentication results header. It states plainly whether SPF, DKIM, and DMARC passed.

Three problems that show up most often:

1. Two SPF records on one domain. Only one is permitted; two is a permanent error. Merge them into a single record with multiple include: terms.
2. A missing DMARC record, which means no reporting and no policy — anyone can forge your domain and you will not know.
3. Records added but never verified. A DNS typo produces a record that looks present and does not work.

Publishing these once and never checking again is the common pattern, and it fails quietly when a provider changes its infrastructure or a new sending tool is added without updating SPF.

How this fits the rest of the stack

Email authentication is a good example of infrastructure where the failure is invisible from your side — the message sends, no error is returned, and it lands in a spam folder you never see. The records live in the same DNS as the rest of your domain configuration, alongside the ones pointing at your site. Custom domains and certificates on RunxBuild covers attaching a domain and having certificates handled, and if you are sizing what a site, an API, and a database cost together, the RunxBuild hosting calculator shows them as separate line items.

Useful related references:

• What Is a .link Domain, and When Does It Fit a Project?
• Multi-Domain SSL: SAN Certificates, Wildcards, and What to Use
• Math Domain Error Explained: Meaning and How to Debug
• Custom domains and certificates on RunxBuild

FAQ

What is an email domain?

The part of an email address after the @ symbol. It identifies which mail servers are responsible for that address, via the domain’s MX records, and it is the domain whose DNS records determine whether your outgoing mail is trusted.

What is the difference between MX records and SPF?

MX records control receiving — they name the servers that accept mail for your domain. SPF controls sending — it lists which servers are permitted to send mail claiming to be from your domain. They are independent.

Do I need all three of SPF, DKIM, and DMARC?

Yes. SPF breaks on forwarded mail while DKIM survives it, so each covers the other’s gaps. DMARC ties them together with a policy and, importantly, gives you reports on what is being sent in your name.

What DMARC policy should I start with?

p=none, which changes nothing about delivery but sends you reports. Almost every organisation finds forgotten legitimate senders this way. Move to quarantine and then reject after two to four weeks of clean reports.

Why does my SPF record stop working when I add a provider?

SPF permits a maximum of ten DNS lookups and each include: costs at least one. Exceeding the limit makes the whole record fail permanently, so previously passing mail starts failing. Count the lookups rather than assuming.