E-mails not forwarded to inbox

[kevindraai]

Hi Chris,

Great work on implementing email :)
I'm running 3.1.1 and setup for email worked like a charm (after undoing a couple of manual changes Cloudflare).

I've created 2 mail accounts, and I can send mails from both accounts, however I'm not receiving any emails.
Dockflare dashboard shows total e-mails sent & received, but mails received per account = none. (see screenshot)

The Cloudflare email-dashboard shows all inbound-mails being dropped, however after expanding an entry there doesn't seem to be a problem. The inbound-worker has both mailaccounts as triggers (as well as a 5-minute cron).

Sidenote: I used to have the 'simple' version of mail-routing: all mails received by cloudflare were forwarded to my secondary email. I've had to undo some settings to make dockflare mail possible.

Can you help me review my settings and/or other problems that may cause this?

[ChrispyBacon-dev]

Okay, sending is working. If receiving isn’t working, could you please check the CF web page for the K2 storage? See if the email messages are pending. Another question: how was the domain enrollment? There are two users who are having trouble enrolling a domain and obtaining the Cloudflare API token permission. You seemed to have no issues enrolling your domain and setting up your email domain. I’m curious about the difference, as I don’t have any issues either. It must be something I forgot to document while developing.

[kevindraai]

The temp_cache folder has 9 .eml-files. I assume these are the pending mails?
--Update: On the inbound worker I enabled observability. I see that the cronjob processed 9 'buffered email': Processed=9 failed=0. This is repeated each time the cronjob runs. To make sure IDP (Authentik) on the Zone Default Policies (*.tld Wildcards) isn't stopping anything I (temporarily) added the bypass-rule policy to the mail & dockflare ingress rules. Unfortunately no bueno.

Ah, for domain enrollment I had to create an account API-key. After giving it a couple of tries with my 'old' user key and multiple variations of permissions I tried to enroll with an account key.
This after reviewing your code, my 401-error message and the assumption that the user key is accessing a wrong api-uri:

The 401-error message during enrollment points to accounts/$ID/token/verify, instead of user/token/verify api-url. However in your code (dockflare/app/core/email_manager.py) you check for a CF_key starting with cfat:
token = getattr(config, 'CF_API_TOKEN', '') or '' if token.startswith('cfat_'): verify_res = cf_api_request('GET', f'/accounts/{config.CF_ACCOUNT_ID}/tokens/verify') else: verify_res = cf_api_request('GET', '/user/tokens/verify') if not verify_res or not verify_res.get('success'): return perms

So, after creating a new account key I was able to successfully enroll my domain.

[ChrispyBacon-dev]

good news is that the emails are stored and received in the R2 storage which acts as a buffer. question is why its not pushed with you cf inbound worker. can you please try and click on redeploy cf worker?

[kevindraai]

good news is that the emails are stored and received in the R2 storage which acts as a buffer. question is why its not pushed with you cf inbound worker. can you please try and click on redeploy cf worker?

Redeployed and after scrolling down I see mails are 'received'. Not sure if my previous action (bypass policy) already did the trick, because didn't check before pressing redeploy :)
I will undo the policies and check again.. Otherwise perhaps a permanent bypass or a different default zone policy should do it.

[kevindraai]

Okay, this was an easy one to test:
step 1: Kept the bypass-rules as they were: new mails are immediately forwarded to the mailbox.
step 2: Reverted both ingress rules (thus applying zone default policy): mails are not received.
step 3: Apply bypass rule on mail.$domain: mail is forwarded to mailbox.

I assume the webhook gets stuck on the zone default policy.
Not sure if adding the bypass-label by default is suitable for all users.

[ChrispyBacon-dev]

ok but this is a bug. the CF workers should be able to bypass with the webhook secrect that is generated.

found another bug which explaines why you did not receive emails as well. you mentioned you rerolled api? if yes the sha256 for R2 storage bucked is stale but a redeploy workers fixes it.

silver lining is that... I really made sure everything is with a strong security.. specially when it is about emails. so no one can access your R2 bucket or emails on your instance... I look into the default zero trust zone tomorrow. I had this on my radar...

[kevindraai]

I did reroll/recreate the api-key, but that was before a successful enrollment. the workers redeployment was done just now. So the only used api should be the api I enrolled with in the first place.

