Email forwarding not working? Check these 7 things

Before changing settings, send 1 plain test message from an external account through 1 exact route. Note the time and addresses used, then check the destination inbox, junk and quarantine. The checks and logs available depend on your provider.

1. Confirm the exact public address

Start with the address the customer, supplier or office used. Check every character before testing anything else:

• the part before the @;
• the domain after the @;
• missing letters, extra spaces or an old saved address.

A message sent to quotes@example.au tells you nothing about a route configured for quote@example.au.

Use a fresh external account for the test rather than sending only from the destination inbox back to itself. Some providers handle internal and external messages differently, so a plain external test is a clearer starting point.

2. Confirm forwarding is active

The public address and the destination inbox are 2 different parts of the route. Confirm that forwarding is active for the exact public address and that it points to the intended destination.

For example, bookings@example.au may be meant to forward to the owner’s existing inbox but may still point to an old office account. If the route was recently changed, check how long forwarding changes can take before assuming the new setup has failed.

Do not change DNS records or unrelated mail settings as a first response. If you cannot see or confirm the route, ask the provider or administrator responsible for it.

3. Check the destination inbox properly

“Not in the inbox” does not always mean “not delivered”. Search the destination mailbox for the test subject and sender, then check:

• junk or spam;
• quarantine, if the provider has one;
• filters, labels and automatic filing rules;
• blocked senders;
• mailbox capacity or other account warnings.

These behaviours vary by provider. If several people monitor the address, also check whether somebody moved, archived or deleted the message.

4. Run 1 plain external test

Strip the test back to the simplest possible route. From an unrelated external account, send a short plain-text message to the public address with a distinctive, non-sensitive subject such as Forwarding test 14 Aug 10:15.

Do not include links, signatures, images or attachments yet. Wait for the provider’s normal processing window, then record where the message landed. Repeating many tests or changing several settings at once makes the result harder to interpret.

5. Add attachments only after plain mail works

If the plain message arrives, test the real workflow separately. A quote PDF, job photo, plan or invoice may be handled differently because of file size, type or filtering.

Use a small, safe, non-confidential file first. Our guide to testing forwarding with attachments explains the checks without assuming that every provider treats attachments the same way.

If plain mail arrives but the attachment test does not, you have narrowed the problem. Record the file type and approximate size, but do not post confidential files or message headers in a public support thread.

6. Look for conflicting rules or confusing copies

Another rule may redirect the message, send it to multiple inboxes, create a loop or leave a copy somewhere unexpected. Review only the rules connected to the exact public address and destination.

If the route has become complicated, compare forwarding rules and redirects and check whether the source keeps a copy. These distinctions can explain duplicates or an unexpected copy, but they do not confirm the cause in an unseen setup.

7. Escalate with one useful test record

If the route still fails, give the provider or administrator a compact record of the exact test:

• sender and recipient addresses;
• date, time and timezone;
• a non-sensitive subject;
• whether the sender received a delivery or failure notice;
• where you checked for the message;
• whether plain mail worked before an attachment was added.

Ask them to inspect that exact route and timestamp. Avoid sharing confidential message contents, customer documents, tokens or full headers unless a trusted support channel specifically requires them.