DNS Configuration

The DNS records email depends on

DNS tells the internet where to deliver your mail, which servers may send it, how to verify its signatures and what to do when checks fail. A single wrong record can stop inbound mail, break authentication or send your newsletters to spam. Because records interact, they’re best set and verified together.

Records also build up over time. Each provider you trial adds verification entries and includes, and few are removed afterwards. A mail-focused DNS review clears that history and leaves a zone anyone can understand.

Signs your DNS needs attention

• Incoming mail stops or arrives at an old server.
• Authentication checks fail for some messages but not others.
• Records left over from providers you no longer use.
• Nobody has a full list of what your zone contains or why.
• Your DNS moved to a new host and some records didn’t come across.

What’s included

• A full audit of your current zone for mail-related records.
• MX records with correct priorities and valid targets.
• SPF, DKIM and DMARC for every sending domain and subdomain.
• Tracking, return-path and bounce domains for your platforms.
• Autodiscover records where they help mail clients.
• MTA-STS and TLS-RPT where transport security is in scope.
• Sensible TTLs, lowered before changes and raised afterwards.
• Removal of stale records, with your agreement.
• A documented zone with each record’s purpose explained.

How we deliver it

1. Export and review the existing zone, and note which records belong to which service.
2. Agree the target zone with you, including anything to remove.
3. Lower TTLs ahead of significant changes such as MX moves.
4. Apply changes carefully, in an order that avoids gaps in mail flow.
5. Verify from several public resolvers and confirm propagation.
6. Send and receive test mail to confirm every record works in practice.
7. Document the final zone and restore normal TTLs.

DNS hosting considerations

Your DNS host matters. Some limit TXT record length, which affects long DKIM keys. Some proxy services can interfere with mail records if they are set incorrectly: mail hostnames must resolve directly rather than through a web proxy. Moving DNS to a new host is also a common moment for records to go missing, so we compare zones before and after.

Correct DNS supports permission-based sending; it’s the foundation for email authentication and rDNS setup, not a way around receivers’ checks.

How we verify the result

A record that looks correct in a control panel can still be wrong in practice: a typo in a DKIM key, a trailing dot missing, a value split badly across strings, or a cached old answer. We verify at three levels:

1. Direct queries against your authoritative name servers, confirming exactly what is published.
2. Public resolvers in several locations, confirming propagation.
3. Real mail: messages sent and received, with Authentication-Results headers checked.

Only when all three agree do we mark the work complete.

What affects timeline and cost

• Number of domains and subdomains.
• How many services send or receive mail for them.
• Access to the DNS host and its limitations.
• Whether a DNS host migration is part of the work.
• TTL waiting periods before and after changes.

Common DNS mistakes

Deleting a record to take something offline, then being caught by cached negative answers. Publishing two SPF records. Pointing MX at a CNAME. Putting a mail hostname behind a web proxy. Changing MX with a long TTL still in place. Forgetting subdomains that send mail.

Browse all email infrastructure services, read the guide, or contact us.

Frequently asked questions