How to Configure DNS Email Records Without Guesswork

Moving custom-domain email is often less about mailboxes than DNS. Your messages may already be copied, your new inbox may work, and then mail disappears because one MX value has a typo or an old SPF record is still authorizing the wrong sender.

To configure DNS email records correctly, treat each record as a separate job. MX records decide where inbound mail goes. SPF, DKIM, and DMARC tell receiving servers whether outbound mail is legitimate. They work together, but they are not interchangeable. A valid MX record does not authenticate mail, and a perfect DMARC policy cannot rescue an SPF record that exceeds DNS lookup limits.

The good news: this is usually a short, finite setup. The bad news: copying values from two providers into the same DNS zone without a plan can create confusing failures that take hours to surface.

What DNS email records actually control

DNS is the public directory for your domain. When another mail server needs to deliver a message to you, it asks DNS where your domain receives email. When it receives a message claiming to come from your domain, it checks DNS for evidence that the sender was allowed to send it.

Four record types matter for normal custom-domain email:

• MX records route incoming mail to your email provider.
• SPF records list the servers or services allowed to send mail using your domain.
• DKIM records publish a public key used to verify a cryptographic signature on outgoing mail.
• DMARC records tell recipients what to do when SPF or DKIM checks fail, and where to send reports.

You may also see autodiscover, autoconfig, or verification records. Those can help mail apps or prove domain ownership, but they are not the foundation of mail delivery.

The practical rule is simple: preserve what is currently working until the replacement has been verified. If you are changing providers, do not remove old MX records until the new provider confirms that the new ones are live and ready. Do not publish a strict DMARC policy before you know every legitimate system that sends as your domain.

Start with an inventory, not a DNS editor

Before editing anything, list every service that sends mail from your domain. This may include your email host, website forms, invoicing software, support desk, ecommerce platform, calendar tool, and transactional email service. A small business can easily have three or four legitimate senders without realizing it.

This inventory matters most for SPF and DKIM. Your email host might provide the main mailbox sending, while an invoicing system sends receipts and a website sends password resets. If you authorize only the mailbox provider in SPF, the other messages can fail authentication. If you configure DKIM for only one sender, DMARC can still pass for that sender, but not necessarily for the others.

Also identify where DNS is actually managed. Your domain registrar is not always your DNS host. Many domains are registered in one place and use nameservers from a web host, CDN, or DNS specialist. Editing records at the registrar does nothing if the domain points to different authoritative nameservers.

Take a screenshot or export of the current zone before making changes. It is not glamorous, but it is the fastest way back if someone deletes a record that turns out to support a live service.

Configure DNS email records in the right order

For a new email setup, add records first and switch routing last. For a provider migration, this prevents avoidable downtime.

Add and verify MX records

MX records contain a hostname and a priority number. Lower numbers are preferred. If your provider gives you two MX hosts, add both with the exact priorities supplied. The second server is normally a backup route, not an optional extra.

Do not add MX records for two unrelated email providers unless you understand the consequences. Mail servers choose the lowest-priority available destination. If old and new providers have overlapping or conflicting priorities, some messages can land in the old service while others arrive at the new one. That is not a migration strategy. It is split delivery.

Many DNS dashboards automatically append your domain name to entries. If a provider asks for `mx1.example.net`, enter it exactly as their interface expects. Some systems require a trailing period to indicate a fully qualified hostname; most modern dashboards handle this for you. The provider’s DNS instructions should match the syntax of the dashboard you are using.

After the new MX records resolve publicly, send a test message from an unrelated address, such as a personal Gmail or Outlook account. Confirm it reaches the intended mailbox, not merely a webmail interface that still has cached or forwarded mail.

Publish one SPF record

SPF is a TXT record, usually placed at the root of the domain. A basic record might look like this:

`v=spf1 include:mail-provider.example -all`

