## TL;DR
Zendesk rejects attachments by file extension against an allowlist, and "file type not allowed" means the extension is not on it. Check the extension first (a renamed file still carries its real type in some flows), then have an admin add the type to the allowlist if it is legitimate. Do not coach users to rename extensions to dodge the list; that defeats the security control.

## The query

```text
zendesk "attachment rejected: file type not allowed"
```

## Use this when

- Uploads fail with file type not allowed
- Agents need to accept a new file type from customers
- A previously accepted type starts being rejected
- You are documenting attachment policies

## Not for

- File size limit rejections
- Virus or malware scan rejections
- API attachment upload errors
- Email attachments not appearing

## Steps

### 1. Identify the actual file extension

Check the real extension, not what the user calls it. Files saved without extensions, double extensions, and renamed files (report.exe renamed to report.pdf) all fail or misbehave. Confirm what the file actually is.

Expected output: the true file type identified.

### 2. Check the allowlist in admin settings

Compare the extension against the configured allowed types. Allowlist changes by admins explain "it worked last month" cases. Note whether the block is global or channel-specific.

Expected output: extension confirmed absent (or present) on the allowlist.

### 3. Add legitimate types through the admin, not workarounds

If the type is safe and needed (a CAD format for a hardware vendor, a data format for support), have an admin add it to the allowlist. Renaming tricks and zipping to dodge the list undermine the control and confuse the next agent.

Expected output: type added to the allowlist with a documented reason.

### 4. Offer the user a safe alternative format

While waiting on the allowlist change, ask for a PDF export, a screenshot, or a text extraction of the content. Most support needs are met by a readable rendering, not the original file.

Expected output: the needed content received in an allowed format.

### 5. Document the decision

Record which types are allowed, why, and who approved additions. Attachment policy drifts without a log, and the next "add this type" request restarts the debate from zero.

Expected output: an allowlist decision log.

## Template: the reply

```text
Hi [Name], our system does not accept [extension] files, so the upload was blocked.

Could you send the content as [PDF / screenshot / text]? That will come through fine.

I have also asked our admin team to allow [extension] uploads since it is a legitimate format for [use case]. I will let you know once that is enabled.
```

## Variant phrasings

### zendesk allowed attachment types

Step 2. The allowlist is the reference answer.

### cannot upload file to zendesk ticket

Steps 1 and 2. Real type, then the allowlist.

### add file type to zendesk allowlist

Step 3. Admin change with a documented reason.

## Why it happens

Attachment allowlists exist because tickets are a malware delivery vector: customers upload files, agents open them. The blocklist-or-allowlist tradeoff favors allowlists in support contexts, which means legitimate-but-unusual formats get caught. The rejection is the control working; the fix is curating the list, not bypassing it.

## Edge cases

- Email channel attachments: email clients may strip or rename attachments before Zendesk sees them. Check the raw inbound email.
- Executables in archives: zipped executables may pass the extension check and fail a deeper scan. That is a different rejection with a different fix.
- Admin changes take time to propagate: retest after a few minutes, not instantly.
- API uploads enforce the same list. Integration file types need allowlisting too.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TP9G8g32TPQz7vMuYpwQow