Free Email Aliases With Cloudflare Email Routing: Setup and SPF Fix

Yes, you can give a small site a working support@ or info@ address for free with Cloudflare Email Routing, as long as the domain uses Cloudflare DNS. The address is an alias: mail sent to it is forwarded to an inbox you already have, such as a personal Gmail or Outlook account. Most of the work is checking your records before you touch anything.

Here is the detail that catches people out. Once your MX records point to Cloudflare, any message sent to an address that has no rule gets rejected with "Address does not exist", and the sending server does not try again. So the order of your steps matters more than the clicks.

By the end of this guide you will be able to check your current mail setup, turn on Email Routing without losing mail, merge your SPF record correctly, and prove with a test that the alias works.

What is an email alias, really?

An email alias is an extra address that has no mailbox of its own. When mail arrives for the alias, a service passes it on to a real mailbox somewhere else.

Think of it like a forwarding order at the post office. Letters sent to your shop address get a new label and land in your home letterbox.

With Email Routing, the "post office" is Cloudflare. Your domain's MX record (the DNS record that tells the world which server accepts mail for your domain) points to Cloudflare. Cloudflare reads each routing rule (a simple "this address goes to that inbox" instruction) and forwards the message.

Heads up: this guide covers incoming mail only. Email Routing rules forward mail to you; they do not let you write to your customers as support@example.com. At the time of writing (6 November 2026), Cloudflare says Email Routing is available on both the Workers Free and Workers Paid plans, and lists sending as a separate Email Sending feature marked Beta, where sending to arbitrary recipients requires the Workers Paid plan. When you reply to a forwarded message, the reply comes from your own inbox address.

Before you start

Run through this list before you change any record. Together the items make the change safe to undo.

• Domain on Cloudflare DNS. Cloudflare's docs say you must be using Cloudflare DNS to use Email Service. If your nameservers point somewhere else, read the variants section first.
• A Cloudflare login with access to the account that holds the domain.
• Your current MX and SPF records, written down. Step 1 shows how to read them with dig.
• Access to your existing mailbox provider, if you have one (Google Workspace, a cPanel host, or similar).
• A destination inbox that you can open right now, because Cloudflare sends a verification link to it.
• A second email account for testing, different from the destination inbox.
• Time: about 30 minutes, plus waiting for DNS. Cloudflare says DNS changes can take up to 24 hours to spread globally, but usually finish within 5 to 15 minutes for domains on Cloudflare DNS.
• A backup of your DNS records, exported from the dashboard in Step 1.
• Risk level: low if the domain receives no mail today. Medium if it already has working mailboxes, because Email Routing needs to own the root MX records.

Quick tip: do this at a quiet time of day, when a missed message hurts no one.

Set up your alias, step by step

Step 1: Record your current mail setup

First, find out who answers mail for your domain today. This tells you which path in this guide applies to you.

Run this command in a terminal to see your current MX records:

dig +short MX example.com

Each line is a priority number and a mail server name. If you see nothing, the domain receives no mail today, which is the easy case.

Run this command to list the TXT records at the root of the domain:

dig +short TXT example.com

Look for a line that starts with "v=spf1. That is your SPF record (a TXT record that lists which servers may send mail for your domain). Copy it into a note. Two such lines means a problem to fix first; see Troubleshooting.

Run this command to confirm the domain really uses Cloudflare nameservers:

dig +short NS example.com @1.1.1.1

The two names you get back should match the two nameservers shown on your zone Overview page in the Cloudflare dashboard.

Now take a backup. In the Cloudflare dashboard, go to the DNS > Records page, select Import and Export, then select Export. Save the file somewhere you will find it again.

Step 2: Add and verify your destination address

The destination address is the real inbox that receives the forwarded mail. Cloudflare will not forward anything to it until you prove you own it.

Destination addresses belong to your Cloudflare account, not to one domain, so you can add them before onboarding. Your rules can then go live the moment routing starts.

1. Go to Compute > Email Service > Email Routing > Destination Addresses.
2. Under Destination addresses, enter the inbox address in the inline form and submit it.
3. Open the email Cloudflare sends to that inbox and select Verify email address.

What you should see: the address listed on the Destination Addresses page as verified. If the email does not come, check spam, then resend it from the same page.

Heads up: until a destination address is verified, any routing rule that points to it stays disabled.

Step 3: Onboard the domain to Email Routing

1. Go to Compute > Email Service > Email Routing.
2. Select Onboard Domain.
3. Choose your domain from the list. Review the DNS records Cloudflare plans to add.
4. Select Done.

Cloudflare adds three MX records, a DKIM record, and, if you have no SPF record yet, an SPF record. DKIM (DomainKeys Identified Mail) is a digital signature that proves a message was not changed on the way.

These are the MX records Email Routing uses, as listed in Cloudflare's domain configuration docs:

MX example.com route1.mx.cloudflare.net
MX example.com route2.mx.cloudflare.net
MX example.com route3.mx.cloudflare.net

The priority numbers are assigned automatically by Cloudflare, so do not worry about them.

