How do you set up email on a new business domain?

A new domain is a clean slate. Nothing is configured and it has no sending history. Until you publish SPF, DKIM and DMARC, receivers have no reliable way to tell your real mail from a forgery. Setting up email properly from day one is far easier than untangling a half-configured domain later.

This checklist covers every DNS record a business domain needs for email, in the order to add them, with optional extras at the end. If the terms are new to you, skim SPF vs DKIM vs DMARC first.

What is the full checklist?

The rest of this guide takes each step in turn.

Step 1 and 2: Where do you start?

Pick your mailbox provider (Microsoft 365, Google Workspace or another) and add the domain there first. The provider gives you the exact MX, SPF and DKIM values for your tenant, and usually asks you to prove ownership with a TXT record.

Then find where your DNS is hosted. It's often your registrar, but not always. Our MX Lookup shows the live nameservers. We have step-by-step guides for adding records at Cloudflare, GoDaddy and Namecheap.

Step 3: How do you set up MX records?

MX records tell the world where to deliver your mail. Add exactly what your provider specifies. Google Workspace, for example, now uses a single MX record, smtp.google.com with priority 1, and says it can take up to 72 hours for new MX records to start working (Google Workspace Admin Help).

• Remove any default MX records your registrar added, such as ones pointing to its own mail or forwarding service, unless your provider says to keep them.
• Point MX at a hostname, never an IP address.
• If you plan to filter inbound mail through a gateway, your MX will point to the filtering service instead, which then delivers to your mailboxes.

Our guide to what an MX record is explains priorities and backup MX.

Step 4: How do you set up SPF?

SPF lists the servers allowed to send mail as your domain. Publish one TXT record at your bare domain. RFC 7208 says a domain "MUST NOT have multiple records" that an SPF check would select.

Start with your mailbox provider's include, then add every other service that sends as your domain: website forms, invoicing, CRM, newsletters, help desk. A typical new Microsoft 365 domain starts with:

v=spf1 include:spf.protection.outlook.com -all

Microsoft documents this value for domains on Microsoft 365 (Microsoft Learn). Our SPF provider pages list the include for each common service, and the SPF Record Generator merges them and counts DNS lookups, which must stay at 10 or fewer. See SPF softfail vs hardfail to choose between ~all and -all.

Step 5: How do you set up DKIM?

DKIM signs each message so receivers can check it came from your domain unaltered. Each service that sends for you needs its own DKIM key on your domain:

• Microsoft 365: publish two CNAME records (selector1._domainkey and selector2._domainkey), then turn on signing in the Defender portal (Microsoft Learn).
• Google Workspace: generate a key in the Admin console, publish it as a TXT record at google._domainkey, then select Start authentication. Choose a 2048-bit key if your DNS host supports it.
• Other senders: each has its own selector and record. Our DKIM records by provider pages list them.

Our DKIM setup guide for Microsoft 365 and Google Workspace has the full steps. Check each key with the DKIM Checker.

Step 6: How do you start DMARC on a new domain?

DMARC ties SPF and DKIM to the address people see in the From line, tells receivers what to do with failures, and sends you reports. Google recommends you "Set up DKIM and SPF at least 48 hours before setting up DMARC," then start with a policy of none for about a week while you read the daily reports (Google Workspace Admin Help).

A first record, published as TXT at _dmarc:

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

Use a reporting mailbox you will actually read, or a report service. The DMARC Record Generator builds the record, and DMARC record examples explains every tag.

Step 7: Do you need reverse DNS?

Only if you run your own mail server. Google requires that "sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records" (Gmail Help). Hosted providers manage this for their own IPs. For a self-hosted server, ask whoever owns the IP address, usually your hosting company, to set a PTR record whose hostname resolves back to that IP. Check it with our PTR Lookup, and see reverse DNS for mail servers.

Step 8: How do you test the setup?

1. Run the Email Health Check for an overview of MX, SPF, DKIM and DMARC.
2. Send a message from each sending service through our Email Deliverability Test and confirm SPF, DKIM and DMARC pass.
3. Send mail in from an outside account to confirm delivery works.
4. Add your domain to Google Postmaster Tools so you can see Gmail's view as you start sending.

Step 9: When should DMARC move to enforcement?

Once your reports show every legitimate sender passing. Google's rollout moves from none to quarantine for a growing share of messages, then to reject, reviewing reports daily, and warns that with reject, failing messages "are rejected by receiving servers and never delivered" (Google Workspace Admin Help).

A new domain has an advantage here: there are no forgotten legacy senders. Many established sites never get this far. In our scan of the top 1,000 websites, 38.3% of domains don't enforce DMARC. Our none-to-reject guide covers each stage, including how DMARC test mode replaced percentage rollouts in the current standard.

Step 10: Should you add MTA-STS and TLS-RPT?

They're optional, and worth doing once the basics are stable. MTA-STS (RFC 8461) tells sending servers to deliver to your MX hosts only over TLS with valid certificates. It needs a TXT record at _mta-sts and a policy file served over HTTPS at mta-sts.yourdomain. TLS-RPT adds a TXT record at _smtp._tls so senders report TLS failures to you.

Start the policy in testing mode, read the reports, then switch to enforce. Our MTA-STS and TLS-RPT guide has the record formats, and the MTA-STS Checker validates them.

Step 11: Is BIMI worth it for a new domain?

BIMI shows your logo next to your mail in supporting inboxes. Google's requirements are strict: a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC), and a DMARC policy of quarantine or reject, because "BIMI doesn't support DMARC policies that have the p option set to none" (Google Workspace Admin Help). Google notes that getting a logo trademarked for a VMC can take 6 to 12 months. For most new domains, BIMI is a later project. See BIMI explained.

Step 12: How do you warm up a new domain?

A new domain has no reputation, good or bad. Google's guidance is to "Start with a low sending volume to engaged users, and slowly increase the volume over time," to avoid "sudden volume spikes," and to monitor delivery with Postmaster Tools as you grow (Gmail Help). Everyday one-to-one business mail needs no special plan. Newsletters and bulk sends do; see our warm-up guide.

What about domains you don't use for email?

If you registered extra domains, such as misspellings or other country endings, that will never send mail, lock them down too. Publish an SPF record of v=spf1 -all and a DMARC record with p=reject. Our guide to protecting parked domains has the full set of records.

Next steps

1. Run the Email Health Check on your new domain now, and again after each step.
2. Build your records with the SPF Record Generator and DMARC Record Generator.
3. Confirm each DKIM key with the DKIM Checker.
4. Put a reminder in your calendar to review DMARC reports and move toward enforcement.

If you want inbound spam and phishing filtered before it reaches your new mailboxes, a domain-level filter such as iBlockSpam is added with an MX change; see how it works. More guides are in setup guides.

Once everything is published, the Free Domain Watch can keep an eye on it: weekly checks of your public MX, SPF, DMARC and MTA-STS records, with an email when anything changes.