Set up email with an AI assistant

A connected AI assistant can take a merchant through their store's email setup with the hosted MCP server (https://api.tringify.com/mcp/store): adding a sending domain, getting its DNS records in place, adding sender addresses, choosing the default sender and reply-to address, keeping sending healthy and removing a domain or address safely. Every response carries the same text Store Admin › Settings › Email shows, in the request language. The assistant shows that text as given and follows next_action; it never works out labels, next steps or eligibility itself. Reads need store:settings.email:read, changes store:settings.email:write; installed apps can never hold email access.

Call get_email_overview. badge.label says how the store sends now (Sending from your domain, Setting up your domain or Sending from your Tringify address). steps are always sending domain, sender address, default sender and reply-to, in that order; show each label and message. next_action is the single next step, with the tool and arguments to call; it is absent when everything is done and healthy.

list_email_domain_candidates lists the domains the store can send from (bases) and those still connecting (pending). Let the merchant choose, for example mail.example.com, then call create_email_domain. Adding a sending domain needs a verification code (add_email_domain, email_identity, <store_id>|<domain>); see step 7. A domain outside the store's connected domains is refused with EMAIL_DOMAIN_OUTSIDE_STORE_DOMAINS and details.next_action connect_domain: connect the base domain first (see Connect a domain with an AI assistant).

The new domain's setup has five steps (add_domain, add_records, verifying, verified, ready) and six records: three Tringify email signing (DKIM) CNAME records, two Tringify email bounces records (MX and TXT on bounce.<domain>) and one email policy (DMARC) TXT record. When setup.path is tringify_dns, Tringify hosts the DNS and writes every record itself: tell the merchant there is nothing to add. When it is your_dns, show next_action.message and each record's label, type, host, value (and priority) and status_text, which says what public DNS shows now (Found, Not found yet, Found … instead).

Missing DMARC or bounce records never stop sending: the domain stays Ready to send and issue (dmarc_missing, dmarc_invalid, mail_from_missing, mail_from_drift) with next_action (add_dmarc, add_records) says what to fix. If verification stopped (signing records not found within 72 hours), next_action.key is restart_verification with restart_email_domain, which needs a code and creates new signing records.

When the domain is ready, next_action is add_sender with create_email_sender and {"domain": "mail.example.com"}. Ask the merchant for the address (for example orders@mail.example.com) and its purpose (transactional or marketing). Then next_action is set_default_sender: set_default_email_sender makes it the address order and account emails come from. Both need a code.

Sender addresses don't receive email. When next_action is set_reply_to, ask which inbox should receive customers' replies and call update_email_reply_to (code needed). Tringify emails a confirmation link to it; until it is opened next_action is confirm_reply_to, telling the merchant to open the link.

get_email_overview returns health: badge (Healthy, Needs attention, Action needed), metrics (bounce rate, spam complaint rate, addresses Tringify no longer emails) and issues, each with title, message (the cause) and fix. Bounce rate is a warning from 2% and critical from 5%; spam complaints from 0.1% and 0.3%; rates count from 100 sends in 30 days. A domain whose signing records changed or whose base domain is no longer connected can't send: its issue says so, emails go out from the Tringify address meanwhile, and the merchant is notified.

Adding or removing a sending domain, restarting verification, changing the MAIL FROM subdomain, adding or removing a sender, choosing the default sender and changing the reply-to address need the code Store Admin asks for. A tool called without one is refused with DANGEROUS_CODE_REQUIRED (a wrong one with DANGEROUS_CODE_INVALID) and details.next_action, the exact request_verification_code call. Get the merchant's approval, call it, tell the merchant where the code went (sent_to), ask them for it and call the tool again with otp_code. Never guess or reuse a code.

Call check_email_domain_removal (domain_id) or check_email_sender_removal (address_id). Show its confirm sentence and every impacts[].message: sender addresses removed with the domain, that order and account emails come from the Tringify address instead when it held the default sender, that marketing pauses, and what happens to the DNS records. After the merchant approves, call its next_action (request_verification_code with the given arguments), ask for the code and call delete_email_domain or delete_email_sender with otp_code. Removing the default sender is allowed.

See the Email reference for every field and the OAuth and MCP reference for the tool list.