How a domain becomes an email address

The parts of an email address

Everything after the @ is a domain name. Everything before it is the mailbox name, which only the receiving email provider cares about. The domain decides where the mail goes; the mailbox name decides who gets it once it arrives.

How an email travels

1. You press send. Your email app hands the message to your provider's mail server over SMTP, signing in first.
2. Your provider looks up the MX records of the recipient's domain, the part after the @, to find their mail server.
3. It delivers the message to that server, also over SMTP, normally encrypted with TLS.
4. The receiving server checks the sender: does the sending server appear in the domain's SPF record, does the DKIM signature match, and what does its DMARC policy say? Then it files the message in the inbox, in spam, or rejects it.
5. The recipient's app fetches it over IMAP (or the provider's own app and API).

MX records: where your mail goes

An MX record says "mail for this domain goes to this server", with a priority number. Senders try the lowest number first and fall back to higher ones:

Your email provider gives you these values. An MX record must point at a hostname, never an IP address or a CNAME. A domain with no MX record at all gets mail at the address in its A record, which rarely runs a mail server, so set MX records even if you only forward.

Mailbox or forwarding?

A catch-all delivers mail for any address at your domain, even ones you never set up. It is handy for spotting who shared your address, and also catches a lot of spam.

SPF: who may send as your domain

SMTP lets any server claim to send mail from any domain, which is how spam and phishing began. SPF (Sender Policy Framework) fixes part of that: a TXT record on your domain that lists the servers allowed to send its mail.

v=spf1 include:_spf.mail-provider.example include:newsletter.example ~all

• Each include: adds a service that sends for you: your mailbox provider, newsletter tool, invoicing app.
• ~all means mail from anywhere else is suspicious; -all means reject it.
• Keep exactly one SPF record per name, and no more than 10 lookups inside it.

Build and check one in the SPF guide.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The receiving server fetches your public key from DNS, at a name like selector1._domainkey.example.com, and checks the signature. If it matches, the message really came from a server holding your private key and wasn't altered on the way.

You don't make keys yourself: each sending service gives you a TXT or CNAME record to add, with its own selector, so several services can sign for you at once. Details in the DKIM guide.

DMARC: what to do with fakes

DMARC ties SPF and DKIM to the address people actually see in the From line, and tells receivers what to do when a message fails: deliver it anyway, send it to spam, or reject it. It is a TXT record at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

• p=none only collects reports, which arrive daily from the big providers and show every service sending as your domain.
• Once everything legitimate passes, move to p=quarantine (spam folder), then p=reject (blocked).

Policy options and a builder are in the DMARC guide.

A complete setup, record by record

A typical domain with one email provider and one newsletter tool:

Optional extras: MTA-STS and TLS-RPT require encrypted delivery and report problems, and BIMI shows your logo next to your messages in some inboxes. Check any domain's email setup with the free email checker.

Protecting domains that don't send email

Domains you hold but don't use for email can still be faked in the From line. Three records tell the world they never send or receive mail:

The MX record with a single dot is a "null MX": it tells senders straight away that the domain accepts no mail.

When email goes wrong

Next: the protocols behind all of this, in the protocols guide.