The exact include value comes from your provider. Do not invent it, and do not publish more than one SPF TXT record. Multiple SPF records are a common mistake and can cause receivers to return a permanent SPF error.

If several services send mail for you, combine their approved mechanisms into one record. For example, that might mean one include for your email host and another for your transactional sender, ending with either `~all` or `-all`.

There is a trade-off. `-all` is stricter and says all other senders should fail. It is appropriate once your inventory is complete. `~all` is softer and can be useful during a transition, but it is not a permanent substitute for knowing who sends your mail. Either way, SPF has a limit of 10 DNS lookups during evaluation. Stacking includes from old vendors can push you over that limit and make a record that looks reasonable fail in practice.

Enable DKIM for every real sender

DKIM is usually the most reliable part of email authentication once it is correctly published. Your provider signs outgoing mail with a private key. DNS holds the corresponding public key, often at a hostname like `selector._domainkey.yourdomain.com`.

Copy the selector, host name, and TXT value exactly. DKIM values are long, and a missing character makes the whole record useless. DNS dashboards may display long values in quoted segments. That is normal as long as the published value resolves as one continuous key.

A provider may offer multiple DKIM selectors during key rotation. Keep each requested selector. Removing an older active selector too early can break verification for messages signed before or during the rotation.

If a third-party system sends as your domain, configure its DKIM too. SPF alone may pass, but DKIM gives DMARC another authentication path and is less vulnerable to forwarding changes.

Add DMARC gradually

DMARC lives at `_dmarc.yourdomain.com` as a TXT record. It checks whether SPF or DKIM passes and whether the authenticated domain aligns with the visible From address.

Start with a monitoring policy, not enforcement. For example:

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

This tells receivers to send aggregate reports while taking no enforcement action. Those reports can be noisy XML files, but they reveal legitimate senders you missed and sources attempting to impersonate your domain.

Once you have reviewed the results, move to `p=quarantine` if you want suspicious mail routed to spam, then `p=reject` when you are confident that authorized senders align correctly. Strict enforcement is valuable for a domain that should not be spoofed. It can also block legitimate receipts, forms, or automated notices if you skipped the inventory step.

Avoid the migration mistakes that cause lost mail

DNS changes are not always instant. Each record has a TTL, or time to live, which tells resolvers how long they may cache the answer. A lower TTL before a planned migration can shorten the transition window, but it cannot erase caches that already stored the old value.

Keep the old email account active for a reasonable overlap period. How long depends on your prior TTL, the provider’s routing behavior, and whether important correspondents use systems with stale caches. For most small-domain moves, several days is cheap insurance. Do not cancel the old service the minute a single test message succeeds.

Also check for records that look unrelated. A website’s contact form may use a subdomain, such as `mail.example.com`, or a SaaS platform may need a CNAME for DKIM rather than a TXT record. Removing “unused” DNS entries without understanding them can break mail that only appears once a month.

FranklyMail verifies MX, SPF, DKIM, and DMARC status during setup, which is useful because DNS dashboards do not tell you whether a record is merely saved or actually doing the job it was meant to do.

Test delivery, not just DNS visibility

A DNS lookup confirms that a record exists. It does not prove receiving servers accept your mail, that outbound messages are signed, or that DMARC aligns.

Send test messages to a few major mailbox providers and inspect the message headers. Look for SPF, DKIM, and DMARC results. You want passing results for the domain shown in the visible From address. Then reply from each destination and verify that inbound mail arrives at the expected new mailbox.

If something fails, change one thing at a time. Replacing all records at once makes diagnosis harder. Check the hostname, selector, and priority first, then confirm that you did not create duplicate SPF or DMARC records. Most DNS email problems are small transcription errors, stale records, or an overlooked service sending on the domain’s behalf.

Custom-domain email should not require enterprise software or a sales call. It does require a clean DNS zone, a complete view of your senders, and enough patience to verify the change before tearing down the old setup. That is the boring part of email infrastructure, and boring is exactly what you want.