Does moving my DNS to Cloudflare break my email?

Hosting your DNS at Cloudflare does not break mail by itself. Two things do. The first is proxying a hostname that carries mail: Cloudflare documents that MX records are always DNS only and that the hostname an MX points to must resolve to a DNS-only target, because SMTP, IMAP and POP3 do not pass through an HTTP proxy. The second is Email Routing, which takes over the MX records for the domain when you enable it. Check both before you blame the mail provider.

Why does my sending platform say the DKIM record is missing when I can see it in Cloudflare?

Two usual causes. If the record is a CNAME pointing at the vendor and it is proxied, Cloudflare flattens it and returns Cloudflare addresses instead of the vendor target, so the lookup does not find the key. Set it to DNS only. If it is a TXT record holding a 2048-bit key, remember that a TXT string caps at 255 characters. Google documents splitting the key into several quoted strings inside the same record value, or falling back to a 1024-bit key when the DNS host cannot store the longer form.

Can I have two SPF records at Cloudflare, one for each provider?

No. Cloudflare states that more than one SPF record on a domain is not allowed and stops things working, and RFC 7208 is the reason: a checking server that finds two records starting with v=spf1 gets a permanent error rather than a policy. Merge every sender into a single TXT record, then count the DNS lookups, because RFC 7208 allows a maximum of ten per evaluation and each include, a, mx and redirect mechanism spends from that budget.

SPF, DKIM and DMARC on Cloudflare DNS

Say a twelve-person architecture studio moves its DNS to Cloudflare on a Friday afternoon because someone read that it makes the website faster. It does. On Monday the office manager mentions that no client email has arrived since the weekend, and the three invoices sent on Friday are sitting in spam folders. Nobody touched Google Workspace. Nobody touched the mail flow. What changed is the zone the rest of the internet reads.

Cloudflare is a reasonable place to keep a small company's DNS, and we move clients onto it on purpose. It also has two behaviors that are right for a website and wrong for mail, and both fail without announcing themselves. This is the setup we run on a Cloudflare zone, and the two settings we check before anything else.

Before you add a record: is this zone actually authoritative?

The first thing we check on any client domain is where the nameservers point. A business that has been going since 2018 usually has three plausible DNS panels: the registrar, a web host, and whatever was added later. Records typed into a panel that is no longer authoritative look perfect in the interface and do nothing at all. On a Cloudflare migration this is more common than it sounds, because the registrar's own DNS editor keeps working long after the nameservers moved.

Confirm the nameservers, then edit in one place only.

The three records, and the types Cloudflare expects

All three authentication records are TXT records. Cloudflare's DNS documentation is explicit about this and about why: the dedicated SPF record type was deprecated in RFC 7208, so SPF belongs in a TXT record, and there is no DKIM record type and no DMARC record type either. If you go looking for them in the type dropdown you will not find them, and that absence sends a fair number of people off to a support forum.

For a domain whose mail runs on Google Workspace, the set looks like this. Google publishes smtp.google.com as the single MX value, and notes that accounts set up before 2023 may still carry the older aspmx hosts, which remain supported and need no change if mail is working.

Type: MX    Name: @                  Value: smtp.google.com                   Priority: 1
Type: TXT   Name: @                  Value: v=spf1 include:_spf.google.com ~all
Type: TXT   Name: google._domainkey  Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...
Type: TXT   Name: _dmarc             Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Two details on that block. Google's guidance is to remove other MX records once the new value is in, because mail may not work correctly if old entries survive, and to allow up to 72 hours for new MX values to be recognized. And the DKIM value is generated in the Admin console, not copied from anywhere else: the default selector prefix is google, and the string is unique to your domain.

The DKIM key is where a size problem appears. A TXT string caps at 255 characters, and Google documents that a 2048-bit key does not fit in one, so it can be truncated or come back out of order. Google's instruction is to split the key into several quoted strings inside the same record value, and to fall back to a 1024-bit key only if your DNS host cannot store the longer form.

Footgun 1: a proxied hostname that carries mail

Cloudflare's proxy is the orange cloud. Proxied means visitors resolve your name to Cloudflare's anycast addresses and traffic passes through Cloudflare first. DNS only, the gray cloud, means Cloudflare answers with the value you typed and stays out of the way.

For mail, DNS only is the only option that works. Cloudflare documents that MX records are always DNS only and cannot be proxied, and, the part people miss, that the hostname an MX record points to must also resolve to a DNS-only target. Proxy a name that handles mail and sending servers try to connect to Cloudflare instead of your mail server, and SMTP, IMAP and POP3 do not pass through an HTTP proxy.

A Google Workspace domain is partly protected here by luck, because its MX points at a Google hostname outside the zone. The version that still catches these domains is the CNAME. Cloudflare flattens proxied CNAME records and returns Cloudflare addresses in place of the target, which is exactly what you want for a website and exactly wrong for a DKIM CNAME from Mailchimp, HubSpot or Klaviyo, or for a vendor's domain verification record. The provider looks up the name, gets an address instead of what it published, and reports the record as missing. Cloudflare's own guidance says records used for email routing or third-party domain verification should be DNS only, and that CNAMEs proving domain ownership should not be proxied.

