Using a free email address like [email protected] works fine for personal use, but for any business or professional project, a custom domain email such as [email protected] signals credibility and builds trust with clients, customers, and partners. Setting one up requires configuring several DNS records correctly, and a single typo can mean lost emails or deliverability problems.
This guide walks you through the complete process of setting up custom domain email with the two most popular providers -- Google Workspace and Microsoft 365 -- including MX records, SPF, DKIM, and DMARC configuration.
Why You Need a Custom Domain Email Address
Before diving into the technical setup, it is worth understanding why a custom domain email matters. Beyond the professional appearance, there are practical advantages that directly affect your business operations.
Brand consistency is the most obvious benefit. Every email you send reinforces your domain name and brand identity. Recipients see [email protected] rather than a generic provider address, which builds immediate recognition.
Email deliverability improves significantly with properly authenticated custom domain email. When you configure SPF, DKIM, and DMARC records (which I will cover below), email providers can verify that messages genuinely come from your domain. This reduces the chance of your emails landing in spam folders.
Administrative control gives you the ability to create and manage email addresses for your entire team, set up distribution lists, configure email routing, and enforce security policies -- all under your own domain.
Portability means your email address stays the same even if you switch hosting providers. Your domain is yours, and the email addresses tied to it move with you.
Setting Up MX Records for Google Workspace
MX (Mail Exchanger) records tell the internet which mail servers handle email for your domain. When someone sends an email to [email protected], the sending server looks up your domain's MX records to figure out where to deliver the message.
Step 1: Verify Domain Ownership
Google Workspace requires you to prove you own your domain before you can configure email. Google provides several verification methods, but the most common is adding a TXT record to your DNS:
yourdomain.com. IN TXT "google-site-verification=UNIQUE_STRING_FROM_GOOGLE"
Log in to your domain registrar or DNS provider, navigate to DNS management, and add this TXT record. The exact value will be provided in your Google Workspace admin console under Setup > Verify domain.
Step 2: Add Google Workspace MX Records
Once verified, replace any existing MX records with the following Google Workspace mail servers:
yourdomain.com. IN MX 1 ASPMX.L.GOOGLE.COM.
yourdomain.com. IN MX 5 ALT1.ASPMX.L.GOOGLE.COM.
yourdomain.com. IN MX 5 ALT2.ASPMX.L.GOOGLE.COM.
yourdomain.com. IN MX 10 ALT3.ASPMX.L.GOOGLE.COM.
yourdomain.com. IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.
The numbers (1, 5, 10) represent priority values. Lower numbers indicate higher priority. Email senders will attempt the priority-1 server first, then fall back to the others if it is unavailable.
Important: Remove any pre-existing MX records that point to other mail servers (such as your hosting provider's default mail server). Leaving old MX records in place can cause unpredictable email routing where some messages go to the wrong server.
Step 3: Configure SPF for Google Workspace
SPF (Sender Policy Framework) tells receiving mail servers which servers are authorized to send email on behalf of your domain. Add this TXT record:
yourdomain.com. IN TXT "v=spf1 include:_spf.google.com ~all"
If you also send email through other services (such as a marketing platform or transactional email provider), include them in the same SPF record:
yourdomain.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
Critical rule: You can only have one SPF record per domain. Multiple SPF TXT records will cause validation failures. Combine all your authorized senders into a single record. After publishing, validate your SPF record to catch syntax errors and DNS lookup limit violations before they affect deliverability.
Step 4: Set Up DKIM for Google Workspace
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails, allowing recipients to verify that the message was not tampered with in transit.
In the Google Workspace Admin console, navigate to Apps > Google Workspace > Gmail > Authenticate email. Google will generate a DKIM key for you. Add it as a TXT record:
google._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=YOUR_LONG_PUBLIC_KEY_STRING"
The selector is typically google for Google Workspace. After adding the record, return to the admin console and click Start authentication. It may take up to 48 hours for the record to propagate and for Google to begin signing outgoing emails. Use the DKIM record checker to confirm the public key is published correctly at the expected selector subdomain.
Step 5: Publish a DMARC Policy
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do with messages that fail authentication. Start with a monitoring-only policy:
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
This p=none policy will not reject any email but will send you reports about authentication results. After monitoring for a few weeks and confirming everything works correctly, you can tighten the policy:
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"
Eventually, move to p=reject for maximum protection against email spoofing.
Setting Up MX Records for Microsoft 365
The process for Microsoft 365 is similar in concept but uses different record values and includes a few additional DNS records.
Step 1: Verify Domain Ownership
Microsoft 365 also requires domain verification. In the Microsoft 365 admin center, go to Settings > Domains > Add domain. Microsoft typically provides a TXT record for verification:
yourdomain.com. IN TXT "MS=ms12345678"
Add this record to your DNS, then click Verify in the admin center.
Step 2: Add Microsoft 365 MX Records
Microsoft provides a single MX record that routes through their Exchange Online infrastructure:
yourdomain.com. IN MX 0 yourdomain-com.mail.protection.outlook.com.
Note that the MX target hostname replaces dots in your domain name with dashes. For example, if your domain is example.co.uk, the MX target would be example-co-uk.mail.protection.outlook.com.
Microsoft also requires an Autodiscover CNAME record for Outlook client configuration:
autodiscover.yourdomain.com. IN CNAME autodiscover.outlook.com.
Step 3: Configure SPF for Microsoft 365
Add the following SPF record:
yourdomain.com. IN TXT "v=spf1 include:spf.protection.outlook.com ~all"
As with Google Workspace, combine this with any other authorized senders in a single SPF record if needed.
Step 4: Set Up DKIM for Microsoft 365
In the Microsoft 365 Defender portal, navigate to Email & collaboration > Policies & rules > Threat policies > DKIM. Select your domain and enable DKIM signing. Microsoft will prompt you to create two CNAME records:
selector1._domainkey.yourdomain.com. IN CNAME selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com.
selector2._domainkey.yourdomain.com. IN CNAME selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com.
These CNAME records point to Microsoft-hosted DKIM keys, which allows Microsoft to rotate the keys automatically without requiring you to update DNS records manually.
Step 5: Publish a DMARC Policy
The DMARC setup is identical regardless of your email provider:
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Follow the same gradual enforcement strategy described in the Google Workspace section above. You can check your DMARC policy at any stage to verify the record syntax and confirm reporting addresses are working.
Verifying Your DNS Records with DNS Checker
After adding all these records, you need to verify that they are correctly configured and have propagated across the internet. Misconfigurations are extremely common, and a missing or malformed record can silently break email delivery.
Use the DNS Checker DNS Inspector to look up each record type for your domain:
-
Check MX records: Verify your MX records to confirm the correct mail server hostnames appear with the right priority values. For Google Workspace, you should see all five ASPMX entries. For Microsoft 365, you should see the
mail.protection.outlook.comhostname. -
Check TXT records: Look up TXT records to verify your SPF record, domain verification TXT record, and DKIM keys. Make sure there is exactly one SPF record (starting with
v=spf1). -
Check CNAME records: If you are using Microsoft 365, verify the Autodiscover and DKIM CNAME records resolve correctly.
For a global view of propagation, use the DNS Checker Propagation Checker to see whether your MX and TXT records have propagated to DNS servers around the world. This is especially useful if you have recently made changes and want to confirm they have reached all major regions before switching your mail flow.
Common Mistakes and How to Fix Them
Even experienced administrators make mistakes when configuring email DNS records. Here are the most frequent issues and their solutions.
Multiple SPF records: This is the single most common mistake. If you have two TXT records that both start with v=spf1, SPF validation will fail entirely. Merge all your authorized senders into one record.
Wrong MX priority values: Swapping priority numbers or using the same priority for all records can cause uneven load distribution or delivery delays. Follow the exact priority values provided by your email provider.
Missing trailing dot in record values: Some DNS providers require a trailing dot after hostnames (e.g., ASPMX.L.GOOGLE.COM.), while others add it automatically. If your MX records are not resolving, check whether your provider needs the trailing dot.
Forgetting to remove old MX records: If your domain previously used a different email service, leftover MX records can intercept some of your email. Always remove old MX records before adding new ones.
DKIM key truncation: DKIM public keys are long strings, and some DNS providers have character limits on TXT record values. If your DKIM key is being truncated, you may need to split it across multiple strings within the same TXT record. Most providers handle this automatically, but check the raw record value to be sure.
Not waiting for propagation: DNS changes can take up to 48 hours to propagate globally, though most complete within a few hours. Use the DNS Checker Propagation Checker to monitor progress instead of guessing.
Key Takeaways
- Custom domain email requires configuring MX records to point to your email provider (Google Workspace or Microsoft 365), plus SPF, DKIM, and DMARC records for authentication.
- Google Workspace uses five MX records with different priorities, while Microsoft 365 uses a single MX record plus additional CNAME records for Autodiscover and DKIM.
- You must have exactly one SPF TXT record per domain. Combine all authorized senders into a single record.
- Start DMARC with a
p=nonemonitoring policy, then gradually tighten top=quarantineand eventuallyp=rejectonce you have confirmed all legitimate email passes authentication. - Always verify your DNS records using a tool like the DNS Checker DNS Inspector after making changes, and monitor global propagation with the Propagation Checker.
- Remove old MX records before adding new ones to prevent email routing conflicts.
Frequently Asked Questions
Setting up custom domain email is one of the most impactful DNS configurations you will make. Take the time to get every record right, verify with DNS Checker's DNS Inspector, and monitor propagation with the Propagation Checker. Once everything is configured, test your email setup end-to-end to confirm that messages pass all authentication checks and reach the inbox reliably from day one.