DNS Email Configuration Without the Guesswork

Email migration rarely fails because the mailbox is complicated. It fails because DNS email configuration was copied from an old provider, entered in the wrong place, or changed before anyone checked what the records actually do. Your domain’s DNS decides where mail arrives, which servers may send it, and whether receiving providers have reason to trust it.

That sounds high-stakes because it is. But it is also manageable. Most custom-domain email setups come down to four record types: MX, SPF, DKIM, and DMARC. Configure them carefully, keep old mail working until the new setup has been tested, and you avoid the usual painful version of a migration: messages disappearing into an old inbox or landing in spam while everyone insists they sent them.

What DNS Email Configuration Actually Controls

DNS is the public directory for your domain. It tells other systems where to find your website, how to verify a service, and, in this case, how to route and authenticate email.

MX records handle incoming mail. When someone sends a message to you@yourdomain.com, their mail server looks up your MX records to find the server responsible for accepting that message. If those records still point to a former provider, new mail will keep arriving there.

SPF, DKIM, and DMARC handle outgoing mail trust. They do not make every email provider love every message you send. They establish a clear, standards-based answer to a basic question: is this server allowed to send mail using this domain?

The distinction matters. MX records affect delivery to you. Authentication records affect how the rest of the internet evaluates mail from you. A domain can receive mail perfectly while its outgoing messages fail authentication, and the reverse can also happen.

The Four Records You Need

Every provider has its own hostnames and DKIM values, so never reuse examples from a generic guide. Use the exact records supplied in your account. The purpose of each record, however, stays the same.

MX records route incoming mail

An MX record has a destination and a priority. Lower priority numbers are tried first. Some providers give you two or more MX records for redundancy. Enter all of them exactly as provided.

Before adding new MX records, look at what already exists. It is common to find old Google Workspace, Microsoft 365, Zoho, cPanel, or registrar-hosted email MX entries still active. If you leave old MX records alongside a new provider’s records, delivery becomes unpredictable. Servers may send mail to the wrong destination based on priority or fallback behavior.

During a planned cutover, copy or migrate your existing mail first, create the new mailboxes, and then replace the old MX records. Do not cancel the old service the minute you change DNS. DNS changes can take time to propagate, and a short overlap gives you room to catch problems.

SPF authorizes senders

SPF is a TXT record that lists the services allowed to send email on behalf of your domain. A typical SPF record includes your mailbox provider and may also include a transactional sender, website form service, accounting tool, or support platform.

The rule that causes the most trouble is simple: your domain should have one SPF record. Not one per service. Not one that someone added last year plus another added during a new setup. One record, with every valid sender included.

Multiple SPF TXT records can produce an SPF PermError. That is a configuration error, not a harmless duplicate. Combine the authorized sources into a single record based on each vendor’s instructions.

Be conservative with the ending policy. `~all` is a soft fail and is often a sensible starting point while you identify every legitimate sender. `-all` is stricter, but it can reject or fail mail from a service you forgot about. The right choice depends on how many systems send for your domain and how well you control them.

DKIM signs each message

DKIM uses a private key held by your email provider and a public key published in DNS. Each outgoing message is signed, and recipients can validate that signature using the public key.

Your provider will usually give you either a TXT record or one or more CNAME records under a selector name, such as `selector1._domainkey`. The selector is part of the address. Put it in the host or name field exactly as supplied, rather than appending your full domain a second time.

This is one of the most common DNS editor mistakes. Some registrars automatically add `yourdomain.com` to the host field. If you paste the complete hostname into a field expecting only `selector1._domainkey`, you can accidentally publish a record at `selector1._domainkey.yourdomain.com.yourdomain.com`.

DKIM can also expose stale infrastructure. If a former provider’s DKIM record remains, that is not necessarily harmful. Multiple selectors can coexist. But each selector should belong to a sender you still use. Remove records for retired systems when you are sure they are no longer sending mail.

DMARC sets the policy

