Do I still need SPF and DKIM if Tiendanube sends from its own address?

No. While the store sends from an address on Tiendanube’s domain, Tiendanube’s authentication covers it and your DNS is not involved. The records become necessary the moment you switch the sender to an address on your own domain, because then you are the one vouching for a server you do not run.

Why did my company email stop working after I connected my domain to the store?

Connecting a domain to Tiendanube changes its DNS configuration, and their help center warns that mail on that domain stops sending and receiving immediately unless you re-create your MX, TXT and CNAME records in the new zone. Recover the original values, publish them where DNS is now authoritative, and mail returns once the change propagates.

Can I skip DMARC and just do SPF and DKIM?

You can send mail without it, but you lose the only feedback loop that shows you which systems send as your domain, and you stay spoofable. Google also requires SPF, DKIM and DMARC together from senders pushing 5,000 or more messages a day to personal Gmail accounts. Publishing p=none costs nothing and blocks nothing.

Tiendanube SPF, DKIM and DMARC Setup Guide

What your store actually sends on your behalf

Tiendanube sends mail without you touching it. Order confirmation, account created, payment received, package on its way: the platform generates those messages and hands them to a mail service. Out of the box they leave from an address on Tiendanube's own domain, and that works fine. It just is not your brand.

The moment you switch the sender to an address on your own domain, the responsibility moves to you. You are telling Gmail, Outlook and everyone else that a server you do not own is allowed to send mail carrying your name. If your DNS never says so, the receiver sees an unauthenticated message from your domain and files it accordingly. Tiendanube's own help page puts it plainly: publish the SPF and DKIM records so recipient mail servers recognize your messages and they stop landing in the junk folder.

One detail drives most of what follows. Tiendanube's transactional mail goes out through Amazon SES, which is why their instructions ask you to add include:amazonses.com to your SPF record rather than an address of their own.

Before anything else: connecting your domain can silence your mailboxes

This is the step that costs people days, and it happens before authentication ever enters the picture.

When you connect a domain to Tiendanube, the DNS configuration for that domain changes. Their help center is explicit about what that means: if you already run professional mail on the domain with a service like Google Workspace or Zoho, do not link it until you have your DNS records in hand, because you will stop sending and receiving messages immediately.

So take an inventory first. Open your current DNS zone and write down, character for character:

every MX record with its priority value
every TXT record, in particular the one starting with v=spf1 and anything published at _dmarc
every CNAME tied to mail, which is where a lot of DKIM setups live
any record for a subdomain used by webmail, a CRM, or your invoicing tool

Then decide who holds the zone after the change and re-create those records there the same day. A store that goes live while the owner's inbox is dark is a bad trade.

Where you add the records depends on your domain

Tiendanube's guide for this covers customers whose domain ends in .ar, .co or .cl and who have already pointed that domain to Tiendanube using their DNS records. If your domain is anything else, the platform tells you to add the SPF and DKIM records directly at the external host where your DNS actually lives.

The values are the same either way. Only the control panel changes. Find out which case you are in before you start clicking, because editing the wrong zone produces records that look perfect and do nothing at all.

SPF: merge Amazon SES into the record you already have

A domain gets exactly one SPF record. Publishing a second one does not add coverage, it invalidates both, and receivers treat the result as a permanent error. This is the single most common way store owners break mail they had working.

Tiendanube's instruction reflects that: edit your domain's DNS zone, find the existing TXT record that begins with v=spf1, and add include:amazonses.com before the final ~all. If you have no SPF record at all yet, you create one. If you have one, you extend it.

With Google Workspace holding your mailboxes and Tiendanube sending store mail, the merged record looks like this:

Type:  TXT
Name:  @
Value: v=spf1 include:_spf.google.com include:amazonses.com ~all

With Zoho Mail instead, Zoho asks you to update your existing record with include:zoho.com, so the same domain ends up with:

Type:  TXT
Name:  @
Value: v=spf1 include:zoho.com include:amazonses.com ~all

Now the part most guides skip. SPF is evaluated against the envelope sender, the address the sending server announces during the SMTP conversation, not the From address your customer reads. When a platform sends on your behalf and keeps its own return path, your SPF include authorizes the delivery, but the domain SPF validated is the platform's, not yours. That still leaves DMARC unsatisfied, because DMARC wants the authenticated domain to match the From header. Which is exactly why the next step is not optional.

DKIM: the record Tiendanube generates for you

In your store admin, go to Dominios and open Configuración de correo electrónico. The next screen shows you a DKIM record: a TXT name and a TXT value generated for your domain. Per Tiendanube's own instructions, you send those two values to their support team as text, and they complete the matching configuration on their sending servers.

