SPF, DKIM and DMARC Explained for Small Store Owners

Why these three records matter

Anyone can type any address into the “From” line of an email. That’s how phishing emails pretend to come from banks and well-known brands. Mailbox providers like Gmail and Yahoo need a way to check whether an email that says it’s from your-store.com was really sent with your permission.

SPF, DKIM and DMARC are that check. They are records you publish in your domain’s DNS (the settings at your domain registrar or DNS host). Receiving mail servers look them up and use them to decide whether to trust a message.

For a small store, setting them up does two things:

1. Your real emails are more likely to be delivered. Gmail and Yahoo have published requirements that include these records. Mail that doesn’t meet them can be rejected or sent to spam.
2. It’s harder for others to impersonate you. With DMARC enforced, a scammer sending fake “your order has shipped” emails from your domain is much more likely to be blocked.

The quick version

SPF: who is allowed to send

SPF (Sender Policy Framework) is defined in RFC 7208. You publish a list of the servers and services that are allowed to send email for your domain. A receiving server compares the server that delivered the message against that list.

An SPF record is a single TXT record that starts with v=spf1. A typical small-business record looks something like this:

your-store.com.  TXT  "v=spf1 include:_spf.your-mail-provider.example include:mail.your-newsletter-tool.example ~all"

Each include: adds the servers of a service you use: your mailbox provider, your store platform’s order emails, your newsletter tool. The ending says what to think of everything else: -all means “not authorized” (fail), and ~all is a weaker “probably not” (softfail). Your providers will tell you exactly what to add; you rarely write one from scratch.

Three things about SPF trip people up:

1. Only one SPF record per domain. RFC 7208 says multiple SPF records “are not permitted” for the same name, and having more than one produces an error (permerror). When you add a new service, edit the existing record to add another include:. Don’t create a second record.
2. The 10-lookup limit. The RFC limits SPF evaluation to 10 DNS-querying terms (such as include, a, mx and redirect). Each include can contain more lookups inside it. Stack too many services and SPF fails with a permerror. If you’re near the limit, remove services you no longer use.
3. SPF checks a hidden address, not the visible From. SPF checks the “envelope” sender (the MAIL FROM address used during delivery) and the HELO name, not the From address your customer sees. Many newsletter services use their own envelope domain, which is why SPF alone often doesn’t line up with your brand domain. DMARC, below, deals with this.

DKIM: a signature that proves the message is genuine

DKIM (DomainKeys Identified Mail) is defined in RFC 6376. In the RFC’s words, it lets an organization “claim some responsibility for a message by associating a domain name with the message.”

Here’s how it works in practice:

1. Your email provider creates a pair of keys: a private key it keeps, and a public key you publish in DNS.
2. When the provider sends your email, it adds a DKIM-Signature header, a cryptographic signature of key headers and the body, made with the private key. The signature includes d= (the domain taking responsibility) and s= (the selector, a name for the key).
3. The receiving server looks up the public key at selector._domainkey.domain and checks the signature. If it matches, the message really came through a system holding your key and wasn’t changed in transit.

Selectors let one domain have several keys at once, so your mailbox provider and your newsletter tool can each sign with their own key without clashing. Providers usually give you one or two records to add, often as CNAME records pointing to keys they manage, which lets them rotate keys for you.

DKIM has two practical advantages over SPF. It survives normal forwarding, because the signature travels with the message, as long as the content isn’t modified. And the signing domain (d=) can be your own domain even when a third-party service sends the email. That’s what makes it the easiest path to DMARC alignment for newsletter tools.

Gmail’s sender guidelines say a DKIM key must be at least 1024 bits and recommend 2048 bits (Google). If your provider offers a choice, pick 2048.

DMARC: the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM. It was first published as RFC 7489 in 2015 and is now on the Internet standards track as RFC 9989, which obsoletes RFC 7489. It adds two things SPF and DKIM don’t have on their own: alignment and a policy.

Alignment means the domain that passed SPF or DKIM must match the domain in the visible From line. A message from news@your-store.com with a valid DKIM signature for d=your-store.com is aligned. A message with a valid signature for d=newsletter-tool.example is authenticated, but not aligned with your brand, so it doesn’t pass DMARC for your domain.

In the default “relaxed” mode, subdomains count: a DKIM signature for your-store.com aligns with a From address on news.your-store.com. In “strict” mode, the domains must match exactly. Yahoo’s guidelines say relaxed alignment is acceptable, and most small senders don’t need strict mode.

The policy tells receivers what to do when a message fails DMARC. It’s published as a TXT record at _dmarc.your-domain:

_dmarc.your-store.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@your-store.com"

The reports are the part small senders overlook. With rua set, participating mailbox providers send you aggregate reports showing which servers sent mail using your domain and whether it passed. The reports are XML files and are hard to read raw, so many people send them to a DMARC report service that turns them into charts. They show you the services you forgot about (an old invoicing tool, a booking system) before you tighten your policy. DMARC.org recommends starting with p=none to collect data, then moving toward quarantine and reject as you gain confidence.

What Gmail and Yahoo require

Since February 2024, Gmail has enforced sender requirements, and Yahoo publishes matching rules. Both distinguish between all senders and bulk senders. Google defines bulk senders as those sending more than 5,000 messages a day to Gmail accounts (Google; Yahoo).

Google says messages that don’t meet the requirements may be rejected or marked as spam. Most small stores send far fewer than 5,000 emails a day to Gmail, but the bulk-sender rules are a good target anyway: they’re not hard to meet with a reputable email provider.

One-click unsubscribe is defined in RFC 8058. The message carries a List-Unsubscribe header with an HTTPS link and a List-Unsubscribe-Post: List-Unsubscribe=One-Click header, both covered by a valid DKIM signature. That lets a mail app unsubscribe the reader with a single action, without sending them to a web page. Your newsletter tool adds these headers; you just need to confirm with them that it does.

TLS, reverse DNS and message formatting are handled by your email provider’s servers. You don’t set them up yourself, but they’re a good reason to send through an established provider rather than a server you run on your own.

How to set them up: a safe order

You’ll need access to your domain’s DNS settings and admin access to each service that sends email for you. Take it one step at a time.

1. List everything that sends email as your domain. Your mailbox (Google Workspace, Microsoft 365 or similar), your store platform’s order and shipping emails, your newsletter or marketing tool, help desk, invoicing, booking or review-request tools. Anything that puts @your-store.com in the From line counts.
2. For each service, find its authentication instructions. Look in the service’s help center for “SPF,” “DKIM,” “domain authentication” or “sender authentication.” If you can’t find them, ask the service’s support team which records it needs. They will give you the exact values.
3. Set up DKIM for every service. Add the records each service gives you, then complete its verification step. This is the most important step for alignment.
4. Build one SPF record. Combine the include: values from each service into a single v=spf1 record. Check you have only one, and keep the lookup count under 10.
5. Publish DMARC at p=none with reports. Add a _dmarc record with an rua address. Wait a few weeks and read the reports.
6. Fix anything that fails. If reports show a legitimate service failing alignment, go back to step 2 for that service.
7. Tighten the policy. When legitimate mail consistently passes, move to p=quarantine, and later to p=reject if you’re comfortable.

A worked example: a store with three senders

Imagine a small online shop at your-store.com. It uses a hosted mailbox for everyday email, its store platform for order confirmations, and a newsletter tool for promotions. All three put @your-store.com in the From line.

The pattern is the important part. DKIM on your own domain is what makes every service line up, even when SPF can’t. Once all three show DMARC pass in the headers and in the reports, the shop can move from p=none to p=quarantine with confidence that its real mail won’t be caught.

How to check whether your emails pass

You don’t need special software for a basic check. Send an email from each service (a test newsletter, a test order confirmation) to a personal Gmail or Yahoo address. Open it and view the full message headers. Most webmail apps offer an option to show the original message or the message source. Look for the authentication results lines, which report spf=, dkim= and dmarc= as pass or fail, along with the domains involved.

