If a Gravity Forms notification arrives without its uploaded file, start with that notification's attachment setting and the file available to the mail process. A link in the message is not the same as a MIME attachment. Confirm the file was saved before changing SMTP settings.
Identify one entry and one notification
Create a synthetic submission with a small harmless file and an inbox your team controls. Record the form ID, entry ID, notification name and upload field. Check that the entry contains the expected file and that an authorized administrator can access it through the intended workflow.
In the relevant form notification, inspect the Attachments option. The Gravity Forms notification reference states that enabling it attaches files uploaded through File Upload fields. Check the actual notification being sent, because an admin message and a customer receipt can have different settings.
Locate where the file disappears
| Stage |
Evidence to compare |
| Entry saved |
File field references the completed upload |
| Notification selected |
Correct notification and attachment setting |
| Email constructed |
Expected attachment included without exposing contents in logs |
| Provider accepts message |
Message ID and any size or policy rejection |
| Mailbox receives it |
Attachment present, stripped or quarantined |
If even the small control file is missing, investigate configuration and file access before testing a large customer upload. If only larger files fail, compare the complete encoded message size with the provider's documented limit. File size alone does not represent the size of the email transmitted.
Small control: Configuration before size. Remote storage: Authorized worker access. Large file: Compare full message limit. Privacy: Keep uploads protected. Explanatory checklist, not a customer test result.
Review custom code and offloaded storage
The gform_notification filter can modify a notification before it becomes an email. Check code snippets and custom integrations that alter attachments. Do not paste an additional attachment snippet into production without finding out whether another callback already supplies or replaces the list.
A remote URL stored in an entry is not automatically a readable local file for every mail path. If uploads are moved to private object storage, verify how the installed integration retrieves an authorized attachment at send time. A logged-in browser successfully downloading the file does not prove that a background mail worker can access it.
Do not make the upload bucket public to solve the problem. Also avoid writing file contents, signed download URLs or customer filenames into broadly accessible logs. Use a synthetic filename and report only whether the required read succeeded.
Compare original submission with resend
Send one controlled notification after the identified correction, then submit a new test entry. If resending succeeds but the original submission does not, compare timing: the file may be moved, processed or made available later in the workflow. If the reverse occurs, investigate retention or expiring access rather than assuming the setting changed.
Use the notification troubleshooting guide when the whole message is missing. Attachment diagnosis should begin only after the selected notification and destination are established.
Verify recipient access and retention
Confirm the intended recipient receives the expected file and that unrelated notifications do not gain attachments. Emailing a file creates another copy outside WordPress, so review whether an authenticated portal link is more appropriate for sensitive submissions. This is a workflow decision, not a reason to expose private uploads.
HandL WP can trace missing form attachments using the synthetic entry, notification configuration, storage integration and provider disposition. Keep the original upload intact until the failing stage is understood.
References reviewed October 11, 2026. Examples are explanatory, not customer test results.