Setting Up Email for a Domain

Getting mail to arrive is easy. Getting it to arrive in the inbox takes five records and a little patience. The five are MX (where mail for your domain goes), SPF (who may send as you), DKIM (a signature on each message), DMARC (what receivers should do when the first two fail) and, if you run your own server, a matching PTR record.

Since the large mailbox providers began enforcing authentication for bulk senders, a domain with missing or broken records does not just land in spam occasionally. Messages are deferred or refused. The good news is that the work is a one-off. Do it in the right order, test it, and then leave it alone.

This guide follows that order, with the records written out using example.com and documentation addresses so you can see the shape of each one. Substitute the values your provider gives you; never copy the examples blindly.

1. Decide where mail lives

You can use mailboxes from your web host, or a dedicated provider such as Google Workspace, Microsoft 365 or a specialist mail host. Hosting mailboxes are cheap and fine for low volume. Dedicated providers cost more and typically offer better deliverability, shared calendars and support.

The choice sets everything that follows. SPF and DKIM values come from whoever actually sends the mail, so settle this first and then read your provider's setup page for exact values.

2. Point MX records

Add the MX records your provider specifies, and remove old ones. Mixed records from two providers will split your mail between them, and half of it will vanish into a mailbox nobody reads. Lower numbers have higher priority.

example.com.   3600  IN  MX  10 mx1.mail-provider.example.
example.com.   3600  IN  MX  20 mx2.mail-provider.example.

An MX target must be a hostname with an address record, never a bare IP and never a CNAME. If you are moving mail between providers, lower the TTL on the MX records a day ahead (the TTL planner helps), switch, then raise it again.

3. Publish SPF

Create a single TXT record starting with v=spf1 that includes every service allowed to send as your domain, ending with ~all or -all. Stay under ten DNS lookups.

example.com.  3600  IN  TXT  "v=spf1 mx include:_spf.mail-provider.example ip4:203.0.113.25 ~all"

Reading it left to right: the domain's own MX hosts may send, the provider's published list may send, one fixed address may send, and everything else is a soft fail. Use -all (hard fail) once you are certain the list is complete. The SPF builder assembles the record and counts lookups.

Two mistakes cause most SPF trouble. First, having two SPF records. A domain must publish exactly one, and receivers treat two as an error (permerror). Merge them. Second, exceeding the ten-lookup limit. Every include, a, mx and redirect costs a lookup, and includes nest, so five marketing tools can break it. Remove services you no longer use.

4. Publish DKIM

Your provider generates a key pair and gives you a TXT or CNAME record to publish. Once it is live, switch on signing in the provider's admin console. The record name contains a selector chosen by the provider:

sel1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(long public key)..."

Public keys are long. A 2048-bit key exceeds the 255-character limit of a single string in a TXT record, so many DNS editors split it automatically into several quoted strings; some need you to do it. If your provider gave a CNAME instead, publish exactly that and they will keep the key rotated for you.

If you send from several services, each has its own selector and its own record. One selector per sender keeps rotation simple.

5. Publish DMARC

Start with a record that watches and does not yet enforce:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The reports will show who sends mail as your domain: your own servers, your newsletter service, a forgotten billing system, and the occasional forger. After a few weeks of clean reports, move to p=quarantine and eventually p=reject. A staged approach is slower, but it prevents you blocking your own invoices. The DMARC builder writes the record for each stage.

DMARC passes when SPF or DKIM passes and the domain it authenticated matches the visible From address. This alignment is what trips up third-party senders: a newsletter tool may pass SPF for its own domain, which does not help you. Give each such service a DKIM key for your domain.

6. Check reverse DNS and reputation

If you run your own mail server, make sure the sending IP has a matching PTR record and is not on a blocklist. The PTR name should resolve forward to the same address, and the server's greeting should use that name. Ask your hosting company to set the PTR; you cannot do it in your own zone. Many providers also refuse to let a new IP send directly on port 25, so check that first.

If you use a provider, this is their job. Your part is to stay inside their limits and to avoid sending mailing lists you cannot prove people asked for.

7. Test it

Send a message to a few different providers and an email-testing service. Look at the full headers for SPF, DKIM and DMARC results. Fix what shows as failed or neutral. In the raw message, search for Authentication-Results:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com header.s=sel1;
  dmarc=pass header.from=example.com

Three passes with matching domains is what you are aiming for. Check from the command line too:

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT sel1._domainkey.example.com

If a record looks right in your control panel but dig shows nothing, the zone is being served from somewhere else. See How DNS Works for how to find the authoritative servers.

Sending from your website

Avoid the web server's default mail function. Use authenticated SMTP or a transactional email service, so messages are signed and traceable. It makes forms, password resets and order confirmations far more reliable. Use a real mailbox on your own domain as the sender, submit on port 587 with STARTTLS (or 465 with implicit TLS), and add that service to SPF and DKIM.

A worked example

A two-person design studio moves from the mailboxes that came with its web hosting to a dedicated provider, and also sends a monthly newsletter through a third-party tool. Here is the order they work in.

1. They list every system that sends as the domain: the new mail provider, the newsletter tool, and the contact form on the website. Three senders.
2. A day before the move they lower the TTL on the MX records to 300 seconds.
3. They publish the new provider's DKIM record and the newsletter tool's DKIM record, and switch on signing in both consoles. Nothing changes for recipients yet.
4. They replace the SPF record with one that includes both services and the website's SMTP relay, checking the lookup count.
5. They publish DMARC at p=none, pointing reports at a shared mailbox.
6. They swap the MX records, send test messages from every mailbox, and read the headers.
7. After three weeks of reports they find an old invoicing system sending as the domain. They add it to SPF, set up its DKIM, and wait another two weeks before moving to quarantine.

The old mailboxes stay alive for a fortnight, and they copy old mail across with the provider's import tool, so nothing is lost if a late message reaches the old server.

Common mistakes

• Two SPF records, because a second service said "add this" and nobody merged them.
• An SPF record that ends in +all or has no ending, which authorises the entire internet.
• DKIM published but never switched on in the provider's console, so messages carry no signature.
• A DMARC record at p=reject before the newsletter tool was aligned, followed by a week of undelivered newsletters.
• Reports sent to a mailbox on the same domain that is itself failing, so nobody sees them.
• Old MX records left behind, so some mail goes to a mailbox nobody checks.

The checklist

• Provider chosen, and the old provider's MX records removed.
• One SPF record, within ten lookups, listing every sender.
• DKIM published for each sending service, and signing switched on.
• DMARC started at none, with a mailbox that actually reads the reports.
• PTR set for any server you run yourself.
• Website mail goes through authenticated SMTP.
• Headers read on a test message: spf, dkim and dmarc all pass.
• Policy raised to quarantine and then reject when the reports are clean.