What you want to see for each service: DKIM pass with your own domain, and DMARC pass. If DKIM passes but for the provider’s domain instead of yours, domain authentication for that service isn’t finished.

Google also offers Postmaster Tools, where domain owners can monitor their spam rate and authentication results for mail sent to Gmail.

Common mistakes

Where marketingLABO fits

marketingLABO’s dashboard doesn’t include DNS or email authentication settings, so this setup happens with your domain host and with each service that sends email for you. For any email tool, including the one you use for newsletters, ask the provider which SPF and DKIM records it needs and whether it supports one-click unsubscribe.

Once your emails reliably reach the inbox, the next question is what people do with them. marketingLABO tracks email opens and link clicks, and journeys (Standard plan) can branch on whether someone clicked or came back to your site. People who unsubscribe don’t receive the remaining emails in a journey. Because privacy features in some mail apps inflate open counts, we recommend leaning on clicks and returns; see are email open rates still reliable? for why. For a first automated flow, see our welcome email series guide, and check pricing for which plan includes newsletters and journeys.

Frequently asked questions

I only send a few hundred emails a month. Do I really need all three?

Gmail and Yahoo’s minimum for all senders is SPF or DKIM, but Google’s guidance is to set up all three. They protect your domain from impersonation regardless of volume, and setting them up while your sending is simple is much easier than untangling it later.

Will DMARC p=none protect me from spoofing?

No. p=none only asks for reports; it doesn’t tell receivers to block anything. It’s the safe first step, and it meets the bulk-sender DMARC requirement, but protection against impersonation comes from quarantine or reject.

My store platform sends order emails. Do I need to do anything?

If those emails use your own domain in the From line, yes: the platform needs to be authorized in SPF and set up for DKIM on your domain. Check your platform’s help center for its domain authentication steps, or ask its support team.

Do these records affect my website?

No. They are TXT (and sometimes CNAME) records that only mail servers read. They don’t change your site, but take care not to edit or delete other DNS records while you’re there.

What about forwarded email?

Forwarding often breaks SPF, because the forwarding server isn’t on your list. DKIM usually survives if the message isn’t modified. That’s one more reason to make sure DKIM is set up and aligned for every service.

Checklist

1. List every service that sends email using your domain.
2. Set up DKIM on your own domain for each one (2048-bit if offered).
3. Publish exactly one SPF record that includes every sending service, under 10 lookups.
4. Publish DMARC at p=none with an rua address, and read the reports.
5. Confirm your newsletter tool supports one-click unsubscribe and a visible unsubscribe link.
6. Keep spam complaints low: send only to people who asked, and make leaving easy.
7. Move to quarantine, then reject, once legitimate mail consistently passes.

Ready to see what happens after the email lands? Create a free account and start with site analytics and visitor history.

Sources

1. Google Workspace Admin Help, “Email sender guidelines” (accessed October 12, 2026): https://support.google.com/a/answer/81126
2. Yahoo Sender Hub, “Sender Best Practices” (accessed October 12, 2026): https://senders.yahooinc.com/best-practices/
3. DMARC.org, “Overview” (accessed October 12, 2026): https://dmarc.org/overview/
4. RFC 7208, Sender Policy Framework (SPF) (accessed October 12, 2026): https://www.rfc-editor.org/rfc/rfc7208
5. RFC 6376, DomainKeys Identified Mail (DKIM) Signatures (accessed October 12, 2026): https://www.rfc-editor.org/rfc/rfc6376
6. RFC 7489, DMARC (original, now obsoleted) (accessed October 12, 2026): https://www.rfc-editor.org/rfc/rfc7489
7. RFC 9989, DMARC (standards track) (accessed October 12, 2026): https://www.rfc-editor.org/rfc/rfc9989
8. RFC 8058, Signaling One-Click Functionality for List Email Headers (accessed October 12, 2026): https://www.rfc-editor.org/rfc/rfc8058