Your inbound forwarding address — format and security

When this article matters

You're either thinking about whether the forwarding address is safe to share with a vendor or filter, or your address accidentally got published somewhere and you want to know what the damage is. This article explains exactly how the address is structured, what the security layers are, and how to regenerate when needed.

If you just want to set up forwarding for the first time, see set up email forwarding; this article is the deep-dive on the address itself.

What the address looks like

Your address has the form u-<hash>@in.taxiteasy.org — for example, [email protected]. Three parts:

• u- — a fixed prefix marking this as a user-account inbox (vs system addresses on in.taxiteasy.org for webhooks or test routes).
• The hash — 8 to 16 hex characters, generated cryptographically when your account is created. Not derived from your email, your user ID, your name, your signup date, or any other pattern. Two users with adjacent signup dates have completely uncorrelated hashes; you cannot guess one from the other.
• @in.taxiteasy.org — our inbound domain. The in. subdomain is dedicated to inbound email; we don't send mail from it. Resend (our inbound provider) routes any *@in.taxiteasy.org to our webhook, and the hash tells us which account it belongs to.

The hash space is at minimum 16 hex digits = 16^16 = 2^64 ≈ 1.8 × 10^19 possibilities. Brute-force guessing at, say, 1000 attempts/sec (most provider abuse-throttles cap well below this) would take longer than the age of the universe.

Why it's structured this way

Three design choices, each addressing a specific risk:

• Per-account scoping. Every email to your address goes only into your account's pipeline. There's no shared inbox where messages might be routed to the wrong place. Even if a vendor sends to a stale forwarding address you used to have, that old address is dead — it doesn't fall back to a generic inbox.
• Non-guessable hash. Random means an attacker cannot try u-tomklein@… or u-acme-corp@… and expect to inject documents. Even an attacker who knows you're a TaxItEasy user cannot enumerate the right hash. (Compare to providers who use guessable patterns like [email protected] — those are vulnerable to address-enumeration attacks.)
• Provider-agnostic routing. Resend handles inbound for the entire domain; the hash is our internal account identifier. If we ever change inbound provider, addresses don't change — the mapping is on our side, not in DNS.

Two security layers

The address structure protects against one class of attack (random guessing). Two other layers protect against the others.

Layer 1 — address secrecy

The hash being non-guessable matters only if you keep it from leaking. The address is meant to be unknown to anyone who shouldn't email it. Treat it like a password:

• Don't post it on a public webpage, forum, or chat.
• Don't include it in CSV exports you send around.
• Don't share it with your accountant for "easier client invoices" — use invite your tax advisor instead, which has its own audit trail.
• If you must share it (e.g. setting up a forwarding rule in an inbox that auto-confirms with the destination), make sure the rule-setup screen is the only place the address appears.

Layer 2 — sender authentication (SPF + DKIM)

Even if your address leaks, an attacker can't easily spoof a sender. Every inbound email is verified:

• SPF (Sender Policy Framework) — checks whether the sending server is authorised to send mail for the claimed sender domain. Forwarded mail breaks SPF (the forwarder isn't on the original sender's SPF allow-list), which is why we don't require SPF to pass.
• DKIM (DomainKeys Identified Mail) — a cryptographic signature added by the original sending server. Forwarding usually preserves DKIM intact. We require either SPF or DKIM to pass.

A spoofed sender — someone trying to send From: [email protected] from a random server they control — typically fails both SPF and DKIM, because they don't have Hetzner's DKIM signing keys and they're not on Hetzner's SPF allow-list. The message is rejected at our inbound webhook before it ever enters your account; the rejection is logged as email.inbound_rejected_auth in your audit log, with the actual sender IP and the failure reason.

If a sender passes both SPF and DKIM but you still don't trust them (e.g. a phishing-aware sender who has set up their own legitimate domain), the message lands in your Activity log and you can ignore it.

What we keep, what we discard

Field	Stored?	Notes
Sender address	Yes	For audit log + classifier learning.
Send date	Yes	For audit log + duplicate detection.
Subject line	Yes	For audit log + classifier features.
Email body (plain text)	No	Read once for classification, then dropped.
Email body (HTML)	No	Same as plain text — read once, dropped.
Inline images	No	Not extracted.
Attachments (PDF, JPG, PNG, HEIC)	Yes	Run through Documents pipeline, encrypted, stored.
Other attachments	No	Stripped at intake.
Email headers (full set)	No, only fields above	We retain only the fields needed for audit / classification.

The "body is read once and dropped" design is deliberate. Even if you forward a deeply confidential email body, the body itself is not retained on our side — only the attachments are. The classifier produces a label (invoice / receipt / statement / irrelevant) and a confidence score, and those are kept; the source text is not.

Regenerating the address

If your address ever leaks — published to the wrong audience, shared with someone you no longer trust, used by a forwarding rule on an old corporate mailbox you can't access — you can regenerate.

Settings → Email integration → Regenerate forwarding address. The old hash stops accepting mail immediately (any email to the old address bounces with "550 5.1.1 user unknown"); you get a new hash to forward to.

After regeneration, you'll need to:

• Update any auto-forwarding rules in Gmail / Outlook / Apple Mail / iCloud / Fastmail / wherever you'd previously configured them. The old address is dead.
• Update any sender-side configuration (e.g. if a vendor lets you set the destination for invoice emails, change it to the new address).
• Optionally, tell vendors / collaborators who had the old address that you've rotated.

Regeneration is non-destructive on your data side. Past extractions stay; the audit log is intact; nothing about the forwarding history is rewritten. Only the address itself changes.

There's no limit on how often you can regenerate. If you accidentally regenerate (typo, slip of the click), you'd have to redo the rules with the new address — you can't roll back to the old one.

Troubleshooting

My address accidentally got published / shared widely. Regenerate immediately (Settings → Email integration → Regenerate forwarding address). Then update your auto-forwarding rules. The exposure window between leak and regeneration is the only time a third party could inject mail, and even then they'd be subject to the SPF/DKIM check — so the risk is constrained to authenticated mail from domains they control.

Someone tries to send me a fake invoice via my forwarding address. If they don't pass SPF / DKIM — which a typical spoofed sender doesn't — the message is rejected before it enters your account; the rejection appears in Settings → Audit log with the sender IP. If they pass authentication, meaning they sent the email from a legitimately-configured server they control, the message lands in your Activity log; you can review and ignore. Forwarded fake invoices from a domain they control are fundamentally indistinguishable from forwarded invoices from a domain the actual vendor controls; the protection here is human judgment, not authentication.

Can I see who sent what? Yes — Settings → Email integration → Activity log. Every inbound email with sender, date, subject, classification (invoice / receipt / statement / irrelevant), confidence score, number of attachments extracted, and a deep-link to the resulting document if one was created.

I want to set up multiple forwarding addresses (one per project). Not currently — each account has exactly one forwarding address. The use cases (per-project tagging, per-client attribution) are better solved by companies: each company has its own forwarding address. So one account with three companies = three forwarding addresses.

Can I make the address shorter / more memorable? No — that would defeat the non-guessability property. The hash is random for a reason.

My address bounced an email and I don't know why. Check Settings → Audit log for the rejection entry. Common reasons: SPF + DKIM both failed (spoofed sender or weirdly-configured forwarder), attachment exceeded 20 MB, attachment was an unsupported format. Each rejection includes a specific reason code.

Related

• Set up email forwarding — using the address in practice
• How to disconnect an email account — the direct-OAuth alternative cleanup
• What happens when you forward a newsletter — how classification decides what to keep
• Email attachment size and format limits — what attachments survive intake