DMARC tells receiving servers what to do when SPF and DKIM do not align with the visible From address. It also provides reporting, which helps you see who is sending mail as your domain.

Start with a monitoring policy if you do not already know every sender:

`v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`

The reporting address should be a real mailbox or alias that can receive external mail. Reports are XML files and can be noisy, but they are useful evidence. They show whether a forgotten website plugin, vendor platform, or old server is still trying to send as your domain.

After you have reviewed the reports and fixed legitimate senders, move toward `p=quarantine` or `p=reject`. Those policies offer better protection against domain spoofing, but only after you know your own mail is aligned. A strict DMARC policy applied too early can block valid invoices, support replies, or application notifications.

Where to Add the Records

Your email provider does not necessarily control your DNS. The correct place to edit records is wherever your domain’s authoritative nameservers are managed. That might be your registrar, Cloudflare, a hosting company, or a separate DNS service.

Do not assume that the company where you registered the domain is also the company serving its DNS. Check the nameserver settings. If they point to another platform, changes made at the registrar may do nothing.

DNS control panels label fields differently. You might see Name, Host, Label, or Record Name. You might see Value, Content, Target, or Points To. The labels vary, but the record data does not. Enter the record type, hostname, destination or value, and TTL as instructed.

A trailing dot in a hostname is usually optional in modern DNS dashboards. Some interfaces add it automatically; some accept either format. The larger risk is entering a hostname in the wrong field or allowing a control panel to append the domain twice.

A Safer Order for Changing Email DNS

Changing everything at once is tempting, especially when an old provider’s billing date is approaching. It is also how people create avoidable downtime. A better approach is to prepare first and switch routing last.

Create mailboxes, aliases, and catch-all rules at the new provider. If you are moving existing mail, begin the IMAP migration while the old account remains available. Then publish DKIM and update SPF to include the new provider. Those records can exist before the MX cutover because they do not change where incoming mail goes.

Next, publish DMARC with `p=none` if you are new to DMARC or adding new senders. Finally, replace the MX records and send test messages from several outside services. Test both directions: send from Gmail or Outlook to your domain, then send from your domain back to those accounts.

FranklyMail provides live checks for MX, SPF, DKIM, and DMARC because waiting for a vague “DNS may take 24 to 48 hours” message is not a useful operational plan. Propagation can be quick, but cached records and incorrect entries are different problems. Verification tells you which one you have.

Common Failures That Look Like DNS Problems

Not every mail issue is a DNS issue. A message sent to an old mailbox after an MX change may be the result of cached routing, but it may also be a forwarding rule at the old provider. Outgoing mail that lands in spam may involve missing authentication, poor sending reputation, message content, or a new domain with little history.

Another frequent problem is forgetting that services other than the mailbox provider send email. A website contact form, calendar system, CRM, billing platform, and transactional email service may all use your domain in the From address. Each one needs to be included in SPF and configured for DKIM alignment if you want DMARC to pass consistently.

Avoid the shortcut of authorizing the whole internet. SPF records with broad includes or an open `+all` policy defeat the point of sender authorization. The same applies to DMARC records that stay at `p=none` forever. Monitoring is useful, but it is not enforcement.

Verify Before You Declare the Switch Finished

A DNS record existing in a control panel is not proof that it is public, correct, or working. Check that MX lookups return only the intended mail servers. Confirm there is one valid SPF record. Send a real message and inspect whether DKIM passes. Then confirm DMARC passes for the domain shown in the From field.

Also test the addresses people actually use: primary mailboxes, aliases, role addresses such as support@, and catch-all delivery if you rely on it. Email is infrastructure, so test the boring cases before they become expensive cases.

Give your new configuration a day or two of normal use before shutting down the former mail service. Keep an eye on DMARC reports and any bounce messages during that overlap. A careful DNS change is not glamorous, but it is one of the few admin tasks where ten quiet minutes of verification can prevent days of missed email.