iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To set up catch-all email, choose the service that will receive your domain’s inbound mail, point the domain’s MX records to that service, verify the destination mailbox if required, and enable a rule that sends unmatched recipients to that destination. A catch-all handles addresses that do not have individual mailboxes or aliases, including many typing errors. It does not automatically provide spam filtering or permission to send as every address.
What catch-all email does
A catch-all (sometimes written catchall) is an inbound routing rule for a domain. When a message arrives for a local part that has no explicitly configured mailbox, alias, or route, the mail service sends it to one designated destination. For example, if sales@example.com exists but somebody writes to saels@example.com, a working catch-all can deliver that message to the mailbox you selected.
The rule applies only after the receiving service has accepted mail for the domain. Your domain’s MX (Mail Exchange) records determine which service receives that mail; the catch-all rule then decides what to do with recipients that the service cannot match. This is why enabling a switch in one provider while another provider still controls the MX records has no reliable result.
Free tools Windows power users keep installed
One-click scans. No signup required.
What a catch-all can and cannot do
- Can: collect mail sent to unrecognized or nonexistent addresses at the configured domain.
- Can: reduce the chance that a legitimate message is lost because the sender mistyped the local part.
- Cannot be assumed to do: filter spam, create individual inboxes, or authorize outbound sending from every collected address.
- May also collect: unwanted mail, automated messages, and messages intended for somebody else.
Plan a review and retention process before turning it on. A single mailbox can become noisy, and forwarding every typo may expose messages to a destination that was not intended by the sender.
Decide which service controls inbound mail
First identify the service that should accept mail for the domain. There must be one deliberate inbound architecture: the MX records should lead to the service where the catch-all behavior is configured. Do not assume that two unrelated services can independently control the same domain’s inbound delivery. Some providers publish multiple MX records for redundancy, but those records still belong to the same receiving service or architecture.
Hosted mailbox service versus forwarding
| Approach | How it works | Important checks |
|---|---|---|
| Hosted mailbox service | The provider receives mail, stores it in a mailbox, and applies its routing policy. The catch-all address is usually another mailbox in that service. | Confirm the provider’s MX values, catch-all feature, mailbox licensing or eligibility, and whether the destination must be verified. |
| Forwarding to an existing mailbox | The provider receives mail for the domain and forwards unmatched recipients to an address you already use elsewhere. | Verify the destination, understand forwarding and spam behavior, and confirm that the receiving service accepts forwarded messages. |
| Custom processing | Some services can send unmatched mail to a programmable endpoint, such as a Worker, instead of a mailbox. | Check the provider’s supported destination types, limits, error handling, and storage responsibilities. |
The available sources do not establish a complete price, deliverability, or eligibility comparison for all providers. Check the current plan requirements for the service you select rather than assuming that catch-all is included in every tier.
Check your current MX records
- List the domain’s current MX records at your DNS host or with a DNS inspection tool.
- Identify which service owns those records and whether the domain already has working mailboxes.
- Decide whether you are replacing that inbound service or adding the catch-all within it.
- Record the existing SPF, DKIM, and DMARC records before making changes so you can preserve legitimate sending services.
If a provider’s setup guide tells you to remove other MX records, treat that as an instruction for that provider’s architecture, not a universal rule. Microsoft’s Microsoft 365 guidance, for example, tells administrators configuring its domain setup to delete other MX records. Use the exact MX values and record instructions supplied for your chosen account.
Set up catch-all with Cloudflare Email Service
Cloudflare states that Email Service requires Cloudflare DNS: “You must be using Cloudflare DNS to use Email Service.” Read the current onboarding instructions at Cloudflare’s route-email setup documentation before changing records. Cloudflare documents catch-all entries for apex domains, so confirm that your intended domain is supported if you are trying to catch mail for a subdomain.
1. Confirm Cloudflare DNS is authoritative
Move or verify the domain’s authoritative nameservers in Cloudflare before starting Email Service onboarding. If another DNS provider remains authoritative, Cloudflare cannot publish the required records through its DNS service and the Email Service setup will not be complete.
2. Start Email Service onboarding
- Open the Email Service route-email setup in the Cloudflare dashboard.
- Select the domain you want to receive mail for.
- Review the DNS records Cloudflare proposes to add. The onboarding flow can include MX records for incoming routing and TXT records for SPF and DKIM.
- Apply the records only after checking that they do not unintentionally remove records needed by another active mail system.
Cloudflare says its DNS changes usually take 5–15 minutes for domains using Cloudflare DNS, but propagation can take up to 24 hours globally. These are estimates, not guarantees; continue testing only after the records are visible from outside your local network.
3. Add and verify the destination
- In Email Routing, add the mailbox that should receive unmatched mail.
- Open the verification message sent to that mailbox and complete the verification link or action.
- Return to the routing settings and confirm that the destination is shown as verified.
Cloudflare requires a verified destination before you can use that address in a forwarding rule. If the verification message is missing, check the destination’s spam or quarantine folders and confirm that the address was entered correctly.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 114. Enable the catch-all rule
- Open Routing Rules in the Cloudflare dashboard.
- Enable Catch-all.
- Select the action that forwards unmatched messages.
- Choose the verified destination mailbox, or select a Worker if your account and design use that supported destination.
- Save the rule and check that it is active.
Cloudflare describes a routing rule as a pairing of an email pattern with a destination. Its catch-all behavior forwards every message sent to the domain, including misspelled local parts, to the selected destination. Catch-all entries are documented for apex domains only; do not assume that the same control automatically covers subdomain.example.com.
Set up catch-all routing in Google Workspace
Google Workspace documents a separate Gmail routing procedure for messages sent to incorrect or nonexistent addresses. Use Google’s current Admin console labels rather than copying steps from another provider.
- Sign in to the Google Workspace Admin console with an account that can manage Gmail settings.
- Go to Apps > Google Workspace > Gmail > Routing.
- Create a routing rule for messages sent to incorrect or nonexistent recipients.
- Configure the rule to modify the message and replace the recipient with the chosen catch-all address.
- Save the rule, allow the change to become active, and send a test message to an address that has no configured mailbox or alias.
The exact wording and placement of controls can change in the Admin console. Google’s documented flow is specific to Gmail routing; Cloudflare’s Routing Rules path is not a substitute for it. Confirm that the domain’s MX records already point to Google’s mail service before expecting this rule to run.
Configure DNS authentication without breaking existing mail
Catch-all delivery and sender authentication are related to the same domain but solve different problems. MX records identify the inbound service. SPF, DKIM, and DMARC help receiving systems evaluate messages sent from your domain. A forwarding rule does not, by itself, create valid outbound authentication.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
MX: select one inbound authority
Copy the MX hostnames and priorities from the selected provider’s current setup instructions. Do not combine values copied from different providers unless the provider explicitly documents that architecture. If you leave an old provider’s MX records in place, some senders may deliver to the old service and never reach the catch-all rule.
Rank #3
- Fortinet FortiMail-VM virtual appliance for all supported platforms. 8 x vCPU cores
- Fortinet SW FML-VM08
- Manufacturer Part: FML-VM08
SPF: keep one policy and merge requirements
SPF is published in a TXT record. Cloudflare advises merging its SPF requirement with an existing SPF record instead of publishing conflicting SPF records. The same principle applies generally: inspect the current policy, add the mechanisms required by services that genuinely send mail for your domain, and keep a single coherent SPF record. Copy the exact value supplied for your account; do not reuse a record shown for another provider.
DKIM: publish the provider’s selector
DKIM uses a provider-specific selector and public key, usually published as a TXT or CNAME record. Add the selector and value generated for your sending service. A Cloudflare Email Service authentication record and a Microsoft-specific record are not interchangeable, and a receiving-only forwarding setup does not eliminate DKIM requirements for a separate service that sends mail.
DMARC: align policy with your sending inventory
DMARC evaluates SPF and DKIM alignment and lets you request reporting or enforcement. Start from the policy appropriate for the legitimate services that send as your domain. Changing DMARC while migrating MX records can affect outbound mail independently of catch-all delivery, so make the two changes deliberately and monitor reports if you use them.
Cloudflare’s authentication documentation distinguishes Email Routing records from Email Sending records. Use the records for the actual service and account in use, and recheck the provider’s documentation before publishing exact values because labels and values can change.
Test the setup end to end
Test from an address outside the domain’s own mailbox system so you exercise public DNS and the real inbound path.
- Choose a local part that is definitely not configured, such as a random string rather than a known alias.
- Send a plain test message from an external account to that address.
- Confirm that the message arrives at the selected catch-all destination.
- Send a second message with a deliberately mistyped version of a real address and verify that it follows the same rule.
- Send a message to a known mailbox or alias and confirm that the explicit route still wins over the catch-all.
- Inspect the received headers for the receiving service and forwarding path if delivery is delayed or appears in spam.
Record the test address, time, originating service, and result. This gives you a baseline for troubleshooting after DNS or routing changes.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot messages that do not arrive
The message never reaches the destination
- Check MX records first. They must point to the service where the catch-all rule is enabled. An active rule in a provider that does not receive the domain’s mail cannot process the message.
- Check propagation. Cloudflare says changes are usually visible in 5–15 minutes on Cloudflare DNS but may take up to 24 hours globally. Microsoft describes its DNS changes as typically taking about 15 minutes, with longer delays possible. Treat both figures as estimates.
- Confirm the rule is active. A saved draft, disabled rule, or rule with the wrong domain will not route mail.
- Check destination verification. For Cloudflare forwarding, the destination must be verified before it can be selected.
Only some senders reach the catch-all
Different senders can cache DNS responses for different periods. Compare the public MX result seen by an affected sender with the result seen by your own test. Also check whether the sender is using an old cached route or whether the domain has multiple MX records belonging to different services.
Recommended Free Tools
Known addresses are being caught unexpectedly
Review rule order and the explicit mailbox or alias configuration. A catch-all should handle unmatched recipients; a provider may apply more-specific routes before it, but the exact precedence is provider-specific. Remove obsolete rules and test a known address separately from a random nonexistent one.
Forwarded mail is rejected or classified as spam
Catch-all documentation describes inbound routing, not a guarantee of spam filtering or sender reputation. Inspect the forwarding provider’s logs and the destination mailbox’s quarantine. Keep SPF, DKIM, and DMARC records aligned with the services that actually send mail, and avoid claiming that catch-all forwarding authorizes outbound mail from every collected address.
SPF validation reports a conflict
Look for more than one SPF TXT record at the domain. Merge the requirements of the legitimate sending services into one provider-supported policy, following the selected provider’s current syntax. Do not paste a second example record beside the first.
Operational and security considerations
Control volume and retention
Because the rule accepts unrecognized recipients, it can collect automated notifications, bot traffic, and messages intended for former users. Use mailbox quotas, retention rules, or a dedicated review folder where your provider supports them. If the mailbox is shared, restrict access to people who need to read potentially sensitive misdirected mail.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Protect the destination
Enable strong authentication and recovery options on the destination mailbox. A catch-all concentrates messages that might otherwise have gone to separate addresses, so compromise of that mailbox can expose a wider set of correspondence.
Decide whether you need the feature permanently
A catch-all is useful during a migration, for monitoring abandoned addresses, or for a small domain where occasional typos matter. For a high-volume public domain, explicit aliases and rejection of unknown recipients may provide better control. Review the collected messages after an initial period and disable the rule if its noise or privacy cost exceeds its benefit.
Quick Recap
Provider differences to verify before changing DNS
| Question | What the documented paths establish | What you must verify for your account |
|---|---|---|
| Where is the catch-all configured? | Cloudflare uses Routing Rules; Google Workspace uses Gmail Routing in the Admin console. | Current menu labels, administrator permissions, and rule precedence. |
| What destination can receive mail? | Cloudflare documents a verified address or a Worker. | Whether your selected service supports a mailbox, alias, webhook, or programmable endpoint. |
| Which domains are covered? | Cloudflare documents catch-all entries for apex domains. | Subdomain support and whether each subdomain needs separate MX records. |
| Which DNS records are required? | Cloudflare onboarding can add MX, SPF, and DKIM-related records; other providers publish their own values. | Exact records for your provider, account, sending services, and current DNS host. |
| How long will changes take? | Cloudflare estimates 5–15 minutes usually on Cloudflare DNS and up to 24 hours globally; Microsoft estimates about 15 minutes typically, with longer delays possible. | Whether your registrar, DNS host, and sender caches introduce additional delay. |
Frequently overlooked details
- A catch-all is not the same as a plus-addressing feature. Plus addressing adds a tag to an existing mailbox address; catch-all handles recipients that are otherwise unmatched.
- Changing MX records can interrupt existing mail if the old service still contains the only copies of messages. Confirm migration and retention requirements before switching.
- Adding an SPF record for a receiving or forwarding service does not automatically cover every system that sends mail for your domain.
- Exact dashboard labels and DNS values are provider- and account-specific. Recheck the current documentation immediately before implementation.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
