How to Set Up Email on a New Domain, in the Right Order

A new domain is a clean start, and that is exactly why its email setup is easy to get wrong. It feels safe to click through the setup screens in whatever order they appear. Then the first invoices land in spam, a contact form message never arrives, and nobody can say which DNS record is to blame. The fix is doing the steps in the right order, and checking each one before moving to the next.

Step 1: Find out where your DNS lives

Before you add a record, find out where you edit this domain's DNS. It is wherever the domain's nameservers point: your registrar, your web host, or a DNS service such as Cloudflare. Records added anywhere else have no effect, and this is the most common reason a correct record appears not to work. Check the nameservers, open the DNS editor in that one place, and stay there for the whole job.

Step 2: List every sender before you touch DNS

Write down everything that will send mail as your domain. Start with your mailbox provider, then add the quiet senders people forget: the contact form on your website, an invoicing app, a newsletter tool, and any app that sends password resets or order confirmations.

This list drives the rest. SPF, the record naming the servers allowed to send for your domain, must cover every sender on it. DKIM, the signature proving a message is genuine, must be switched on for each sender that supports it.

Step 3: Create the mailboxes, then verify the domain

Add your domain to your mailbox provider and create the mailboxes you need, including role addresses such as info@ and support@ if you plan to use them. The provider will ask you to prove you own the domain, usually by adding a TXT record it gives you. Add exactly that record, wait for DNS to catch up, and complete the verification in the provider's panel.

Do this before you point mail at the provider. If MX records switch over before a mailbox exists, incoming mail has nowhere to land.

Step 4: Point MX at your provider and check it

Add the MX records your provider gives you, with the priorities exactly as shown. Priority numbers decide which mail server is tried first, so copy them as well as the server names. Remove old MX records pointing somewhere else, unless your provider tells you to keep them as a backup.

Then check your work with the MX Record Checker. It shows the mail servers a stranger will find for your domain, and whether they resolve. If it still shows old values, you are probably looking at cached DNS. Wait and check again, rather than adding the records a second time in another panel.

Step 5: Publish one SPF record

SPF is a single TXT record on your root domain listing the servers allowed to send mail for you. Your provider will give you the value, often an include: line naming its sending servers. If another service on your list also sends mail, its include: entry goes into the same record, edited in, not added as a second record.

There must be exactly one SPF record. Two SPF records do not combine. Receivers treat the situation as an error and SPF fails. Every include: also costs a DNS lookup, and the standard caps the total at 10, so keep the list to services you actually use.

Step 6: Switch on DKIM for each sender

DKIM adds a digital signature to each outgoing message. The private key stays with the sender, and the matching public key is published in your DNS under a name called a selector, which your provider chooses. Switch DKIM on in each sending service and publish the record it gives you, copying it character for character.

Never copy a DKIM record from a tutorial or another account. The keys belong to your account and your selector, and a copied key will not match the signatures your provider produces.

Step 7: Add DMARC last, starting with monitoring only

DMARC tells receivers what to do with mail that claims to be from your domain but fails SPF or DKIM. It reads their results, so it only makes sense once they are in place. This step comes last.

Start with a monitoring policy, p=none, and a reporting address you control, in a TXT record at _dmarc on your domain. In this mode DMARC changes nothing about delivery. It only asks receivers to send reports showing who is sending as your domain and whether each sender passed. Read them for a few weeks.

Only when the reports show your legitimate mail passing cleanly should you tighten the policy, first to quarantine, which sends failing mail to spam, and later to reject, which refuses it outright. Jumping straight to reject on day one is how people block their own invoices.

Step 8: Test like a stranger would

Verify the setup from the outside. Run the SPF, DKIM and DMARC Checker on your domain and fix anything it flags. Then send a test message from your new mailbox to a personal address on a different provider, open it, and inspect the original message headers. You are looking for SPF, DKIM and DMARC each showing a pass.

If one fails, go back to the step that owns it. A DKIM failure is a key or selector problem, an SPF failure is a sender missing from the record, and a DMARC failure usually means the domain that passed does not match the domain in the visible From address. Also test the contact form and any automated mail on your list.

Step 9: Start sending gently

A new domain has no sending history, so receivers treat its first mail with extra caution. Begin with mail to people who expect it: replies, confirmations, and messages to contacts who know you. Do not launch with a bulk campaign to a bought or imported list. Keep the DMARC reports coming in, and check them whenever you add a new tool.

What to do first

Today, do Steps 1 to 3: find where your DNS lives, write down every sender, and create the mailboxes and verify the domain. Next, point MX at the provider, check it, and add SPF and DKIM from the exact values your providers give you. Add DMARC at p=none last, test with a real message, and let the reports guide you to quarantine and reject. Done in that order, a new domain's email is set up once, checked as you go, and easy to keep correct.