When a customer tells you their website is down or their email has stopped arriving, the cause is nearly always DNS. Before you change anything, establish whether Storefront manages that domain's DNS at all.
Domains using Shopco nameservers are yours to fix in Storefront Manager. Domains using custom nameservers are managed at the customer's own DNS provider, and nothing you change in Storefront will reach them.
Work through the steps below in order. Each one rules out a cause before you move to the next.
Before you start
Have the domain name and the customer's account open in Storefront Manager. If the customer reported a specific time the site went down, note it. Most of the causes below are tied to a change someone made.
Step 1: Check the domain is still registered and active
Open the domain in Storefront Manager and look at its status. A domain that has expired or entered redemption stops resolving, and no DNS change will bring the site back until the domain is renewed.
If the status is Expired or Redemption, renewal is the fix, not DNS. See Domain statuses and renewal reminders.
If the status is Active, continue to step 2.
Step 2: Check which nameservers the domain uses
Open the domain's Nameservers section.
Shopco nameservers (a.ns.shopco.com, b.ns.shopco.com, c.ns.shopco.com) mean Storefront serves the DNS zone and you can fix the records yourself. Continue to step 3.
Any other nameservers mean the domain's DNS lives with an external provider. Storefront does not serve the zone, the DNS Records section will not appear on the domain's page, and the customer or their web host has to make the fix at that provider. Tell the customer where their DNS is actually managed, because this is the point most tickets stall on.
To bring the domain under Storefront DNS management, switch it to Shopco nameservers. Copy the existing records first, or the site goes down the moment the switch takes effect. See Transferring systemDNS zones to Storefront.
Step 3: Find out what changed
A zone that worked yesterday and fails today almost always had something change. Match the customer's report to one of the following.
Someone switched the nameservers recently
Nameserver changes propagate across the internet and can take up to 48 hours. If the switch was recent and the records are correct, the answer is to wait.
If the switch happened more than 48 hours ago and the site is still down, the records are the problem rather than the propagation. Compare the current Storefront DNS records against the zone the domain had before the switch. A missing A record takes the website down, and a missing MX record takes email down.
If DNS is broken now and you need the site back immediately, switch the nameservers back to the original provider, then recreate the records in Storefront before switching again.
A DNS record was edited or deleted
Changes propagate based on the record's TTL. The default TTL is 900 seconds, so most changes appear within 15 to 30 minutes, though they can take up to 48 hours. Confirm the change saved correctly in the DNS Records table before assuming propagation is the delay.
Deleted records cannot be recovered. Add the record again manually. For MX and TXT records, get the correct values from the customer's email provider rather than guessing, because a wrong SPF or DKIM value will deliver mail to spam instead of failing outright.
Someone used Reset to Default
Reset to Default applies your DNS template as it exists right now, not as it existed when the domain was registered. If you have updated the template since, the reset applies the current version and overwrites records the customer was relying on. Check the template in Settings → Advanced Settings → Domain Defaults to see what was applied, then re-add anything the customer needs.
The domain was registered recently and never worked
This is a different problem from a site that went down. The DNS template did not apply at registration. The usual cause is that the customer's session expired between clicking a template link and completing the registration, in which case your default template applied instead, or no template applied at all if you have no default set.
Templates also never apply to domains using custom nameservers. Check the nameservers first, then the template's active toggle, then the template ID in the query-string link if you used one. See DNS templates.
When only email stopped
Email failures narrow the search to three record types. Check them in this order:
- MX records point to the customer's mail host. If these are missing or wrong, mail stops arriving.
- TXT records hold SPF and domain verification values. A missing or incorrect SPF record usually means mail still arrives but lands in spam.
- CNAME records hold DKIM selectors, in the format
selector._domainkey.domain.tld(This is an example).
The customer's email provider publishes the exact values these records need. Verify against the provider's documentation rather than copying from another domain, because the values differ per account.
When to contact OpenSRS Support
Contact OpenSRS Support when the nameservers are correct, the records match what the customer expects, more than 48 hours have passed, and the domain still does not resolve. Include the domain name, the records you have confirmed, and the time the problem started.
Related articles
- Storefront nameservers
- Managing DNS records
- Transferring systemDNS zones to Storefront
- DNS templates
- Domain statuses and renewal reminders
Full Storefront documentation
These troubleshooting articles cover what to do when something breaks. Setup guides, feature documentation and the Storefront API reference all live on the Storefront documentation portal.