Why couldn't Voicegram confirm who sent an email?

When an email reaches a Voicegram's saving address, we save it only if it is from your team or from the person who left the Voicegram. An email from anyone else is not saved. We also ask the email provider whether the message really came from the address in its From line. If the provider can confirm it, the email is saved with a small green shield beside the sender's name: Sender confirmed. If it cannot, the email is still saved, and the shield is amber with a question mark: Sender not confirmed. Click or tap either shield to read the short explanation.

A reply from the person who left the Voicegram that shows the amber shield is handled exactly like any other reply: it is saved, it notifies your team, and it shows the New reply tag in your inbox. An amber-shielded email from your team is saved too. The amber shield means one thing: check with the person before you act on it.

When a teammate forwards an email to the saving address, the shield is about the person who forwarded it, and it reads Forwarder confirmed or Forwarder not confirmed. We cannot check who wrote the message inside the forward.

This is a different mark from the Not verified badge you may see beside a sender in your inbox. That badge means the person left the Voicegram without confirming their own email or phone with a code. The shield is about an email saved in the conversation.

Why it happens

Email domains prove who sends from them with records the domain owner publishes. When a domain has not set them up, nobody can tell a real message from that domain apart from a message that only claims to come from it.

This matters here because the saving address is not a secret. The person who left the Voicegram sees it when it is copied in on your email, and so does anyone they forward that email to. Anyone who has it could send an email that claims to come from you or from them. An email with the amber shield may well be genuine, but we cannot tell it from one of those.

The most common cause is a business domain whose email is hosted by a provider, such as Google Workspace, without DKIM signing turned on for the domain, or with no DMARC record. Mail still delivers, but it is signed for the provider's domain instead of yours, so it cannot be tied to your address. Personal addresses at Gmail, Yahoo and AOL are confirmed.

Get emails from your team confirmed

If emails from your team's addresses show the amber shield, the fix is a one-time setting on your domain, made by whoever manages your company email. Ask them to set up email authentication (DKIM and DMARC) for the domain, in two steps:

1. Turn on DKIM signing. In Google Workspace, sign in to the Admin console and go to Apps, Google Workspace, Gmail, Authenticate email. Generate a DKIM record for the domain, add it to the domain's DNS records, then click Start authentication. Other email providers have the same setting in their admin settings.
2. Publish a DMARC record, if the domain does not have one yet. Where the domain's DNS records are managed (often the company the domain was bought from), add a TXT record named _dmarc with the value v=DMARC1; p=none. A policy of p=none is the usual starting point: it does not change where your mail is delivered. Without a DMARC record there is nothing for the check to pass.

Do both: the check passes when the domain has a DMARC record and its mail is signed for the domain itself, which is what step 1 turns on. Emails sent after both are in place are saved with the green shield. Emails already saved keep the shield they have.

Entries you log yourself

Entries a team member logs by hand in the dashboard carry no shield. Someone signed in to your workspace wrote them, so there is nothing to check.