Rolling out soon: sender checks and these warnings will appear on new messages after an upcoming update. Until then, initdesk doesn't check senders yet, so a message with no warning has not passed any check.

initdesk checks whether each incoming message really came from the address or account it shows. When a check fails or can't be done, a short warning line appears on that message. The warning never blocks you from replying.

Why checking who sent an email is hard

Email was designed without any proof of who the sender is, so anyone can write any address in the "From" line. Domains added three checks later, called SPF, DKIM and DMARC, which let a domain say which servers may send for it and sign its emails. These checks only help when the sender's domain has set them up, and many haven't, or have set them up loosely. Forwarders and mailing lists often change the email on the way, which breaks the signature even when the email is real.

That means a failed check doesn't prove an email is fake, and a passed check doesn't prove the person is trustworthy. Their account could have been hacked, or the email could come from a lookalike address (for example acme-support.co instead of acme.com) that passes its own checks. No warning doesn't mean safe.

What initdesk does

initdesk doesn't block or hide any email. We show the evidence we have. When the checks pass, you see nothing. When they fail or disagree, you see an amber warning. When we tried to check a new email but didn't have enough information, you see a grey note. Messages we never checked, such as older tickets and tickets created through the API or an import, show no line. When an email was forwarded through Google Workspace, Gmail or Microsoft 365, we use the signed record those providers add to keep the original result. Your team decides what to do, and for anything sensitive (password resets, payment or bank changes, data exports), confirm through a channel you already trust.

What you'll see

The warning belongs to the message it appears on. The first message of a ticket shows who opened the ticket, and each reply in the timeline has its own result. A warning on one message doesn't change any other message or the requester.

What to do when you see an amber warning

Treat the request with extra care, especially if it asks you to:

• change an email address, phone number, or password,
• send money, invoices, or bank details,
• share personal or account data.

Confirm through a channel you already trust before acting. For example, reply to the address on file in a new ticket, or call the customer. See Handling sensitive requests safely.

Don't assume fraud. An amber warning doesn't prove the message is fake, and some real emails get it because of how the sender's company set up its mail. If a customer's real emails keep showing the warning, ask them to have their IT team review their domain's email sending setup (their SPF, DKIM and DMARC records).

Messages that weren't checked

• Older tickets. Messages received before this check existed show no line, because initdesk doesn't recheck old mail.
• Tickets created through the API or an import. These aren't checked, because an API token proves that your integration made the call, not who the customer is. They show no line.

On these messages, no line means "not checked", not "passed".

Forwarding and sender verification

If you forward your support address into initdesk, the way you forward matters:

• Google Workspace, Gmail and Microsoft 365 forwarding keep the original sender's result, so forwarding alone doesn't cause a warning.
• Other forwarders and mailing lists can make real emails show "Sender authentication failed", because they change the message on the way. To avoid this, forward with Google Workspace, Gmail or Microsoft 365, or use one of the methods in Handle support email.

Other channels

• WhatsApp and Telegram: messages are checked against the account the provider reports. When the provider confirms it, no warning appears.
• Support portal: customers who signed in with their email code count as verified.
• Your team: replies and internal notes from signed-in teammates count as verified for the teammate, not the customer.

Developers can read the same result through the API. See the initdesk Developer Reference.