The DKIM record lives on its own name, with a selector (the label before ._domainkey) that Cloudflare provides:

TXT cf2024-1._domainkey.example.com "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

The p= part is a public key that Cloudflare generates for you.

If onboarding stops with error 2008 and the message "Non-Cloudflare MX records exist", your domain already has mail records from another provider. Stop here and read the section on existing mail providers before you delete anything.

Step 4: Merge your SPF record

This is the step most people get wrong. If your domain already had an SPF record, Cloudflare does not add a second one; you must add Cloudflare's part to the record you have.

When no SPF record existed, Cloudflare adds this one for you:

TXT example.com "v=spf1 include:_spf.mx.cloudflare.net ~all"

When an SPF record already exists, you edit it in DNS > Records and add include:_spf.mx.cloudflare.net right after v=spf1. Keep every other part as it was.

Why this matters: the SPF standard, RFC 7208, says a domain must not have multiple SPF records. If a receiving server finds more than one, the SPF check returns "permerror", which is a permanent error, and the check fails for every server you listed.

Cloudflare's docs give this example of a merged record for a domain that also uses Google:

TXT example.com "v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all"

Keep the record ending in ~all (soft fail) or -all (fail). Cloudflare's troubleshooting page warns against +all, which would allow anyone to send as you.

If you want a refresher on how SPF, DKIM and DMARC fit together, our guide on setting up SPF, DKIM and DMARC for small business email walks through each record.

Step 5: Create the routing rule

Now you tell Cloudflare which alias goes to which inbox. Do this right after onboarding, because mail to an address without a rule is rejected for good.

1. Go to Compute > Email Service > Email Routing.
2. Select your domain.
3. Select the Routing Rules tab.
4. Select Create routing rule.
5. In Email pattern, enter the local part (the bit before the @), for example support, and select your domain.
6. In Action, choose Send to an email.
7. In Destination, choose the verified inbox from Step 2.
8. Select Save.

What you should see: the rule in the list with an Active status. Repeat for info or any other alias you want.

Quick tip: if you create two rules with the same email pattern, only the one shown first in the list processes mail. Keep one rule per address so you always know which one is in charge.

The same tab has a Catch-all rule that forwards mail for every address on your domain, including typos like ifno@. It also forwards spam sent to random names, so start with named rules.

A worked example (made up)

This is a made-up example with example values only. No real customer data is used.

Amina runs a small bakery site at example.com. Her DNS is on Cloudflare. She wants support@example.com to land in her personal inbox, owner@example.net.

Her preflight checks show no MX records and one SPF record that her newsletter tool asked her to add:

TXT example.com "v=spf1 include:spf.mailer.example.org ~all"

She adds and verifies owner@example.net as a destination, then onboards example.com. Cloudflare adds the MX and DKIM records but leaves her SPF record alone, because one already exists.

She edits the SPF record so it now reads:

TXT example.com "v=spf1 include:_spf.mx.cloudflare.net include:spf.mailer.example.org ~all"

Then she creates the support rule pointing to owner@example.net. A test from a friend's account arrives within a few minutes.

Variants that change the steps

Your domain is registered elsewhere, but DNS is on Cloudflare

This is the normal case, and the steps above apply as written. Where you bought the domain does not matter, as long as the nameservers are the two Cloudflare ones.

Your domain uses a different nameserver

If the NS check shows your host's or registrar's nameservers, the world reads your DNS from them, not from Cloudflare. Email Service needs Cloudflare DNS, so you would first have to move the domain to a primary (full) setup on Cloudflare.

That move means changing nameservers at your registrar, and Cloudflare says to wait up to 24 hours for the registrar to update them. Its setup guide also says to turn off DNSSEC (a signing feature that protects DNS answers) at the registrar before you switch, or the domain can become unreachable.

Heads up: records you add in the Cloudflare dashboard while the nameservers point elsewhere are not the records the world sees. If that sounds familiar, read our guide to fixing shadowed DNS records on Cloudflare before you go further.

A CNAME (partial) setup is a different case. Cloudflare's docs say it is only available on Business or Enterprise plans and that these domains are not using Cloudflare's authoritative nameservers.

You already use Google Workspace or cPanel mailboxes

Cloudflare's troubleshooting page says Email Routing requires exclusive control of the root domain MX records. Your current mail server and Email Routing cannot both receive mail for example.com.

What NOT to do: do not delete your provider's MX records just to get past error 2008 while people still read mail in those mailboxes. From that moment, new mail goes to Cloudflare, and any address without a rule is rejected.

If your real mailboxes already live with Google Workspace or a cPanel host, the simpler answer is usually to create the alias inside that provider. If you use cPanel mail, our guide to cPanel business email on IMAP and your phone covers that side.

Another option is a subdomain. Cloudflare lets you add a subdomain to Email Routing under Compute > Email Service > Email Routing, then the apex domain's Settings > Subdomains. Cloudflare adds the required records to that subdomain, so an address like support@help.example.com can forward while your main mailboxes stay as they are.

If you do want to leave your old provider and move fully, follow Cloudflare's order:

