Email on Your Own Domain: MX, SPF, DKIM and DMARC Explained

An email address like [email protected] looks more professional than a free webmail address, and it ties every message you send to your brand. It also means your address stays yours even if you change email providers, because you control the domain.

Setting it up involves a few entries in your domain's DNS, which works like the internet's address book. The names of those entries, MX, SPF, DKIM and DMARC, sound intimidating, but each has a simple job. Getting them right affects whether your messages land in the inbox, the spam folder, or nowhere at all.

This guide explains what each piece does in plain English. Your email provider will give you the exact values to enter; the goal here is to understand what you are setting up and why it matters.

The pieces you need

To use email on your own domain, you need two things: the domain itself, registered through a domain registrar, and an email hosting service that actually stores and sends your mail. Business plans from providers such as Google Workspace or Microsoft 365 are common choices, and many web hosts include email as well.

You then add DNS records wherever your domain's DNS is managed, which might be your registrar, your web host or a separate DNS service. Those records tell the rest of the internet where to deliver your mail and how to check that messages claiming to come from you are genuine.

MX records: where your mail goes

An MX (mail exchanger) record tells other mail servers where to deliver email addressed to your domain. When someone writes to [email protected], their mail server looks up the MX records for yourbusiness.com and hands the message to the server listed there.

You can have several MX records, each with a priority number. Servers with lower numbers are tried first, and the others act as backups. If your MX records point to the wrong place, incoming email won't arrive, which is why switching email providers needs careful planning.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a published list of the servers allowed to send email for your domain, stored as a single text record in your DNS. When a receiving server gets a message claiming to be from your domain, it can check whether the sending server is on your list.

A few practical points:

• Your domain should have only one SPF record. If several services send mail for you, such as your email provider, a newsletter tool and an invoicing system, they all need to be included in that one record.
• The SPF standard limits a check to ten DNS lookups, so a record that includes too many services can stop working.
• Forgetting to include a service is a common reason its messages end up in spam.

DKIM: a tamper-evident signature

DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing message. Your email provider signs messages using a private key that it keeps secret, and you publish the matching public key in your DNS. Receiving servers use that public key to confirm that the message was signed on behalf of your domain and wasn't altered in transit.

Your provider generates the keys and tells you which record to add. Each service that sends email on your behalf typically needs its own DKIM setup.

DMARC: the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It lets you tell receiving servers what to do when a message claiming to be from your domain fails those checks, and it asks them to send you reports about what they see. It also checks alignment, meaning whether the domain that passed SPF or DKIM matches the domain in the visible From address. That is what stops a scammer from passing checks with their own domain while displaying yours.

A DMARC record sets one of three policies:

• none: take no special action, just report. This is the usual starting point.
• quarantine: treat failing messages as suspicious, typically by sending them to spam.
• reject: refuse failing messages outright.

Google's setup advice is to start with none, review the reports to confirm that all your legitimate mail is passing, and then move gradually to stricter policies. Reports can be frequent and technical, so it helps to send them to a dedicated mailbox or a reporting service.

The DMARC specification itself was updated in 2026, when the IETF, the body that develops internet standards, published RFC 9989 as a standards-track replacement for the original 2015 document. The core ideas described here carry over.

Why deliverability matters

Deliverability is whether your email actually reaches the inbox. For a business, a quote, invoice or appointment confirmation that lands in spam can mean a lost customer, and you may never find out it happened.

Large mailbox providers have tightened their rules in recent years. Google's sender guidelines, in force since February 2024, require everyone sending to personal Gmail accounts to set up SPF or DKIM, and require senders of more than 5,000 messages a day to use SPF, DKIM and DMARC. Microsoft introduced similar requirements in 2025 for high-volume senders to Outlook.com, Hotmail and Live addresses. Even if you send far fewer messages, setting up all three is widely recommended, and it makes it harder for criminals to send convincing fake emails in your name.

A simple setup checklist

1. Choose an email host and add the MX records it provides.
2. Create one SPF record that includes every service that sends mail for you.
3. Turn on DKIM in each sending service and publish its records.
4. Add a DMARC record with a policy of none and an address to receive reports.
5. Send test messages to a few different email providers and confirm they arrive.
6. Review your DMARC reports, then tighten the policy once you're confident.

Keep a list of every service that sends email using your domain. Whenever you add a new one, such as an online booking system, remember to update SPF and DKIM.

Key takeaways

• Email on your own domain looks professional and stays under your control.
• MX records say where incoming mail goes; SPF lists who may send; DKIM signs messages; DMARC sets the policy and sends you reports.
• Use a single SPF record that covers every service sending on your behalf.
• Start DMARC at none, watch the reports, then tighten gradually.
• Major providers such as Gmail and Outlook now require authentication, especially from bulk senders.

Sources

• Google Workspace Admin Help, Email sender guidelines
• Google Workspace Admin Help, Set up DMARC
• Microsoft Tech Community, Outlook's new requirements for high-volume senders
• RFC 7208, Sender Policy Framework (SPF)
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
• RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC)