Email Domain Verification (DNS TXT)
Email domain verification is one of the most important setup steps for the shared inbox channel. It can look like a small technical task, but it decides whether inbound email can be safely associated with your organization.
When teams skip this step or rush it, they usually run into confusing launch behavior. Messages may not route, test emails may appear inconsistent, and setup can feel broken even when other settings are correct. In reality, the system is waiting for proof that your organization controls the sending domain.
That proof is done through DNS TXT verification.
What Verification Actually Does
In the Email Inbox settings flow, you add your domain, then Jardine gives you a TXT record name and TXT record value. You publish that exact record in your DNS provider. After DNS propagation, you trigger verification.
This gives your support system a reliable identity anchor. Without domain verification, inbound email routing cannot safely assume that mail addressed to that domain belongs to your organization context.
A helpful way to think about this is: OAuth proves account access, but DNS TXT proves domain ownership. For shared inbox email, domain ownership is the core trust signal.
In the UI, this appears as domain status transitions. A domain starts in a non-verified state, and after successful verification it moves to verified. That status is not cosmetic. It is what enables safe inbound mapping behavior for email flows.
A Clean Setup Sequence
The most reliable way to set this up is to follow one sequence without skipping ahead.
Start in Settings -> Email Inbox and add your domain, for example example.com. The interface returns DNS verification details including TXT name and TXT value.
Then open your DNS provider and create the TXT record exactly as provided. This is where most errors happen: extra spaces, missing prefixes, wrong host field, or record added to a different DNS zone than the one actually serving your domain.
After saving the record, wait for DNS propagation. Depending on provider and TTL, this can be quick or can take longer than expected. If verification fails immediately after record creation, that often means propagation is not complete yet, not that your setup is wrong.
Back in Jardine, run domain verification again. Once verification succeeds, status updates to verified and the rest of the email setup path becomes much smoother.
At that point, you can continue with forwarding and inbound flow checks using the support inbox address shown in Email settings.
How This Fits Into Real Support Operations
Let’s say your team wants customers to email support@example.com, and you want Jardine to process that traffic in the same decision loop used by your other channels.
With verification complete, you can safely connect your mailbox forwarding flow to the managed support inbox address. Now incoming customer email can enter Conversations and be handled consistently with your knowledge, routing, and ownership policies.
Without verification, this flow is fragile. You might still see partial setup progress, but dependable routing behavior is much harder to achieve.
This is why teams that launch successfully treat domain verification as a readiness gate, not an optional checkbox.
Common Failure Patterns and Fast Fixes
The most common failure is record mismatch. The TXT name or value in DNS does not exactly match what the settings screen generated. Re-copy both fields and re-apply.
The second common issue is DNS location mismatch. Teams sometimes update DNS in one provider while authoritative DNS is managed elsewhere. Confirm which nameservers are authoritative for your domain before troubleshooting deeper.
The third issue is propagation timing. Verification attempts immediately after record creation can fail even when record values are correct. Wait and retry.
A fourth issue is domain confusion in organizations with multiple domains. If support mail is routed through support.example.co but only example.com is verified, inbound behavior may not match expectations. Verify the actual domain involved in routing.
Launch Guidance
Treat email domain verification as the foundation for shared inbox reliability. Complete it early, verify it carefully, and only then move to higher-level behavior testing.
Once verified, continue with Shared Inbox Email to finish forwarding and operational flow checks. If you are also connecting other channels, this same discipline helps: establish trust and ingress reliability first, then tune policy behavior second.
A stable support operation starts with trusted ingress. Domain verification is the email version of that principle.