Custom Domain Email and DNS Done Right: SPF, DKIM, and DMARC

Posted on: July 11, 2026
Custom domain email DNS records: MX, SPF, DKIM, and DMARC

You bought a domain. You want email that reads hello@yourcompany.com instead of a free Gmail or Yahoo address. Good. It looks professional, it builds trust, and it keeps your business identity in your own hands.

But there is a catch nobody warns you about. Setting up the mailbox is the easy part. Getting your email to actually arrive, in the inbox and not the spam folder, depends on a handful of DNS records that most people either skip or get wrong.

This guide walks through every record you need, in plain English, with the exact values for the two most common providers. Much of this is a one-time setup you can do yourself in an afternoon. We will be honest about which parts are genuinely fiddly and which are not.

The short version

To send and receive professional email on your own domain, you configure four things in your domain's DNS settings:

  • MX records: tell the world which server receives mail for your domain.
  • SPF: lists which servers are allowed to send mail as your domain.
  • DKIM: adds a tamper-proof cryptographic signature to every message you send.
  • DMARC: ties SPF and DKIM together and tells receivers what to do with mail that fails.

Skip any one of these and your mail may still send, but it is far more likely to land in spam or be rejected outright. As of 2024, the big mailbox providers made SPF, DKIM, and DMARC effectively mandatory for anyone sending in volume. More on that below.

A quick word on where DNS lives

All of these records are added wherever your domain's DNS is managed. That is usually your registrar (where you bought the domain, such as GoDaddy, Namecheap, or Cloudflare) or a DNS host you have pointed the domain at.

The record types you will use are simple. A TXT record holds text. A CNAME points one name at another. An MX record points to a mail server with a priority number. If your DNS panel has fields labelled Host or Name, Type, Value or Points to, and TTL, you have everything you need.

One term to know upfront: TTL (time to live) is how long the world is allowed to cache a record before checking again. A lower TTL means changes propagate faster. We will come back to it.

Step 1: MX records, so you can receive mail

MX stands for Mail Exchanger. An MX record answers a single question: when someone sends an email to anyone @yourcompany.com, which server should it go to? You point it at your mail host.

Each MX record carries a priority number (sometimes called preference). Lower numbers are tried first. If you list several servers, senders fall back to the higher numbers when the first is unreachable.

For Google Workspace, Google now uses a single, simpler MX record. In your DNS, add:

Type: MX
Host: @
Priority: 1
Value: smtp.google.com

Older Google Workspace accounts were set up with five separate MX records (ASPMX.L.GOOGLE.COM and four ALT servers). Those still work perfectly, so if that is what you have, there is no need to change anything. New setups should use the single smtp.google.com record. Google's own MX setup guide has the current details.

For Microsoft 365, the MX value is unique to your tenant. It looks like your domain with the dots turned into dashes:

Type: MX
Host: @
Priority: 0
Value: yourcompany-com.mail.protection.outlook.com

Do not guess this value. The exact one is shown in the Microsoft 365 admin center under Settings, then Domains. Microsoft documents all of this in its external DNS records reference.

Important: when you switch to a new mail host, delete any old MX records left over from a previous provider. Leaving stale MX records in place is a classic way to have some of your mail quietly vanish.

Step 2: SPF, so your mail is trusted

SPF (Sender Policy Framework) is a single TXT record that lists the servers allowed to send mail on behalf of your domain. When a receiving server gets a message claiming to be from you, it checks the sending server against your SPF record. If the server is not on the list, the message looks like a forgery.

SPF is defined in RFC 7208, and it has a few rules that trip people up constantly.

You may have only one SPF record. This is the single most common mistake. If you publish two v=spf1 records, for example one for Google and one for your newsletter tool, SPF breaks entirely and returns an error. When you add a new sender, you merge it into your existing record. You do not add a second one.

The exact record for Google Workspace:

Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com ~all

The exact record for Microsoft 365:

Type: TXT
Host: @
Value: v=spf1 include:spf.protection.outlook.com -all

Notice the endings differ. ~all is a softfail (accept the mail but treat it as suspicious). -all is a hardfail (treat unauthorised mail as a failure). Google recommends ~all and Microsoft recommends -all. Follow whichever your provider specifies rather than forcing one or the other.

If you also send through other services, a newsletter platform, a CRM, an invoicing tool, you add each one with its own include: inside the same record. For example:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

There is one more limit worth knowing. SPF is allowed a maximum of ten DNS lookups. Each include: counts as at least one. Pile on too many sending tools and you will exceed the limit, which also breaks SPF. If you find yourself near the limit, remove services you no longer use.

Step 3: DKIM, so your mail cannot be tampered with

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the headers of every message you send. Your mail host holds a private key and signs outgoing mail with it. You publish the matching public key in DNS. The receiving server fetches that public key, checks the signature, and confirms the message genuinely came through your authorised host and was not altered on the way. It is defined in RFC 6376.

The single most important thing to understand about DKIM is this: publishing the DNS record is not enough on its own. You must also switch DKIM signing on inside your mail host's admin console. The DNS record and the console setting are two halves of the same switch. This is the number one reason people think they have set up DKIM when they have not.

For Google Workspace: go to the Admin console, then Apps, Google Workspace, Gmail, Authenticate email. Generate a key (choose 2048-bit if your registrar supports it), publish the TXT record it gives you at the host google._domainkey, then come back and click Start authentication. Note that you may need to wait roughly a day after first setting up Gmail before Google will let you generate the key.

