Five ways to get a custom domain for business email

A custom email domain - mail that arrives and sends as @yourcompany.com instead of a provider's own domain - comes down to five practical routes. They differ in cost, setup effort, and how much of the DNS configuration is done for you, but every one of them still needs SPF, DKIM and DMARC set up by hand at some point.

The five routes, compared

What's common to all five

Regardless of route, four DNS record types decide whether mail from the domain actually works:

• MX - where inbound mail to the domain is delivered. This is the only one of the four that differs if you choose forwarding versus real mailbox hosting.
• SPF - which servers are authorized to send as the domain.
• DKIM - the cryptographic signature proving mail wasn't altered in transit.
• DMARC - what receivers should do when SPF or DKIM fail, and where to send reports.

Steps for each route

Google Workspace / Microsoft 365: verify domain ownership (a TXT record the provider gives you), the provider auto-generates SPF and DKIM values to paste into DNS, then you publish DMARC yourself - neither platform does this by default despite walking you through the first two.

Registrar + standalone hosting: point MX at the hosting provider, get the SPF/DKIM values from their mail panel, publish DMARC yourself. Expect to do more of this manually than with the larger platforms, with less guided documentation.

Forwarding only: set MX to forward to your existing inbox, and - this is the step people skip - add the forwarding service's sending servers to SPF if you ever reply "from" the custom address, since otherwise your replies fail authentication even though receiving works fine.

Budget providers: setup quality varies widely; check their documentation specifically mentions DMARC, not just SPF and DKIM, before committing.

A worked example: a complete record set

For a domain yourcompany.com hosted through a standard business email provider, a working set looks like:

yourcompany.com.         MX   10 mail.yourprovider.com.
yourcompany.com.         TXT  "v=spf1 include:_spf.yourprovider.com ~all"
selector1._domainkey.yourcompany.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."
_dmarc.yourcompany.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com"

The failure mode each route hits most often

Google Workspace / Microsoft 365: the domain-verification TXT record gets published, SPF and DKIM get pasted in, and the admin stops there because the console shows a green checkmark on "domain verified" - which only confirms ownership, not that mail will authenticate. DMARC has to be added as a separate TXT record that neither console prompts for. A domain running this way for months typically shows p=none or no DMARC record at all, which means SPF/DKIM failures are silently ignored rather than reported or enforced.

Registrar + standalone hosting: the MX record gets pointed correctly (mail arrives, so the setup "looks done"), but the SPF record is copied from a generic template that lists only the hosting provider's own servers - not any third-party tool (a CRM, a helpdesk, a marketing platform) that also sends as the domain. The result is intermittent authentication failures that only show up for mail sent through the second tool, which makes the problem look random until someone checks SPF against every actual sending source rather than just the primary one.

Forwarding-only: this is the route with the most specific trap. Receiving works immediately because MX is correctly configured. But six months later someone replies to a customer "from" the forwarded address through the forwarding provider's own send-as feature, and that reply fails SPF because the forwarding service was never added as an authorized sender - it only needed authorization to receive and relay, not to originate replies.

Checking a route before committing to it

Before signing up for any provider, ask support directly: "do you publish a DKIM record automatically, and do you provide DMARC setup instructions, or only SPF?" A provider whose documentation stops at SPF is signaling that DMARC will be left to you - not a dealbreaker, but worth knowing before, not after, the first month of mail.

What not to do

• Don't assume MX alone means outbound mail works - MX only governs receiving.
• Don't skip DMARC because the setup wizard didn't ask for it - none of the major providers configure it automatically.
• Don't choose forwarding-only and then start sending marketing campaigns "from" that address without adding the real sending source to SPF - the campaign mail will fail authentication even though test replies from your personal inbox might pass.
• Don't let a domain sit unverified for weeks after purchase - an unauthenticated domain that starts sending abruptly, even legitimately, reads like a new risk to mailbox providers.

Once a domain is registered and the MX/SPF/DKIM/DMARC records are live, MailPilot checks them against what's actually published, warms the mailbox over OAuth or SMTP/IMAP, and tracks reputation daily from the first send - useful for catching a half-finished setup (SPF live, DKIM not yet signing) before it costs you placement.