How Inspection Email Sending Limits and Delivery Works
Source: autosoft-workshop/app/controllers/inspections_controller.rb, workshop_mailer.rb
- Daily email sending limits are enforced by subscription tier: Trialing accounts can send 9/day, Active and limited_active accounts 249/day, Full active accounts 3,000/day
- If the company's email address is verified, emails are sent from the company's own address; if unverified, emails come from the system default address
- The default email subject is "Inspection Report from {company_name}" — this can be customized
- The inspection report link is always appended to the email body regardless of what the user types
- When requesting customer approval via email, the system changes the inspection status, appends a verification code, and logs the transaction
- Spam detection runs on inspection emails — suspicious content may block delivery
- Amazon SES region is selected based on the production URL: Australian sites route through the AU SES region
- The company name has commas stripped in the email From header to prevent header injection issues
- Multiple recipients are supported by separating addresses with semicolons, commas, or spaces
- Remote attachment fetching (pulling files from URLs to attach) disables SSL verification — this is a security concern but prevents failures from self-signed certificates
Support scenarios
- "I can't send any more inspection emails today" → the account has hit its daily limit based on subscription tier (9/249/3,000)
- "The email came from a weird address, not our company email" → the company's email address is not verified; they need to verify it to send from their own domain
- "The customer says the email looks like spam" → spam detection may be flagging the content, or the unverified sender address reduces deliverability
- "I sent to multiple people but only one received it" → check the separator format; recipients must be separated by semicolons, commas, or spaces
- "The email has an attachment link but the certificate is invalid" → remote attachment fetching bypasses SSL verification, so this should still work; the issue may be elsewhere