So: walk the A, AAAA and CNAME records and set every one touching mail, sending vendors or domain verification to DNS only. TXT records are never proxied, so the SPF, DKIM and DMARC values themselves are not at risk. The names around them are.

Footgun 2: Email Routing quietly owning your MX

Cloudflare Email Routing forwards mail addressed to your domain on to a mailbox somewhere else. It is genuinely useful for a domain that has no mail service of its own. It is a problem when the domain already has one, because Cloudflare documents that turning Email Routing on means Cloudflare manages your MX records and may create further DNS records automatically, and that those MX records can conflict with the ones your mail provider needs.

The reverse direction is worse, because it is silent. Cloudflare documents that disabling Email Routing removes every routing-related record it added at the root of the domain, MX, SPF and DKIM included. A domain that was relying on the SPF record Cloudflare published loses SPF entirely the moment somebody switches the feature off during a tidy-up, and nothing visibly breaks until a week of mail has been filtered.

Cloudflare's documented order for changing provider is the one we use: unlock the routing records, add the new provider's records alongside them, verify that mail is flowing, then remove the old ones. Two questions cover this on an audit. Does the zone hold MX records nobody remembers creating? Is Email Routing enabled on a domain that already has a mailbox provider?

One SPF record, and the ten-lookup budget

Cloudflare's troubleshooting guidance states the rule plainly: more than one SPF record on a domain is not allowed and stops things working. Go to DNS and Records, filter for TXT entries beginning with v=spf1, and if there are two, merge them into one rather than picking a favourite. This is not a Cloudflare quirk: RFC 7208 defines the behavior, and a checking server that finds two SPF records has a permanent error rather than a policy.

Merging is where the second limit bites. RFC 7208 allows a maximum of ten DNS lookups while evaluating an SPF record, and every include:, a, mx and redirect mechanism spends from that budget. Merging a mail provider, a CRM, an invoicing tool and a newsletter platform into one record is exactly how a domain lands at twelve lookups, and receivers may treat the result as a permanent error and reject or flag the mail. Cloudflare's DMARC Management section checks your record against that limit for you. We wrote the full method for getting back under it in SPF: too many DNS lookups.

Verify from outside the dashboard

A record that exists in the Cloudflare editor has not necessarily reached the world, and the dashboard cannot tell you whether Gmail likes the result. Check from outside: resolve each name, confirm exactly one SPF record, confirm the DKIM selector returns a key rather than an address, confirm the DMARC record parses, then send a real message to an inbox you control and read the headers.

If the headers show DKIM passing but DMARC failing, the problem is alignment rather than DNS, and the DKIM failure guide covers what that looks like on Workspace.

TTL and the part that is just DNS

Cloudflare lets you set a TTL per record, and the honest version of propagation is that resolvers hold the answer they already have for as long as the previous record told them to. Lowering the TTL after you make a change does nothing for the caches that are already holding the old value. Lower it a day or two before a planned MX move, make the change, then put it back. Google's own note that MX changes can take up to 72 hours to be recognized is the number to quote when someone asks why the mail is not moving yet.

DMARC, and reading the reports before you tighten anything

Start the DMARC record at p=none with a rua address. At p=none nothing is rejected, and the aggregate reports tell you which senders are failing, which is the information you need before moving to quarantine or reject. Cloudflare's documentation says DMARC Management sits under Email and DMARC Management in the dashboard, and that once a domain's DNS is on Cloudflare the feature is available with no additional configuration or cost, checked 14 September 2026. If you would rather paste a single report and read it now, our DMARC analyzer does that, and how to read an aggregate report decodes the XML field by field.

Give it a few weeks of real traffic. Moving to enforcement before you have identified every legitimate sender is how invoices and CRM mail get rejected by your own policy, and that sequence is in moving DMARC from p=none to p=reject.

The order we work in on a Cloudflare zone

Confirm the nameservers really point at Cloudflare.
Set every mail-related A, AAAA and CNAME record to DNS only.
Check whether Email Routing is on, and whether it owns MX records it should not.
Fix MX, then confirm mail is flowing before touching authentication.
Merge to exactly one SPF record and count the lookups.
Generate DKIM in the provider's console and publish the full key, split into quoted strings if it needs it.
Publish DMARC at p=none with a reporting address.
Verify from outside, then read reports for a few weeks before enforcing.

How Guanacos Tech helps

We do this end to end for small and mid-sized companies across North America and Latin America: audit the zone, find the proxied record or the routing feature that is doing the damage, publish and verify the three records, track down the senders nobody remembered, then read DMARC reports before moving the policy to enforcement. If your mail went strange after a DNS move and you would rather not guess, run the checks above, or book a call and we will look at the zone with you. The full engagement is described in email deliverability.

SPF, DKIM and DMARC on Cloudflare DNS: the exact records, and the two settings that silently break mail