SPF, DKIM and DMARC explained for online shops

Why inboxes check these three records#

Anyone can type any address into the From line of an email. SPF, DKIM and DMARC are how a receiving inbox tells whether a message that claims to come from ninefold.example really came from Ninefold. Each one is a DNS record you publish on your domain, and each answers a different question.

For a shop, the practical effect is inbox placement. Google asks every sender to set up SPF or DKIM, and senders of more than 5,000 messages a day to personal Gmail accounts must have SPF, DKIM and DMARC ^S4. Yahoo sets the same baseline for its bulk senders ^S5. Even below those volumes, authenticated mail builds sender reputation on your own domain, and a DMARC record makes it much harder for someone to send phishing email in your name.

What each record does#

SPF: which servers may send for you

SPF is a TXT record that lists the servers allowed to send mail for a domain. The receiving server compares the IP address that connected to it with that list. SPF checks the envelope sender (the MAIL FROM address used during delivery, which also receives bounces), not the From address your customer sees ^S1. A typical record for a shop that uses a workspace mailbox and an email marketing service looks like this:

v=spf1 include:spf.mailbox.example include:spf.mailservice.example ~all

Each include pulls in another provider’s list. The ending says what to do with everything else: -all is a fail, ~all is a softfail, which receivers should not reject on by itself ^S1.

DKIM: a signature on every message

DKIM adds a cryptographic signature to the message headers. The signature names a signing domain (d=) and a selector (s=), and the receiver fetches the public key from a DNS record at selector._domainkey.domain ^S2. If the signed headers or the body changed on the way, the check fails. The signing domain does not have to match the From address under DKIM alone ^S2, which is why DMARC exists.

DMARC: the policy that ties them to your visible sender address

DMARC is a TXT record at _dmarc.yourdomain. It asks receivers to confirm that SPF or DKIM passed for a domain that matches the visible From address, tells them how to treat mail that fails (none, quarantine or reject), and says where to send reports ^S3. A first record can be as short as v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example.

How they work together: alignment#

SPF and DKIM can both pass for the wrong domain. A marketing service might pass SPF for its own bounce domain and sign with DKIM as itself, while the From line says ninefold.example. Neither result says anything about Ninefold.

DMARC closes that gap with alignment. A message passes DMARC when SPF passes for a domain that aligns with the From domain, or DKIM passes for a domain that aligns with it ^S3. Alignment is relaxed by default, so a DKIM signature from mail.ninefold.example aligns with a From address at ninefold.example; strict alignment requires an exact match ^S3. Gmail and Yahoo both state the same rule for bulk senders: the From domain must align with the SPF domain or the DKIM domain ^S4S5.

Aligned DKIM matters more than aligned SPF. When a message is forwarded, the forwarding server connects from its own IP address, so SPF for the original domain often fails ^S1. A DKIM signature survives as long as the message is not modified.

What a shop needs to publish#

List every service that sends email with your domain in the From address before you touch DNS. For a small apparel brand like Ninefold that usually means a workspace mailbox, the store platform’s order and shipping emails, a help desk, and an email marketing tool. Each one needs to be covered.

1. One SPF record that includes every service that sends as your domain.
2. DKIM turned on in every one of those services, using your domain as the signing domain. Each service gives you its own record and selector, so several DKIM records can live side by side.
3. One DMARC record, starting at p=none with a reporting address, so you can see who sends as you before you enforce anything. The DMARC setup guide walks through the move to quarantine and reject.

Authentication is one part of what inbox providers expect. They also look at one-click unsubscribe and your spam complaint rate; the deliverability basics guide covers the rest.

Common mistakes#

• Two SPF records. A domain may have only one record starting with v=spf1; with two, SPF returns a permanent error for every message ^S1. Merge them into one record.
• Too many lookups. Each include, a, mx, ptr, exists and redirect costs a DNS lookup, and SPF stops with an error after 10 ^S1. Remove services you no longer use instead of stacking includes.
• DKIM signed with the provider’s domain. The signature passes, but it does not align with your From address. Set up DKIM on your own domain in each tool.
• Jumping straight to p=reject. A forgotten sender, such as the order confirmation emails from your store platform, starts failing silently. Start at p=none and read the reports first.
• No reporting address. A DMARC record without rua gives you no data to act on. Yahoo strongly recommends a working rua tag during setup ^S5.

How to check your records#

You can check what is published with a DNS lookup, and what receivers actually saw by reading a real message.

• From a terminal: dig +short TXT ninefold.example shows the SPF record, dig +short TXT _dmarc.ninefold.example shows DMARC, and dig +short TXT selector._domainkey.ninefold.example shows a DKIM key once you know the selector.
• From a browser: any DNS lookup tool that queries TXT records gives the same answers.
• From a real message: send a test to a Gmail address, open it, choose More, then Show original ^S6. The header shows an SPF, DKIM and DMARC result for that message, and the domains each one passed for.

DMARC is now on the IETF standards track: RFC 9989, published in May 2026, replaces RFC 7489 ^S3S7. Records still start with v=DMARC1, so a record written to the older rules keeps working ^S3.

Setting up authentication with Tellnod in Claude or ChatGPT#

Tellnod is an MCP connector for writing, previewing and sending marketing email from Claude or ChatGPT. You can send on day one from an address named after your shop on Tellnod’s shared domain, such as hello@yourshop.tellnodmail.com, with no DNS changes, within limits of 500 recipients per campaign and 1,000 emails a month. Verifying your own domain lifts those limits and is the setup we recommend.

To verify your domain, ask in the chat, for example: “Set up ninefold.example as my sending domain.” Tellnod gives you the SPF, DKIM and DMARC records and checks them for you. If someone else manages your DNS, ask: “Create a setup link for our web developer.” They can add the records in one click on supported DNS providers, or copy them, without creating an account, and you are notified in the chat and by email once the domain is verified. DNS changes usually take a few minutes and can take up to 48 hours.

Authentication does not change how sending works: every campaign shows a desktop and mobile preview, and nothing goes out until you press Confirm on the approval card. To start, connect Tellnod to Claude or ChatGPT; the pricing page lists the free plan and paid tiers.

FAQ#