DKIM is what carries you across the finish line here. It signs the message with a key published under your domain, so the signature and the From address agree, and DMARC has something aligned to pass on. Where SPF gets awkward with third-party senders, DKIM is straightforward.

Keep this separate in your head from your mailbox provider's DKIM, because you will run both at once and they do not conflict. Google Workspace generates its key in the Admin console and publishes it under the google selector by default, so the record lands at google._domainkey, and Google recommends the 2048-bit option where your DNS provider supports it. Zoho publishes under a selector you choose, commonly zmail, so the host name is zmail._domainkey, and after you save it you click Verify in the Zoho console and allow up to 12 to 24 hours depending on your TTL.

Two senders, two keys, two selectors, one domain. That is the normal, correct end state.

Running Zoho Mail or Google Workspace alongside the store

Tiendanube does not give you mailboxes on your own domain. Their help center says so directly: you contract that service elsewhere. So the usual shape for a small store is a mailbox provider for the humans and Tiendanube for the automated store mail, both authenticated on the same domain.

Two things to watch when you stack senders. First, every one of them needs its own DKIM key, not just a mention in SPF. Second, SPF has a hard budget of ten DNS lookups, and each include spends at least one. Two senders is comfortable. Add a newsletter tool, an invoicing provider and a CRM and you can cross the line without noticing, at which point the whole record fails. If you are close, read our guide on getting SPF back under the ten lookup limit before you add anything else.

DMARC, step by step

DMARC ties the two together. It tells receivers what to do when a message claims to be from your domain but neither SPF nor DKIM passes in a way that matches that domain, and it asks them to send you reports about what they saw. Alignment is the whole idea: it is not enough for SPF or DKIM to pass, the domain that passed has to be the domain in the From header.

Start in monitoring mode. Publish this and change nothing else:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

With p=none nothing gets blocked. Reports start arriving within a day or two, and they will show you every system sending as your domain, including the invoicing tool nobody remembered. Give it two weeks, confirm your store mail and your mailbox mail both show up aligned, then tighten to p=quarantine, and only after that to p=reject.

There is a deadline hiding in this for anyone doing email marketing from the store. Google requires every sender to have SPF or DKIM set up, and senders pushing 5,000 or more messages a day to personal Gmail accounts must have SPF, DKIM and DMARC, keep the spam rate reported in Postmaster Tools under 0.30 percent, and support one-click unsubscribe on marketing messages. Order confirmations rarely reach that volume. A campaign to your customer list can.

Mercado Shops: same rules, different panel

If your store runs on Mercado Shops rather than Tiendanube, nothing about the standards changes. You still connect a domain, which still moves or alters DNS delegation, which still puts your existing MX and TXT records at risk if you have not written them down. You still need one merged SPF record covering whatever sends on your behalf, a DKIM key for each sender, and a DMARC record at _dmarc.

What differs is where the platform documents its sending service and which values it asks you to publish. Get those from Mercado Shops directly rather than assuming Tiendanube's include applies, then follow the same order: inventory, SPF, DKIM, DMARC at p=none, read reports, tighten.

Verify instead of assuming

DNS panels are good at accepting records that are subtly wrong. So check the published result, not the form you filled in.

Query your domain's TXT records and confirm there is exactly one v=spf1 entry and that it contains every sender you expect. Query _dmarc and confirm the policy is there. Then place a real order in your own store, open the confirmation message in Gmail, and read the Authentication-Results header: you want SPF or DKIM showing pass with your domain, and DMARC showing pass. Our free email troubleshooter runs the DNS side in a few seconds, and the header analyzer decodes what came back on the actual message.

The mistakes that cost the most time

Two SPF records. You added a new v=spf1 line instead of editing the existing one. Merge them into one and delete the spare.
The record on the wrong name. Many DNS panels append the domain automatically, so typing zmail._domainkey.yourdomain.com produces a record at zmail._domainkey.yourdomain.com.yourdomain.com. Enter the host part only and check the saved result.
DMARC on the root. The policy record belongs at _dmarc, never at @.
Editing the zone you no longer control. After connecting the domain to the store platform, authoritative DNS may have moved. Records added at the old provider do nothing.
Going straight to p=reject. Enforcement before reports is how invoicing mail and order confirmations quietly start disappearing.

How Guanacos Tech helps

Most store owners we see did nothing wrong. They connected a domain to a platform that rewrote DNS, and mail that used to work stopped working, and the two events were a week apart so nobody connected them. We map every system sending as your domain, publish one SPF record that covers all of them without blowing the lookup budget, get DKIM signing on each sender, and walk DMARC from monitoring to enforcement while reading the reports with you. If your order confirmations are landing in spam, or your inbox went quiet after a store migration, book a call and we will trace it together.

Tiendanube: how to set up SPF, DKIM and DMARC so your store emails stop landing in spam