Senders and branding
Every Verify code reaches your user as an email, SMS, WhatsApp, or Telegram message. Email, SMS, and WhatsApp send under one of two Bird-managed identities, Bird Verify or Authifly, and you choose which one per channel. Telegram uses its own verified notification account and has no sender to select. Email can also send from a domain you have verified yourself.
The senders live on the Configure page's Channels tab, one row per channel:
Who your codes come from
Email, SMS, and WhatsApp offer up to three levels of branding:
- Bird Verify is the default and needs no setup. Codes go out under Bird's own identity.
- Authifly is Bird's standalone verification brand. Codes go out under Authifly instead, so no platform vendor appears in front of your users. A recipient who looks it up finds authifly.com, which explains that Authifly delivers one-time codes on a business's behalf.
- Your own sending domain applies to email, so codes come from an address at your domain. See Branded email sender.
Select an identity per channel on the Channels tab, where the Email, SMS, and WhatsApp rows each offer Bird Verify (default) and Authifly. You can also pin a different identity for one country in country configuration; a per-country choice wins over the channel default for recipients there.
Switching identity changes the sender your user sees. It leaves the code, the expiry, and every other verification setting untouched.
The email your user receives
By default the code email arrives from Bird Verify <otp@verify.bird.com> with the subject "Your verification code". On Authifly it arrives from Authifly OTP <otp@verify.authifly.com>, with the same subject.
The body is a single card: an eyebrow naming the shared identity, the code set large in monospace type, the expiry line, and a disclaimer. Each identity carries its own colours. The plain-text version carries the same content:
Exemplo de código
Your verification code is 123456.followed by the expiry window with a warning never to share the code, and a closing line that the email is safe to ignore if the code wasn't requested.
The expiry line shows the configured code lifetime on the first send and the remaining window on a resend. OTP email carries no open or click tracking because it contains no link, and tracking pixels can hurt transactional-mail deliverability.
The SMS your user receives
The SMS leads with the code, where a glance (and the OS's code autofill) looks first:
Exemplo de código
123456 is your verification code. It expires in 10 minutes. Do not share it.Where a country permits branded alphanumeric sender IDs, the code arrives from Bird Verify or Authifly, matching the identity you selected. Countries that require a local number or a short code show that sender instead. The message text reads the same under either identity.
The WhatsApp message your user receives
On WhatsApp the code arrives from a Bird-managed business number as an authentication-template message: the Bird Verify number by default, or the Authifly number when you select that identity. WhatsApp fixes the layout for authentication templates, so the body leads with the code and offers a one-tap Copy code button:
Exemplo de código
123456 is your verification code. For your security, do not share this code.The code is the only variable, and the copy is fixed by WhatsApp's authentication-template format, so it reads the same in every country.
The two identities differ in one visible way. Under Authifly the message carries a second button, a reply reading "I didn't request a code", which WhatsApp generates for authentication templates. The Bird Verify template has one button, the code copy. WhatsApp owns the extra button end to end: a tap stays inside WhatsApp, reaches no webhook, and leaves the verification running. There's no API call to cancel a disowned verification; treat the reply as a signal in your own fraud logic.
Delivery is an ordinary WhatsApp template send, so the recipient needs WhatsApp on that number; where they don't, or the message can't be delivered, the verification advances to its next channel.
The Telegram message your user receives
On Telegram the code arrives from Telegram's own verified notification account. Telegram controls the account, message layout, and wording, so the channel has no sender to select, and neither Bird nor your organization appears as the sender:
Exemplo de código
123456 is your verification code.The recipient's phone number has to be registered with Telegram. A number is checked for whether it can receive a Telegram message before one is sent, and where the answer is no, the verification advances to its next channel without a message going out.
Branded email sender
You can replace the shared email sender with an address on your own domain, so codes arrive from verify@yourdomain.com instead of a Bird-managed address. The prerequisite is a verified sending domain in the same workspace: Verify won't send from a domain you haven't proven you own.
On the Channels tab, open the Email row's sender control, select Custom sender, choose a local part (the part before the @) and one of your verified domains, and save. Selecting Bird Verify (default) or Authifly switches back to a shared identity at any time. You can also pin a different sender for one country in country configuration; a per-country choice wins over this default for recipients there.
Two things to know before you switch:
- The body stops naming an identity. A shared identity's body tells the reader that Bird Verify or Authifly will never ask them for the code. Sending from your own domain drops that name rather than replacing it, because your recipients have no relationship with either: the eyebrow reads "Verification" and the warning becomes "Don't share it with anyone." The subject and the code layout are unchanged, you cannot customize the template, and the copy is English only.
- The domain must stay verified. A domain that a live configuration pins cannot be deleted, but a domain whose DNS regresses stops being able to send. Sends from it then fail, and delivery advances to the verification's next channel rather than silently reverting to a shared identity. Fix the domain, or switch the channel back to a shared identity.
Next steps
| Page | What it covers |
|---|---|
| Sending domains | Registering and verifying the domain a branded sender needs |
| Country configuration | Pinning senders and channel order per country |
| Sending verifications | The send and check calls and verification settings |