SPF, DKIM, and DMARC for several product domains

The first product gets its email records set up with care, because nothing works until the welcome email arrives. The third or fourth product gets whatever the email service's setup page said to paste in, on a weekend, and nobody looks again. Then a newsletter tool gets added, a domain moves to a new DNS host, and password resets from one product start landing in spam while the others are fine.

Email authentication is per domain, so with several products you have several separate setups to keep right. Here is how to set each one up so it holds, what changes when products share a domain or an email account, and how to check all of them without opening five DNS dashboards.

What each record does

SPF is one TXT record on the domain listing the services allowed to send mail as it.
DKIM is a signature each sending service adds to its messages, checked against a public key you publish at a name like s1._domainkey.yourproduct.com. Every service that sends for you has its own key.
DMARC is a TXT record at _dmarc.yourproduct.com. It requires the domain in the From line to match the domain that passed SPF or DKIM, tells receivers what to do with mail that fails, and asks them to send you reports.

What Gmail and Yahoo now expect

Since February 2024, Google's sender guidelines require every sender to Gmail to set up SPF or DKIM and keep its reported spam rate below 0.3%. Senders of more than 5,000 messages a day to Gmail must set up SPF, DKIM, and DMARC (a policy of p=none is enough), align the From domain with SPF or DKIM, and offer one-click unsubscribe on marketing mail. Yahoo's rules are close to the same.

Two details matter when you run several products. Google counts the 5,000 across a primary domain, so mail from yourproduct.com and news.yourproduct.com adds up, while separate products on separate domains are counted separately. And once a domain crosses the line, it is a bulk sender for good, even if volume drops later. The simplest answer is to set up all three on every product domain, whatever its size today.

List every sender, per domain

Before touching DNS, write down what sends mail as each product. For a typical small SaaS product the list looks like this:

Your mailbox provider, for the founder's own replies and support.
The app's email service, for sign-in links, password resets, and receipts.
A newsletter or lifecycle tool, for onboarding sequences and announcements.
Anything else with your From address: a help desk, a billing tool that sends invoices as you, a form tool that sends replies.

The list is usually different for each product, which is exactly why copying one product's records to the next goes wrong. A product that never used the newsletter tool should not authorize it, and a product that added a help desk last month needs it added.

SPF: one record, few lookups

Each domain gets exactly one SPF record, with an include for each sender on its list:

# TXT record on yourproduct.com
v=spf1 include:_spf.google.com include:amazonses.com ~all

Two rules from the SPF standard catch people out:

Two SPF records is an error, not a merge. When a domain has more than one v=spf1 record, the check fails with a permanent error. This happens most when a second service's setup page says "add this TXT record" and you add it next to the first. Fold the new include into the existing line instead.
Ten DNS lookups, in total. Every include, a, mx, ptr, and exists counts, including the ones inside each provider's include. Go over and SPF fails for every message. Remove services you no longer use before adding new ones.

End the record with ~all or -all, so senders not on the list are treated as suspect or rejected.

DKIM: turn it on at every sender

DKIM is set up inside each sending service, not in one place. Each one gives you a record or two to add, and shows the domain as verified once DNS has them. With several products, the mistake is turning it on for the app's email service and forgetting the newsletter tool, or verifying a product's domain in the service and never adding the records after a DNS move.

DKIM is also what keeps DMARC passing when SPF cannot. Forwarded mail often fails SPF, because the forwarding server is not on your list, but a DKIM signature survives the trip.

DMARC: reports first, then enforce

Start each domain with a policy that only asks for reports:

# TXT record on _dmarc.yourproduct.com
v=DMARC1; p=none; rua=mailto:dmarc@yourproduct.com

Receivers then send daily summaries of who sent mail as that domain and whether it passed. Read them for a few weeks. Any service you use that shows up failing needs SPF or DKIM fixed. Anything you do not recognize is someone else using your name. Once only your own services appear, move to p=quarantine, then p=reject.

With several products, point every domain's reports at one mailbox, or at one report-reading service, so a single place shows all of them. Reports from many domains in one inbox are hard to read raw, but they are easy to sort by domain.

Subdomains and shared accounts

Some founders send marketing from a subdomain, like news.yourproduct.com, so a newsletter that draws complaints does less harm to the address that sends password resets. If you do, set the subdomain up at its sending service like any other domain: its own SPF record and its own DKIM keys. DMARC is simpler: a subdomain falls back to the main domain's record, and the main record's sp= tag can set a separate policy for subdomains.

Several products often share one account at an email service. That is fine for authentication, since each domain gets its own records, but the service judges bounce and complaint rates across the whole account. One product with a stale list can get sending paused for all of them, so watch those rates per domain, not just per account.

Domains that never send mail

Portfolios collect domains: old names, typo catches, a product that was shut down. A domain with no email records is easy to send fake mail from. If it never sends mail, say so:

# TXT record on olddomain.com
v=spf1 -all
# TXT record on _dmarc.olddomain.com
v=DMARC1; p=reject

That tells receivers to reject anything claiming to come from it.

Check all of them each week

Records break quietly: a DNS host move drops the DKIM keys, a new tool adds a second SPF record, a domain lapses. Nothing errors in your app; mail just starts going to spam. A short weekly look covers it:

Each product domain has one SPF record ending in ~all or -all, and a DMARC record.
Each sending service shows the domain as verified.
Bounce and complaint rates per domain are well under your email service's limits.
The DMARC reports show no new sender.

To test one real message, send it to a Gmail address and open "Show original", which shows whether SPF, DKIM, and DMARC passed. The weekly review routine has a slot for this next to uptime and revenue.

How LopeBase does it

We run several products ourselves, each with its own domain and its own mix of senders. The free SPF, DMARC, and DKIM checker reads any domain's records from public DNS with no account: whether there is exactly one SPF record and how it ends, the DMARC policy, and DKIM keys at common selectors (google, default, selector1, selector2, k1, resend, and s1). A selector it does not know cannot be looked up from outside, so a key elsewhere shows as not found.

In LopeBase, the same checks are a section of each property's SEO audit, so every product's records are on one screen and you can run it again whenever you like. If a product sends through Resend, LopeBase also reads its recent bounce and complaint rates and whether each sending domain is verified, and flags a domain getting close to Resend's limits. One Resend account that sends for three products can be split by domain, so the check names the product causing trouble. Newsletter mail in Sequenzy connects beside it. What LopeBase does not do: send test email, read DMARC reports, or change your DNS. It tells you what to fix, and the checker's page shows the records to add.