1. Add and verify all destination addresses first.
2. In DNS > Records, delete the old provider's MX records, and go straight to the next step, because there is a short window with no MX records at all.
3. Onboard the domain to Email Routing. If you have an SPF record, merge the Cloudflare include as in Step 4.
4. Create every routing rule immediately.

Keep the old provider account open until Email Routing is active. If you still send mail through the old provider, keep its SPF include and its DKIM records; DKIM selectors have different names, so they do not clash.

How to check it worked

Give DNS 5 to 15 minutes, then run these checks.

Run this command to check the MX records:

dig +short MX example.com

You should see three lines, one for each Cloudflare server, like this (your priority numbers will be whatever Cloudflare assigned):

PRIORITY route1.mx.cloudflare.net.
PRIORITY route2.mx.cloudflare.net.
PRIORITY route3.mx.cloudflare.net.

Run this command to check that exactly one SPF record exists:

dig +short TXT example.com | grep spf

You should see exactly one line, and it should contain include:_spf.mx.cloudflare.net. For a domain with no other senders, it looks like this:

"v=spf1 include:_spf.mx.cloudflare.net ~all"

Run this command to check the DKIM record:

dig +short TXT cf2024-1._domainkey.example.com

You should see a value that starts with "v=DKIM1; h=sha256; k=rsa; p=, followed by a long key.

In the dashboard, go to Compute > Email Service > Email Routing > Settings. The DNS records section lists the MX, SPF and DKIM records, and Check that each record there matches the values in this guide.

Finally, send a real test. Use an account that is different from the destination inbox, because Cloudflare notes that some providers discard messages that appear to come from the same account they are delivered to. Send to support@example.com, then check the destination inbox, and look in spam if it is not there.

Troubleshooting

Error 2008: "Non-Cloudflare MX records exist"

Cause: the domain still has MX records from another provider, such as Google Workspace, Microsoft 365, Zoho Mail or a cPanel host.

Fix: if you still need those mailboxes, use the provider's own aliases or a subdomain. If you are moving away, follow the four-step order in the variants section.

Senders get "Address does not exist"

Cause: your MX records point to Cloudflare, but there is no rule for the address they wrote to. The sender's server does not retry.

Fix: create the missing rule in the Routing Rules tab, or turn on the Catch-all rule. Then ask the sender to send again, because their first message is gone.

The rule exists but nothing is forwarded

Cause: the destination address is not verified, so the rule stays disabled.

Fix: open Destination Addresses, check that the address is verified, and resend the verification email if it is not.

The test email never arrives

Cause: you sent the test from the same account that receives it, or the message landed in spam.

Fix: send from a different account and check spam. If the records are brand new, wait 5 to 15 minutes and run the dig checks again.

Two SPF records, or an SPF "permerror"

Cause: Cloudflare added an SPF record and an older one was already there, or someone added a second record by hand. RFC 7208 says more than one SPF record gives a "permerror" result.

Fix: in DNS > Records, look for TXT records that start with v=spf1. Merge every include into one record and delete the rest. If you are unsure which one to keep, compare them with your old SPF notes from Step 1 and keep the one your current senders need.

You cannot edit or delete the MX records

Cause: after onboarding, Cloudflare locks the records it manages, and locked records cannot be edited or deleted from DNS > Records.

Fix: go to Compute > Email Service > Email Routing, select the domain, open Settings, find the record in DNS records and select Unlock. Only the root domain MX, SPF and DKIM records for Email Routing support this.

Pro tips and security notes

Watch the SPF lookup limit. RFC 7208 says the terms that cause DNS lookups (include, a, mx, ptr, exists and redirect) must stay at 10 or fewer, or the check returns "permerror". The count is global, so includes inside the records you include also count.

If merging pushes you over 10, remove the include: entries you no longer need, and ask your mail provider which senders are still active.

Quick tip: after a week, look at your DMARC reports if you have them turned on. They show which servers send as your domain and whether SPF passes. Our guide to reading DMARC aggregate reports explains the XML line by line.

Ask your host or a developer for help when:

• your nameservers are not on Cloudflare and you are not sure who controls the registrar;
• the domain already has working mailboxes and you need to plan a move;
• your SPF record already has many includes and you are close to the lookup limit;
• DNSSEC is turned on and you need to change nameservers.

The one message worth forwarding

If someone else manages your DNS, send them this message as it is:

"Hi, I would like to set up free email forwarding for our domain with Cloudflare Email Routing, inbound only. Could you please: 1) export our DNS records from Cloudflare as a backup; 2) tell me our current MX and SPF records, and whether any mailboxes still use the current MX; 3) if the MX is free to change, onboard the domain under Compute > Email Service > Email Routing and merge include:_spf.mx.cloudflare.net into our existing SPF record so we keep exactly one v=spf1 record; 4) create a rule for support@ to my verified inbox right after onboarding, since mail to addresses without a rule is rejected. I will test from a separate account when you are done. Thanks!"

The takeaway: check your records first, verify the inbox, keep exactly one SPF record, and create the rule the moment Cloudflare takes over your MX.