For Microsoft 365: DKIM uses two CNAME records with the hosts selector1._domainkey and selector2._domainkey. There are two selectors so Microsoft can rotate keys safely over time. The exact target values are shown in the Microsoft Defender portal, or via the Get-DkimSigningConfig PowerShell command. Pull them from there rather than copying an example, because they are specific to your tenant. Then enable signing in the Defender portal.

On key length: 2048-bit keys are the current recommendation and are stronger than the older 1024-bit default. Google offers 2048-bit in the console. Microsoft still defaults to 1024-bit, so if you want the stronger key you select it explicitly. This is a best-practice recommendation rather than a hard requirement, so do not lose sleep if you inherit a 1024-bit setup.

Step 4: DMARC, so everything is enforced

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It is a TXT record at the host _dmarc that does two things: it tells receiving servers what to do when a message fails your checks, and it asks them to send you reports about mail claiming to be from your domain. It is defined in RFC 7489.

The key idea DMARC adds is alignment. It is not enough for SPF or DKIM to simply pass. The domain that passed has to match the domain in your visible From address. This is why mail sent through a third-party tool can pass SPF yet still fail DMARC: the check passed, but on the tool's domain, not yours. Configuring your sending tools to sign and send with your domain is what fixes it.

DMARC has three enforcement levels:

  • p=none: monitor only. Take no action, just send reports. This is where you start.
  • p=quarantine: send failing mail to the spam folder.
  • p=reject: refuse failing mail outright.

The safe rollout is to walk up that ladder, not jump to the top. Start with a monitoring record:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com

The rua= address is where aggregate reports are sent. These arrive as daily XML files. They are not pretty, but a free DMARC report reader will turn them into a readable picture of who is sending mail as your domain and whether it passes.

Leave the record on p=none for a few weeks to a couple of months, long enough to confirm every legitimate sender you use is passing and aligned. Only then move up to p=quarantine, and eventually p=reject once you are confident. Jumping straight to p=reject before monitoring is the fastest way to silently block your own invoices and newsletters. This patience is the whole point.

One forward-looking note. The DMARC standard is being revised (informally called DMARCbis), and the update will retire the older pct= tag in favour of a new testing tag. It is not yet a finalised standard, so the record above still follows the current RFC and will keep working. We mention it only so the term does not surprise you later.

Why all of this became non-negotiable in 2024

For years, SPF, DKIM, and DMARC were treated as optional extras. That changed in February 2024, when Google and Yahoo introduced new requirements for bulk senders. Anyone sending 5,000 or more messages a day to Gmail or Yahoo now has to have all three in place, offer one-click unsubscribe on marketing mail, and keep spam complaints below 0.3%.

Microsoft followed with similar enforcement for high-volume senders to its consumer inboxes (outlook.com, hotmail.com, live.com), rolling out through 2025. Mail from non-compliant high-volume domains was first sent to Junk, then rejected.

The 5,000-a-day threshold means a typical small business is not formally forced to comply. But here is the honest takeaway: these three records are now the baseline that mailbox providers use to decide whether you look trustworthy at all, and the thresholds keep drifting downward. Setting them up correctly is the single best thing you can do to make sure your email reaches people, whether you send fifty messages a day or fifty thousand.

The mistakes we see most often

  • Two SPF records. Adding a second v=spf1 record instead of merging. This breaks SPF completely. Always merge into one.
  • DKIM in DNS but not switched on. The public key is published, but signing was never enabled in the admin console, so nothing is actually signed.
  • Jumping to p=reject too early. Enforcing DMARC before monitoring reports, which quietly blocks legitimate mail from tools you forgot about.
  • Too many SPF lookups. Adding one sending tool after another until you cross the ten-lookup limit and SPF fails.
  • A high TTL during changes. If your records have a 24-hour TTL, every fix takes a day to take effect. Lower the TTL before you start editing.
  • Forgetting to update SPF when adding a tool. A new CRM or newsletter platform starts failing the moment it sends, because it was never added to your record.

How to check your work

Do not trust that a record is live just because you saved it. Verify it. DNS changes are governed by your TTL and can take anywhere from a few minutes to, in the worst case, up to 72 hours to be seen everywhere. Lowering your TTL to 300 seconds a day before a big change makes this far quicker, and you can raise it again afterwards.

Some reliable ways to check:

  • Command line: dig MX yourcompany.com +short, dig TXT yourcompany.com +short for SPF, and dig TXT _dmarc.yourcompany.com +short for DMARC. On Windows, nslookup -q=txt _dmarc.yourcompany.com does the same job.
  • MXToolbox: the SuperTool checks MX, SPF, DKIM, and DMARC and flags problems in one place.
  • Google Admin Toolbox Check MX: Google's own tool for validating a Workspace setup.
  • mail-tester.com: send a real message to the address it gives you and get a 0 to 10 score with a pass or fail breakdown for each check. This is the best final test, because it exercises the whole thing end to end.

What you can do yourself, and where we come in

Here is the honest part. For a single mail provider and no exotic sending tools, this is genuinely a do-it-yourself job. Add the MX records, add one SPF record, switch on DKIM in the console and publish its record, publish a DMARC record on p=none, wait, verify with mail-tester, and you are done. Many small businesses never need help beyond that.

Where it gets fiddly is when you send through several services at once, when you hit the SPF lookup limit, when DMARC reports show failures you cannot explain, or when you are moving a live domain to a new provider without losing a single message. That is where a careful hand and an hour of attention save you a lot of grief.

If you would like a second set of eyes, our free audit includes a check of your email and DNS setup. We will tell you plainly what is configured correctly, what is missing, and whether it is a five-minute fix or something worth handing over. No pressure, just the facts about where your email stands.