Custom Sending Domain with YeshID

Last updated: July 30, 2026

YeshID can send onboarding and access emails from your own domain instead of the default YeshID sender. So instead of a new hire seeing an email from notifications@yeshid.co, they see one from onboarding@mail.yourcompany.com — a sender they recognize, on a domain you control.

A custom sending domain is a good fit if you want YeshID’s automated emails to look like they come from your company, improve deliverability under your own domain reputation, or satisfy a brand or security requirement that outbound mail originate from your domain. Setup is a one-time task: you add a sending subdomain and a from address in YeshID, publish a few DNS records at your DNS provider, and verify. After that, eligible emails send from your domain automatically.

Custom Sending Domain is a gated feature. If you don’t see Sending Domain under Settings, talk to your YeshID contact about enabling it for your account.

What it gives you

Recognizable sender. Onboarding and access emails come from your domain, so your people trust them instead of marking them as spam.

Your domain’s reputation and controls. Mail is sent under a subdomain you own, with SPF and DKIM records you publish — so it aligns with your existing email authentication setup.

No disruption if something’s off. If your custom domain isn’t verified (or DNS drifts later), YeshID quietly falls back to the default YeshID sender so emails still go out. Note that this fallback covers an unverified domain — a verified domain that is missing its MX records will still send, but some recipients won’t receive it. See “Add the MX records” below.

Before you begin

Make sure you have:

Admin access in YeshID.
A sending subdomain you control — for example mail.yourcompany.com. Use a dedicated subdomain for sending, not your root domain. The subdomain must belong to a domain your organization has already verified in YeshID (typically through your directory or Google Workspace).
Access to your DNS provider (Cloudflare, Route 53, GoDaddy, etc.) so you can add the records YeshID gives you.

Key terms

Term	What it means
Sending domain	The subdomain YeshID sends mail from, e.g. mail.yourcompany.com. This is the domain you authenticate with DNS records.
From address	The address recipients see in the From field, e.g. onboarding@mail.yourcompany.com. Must be on your sending domain.
DNS records	The TXT, CNAME, and MX entries you add at your DNS provider so the email provider can prove you own the domain and send on its behalf (SPF, DKIM, and related records).
Sending records	The SPF and DKIM records that authenticate your mail. These are the records verification checks.
MX records	The two records that make your sending subdomain reachable. Verification does not check these, but some mail providers require them. See “Add the MX records”.
Verified	The state once the sending records are found and valid. Until a domain is verified, emails fall back to the default YeshID sender. Verified does not mean your MX records are in place.
Default YeshID sender	The standard YeshID from address used for all accounts without a verified custom domain, and used as the automatic fallback.

Set up your sending domain

In YeshID, go to Settings > Sending Domain.
Enter your Sending domain (e.g. mail.yourcompany.com) and a From address on that domain (e.g. notifications@mail.yourcompany.com).
Select Save domain. YeshID registers the domain with its email provider and returns the DNS records you need to publish.
In the DNS records section, copy each record (Type, Host/Name, Value) and add it at your DNS provider. Use the copy button next to each value to avoid typos.
Add the two MX records described below. They are not shown in the DNS records table, and you must add them manually.
Once the records are in place, select Verify DNS records.
When the records are found and valid, the domain is marked Verified and your eligible emails start sending from your domain.

DNS changes can take time to propagate. If verification reports not verified yet, wait a bit and try again — you don’t need to re-enter anything.

You can leave and come back to this page; YeshID re-checks the live status from the email provider each time, so the DNS table and verification state always reflect reality.

Add the MX records

In addition to the records shown in the DNS records table, add both of these MX records on your sending subdomain:

Type	Host/Name	Value	Priority
MX	your sending subdomain (e.g. `mail`)	`mxa.mailgun.org`	10
MX	your sending subdomain (e.g. `mail`)	`mxb.mailgun.org`	10

Both records must be present. The priority value is not critical, as long as it is the same for both. As with the other records, enter the Host/Name the way your DNS provider expects — most want the relative label (mail), not the full subdomain.

Verification does not check these records. Your domain will show Verified once SPF and DKIM are valid, whether or not the MX records exist. Add them anyway.

Here is why they matter. Every message YeshID sends from your domain carries a return address on your sending subdomain, something like bounce+...@mail.yourcompany.com. Before accepting a message, some mail providers look up that domain and require it to have an MX or A record. A subdomain with only SPF and DKIM has neither, so those providers refuse the message outright. Providers that skip this check accept it normally.

In practice this means mail reaches some recipients and silently fails for others. Apple and iCloud addresses are the most common casualties; Gmail recipients typically receive everything, which is why the problem can go unnoticed. Adding the two MX records above resolves it.

Which emails send from your domain

Once your domain is verified, YeshID sends onboarding and access emails — the welcome and identity-access emails a new hire receives during onboarding — from your custom from address.

Other system emails (for example, admin digests and notifications not tied to a specific person’s onboarding) continue to send from the default YeshID sender. The goal is to brand the emails your people receive, where a recognizable sender matters most.

Changing or removing your sending domain

Both actions live on the same Settings > Sending Domain page once a domain is configured.

Action	What happens
Change domain	Lets you enter a new sending domain and from address. You’ll need to add new DNS records — including the MX records — and verify the new domain. Until the new domain is verified, onboarding and access emails fall back to the default YeshID sender, and the previous domain is removed from the email provider.
Stop using custom domain	Removes the domain entirely. It’s deleted from the email provider and onboarding and access emails go back to the default YeshID sender. To use a custom domain again later, you’ll add it, re-create the DNS records, and verify from scratch.

Troubleshooting

Situation	What it means	What to do
Verification says not verified yet	The email provider can’t yet see all the required DNS records — usually DNS propagation, a typo, or a missing record.	Re-check each record against your DNS provider exactly as shown, then wait and select Verify DNS records again. Propagation can take minutes to hours.
Emails are still coming from the default YeshID sender	The domain isn’t verified, or a DNS record changed and the domain is no longer valid.	Open Settings > Sending Domain and check the status. Re-verify if needed. YeshID falls back to the default sender whenever the custom domain isn’t valid.
A DNS record shows Not found	That specific record is missing or incorrect at your DNS provider.	Copy the exact value from the table and add or fix that record, then verify again.
Some recipients get the email and others never do	Your sending subdomain is most likely missing its MX records. Personal addresses at Apple or iCloud are the usual casualties, while Gmail recipients receive everything normally.	Run `nslookup -type=MX mail.yourcompany.com` against your sending subdomain. You should see `mxa.mailgun.org` and `mxb.mailgun.org`. If nothing comes back, add both — see “Add the MX records”. A domain showing Verified can still be missing them.
A new hire says they never got their access email	The access email goes to the employee’s personal email address, not their new work address.	Check the personal inbox and its spam folder. If that address is at Apple or iCloud, also confirm your MX records are in place.

Tips

Use a dedicated subdomain (like mail. or notifications.) rather than your root domain, so YeshID’s sending reputation is isolated from your primary mail.
Keep the DNS records in place. Removing them later will invalidate the domain and silently revert emails to the default YeshID sender.
Add the MX records at the same time as the rest. They’re easy to skip because verification passes without them, and the resulting failures only show up for some recipients.
Verify before you announce. Confirm the domain shows Verified and send yourself a test onboarding before telling your team the change is live. Test to a non-Gmail address — ideally iCloud — since Gmail will accept mail that stricter providers reject.

Notifications with YeshID