Why do Smart OSH emails arrive as spam?

When the emails sent by Smart OSH (notifications, Excel exports, authorisations, etc.) end up in the spam folder or are held in quarantine by the client’s filter, it is almost always due to a single reason: the tenant has configured a sender with their own domain that has not authorised our email provider to send on their behalf.

Cause

Smart OSH sends emails through its email provider (SendGrid). If the tenant configures a sender with their own domain (for example @mycompany.com) without having authorised that provider, the messages are not aligned with SPF, DKIM and DMARC for that domain.

The result is that the client’s filters (and those of any external recipient) detect an inconsistency between the visible sender domain and the actual sending infrastructure, interpret it as possible spoofing (identity theft) and, correctly, mark the email as spam or send it to quarantine.

Note

This is not a fault of Smart OSH or the email provider itself. It is the expected behaviour of anti-spam systems when a sender domain has not authorised the infrastructure from which the email is sent.

Where the sender is configured

The sender of the emails is defined in the tenant settings:

Settings >> Sending >> Sender of email dispatches

Solutions

There are two options to resolve this at the root.

Option 1 — Use the default sender ([email protected])

By configuring the sending with our own domain (smartosh.com), the emails are already correctly authenticated by us and stop being marked as spam.

• This is the quickest option and does not depend on the client’s IT team.
• Trade-off: the visible sender ceases to be the client’s domain and becomes @smartosh.com.

Option 2 — Keep your own domain and authenticate it

If the client prefers to keep their own domain as the sender (for example @mycompany.com, or a dedicated subdomain such as @notifications.mycompany.com), they must authorise our email provider to send on behalf of that domain through domain authentication (Domain Authentication).

The process is:

1. The client confirms which domain or subdomain they want to authenticate.
2. Smart OSH provides a set of DNS records (CNAME for DKIM and SPF adjustment).
3. The client’s systems team publishes those records in the DNS zone of the corresponding domain.
4. Once propagated, the emails are signed with DKIM and aligned with SPF and DMARC, and the reason for being marked as spam disappears.

Recommendation

When opting to keep your own domain, it is good practice to use a dedicated subdomain for notifications (for example notifications.mycompany.com) instead of the main domain. This isolates the reputation of automated dispatches from the usual corporate email.

What DOES NOT solve the problem

Adding the outbound IPs of our email provider to the client’s whitelist does not solve the issue. The root cause is the misalignment of DKIM/DMARC with the sender domain, not the IP reputation. Even if the client’s internal servers accepted the emails bypassing the filter, external recipients (other companies, citizens with Gmail, Outlook, etc.) would still receive them as suspicious.

Migrating to another SMTP provider is also not viable: Smart OSH uses SendGrid through an integration that allows tracking the status of dispatches (deliveries, opens, bounces), a functionality necessary for the correct operation of the application.