Setting up your Outbound Email

Microsoft 365 Troubleshooting Guide (OAuth Integration)

If you are using the Connect to Microsoft secure OAuth configuration (instead of legacy SMTP) and encounter errors, please use the guides below to resolve common Microsoft 365 configuration blocks.

Error 1: "Approval Required" or "Need admin approval" during Step 1

• When it happens: While trying to complete the initial authority/permission connection.
• Why it happens: Microsoft requires a Global Administrator to sign off on third-party application permissions for the entire tenant. Standard user accounts cannot grant this access.
• How to fix it: 1. Ensure you are logging into the Microsoft prompt using a Global Admin account. 2. Alternative (Temporary GA Escalation): If your target mailbox user needs to do the setup but isn't an admin, your IT department can temporarily elevate that user account to a Global Admin role. Once the setup is successfully authorized, the GA role can be removed immediately. Cloud Depot's access is saved at the tenant level and will not break when the user is downgraded back to a standard user.

Error 2: "Request does not have the right to send mail on behalf of..." (ErrorSendAsDenied)

• When it happens: Usually occurs when trying to send emails from a Shared Mailbox (e.g., accounts@ or billing@).
• Why it happens: Because Shared Mailboxes do not have passwords, you must log in as a licensed user account during Step 2 of the setup. If that specific user doesn't have permissions to act as the shared mailbox, Microsoft blocks the email.
• How to fix it: Your Microsoft 365 Global Admin must grant "Send As" rights to the user who authenticated the app:
  1. Open the Exchange Admin Center (admin.exchange.microsoft.com).
  2. Navigate to Recipients > Mailboxes and select the Shared Mailbox.
  3. Go to the Delegation tab.
  4. Under Send as, click Edit and add the user account that was used to authorize Step 2 of the Cloud Depot setup.
  5. Click Save. (Note: Microsoft can take 15–30 minutes to apply this permission change).

Error 3: "Mailbox Not Found" or 404 Errors

• When it happens: During configuration or when the system attempts to send an outbound invoice/notification.
• Why it happens: Microsoft Graph requires the sending address to be connected to a physical cloud storage container (a real mailbox).
• How to fix it: Verify the email address in your configuration matches these criteria:
  • No Aliases: Ensure the email address is the Primary SMTP address of the mailbox, not an alias.
  • No Distribution Lists: The address cannot be a standard distribution group or email group, as these do not contain a mailbox backend.
  • Check Licensing: If it is a standard user account, make sure it has an active Exchange Online license assigned. If you want a free alternative that doesn't use a license, convert the account into a Shared Mailbox in your M365 Admin Center.

Error 4: Automated background emails failing / Access Blocked (AADSTS53003)

• When it happens: The connection setup reports a success, but automated, background emails (like late-night invoice runs) fail to deliver.
• Why it happens: Your company likely has a Conditional Access Policy configured in Microsoft Entra ID that restricts access based on the country of origin (Geofencing). While your human users log in safely from your home country, Cloud Depot's background automated servers operate from secure data centers that might trigger this country block.
• How to fix it: Your IT department can easily exclude the integration without lowering your security:
  1. Open the Microsoft Entra Admin Center (entra.microsoft.com).
  2. Go to Protection > Conditional Access and select your Location/Country policy.
  3. Under Target resources, click the Exclude tab.
  4. Search for and select the Cloud Depot Enterprise Application, then click Save.
  5. This keeps your policy active for humans while allowing the background system to successfully relay billing data.

Resolving the "noname" or "winmail.dat" Ghost Attachment Issue 

When sending automated invoices, receipts, or statements through a connected Microsoft 365 mailbox, you might occasionally hear from a customer using Google Gmail or Apple Mail stating they received an extra, unopenable file named "noname" or "winmail.dat" alongside your actual PDF document.

Rest assured, your software is operating correctly, and your actual PDF is safe. This is a known formatting mismatch between Microsoft Exchange and other external email networks.

Why This Happens

Microsoft 365 occasionally packages outbound emails using a proprietary layout format called TNEF (Transport Neutral Encapsulation Format), also known as Rich Text Format.

When an email leaves your Microsoft network and arrives at an external provider like Gmail, Google’s servers do not recognize Microsoft's proprietary structural layout code. Because Gmail doesn't know how to render this hidden data block, it displays it as a blank, generic file attachment and names it "noname".

Summary: The noname file is just harmless Microsoft formatting data that other email providers cannot read.

How to Fix It (For Microsoft 365 Administrators)

This can be resolved permanently across your entire company by changing a single setting in your Microsoft 365 Exchange Admin Center. This forces Microsoft to send clean, universally readable HTML to outside domains instead of proprietary Rich Text.

Have your IT Administrator follow these quick steps:

1. In the left-hand navigation menu, go to Mail flow > Remote domains.
2. Click on the Default domain profile (this profile governs all outbound emails sent outside your organization).
3. Look for the section labeled Use rich-text format (you may need to click Edit text and character set depending on your dashboard view).
4. Change the setting from its current value to Never.
5. Click Save.

Note: Microsoft cloud servers can take anywhere from 10 to 30 minutes to replicate this setting globally. Once applied, all future outbound attachments will deliver cleanly without the ghost file.