To configure Cloudflare DNS for a business domain, publish the website and email records supplied by your providers, keep mail hostnames out of the standard HTTP proxy, then test both DNS and delivered messages. Changing DNS does not by itself configure a mailbox, enable DKIM signing or establish DMARC alignment.
This guide covers authoritative DNS for a domain you manage in Cloudflare. It is for connecting a business website and email services, rather than changing the DNS resolver on your laptop.
TL;DR:
- Inventory the existing records before changing them.
- Copy domain-specific email values from your actual providers.
- Check the proxy status of mail and verification hostnames.
- Verify the website, incoming email and every outgoing mail stream separately.
For authentication concepts and provider setup, use our SPF, DKIM and DMARC guide. The Gmail and Yahoo requirements overview explains when the receiving providers’ rules apply.
Collect the Values Before Editing DNS
Record who controls the registrar, Cloudflare account, web hosting and mail services. Make sure the business can access those accounts and that someone is responsible for approving the change.
Export or record the current zone, including website, mail, verification and any SRV or CAA records your services use. For each proposed change, save the old value, the new provider-supplied value and the service that depends on it. Treat deletion as a separate decision from adding a new record.
If Cloudflare already hosts the active zone, changing a record does not normally require changing nameservers again. If you are moving the domain into Cloudflare, follow its full-setup procedure: review the imported records, use the assigned nameservers and handle existing DNSSEC before the switch.
Cloudflare’s standard migration procedure calls for disabling existing DNSSEC at the registrar before replacing nameservers, then enabling it through Cloudflare once the zone is active. A stale DS record can make the domain fail validation. Follow the documented migration path appropriate to your setup. For the concepts, see DNSSEC and CDNs explained.
Match Each Record to Its Job
| Record | Business purpose | Where the value comes from |
|---|---|---|
| A or AAAA | Resolve a hostname to an IPv4 or IPv6 address | Your web or mail host |
| CNAME | Point a hostname to another DNS name | Your hosting, verification or email provider |
| MX | Identify where incoming mail should be delivered | The receiving mail provider, including priority values |
| TXT for SPF | Publish the sending sources authorized for that hostname | Your legitimate sending services |
| TXT or CNAME for DKIM | Publish or point to the public signing key | The email provider’s selector and domain-specific value |
| TXT for DMARC | Publish the domain’s authentication policy and reporting destination | The policy you have chosen for that domain |
Cloudflare documents these types in its DNS record reference. Match the record’s purpose before copying a value: a website address, mailbox destination and DKIM target are not interchangeable.
Add the Website Records
Open the domain in Cloudflare and go to DNS → Records. Add or edit the A, AAAA or CNAME values supplied by your hosting provider. Check both the root domain and www if your website uses them.
For each record, verify the final hostname, record type, content, TTL and proxy setting. Keep only the IPv6 records that point to a working IPv6 service. A correct IPv4 address does not fix a stale IPv6 destination.
Use the proxy mode that your hosting arrangement supports. Cloudflare’s proxy applies to eligible A, AAAA and CNAME records; DNS-only records return the underlying destination without placing HTTP traffic through the proxy. Proxy behavior.
After saving, test the expected website addresses over HTTPS. Check redirects, certificates and an important business action such as opening the contact form. A successful DNS lookup alone does not test those parts of the service.
Publish Email Records From the Actual Provider
Use the provider’s domain setup screen, rather than a generic list of records. Tenant-specific DKIM targets and product-specific instructions can change. Cloudflare’s record-management instructions cover the interface; your email provider supplies the values.
MX for Incoming Mail
Copy all required MX destinations and their priorities. Check which service should receive mail before replacing an existing MX set. Multiple records can be intentional when they belong to the same documented delivery configuration.
If Cloudflare Email Routing is enabled, it can manage MX records that conflict with a different receiving provider. Check that feature when the visible records differ from the mailbox provider’s instructions. Cloudflare email troubleshooting.
SPF for Authorized Sending Sources
Check the existing TXT records at the hostname before adding SPF. Maintain one record beginning v=spf1 there, incorporating the legitimate sending services according to their instructions. Other TXT records used for verification can coexist.
Two separate SPF policies at the same hostname do not provide a safe way to add a second sender. The protocol specifies a single selected SPF record. RFC 7208, section 3.2.
Record every production sender: employee mail, newsletters, invoices, support systems and application notifications. Their envelope domains and DKIM domains can differ, so their authentication configuration needs separate checks.
DKIM for Signed Mail
Copy the selector, hostname and exact TXT value or CNAME target from the sending provider. Some services require more than one selector for rotation. Enable signing in the provider once its DNS checks pass.
Set a provider-verification or DKIM CNAME to DNS-only when the provider requires the original target. If verification fails, compare the hostname and returned record with the provider’s expected values before adding another record.
DMARC for Policy and Reporting
Publish the policy at the correct _dmarc hostname. For a domain beginning a monitoring rollout, an example is:
v=DMARC1; p=none; rua=mailto:[email protected]
Replace the example domain with a reporting destination you control and configure any required external reporting authorization. Monitoring provides evidence for later policy decisions. The DMARC rollout section explains current standards and receiver-compatibility considerations.
Keep Mail Hostnames DNS-Only
MX and TXT records are always DNS-only in Cloudflare. Also inspect any A, AAAA or CNAME hostname used by mail clients or targeted by MX: changing that hostname’s proxy status can affect the connection.
Cloudflare’s standard HTTP proxy does not carry SMTP, IMAP or POP3. A mail hostname returned as a Cloudflare proxy address can therefore prevent clients from connecting to the mail service. Mail hostname and proxy troubleshooting.
Keep the website’s proxy decision separate from the mail hostname’s configuration, even when both services use the same underlying server.
Verify DNS and Delivered Messages
Replace example.com with your domain in these read-only lookups:
dig +short NS example.com
dig +short A example.com
dig +short AAAA example.com
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
For DKIM, query the selector supplied by the provider, for example selector1._domainkey.example.com, using the appropriate TXT or CNAME type. Compare the answers with the saved expected values. Cached answers can persist according to TTL; Cloudflare explains TTL and cached responses.
Then test the actual services:
- Open the root website and
wwwover HTTPS, where configured. - Receive a message at the business mailbox.
- Send from each production sending service to a test recipient.
- Inspect the delivered message’s SPF and DKIM results and the domains involved.
- Check DMARC alignment with the visible From domain.
- Confirm that the team knows where delivery logs and later DMARC reports can be reviewed.
A published DKIM key does not establish that the provider is signing real messages. A passing signature for a different domain also needs the alignment check described in the authentication guide.
Troubleshoot the Failing Layer
| Symptom | Check first |
|---|---|
| Website fails after a nameserver change | Active nameservers, complete zone records and DNSSEC/DS consistency |
| Incoming mail stops | Provider MX values and whether Email Routing changed the receiving configuration |
| Mail client cannot connect | Mail hostname resolution and DNS-only setting |
| A provider cannot verify a CNAME | Exact hostname and target, proxy status and any relevant CNAME flattening setting |
| DKIM is published but messages fail | Signing enabled at the sender, actual selector and delivered-message results |
| DMARC fails despite SPF or DKIM passing | Alignment between the authenticated domain and the visible From domain |
For CNAME verification, Cloudflare notes that flattening can affect services expecting the CNAME target itself. Review its CNAME flattening guidance.
Keep the before-and-after values and test results with the domain’s access documentation. If you need help untangling ownership, hosting and email configuration, contact us with the services involved and the exact symptom.