You did make it very secure. Self-hosting can be a real pain, but solutions like this are great (when it's up and running).
btw thank you for your quick replies!
If you need help sorting out the enrollment api authorization errors pls let me know

-- update:
After doing some more checking I managed to stop receiving mail again. I checked the other issue and repulled the image/ changed API back to cfut (following the readme with correct permissions).
Mails sending: yes
Mails receiving: No

Mails are stored in the R2 temp-cache folder, but not delivered tot the mailbox.
Tried to redeploy workers again (so no stale api)
worker observability now returns a fetch() error:

Dockflare-mail-manager log shows the following:
2026-05-02 00:50:58 INFO app.api.webhook: Inbound webhook: message=10459cea-f512-4e7a-b9f8-5679bb4c7c68 domain=xxxxx.net from=xxxxx@me.com to=kevin@xxxxx.net 2026-05-02 00:50:58 ERROR app.api.webhook: Inbound webhook failed: message=10459cea-f512-4e7a-b9f8-5679bb4c7c68 Traceback (most recent call last): File "/app/app/api/webhook.py", line 212, in inbound eml_bytes = fetch_email_from_r2(r2_key, domain_cfg) File "/app/app/core/r2_client.py", line 44, in fetch_email_from_r2 resp = s3.get_object(Bucket=bucket, Key=r2_key) File "/usr/local/lib/python3.13/site-packages/botocore/client.py", line 606, in _api_call return self._make_api_call(operation_name, kwargs) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/site-packages/botocore/context.py", line 123, in wrapper return func(*args, **kwargs) File "/usr/local/lib/python3.13/site-packages/botocore/client.py", line 1094, in _make_api_call raise error_class(parsed_response, operation_name) botocore.exceptions.ClientError: An error occurred (Unauthorized) when calling the GetObject operation: Unauthorized

it looks like an error in the key distribution?

[ChrispyBacon-dev]

Found the root cause and a fix is already implemented.

The R2 Unauthorized error is caused by a stale boto3 client cache. When the API token is rerolled, the R2 client stays cached with the old credentials so any subsequent R2 fetch fails with Unauthorized. The fix includes the secret in the cache key so a token change always results in a fresh client. This also explains why Redeploy Workers temporarily helped it effectively forced a credential refresh.

Fix is already pushed to stable branch. Now if there is a change DockFlare will restart mail-manager and mail manager is refreshing itself with the strap boot. It should "self fix" these stale records. I tested it however I'm not 100% sure as there might be some edge cases. Again I really appriciate your feedback.

The Zone Default Policy blocking the webhook is a separate issue I have on my radar and will investigate.

[kevindraai]

I did a docker pull && docker compose. Docker log now shows
2026-05-02 10:52:48 INFO mail-manager: Config bootstrapped from DockFlare Master 2026-05-02 10:52:48 INFO app.core.scheduler: Scheduler: push subscription cleanup scheduled every 7 days 2026-05-02 10:52:48 INFO app.core.scheduler: Scheduler: alias expiry scheduled every hour 2026-05-02 10:52:49 INFO mail-manager: Mailbox sync complete 2026-05-02 10:52:49 INFO mail-manager: Domain config sync complete (1 domains) 2026-05-02 10:52:49 INFO mail-manager: Starting mail-manager on port 8025

However, for some reason the credentials are still not refreshed, even after a worker redeployment:
2026-05-02 10:53:14 INFO app.api.webhook: Inbound webhook: message=59dee29b-b590-45bb-8b34-94c3b45f8c21 domain=xxxx.net from=xxxx@me.com to=kevin@xxxx.net 2026-05-02 10:53:14 ERROR app.api.webhook: Inbound webhook failed: message=59dee29b-b590-45bb-8b34-94c3b45f8c21 Traceback (most recent call last): File "/app/app/api/webhook.py", line 212, in inbound eml_bytes = fetch_email_from_r2(r2_key, domain_cfg) File "/app/app/core/r2_client.py", line 44, in fetch_email_from_r2 resp = s3.get_object(Bucket=bucket, Key=r2_key) File "/usr/local/lib/python3.13/site-packages/botocore/client.py", line 606, in _api_call return self._make_api_call(operation_name, kwargs) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/site-packages/botocore/context.py", line 123, in wrapper return func(*args, **kwargs) File "/usr/local/lib/python3.13/site-packages/botocore/client.py", line 1094, in _make_api_call raise error_class(parsed_response, operation_name) botocore.exceptions.ClientError: An error occurred (Unauthorized) when calling the GetObject operation: Unauthorized

I also did a docker stop dockflare-mail-manager && docker rm dockflare-mail-manger. Any stale caches should be removed (unless the credentials are stored in the persistant storage of the mail-manager?)

[ChrispyBacon-dev]

Ok... I tried to replicate and I think I got it now. for me after reroll API it stays in sync. - repull dockflare image and restart, redeploy worker once and fingers crossed mail-manager will get the sync for R2 auth.

[kevindraai]

Yes, pull/restart and worker redeploy did the trick.
Now a new (minor) error appeared:
WebPushException: Push failed: 403 Forbidden Response body:{"reason":"BadJwtToken"}
But.. mails are delivered to the mailbox :)

[ChrispyBacon-dev]

yes I'm aware of that, I saw it too in my logs . those are push notification delivery failures (sending web push to devices with stale/expired VAPID subscriptions). eg. when web mail browser notification are activated but maybe stale... it will still work , I want to look into that for an automatic expire of stale web push subscriptions. I believe it has something to do with API change an no cleanup of the VAPIDs.

[kevindraai]

Perhaps an auto-renewal of the push subscription each time the web app is accessed? Or a manual “reset” function from the settings page