When to use this article
You set up email forwarding (it worked at first), and now it's not. Invoices that used to arrive automatically aren't showing up in Documents, or the Activity log shows weird rejection reasons. This article walks through the diagnostic flow: did the email even arrive, and if so what happened to it.
For the setup itself, see set up email forwarding. For the address format and security model, see the inbound address explained. For the classification step that decides invoice vs irrelevant, see what happens when you forward a newsletter. For OAuth-based sync (Gmail/Outlook direct connection, not forwarding), see connect Gmail, Outlook, or IMAP.
Step 1 — did the email even arrive
Open Settings → Email integration → Activity log. Three possible states:
- Email shows up + a document was created → Working as intended. If the document didn't appear in Documents, refresh the Documents page (browser-side caching can lag by a minute). Click the document link in the Activity log entry to confirm it's actually there.
- Email shows up + status "rejected" or "skipped" → See the rejection reason. The most common ones are listed in Step 3.
- Email does NOT show up at all → It never reached us. The issue is on the sender side or your forwarding setup. Continue to Step 2.
The Activity log is the authoritative source. If something didn't appear there, we never saw it.
Step 2 — if the email never arrives
The most common causes, in order of frequency:
Wrong address
Verify your forwarding address in Settings → Email integration. There should be a small Copy button next to it. The format is u-<hash>@in.taxiteasy.org — note the in. subdomain. Common typos:
u-<hash>@taxiteasy.org(missingin.) — bounces, doesn't reach usu-<hash>@in.taxiteasy.com(wrong TLD) — doesn't exist, bouncesu-<hash>@inbound.taxiteasy.org(wrong subdomain) — doesn't exist
The hash part is unique to your account; share with no one and don't post it publicly. If you've regenerated your address recently, the old hash is dead and any forwarding rule still pointing to it produces silent bounces.
You regenerated the forwarding address but didn't update the rule
If you clicked Regenerate forwarding address (deliberately or by accident), the old hash stops accepting mail immediately. Any auto-forwarding rule in Gmail / Outlook / iCloud / Fastmail / Apple Mail / wherever still references the old address. Updates to the rule are manual on your side.
Check: open your provider's forwarding rules, compare to the current address in Settings → Email integration.
Gmail auto-disabled your forwarding rule
Gmail occasionally auto-disables forwarding rules after security events on the source account: a password change, a suspicious-login alert, a recent compromise notification. Common trigger: you changed your Gmail password and Gmail flagged the existing forwarding as a possible compromise indicator.
Check: Gmail Settings → Forwarding and POP/IMAP. If your forwarding to in.taxiteasy.org is Disabled or your forwarding addresses list is empty, that's the cause. Re-enable; you may need to walk through Gmail's confirmation flow again (a confirmation code is sent to the destination address — visible in our Activity log).
Outlook / Microsoft 365 admin disabled external forwarding
Microsoft 365 tenants can be configured to block external forwarding (sometimes a default policy in corporate tenants since the 2021 Microsoft 365 security baselines). If you're on a corporate M365 setup and forwarding suddenly stopped after never being touched on your side, ask your IT admin if external forwarding got disabled tenant-wide.
Vendor's mail server can't reach in.taxiteasy.org
Very rare — would affect many senders, not just one. The Activity log would show no emails from anyone, not just one vendor. If you've isolated to a single vendor, this isn't the cause; it's more likely a vendor-side delivery issue.
Your email provider stripped attachments
Some Microsoft Defender or Gmail-quarantine policies strip attachments before forwarding (especially for executable-looking files or invoice-shaped files matching a phishing signature). The email arrives at our Activity log but with attachments_dropped: [list] — the body looks normal but no attachments survived. Look for this specifically if Activity log shows the email but no document.
Quick test
Forward a known good email manually (Forward button in your inbox, paste the address, send). If that arrives in the Activity log, your auto-forwarding rule is the issue (not the address, not us). If the manual forward also doesn't arrive, the address is wrong or our side has a problem.
Step 3 — if the email is rejected
Common rejection reasons (visible in the Activity log entry's reason field):
| Reason code | What it means | Fix |
|---|---|---|
email.inbound_rejected_auth |
SPF and DKIM both failed | Sender's mail provider has misconfigured DKIM. Report to the sender. If you trust the sender despite the failure, contact support — we can whitelist on a case-by-case basis. |
email.webhook_rejected_signature |
Our Resend webhook didn't recognise the signature | Usually a Resend-side issue. We'd see this in our own logs and reach out. If you see it persistently, write to support. |
email.attachment_rejected_format |
Attachment wasn't PDF/JPG/PNG/HEIC | Different attachment, or convert to a supported format. See supported file types. |
email.attachment_rejected_size |
Attachment over 20 MB | Compress, split, or re-export at lower resolution. |
email.quota_exceeded |
Account at monthly document limit | Upgrade or wait for the 1st-of-month reset. See understanding your document counter. |
email.classified_irrelevant |
AI classifier tagged it as not-an-invoice | Open the Activity log entry and click Mark as invoice + extract to force-process it. See what happens when you forward a newsletter. |
email.encrypted_pdf_skipped |
The PDF attachment was password-protected | Decrypt the PDF before forwarding (we can't extract from encrypted PDFs). |
email.duplicate_skipped |
Same attachment hash as an existing document | Already in your account; click through to the existing document. No new document needed. |
email.virus_scan_failed |
ClamAV flagged the attachment | Inspect the attachment locally. If false-positive, support can override; otherwise the attachment is correctly suspicious. |
Each Activity log entry has a "Show details" expansion that includes the full reason, sender IP, original sender, and any classifier confidence scores. Useful for tracing odd cases.
Step 4 — if direct OAuth sync (Gmail/Outlook) stopped
Different path from forwarding — see connect Gmail, Outlook, or IMAP for the OAuth model and how to disconnect an email account for cleanup. The integration page shows the last-sync time and last error if any. If the OAuth token was revoked at the provider's side (Google password change, security event, periodic rotation), you'll see Needs re-auth status; click Reconnect to refresh.
Edge cases
Forwarding worked yesterday, broken today. First diagnostic: what changed on your end? New email rule, vendor changed their sending domain, you regenerated the forwarding address, you changed Gmail password, your provider auto-disabled the rule. Check the Activity log for the last successful email — note its sender + the new sender that's failing; the diff often reveals the cause.
Emails arrive but with weird subject like Fwd: Fwd: Fwd:. Some auto-forwarders chain Fwd: prefixes on multi-hop forwarding. Doesn't break our parser; cosmetic only. The classifier and extractor ignore the Fwd: prefixes when deciding invoice / receipt / statement / irrelevant.
My forwarded emails arrive but with the wrong sender. Some auto-forwarders rewrite the From: header to themselves (the forwarder, not the original sender). Check our Activity log — if sender shows your auto-forwarder address instead of the original vendor, the classifier may miss invoice signals because vendor-specific patterns aren't matched. Try Mark as invoice + extract manually, or configure the rule to use "redirect" (preserves From) instead of "forward" (rewrites From) if your provider supports it. ProtonMail's Sieve and Fastmail's filters both support redirect.
Multi-hop forwarding (my Gmail → my shared inbox → TaxItEasy) is showing the wrong sender. Multi-hop rewrites the From: on each hop. Configure upstream rule to forward directly to TaxItEasy, not through intermediaries, for accurate sender attribution.
I can't tell which forwarding rule fired for a specific invoice. Add a label to your forwarding rule (Gmail: "Forwarded to TaxItEasy" label). The forwarded email retains that label in your Gmail; you can audit your own side.
Forwarding works for invoices but not for receipts. Receipts are a separate classification (different from invoice in the AI classifier's mind). They should still extract; if they're not arriving as documents, check whether they're being classified irrelevant (which they shouldn't be for legitimate receipts). The classifier confidence breakdown in the Activity log entry tells you.
Activity log shows the email was processed but no document appeared. Check Documents → Show all including hidden. Sometimes a low-quality extraction is auto-hidden but the document exists. Or check if the classification was irrelevant (which produces no document by design).
Bulk-forwarded historical emails from 2024 — none arrived. Some auto-forwarding setups time out or rate-limit on bulk forwards. Forward in smaller batches (10-20 at a time, wait a minute between batches). The pipeline processes them all; the rate-limit is your provider's, not ours.
My forwarder uses redirect not forward — does that change anything? Yes, in your favour. Redirect preserves the original sender's SPF and DKIM signatures, which means our authentication check passes more reliably. Forward rewrites the headers and often breaks SPF (the forwarder isn't on the sender's SPF allowlist). Use redirect where your provider supports it (ProtonMail, Fastmail, some IMAP servers via Sieve).
Related
- Set up email forwarding — the setup flow
- The inbound address explained — the address format + security
- What happens when you forward a newsletter — classification step
- Connect Gmail, Outlook, or IMAP — OAuth-based alternative