Debugging Zoho Mail Filters and Auto-Reply for a Custom Domain

Setting up a custom domain email looks simple on the surface: connect the domain, configure MX records, verify delivery, and start using the mailbox. But after setting up Zoho Mail for a custom domain, I ran into a more confusing problem: incoming email worked, but the auto-reply and filter behavior did not trigger the way I expected. This note documents the debugging process for a custom domain email setup where the MX records were already configured, but mailbox automation still needed further checking.

The goal was to use a custom domain email address, such as:

textcontact@example.com

The domain was connected to Zoho Mail, and the basic mail delivery setup was already completed.

At that point, the expected flow was:

textVisitor sends email to contact@example.com
        ↓
Zoho Mail receives the message
        ↓
Filter or auto-reply rule runs
        ↓
Sender receives an automatic response

The confusing part was that the mailbox itself appeared to be working, but the automation layer did not behave consistently.

Before debugging filters or auto-replies, the first thing to confirm is whether the mailbox receives incoming email at all. I tested this by sending an email from another account to the custom domain email address.

If the email does not arrive, the issue is probably not the filter yet. It may be related to MX records, domain verification, mailbox creation, DNS propagation, the wrong recipient address, or a typo in the custom domain email.

If the email does arrive, then the basic delivery path is working. That means the problem is probably in the mailbox rules, auto-reply settings, or filtering logic.

MX records decide which mail server receives email for a domain. In this case, the domain had already been configured for Zoho Mail. Still, it is worth checking because a small DNS issue can make debugging very confusing.

The basic mental model is:

textDomain DNS
   ↓
MX records
   ↓
Zoho Mail servers
   ↓
Zoho mailbox

If the MX records are wrong, email may never reach Zoho. If the MX records are correct but automation does not run, the issue is likely inside Zoho Mail settings.

One important thing to check is whether the address is a full mailbox, an alias, or a forwarding address. This matters because filters and auto-replies may behave differently depending on where the message actually lands.

For example:

textcontact@example.com → real mailbox

is different from:

textcontact@example.com → alias forwarding to another mailbox

If the email address is only an alias or forwarding route, the message may arrive, but the automation rule might need to be configured in the final receiving mailbox instead of the alias address. This is one of the easiest places to get confused.

The next thing to check is whether the auto-reply is enabled inside the correct Zoho Mail account. A common mistake is configuring the right rule in the wrong mailbox.

For example, if the email is sent to:

textcontact@example.com

but the actual receiving mailbox is:

texthello@example.com

then the auto-reply may need to be configured where the message actually arrives.

The question is not only:

textDid I create an auto-reply?

but:

textDid I create the auto-reply in the mailbox that actually receives the message?

Filters can silently fail if the conditions are too narrow. For example, a rule may only apply when:

textTo contains contact@example.com

but the actual message header may route differently if aliases, forwarding, or grouped addresses are involved.

When debugging, it is better to start with the simplest possible rule:

textIf any incoming message arrives,
then apply this action.

After confirming that the rule works, the conditions can be narrowed. A good debugging strategy is:

textStart broad → confirm trigger → narrow condition

not:

textStart narrow → wonder why nothing happens

If multiple filters exist, rule order can matter. One filter may archive, move, label, forward, or stop processing before another rule has a chance to run.

When automation does not behave as expected, I check whether there are multiple filters, whether one filter runs before another, whether any rule stops further processing, and whether the message is being moved before the expected rule sees it.

Even if each rule looks correct by itself, the combined rule order can create unexpected behavior.

Auto-reply systems often avoid sending repeated automatic replies to the same sender too frequently. This prevents loops and spam-like behavior.

That means a test may fail for reasons that are not obvious. For example, if I send five test emails from the same external account, the first one may trigger an auto-reply, while later ones may not.

A better test is to use a different sender account, a fresh subject line, enough time between tests, and one test change at a time. Otherwise, it becomes hard to know whether the problem is the rule or the platform’s anti-loop behavior.

Sometimes the auto-reply may have been sent, but the sender does not see it in the main inbox. I would check the spam folder, promotions folder, updates folder, blocked sender settings, email threading behavior, and whether the auto-reply was grouped under the original message.

This is especially important when testing from Gmail or other mail providers that may sort automated messages differently.

The cleanest debugging flow is:

text1. Send a test email to the custom domain address.
2. Confirm the email arrives in Zoho Mail.
3. Check whether the address is a mailbox, alias, or forwarding address.
4. Create a very broad filter rule.
5. Test with a fresh external sender.
6. Check spam/promotions folders for the reply.
7. Narrow the filter condition only after the broad rule works.
8. Keep one change per test.

This avoids mixing too many variables at once.

A simple test plan can look like this:

textTest 1:
Send email from Gmail to contact@example.com.
Expected result: message arrives in Zoho inbox.

Test 2:
Enable broad auto-reply for all incoming messages.
Expected result: Gmail sender receives auto-reply.

Test 3:
Change condition to "To contains contact@example.com."
Expected result: auto-reply still triggers.

Test 4:
Add filter action, such as label or folder movement.
Expected result: message is labeled or moved correctly.

Test 5:
Retest from a different sender.
Expected result: behavior is consistent across senders.

If the broad rule works but the narrow rule does not, the issue is probably the filter condition. If no rule works but mail arrives, the issue is probably auto-reply settings, account scope, or rule execution. If mail does not arrive, the issue is probably DNS or mailbox routing.

The main mistake is assuming that once MX records are correct, everything else should automatically work.

MX records only solve the mail delivery path. They do not guarantee that filters are configured correctly, auto-replies are enabled for the right mailbox, alias routing behaves as expected, repeated tests will trigger multiple auto-replies, or rules are running in the order expected.

Email automation has more layers than basic email delivery.

The useful mental model is:

textDNS layer:
Does email know where to go?

Mailbox layer:
Does the message arrive in Zoho?

Account layer:
Is the receiving address a mailbox, alias, or forwarding route?

Rule layer:
Do filters match the message?

Automation layer:
Does auto-reply actually send?

Recipient layer:
Does the sender receive or see the response?

Debugging becomes easier when each layer is checked separately.

The biggest lesson is that custom domain email setup does not end at MX records. MX records can be correct while filters or auto-replies still fail.

For future setups, I would separate the process into two stages:

textStage 1: Confirm mail delivery.
Stage 2: Debug mailbox automation.

Trying to debug both at once creates too much confusion.

The practical rule is simple: if the message never arrives, debug DNS and mailbox routing. If the message arrives but automation does not run, debug filters, aliases, auto-reply settings, and rule order. That separation makes the problem much easier to reason about.