Copy-paste DNS instructions stall sending-domain setup because the customer has to translate exact values into a registrar's own form, and nothing tells them whether a failure is a typo or a wait. Connecting the DNS provider removes the translation: the product reads the zone, shows the exact records, and writes them after the customer approves.
The records themselves are simple. The handoff is not. A customer pastes a DKIM key into an unfamiliar screen, waits, and sees a status that does not change. This post covers where that handoff breaks and what changes when the DNS host is connected instead.
Where copy-paste setup breaks
Every step below is small. Together they decide whether a customer finishes setup or opens a support thread.
The host field means something different at each provider. Samva's DNS records table names a record by its full name. GoDaddy wants the name without the zone's suffix, so mail.example.com becomes mail, and a domain added as updates.example.com becomes mail.updates. Namecheap appends the zone name to Host the same way. Paste the full name and the record lands at mail.example.com.example.com. The GoDaddy and Namecheap guides spell out the suffix rule for exactly this reason. Using @ where a subdomain belongs fails in a different way: it puts the record at the root of the zone.
The same record lives in different panels. At Namecheap, TXT records go under Host Records while the return-path MX goes under Mail Settings, and switching that panel to Custom MX can disturb the mail setup the customer already has. A customer who follows a generic checklist can finish half of it without noticing.
The values are long and exact. The DKIM key is longer than 255 characters. Most hosts accept it as one entry; some reject it and need it split into 255-character segments. A dropped character or an added trailing dot produces a record that exists but does not match.
Records can collide. Only one SPF policy can exist at a name, and a CNAME cannot share a name with another record. A customer reading instructions cannot see what already occupies that name.
Waiting looks the same as failing. DNS changes take minutes and sometimes longer to reach resolvers. If the page only says "pending", the customer cannot tell a slow cache from a wrong record, so they re-enter the records, or stop. DomainKit's comparison of manual DNS instructions with an automated flow lists these failure modes, including quoting rules for TXT values that differ between registrars.
What verification should tell the customer
Manual setup works when the product is honest about each record. In Samva, each row in the records table reads Found, Missing, Different value, or Not checked, and the domain is done when the page says Ready to send. Different value points at a typo or a stale record. Missing points at a save that did not happen or an edit at the wrong DNS host. Samva keeps checking in the background and Check now reads the zone straight away. That turns "something is wrong" into a row to fix. See Verify your sending domain for the full flow.
This is the fallback for every domain. It is also the part of the experience that automatic setup shortens.
What changes when the DNS provider is connected
When a domain's nameservers point at Cloudflare or Vercel, the customer connects that account instead of copying anything. Samva sets up customer domains with DomainKit, an open-source TypeScript library, and the flow follows its plan, approve, apply sequence:
- Read the zone. Samva reads the current DNS before proposing anything.
- Show a plan. Each record is Will add (missing), Already there (exact match, left alone), or In the way (a different record holds the name). Samva never replaces a record that is in the way.
- Approve once. Add N records applies the plan the customer reviewed. If DNS changed after the plan was built, the apply stops and the customer checks again for a fresh plan.
- Verify. Samva keeps checking public DNS, because a provider accepting a record does not mean every resolver can see it yet.
The host-formatting, quoting, and suffix questions disappear because the provider's own API receives the record, not a person typing into a form. Collisions show up in the plan before anything is written. A partial failure is recoverable: retry, and records already added show as Already there.
The reasoning behind that design is in DomainKit's case study of how Samva uses it. The customer-facing steps are in Set up DNS automatically.
What still needs a person
Automatic setup is not universal. It is offered when the nameservers already point at Cloudflare or Vercel. Every other DNS host uses the manual records and a provider guide. A record that is in the way still needs a decision from the customer, because Samva will not overwrite it. And connecting a provider does not make DNS propagate faster: the verification status is still the thing to watch.
Check your own setup path
If you ship a product that asks customers to publish DNS records, walk through your own instructions as a customer would. Count the places where someone has to translate a host name, paste a long value, or guess whether a wait is normal. Each is a place to either show the exact value, check it for them, or write it for them once they approve.
For authentication itself, email authentication explains what SPF, DKIM, and DMARC prove. For a domain that is ready, warming it up is the next step before volume.
