DNS & Email Setup Templates for Custom Domains: MX, SPF, DKIM, DMARC and TTL Best Practices

Overview

A custom email domain depends on several DNS records working together. MX records tell other mail servers where to deliver messages. SPF identifies approved sending systems. DKIM adds a cryptographic signature to outgoing messages, while DMARC tells receiving systems how to evaluate authentication results and provides reporting options. Providers may also require CNAME or TXT records to verify domain ownership or activate specific services.

The exact hostnames, values, and record formats depend on your email provider. Treat the templates below as a planning framework rather than universal copy-and-paste values. Before changing production DNS, compare every value with the provider's current setup instructions and record the existing configuration.

For background on record types, see DNS Records Explained: How to Configure A, CNAME, MX, TXT, and AAAA Records. If you are starting a new domain and mailbox at the same time, the custom email domain setup guide provides a complementary walkthrough.

Checklist by scenario

1. Setting up email on a new domain

1. Confirm DNS control. Identify the authoritative DNS provider for the domain. Changes made at a domain registrar will not take effect if the domain uses different nameservers.
2. Verify ownership. Add the provider's requested TXT or CNAME verification record. Keep the value exactly as supplied, including punctuation and quotation marks where the DNS interface requires them.
3. Add MX records. Enter each mail exchanger hostname and priority supplied by the email provider. Remove obsolete MX records only when you are certain they belong to a previous mail service.
4. Add SPF. Create one TXT record at the root of the domain, normally represented by @ in a DNS dashboard. A generic structure looks like v=spf1 include:PROVIDER-A.example ~all, but the provider's published mechanism must replace the placeholder.
5. Enable DKIM. The provider will normally give you a selector and a public key, often published as a TXT record or through a CNAME delegation. A typical selector hostname resembles selector1._domainkey; do not assume the selector or record type without checking the provider instructions.
6. Publish DMARC. Begin with a monitoring policy such as v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com only if you have a mailbox prepared to receive reports. Use a reporting address you control, and review results before moving to a stricter policy.

2. Migrating from one email provider to another

1. Inventory the current records. Export or document MX, SPF, DKIM, DMARC, verification, autodiscover, and any sending-service records before editing DNS.
2. Lower TTL before the planned change. If your DNS provider allows it, reduce the relevant records ahead of the migration. A value such as 300 seconds may make testing easier, but it does not guarantee that every resolver will refresh immediately.
3. Prepare the destination service. Create users, aliases, mailboxes, and DKIM keys before switching MX records. Confirm that the new provider accepts the domain and can send test messages.
4. Update MX carefully. Replace old delivery records according to the destination provider's instructions. Do not leave unrelated or stale MX records in place simply because they appear harmless; they can route mail to the wrong service.
5. Rebuild SPF rather than stacking records. Combine authorized senders into one SPF TXT record. Multiple SPF records at the same hostname can cause authentication failure.
6. Rotate or replace DKIM deliberately. Keep the old selector temporarily if the previous service may still send during the transition, then remove it after the migration window and verification period.
7. Keep DMARC reporting active. Watch for legitimate services still sending as your domain, such as marketing platforms, support systems, website forms, or transactional email tools.

3. Adding a third-party sending service

Marketing, transactional, and application email providers commonly require separate DKIM and SPF authorization. Follow the service's domain-authentication workflow and publish every requested CNAME or TXT record. Avoid assuming that your main mailbox provider automatically authorizes a separate sending platform.

For each service, record the purpose, selector, hostname, value, and owner. If the service supports a dedicated sending subdomain such as mail.example.com or notify.example.com, consider using it to separate application mail from employee mail. The appropriate arrangement depends on your operational and deliverability requirements.

4. Connecting a website and email on the same domain

Website records and email records serve different functions. A and AAAA records route web traffic to an IP address; CNAME records can point a hostname to another hostname; MX records route mail. Changing a website's A record should not normally alter email delivery, but replacing nameservers or editing the wrong hostname can affect both.

After DNS changes, test the website, mailbox login, inbound mail, outbound mail, domain verification, and SSL coverage. The SSL certificate troubleshooting guide can help if a DNS change exposes certificate or mixed-content problems.

What to double-check

• Authoritative nameservers: Confirm which DNS platform answers for the domain before making edits.
• Record names: Some dashboards expect @, while others expect the full domain or a blank host field. Enter the format required by that dashboard.
• Trailing dots: DNS interfaces differ in how they display fully qualified hostnames. Follow the interface convention rather than adding or removing punctuation at random.
• SPF consolidation: Maintain a single SPF record for each hostname. Include every legitimate sender and remove services that no longer send mail.
• DKIM selector accuracy: The selector in the DNS hostname must match the selector used by the sending service. A valid-looking public key under the wrong selector will not authenticate.
• DMARC alignment: SPF or DKIM authentication is most useful when it aligns with the visible From domain. Review provider guidance and authentication reports before enforcing a reject or quarantine policy.
• Verification records: Do not delete a TXT or CNAME record merely because you do not recognize it. It may support a website, certificate, analytics, identity, or email service.
• TTL planning: Use a shorter TTL during a controlled migration if practical, then restore a stable value after testing. TTL affects resolver caching; it does not force an instant global update.
• Testing from outside your network: Check records with more than one DNS lookup tool or resolver. Local caches can make a completed change appear unfinished.

Common mistakes

Changing nameservers without a complete zone copy can remove website, email, verification, and security records at once. Copy the existing zone and confirm critical services before delegating the domain to a new DNS provider.

Using sample values in production is another frequent failure. Replace every placeholder such as PROVIDER-A, selector1, and example.com with values generated for your domain and account.

Publishing multiple SPF records is not the same as adding multiple senders. Merge authorized mechanisms into one record, and review the result whenever a service is added or retired.

Enforcing DMARC too quickly can affect legitimate messages from overlooked systems. Start with monitoring, inspect reports, correct alignment issues, and increase enforcement gradually when your sending inventory is understood.

Testing only outbound mail leaves inbound routing unverified. Send messages in both directions, test aliases and forms, and inspect authentication results in the receiving mailbox.

Forgetting account and domain security can undermine careful DNS work. Use strong administrator authentication, limit access to DNS, and keep recovery details current. See the Domain and DNS Security Checklist for a broader review.

When to revisit

Keep this checklist with your domain and hosting records, and revisit it whenever the underlying configuration changes. Practical review points include:

• Before moving mail to a new provider or changing DNS hosting.
• After adding a marketing, transactional, support, or website-form sending service.
• When a DKIM key is rotated, renewed, or replaced.
• When bounce rates, spam placement, or authentication failures increase.
• Before seasonal campaigns or other periods of higher sending volume.
• After a domain transfer, nameserver change, website migration, or security incident.
• During a scheduled quarterly review of provider requirements and DNS records.

For each review, export the current DNS zone, compare it with your service inventory, test inbound and outbound mail, and confirm SPF, DKIM, and DMARC results. Remove retired records only after confirming that no active service depends on them. Restore normal TTL values after a migration has settled, and document who approved the change.

Finally, keep domain administration separate from guesswork: verify provider-specific values at the time of setup, monitor the results after propagation, and preserve a dated record of successful tests. If a domain change is part of a wider website launch or migration, pair this checklist with the WordPress Website Launch Checklist or the domain transfer checklist.