Email authentication for SaaS companies

28 April 2026 · 12 min read

A SaaS business has an email problem that most companies never face: you do not send one stream of mail, you send several, from different systems, on behalf of different identities, at wildly different volumes, and the failure of any one stream can poison the reputation of all the others. A password reset that lands in spam is a support ticket. A receipt that lands in spam is a chargeback. A "your trial ends tomorrow" notification that lands in spam is churn you will never see in your funnel because the customer simply never opened it.

This guide is written specifically for that situation. It is not a generic DMARC explainer. It is about how a software company should structure SPF, DKIM, DMARC, MTA-STS and BIMI when it runs transactional mail, product and lifecycle mail, bulk marketing mail, and often mail your own customers send through your platform, all at once. The central decision is your subdomain strategy, because at SaaS scale your subdomains are not a tidiness preference, they are how you isolate reputation so a bad day on one stream does not take down your login emails.

If you want a baseline before reading on, run your primary sending domain through the DMARC checker, SPF checker and DKIM checker. Those three answers tell you where you actually stand today, not where you assume you stand.

The four streams a SaaS company actually sends

Before you touch DNS, name your streams. Almost every SaaS sender falls into four buckets, and each has a different risk profile.

• Transactional, security-critical. Password resets, magic links, email verification, two-factor codes, billing receipts, invoices, security alerts. These must arrive in seconds and must never be filtered. Low volume per recipient, high consequence per message.
• Product and lifecycle. Onboarding sequences, "you were mentioned", digest emails, usage alerts, seat invitations, "your export is ready". Medium volume, triggered by user behaviour, mixed engagement.
• Marketing and bulk. Newsletters, feature announcements, webinars, re-engagement campaigns. High volume, low individual urgency, and the stream most likely to generate spam complaints.
• Customer-generated or relay mail. If your platform lets users send mail through you (notifications branded as the customer, shared inboxes, helpdesk replies, sequences sent on a customer's behalf), you carry the deliverability risk of strangers' content.

The mistake that breaks SaaS deliverability is treating all four as one. When marketing blasts a stale list and complaints spike, the receiving providers do not punish "your marketing". They punish the domain that signed and sent it. If that is the same domain that sends your password resets, your logins start landing in spam, and you will spend a week debugging the wrong thing.

Why subdomain sending is the core decision

The single most important architectural choice for a SaaS sender is to send each stream from a dedicated subdomain, with its own DKIM keys and its own SPF policy, all under one organisational DMARC umbrella.

A workable layout looks like this:

yourapp.com               <- corporate / human email (Google Workspace, M365)
notify.yourapp.com        <- transactional & product mail (your ESP / API)
mail.yourapp.com          <- marketing & bulk (your marketing platform)
send.customers.yourapp.com <- customer-generated relay mail (if applicable)

This buys you three concrete things.

Reputation isolation. Mailbox providers track sending reputation largely at the domain and subdomain level. A spam spike on mail.yourapp.com does not directly drag down notify.yourapp.com. Your logins keep working while you clean up marketing. This is the entire reason subdomains exist for senders, and it is worth far more to a SaaS company than to a small business that sends one newsletter a month.

Alignment clarity. DMARC passes only when SPF or DKIM aligns with the domain in the visible From: header. If your transactional mail says From: noreply@notify.yourapp.com, then the SPF and DKIM you configure for that subdomain are exactly the ones that need to align, with nothing else in the mix. One subdomain, one ESP, one clean answer. See DMARC alignment explained for the precise rules.

Independent enforcement pace. You can drive notify.yourapp.com to p=reject quickly, because you control it and you know every system that sends from it. You can leave mail.yourapp.com at p=quarantine a little longer while a marketing platform's setup settles. Per-subdomain records and the organisational sp= tag let you do both at once.

A note that trips people up: DMARC is published per domain, but a subdomain inherits its parent's policy unless it has its own record or the parent specifies a subdomain policy with sp=. So your corporate root can enforce strictly while still controlling defaults for subdomains that have no record of their own. More on that split below and in the subdomain policy guide.

SPF at scale: the 10-lookup limit is your real enemy

SPF has a hard limit that SaaS companies hit faster than anyone else: a receiver must stop after 10 DNS lookups while evaluating your record. Every include: (your ESP, your CRM, your helpdesk, your calendar tool, your monitoring vendor) consumes one or more lookups. Stack four or five vendors on a single domain and you blow the limit. When you exceed it, SPF returns PermError, which most receivers treat as an SPF fail, and now you are leaning entirely on DKIM whether you meant to or not.

This is the strongest practical argument for the subdomain split. If everything sends from the root, your root SPF record looks like this and quietly breaks:

yourapp.com  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mandrillapp.com include:_spf.salesforce.com include:helpscout.net ~all"

That is five includes before you have even added a monitoring tool, and several of those expand to multiple lookups internally. Split by subdomain and each record stays small and well under the limit:

notify.yourapp.com  TXT  "v=spf1 include:sendgrid.net ~all"
mail.yourapp.com    TXT  "v=spf1 include:_spf.example-esp.com ~all"
yourapp.com         TXT  "v=spf1 include:_spf.google.com ~all"

If you genuinely cannot split, SPF flattening (resolving includes to their IP ranges and publishing those directly) keeps you under the limit, but it requires monitoring because vendor IPs change. We cover the trade-offs in how SPF flattening works and the 10-lookup limit. If you are already seeing PermError, the SPF checker will count your lookups for you, and fix SPF PermError walks through the cure.

End every SPF record with ~all (softfail) while you are still validating, and only move to -all (hardfail) once you are certain every legitimate sender is listed. A SaaS company with a long vendor list should be conservative here, because one forgotten include: plus -all plus enforcement equals a stream of legitimate mail rejected.

DKIM: separate keys per stream, and a rotation plan

DKIM is what actually carries most SaaS senders to enforcement, because SPF alignment is fragile (it breaks on forwarding and on any ESP that uses its own return-path). DKIM signs the message with a key whose d= value you control, so it aligns with your From: domain even when the envelope sender does not.

For a SaaS company, three rules matter.

Use a distinct selector per sending system. A selector is the label that points to a specific public key. Give each provider its own selector so you can identify, rotate and revoke keys independently:

s1._domainkey.notify.yourapp.com   <- ESP key for transactional
k2._domainkey.mail.yourapp.com     <- marketing platform key
google._domainkey.yourapp.com      <- Workspace key for human mail

When a DMARC report later shows a strange source signing as your domain, the selector tells you immediately which system it came from. See DKIM selectors explained.

Sign with a 2048-bit key where the provider allows it. Some platforms still default to 1024-bit. Stronger keys are now the norm and some receivers treat short keys with suspicion.

Plan rotation before you need it. Keys leak, vendors get breached, and good hygiene rotates keys periodically. The clean pattern is to publish the new key under a new selector, switch the signing system to it, confirm reports show the new selector passing, then retire the old one. Doing this without an outage is the whole subject of DKIM key rotation. Validate any key you publish with the DKIM checker before you rely on it.

Putting DMARC over the top: organisational policy with subdomain control

Now you tie the streams together. DMARC is published once at the organisational domain and governs everything beneath it through inheritance and the sp= tag.

Start in monitoring mode so you can see every source before you enforce anything:

_dmarc.yourapp.com  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourapp.com; ruf=mailto:forensic@yourapp.com; fo=1; adkim=s; aspf=s"

p=none does not protect you, but it makes every sender visible. Within a couple of days the aggregate reports (the rua stream) will show you, by source, which of your streams pass and which fail. Feed those XML reports into the DMARC report analyzer; reading raw aggregate XML by hand is miserable and you will miss things. The first-read walkthrough is reading your first DMARC report.

For a SaaS company, the subdomain control tags are the interesting part:

• sp= sets the policy for subdomains that have no record of their own. You can enforce p=reject on the root while keeping sp=none during rollout, so a new subdomain someone spins up does not get silently rejected before you have configured it. Or the reverse: relax the root and lock down subdomains.
• adkim=s and aspf=s request strict alignment, meaning the signing or envelope domain must match the From: domain exactly, not just by organisational domain. Strict alignment is a stronger anti-spoofing posture, but it is unforgiving: under adkim=s, mail from notify.yourapp.com signed with a key at yourapp.com will not align. Many SaaS senders keep relaxed alignment (adkim=r) precisely so that a key at the organisational domain still covers subdomains. Choose deliberately and verify with reports before enforcing.

A common, sane end state for a SaaS sender:

_dmarc.yourapp.com         TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourapp.com; adkim=r; aspf=r"
_dmarc.notify.yourapp.com  TXT  "v=DMARC1; p=reject; rua=mailto:reports@yourapp.com"
_dmarc.mail.yourapp.com    TXT  "v=DMARC1; p=quarantine; rua=mailto:reports@yourapp.com"

Here transactional mail is fully enforced, marketing trails at quarantine while its list hygiene proves out, and the root sp=reject means any unconfigured subdomain is protected by default. The discipline of moving from none to quarantine to reject, one stream at a time, without breaking real mail, is the entire enforcement journey: reach p=reject without breaking email and the longer-form enforcement journey.

The customer-generated mail problem

If your platform sends mail on behalf of your customers (helpdesk replies, notifications branded as the customer's own domain, outbound sequences), you have a harder problem than most senders, and it deserves its own subdomain strategy.

You have two models, and they have very different reputation consequences.

You send as your own subdomain on the customer's behalf. Every customer's notifications go out as From: noreply@send.yourapp.com, signed by your keys. Simple to operate, but now every customer shares one reputation. One customer who imports a dirty list and triggers complaints damages deliverability for all of them. Acceptable only if you aggressively police content and complaint rates.

You send as the customer's own domain. Mail goes out as From: support@customerdomain.com, which means the customer must delegate authentication to you: publish a CNAME for a DKIM selector pointing at your keys and add your include: to their SPF. This is the model that scales reputation correctly, because each customer carries their own sending reputation, but it requires you to build the onboarding flow that gets those DNS records published and verified. It is exactly the delegated, hosted-authentication pattern that platforms like ours automate, so customers reach alignment without hand-editing zones.

Either way, your DMARC reports become an early-warning system. A spike in failures from one source, or one customer's selector suddenly signing from an unexpected IP, is something you want to catch before a mailbox provider does. Continuous monitoring with change alerts is the difference between noticing in an hour and noticing in a support escalation; that is what emailed monitoring is for.

MTA-STS and TLS reporting: table stakes for a platform

Once your authentication is in order, MTA-STS is the next layer, and for a SaaS company handling customer data it is close to mandatory. MTA-STS tells sending servers to require TLS when delivering to your domain and to refuse to fall back to plaintext, which closes a downgrade-attack gap that SPF, DKIM and DMARC do not address at all (they authenticate the message, not the transport).

You publish a policy file over HTTPS and a small TXT record:

_mta-sts.yourapp.com   TXT  "v=STSv1; id=20260101000000Z"
_smtp._tls.yourapp.com TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourapp.com"

with a policy served at https://mta-sts.yourapp.com/.well-known/mta-sts.txt. Start the policy in testing mode so TLS-RPT reports show you any delivery problems before you switch to enforce. Validate the whole setup with the MTA-STS checker. For a company whose entire pitch is trustworthy software, advertising enforced transport encryption on your mail domain is a small, visible signal that you take security seriously.

BIMI: the logo, and why it needs reject first

BIMI puts your verified logo next to your messages in supporting mailbox providers, which for a SaaS brand is genuine inbox real estate and a trust cue at exactly the moment a user is deciding whether your password-reset email is real. But BIMI has a hard prerequisite: your domain must already be at DMARC enforcement (p=quarantine or p=reject) with sufficient coverage. You cannot bolt a logo onto an unauthenticated domain.

That dependency is useful framing for the whole project. BIMI is not a separate task, it is the reward for doing SPF, DKIM and DMARC properly first. When you are ready, the BIMI checker validates your record and the SVG, and do you need BIMI covers whether the VMC cost is worth it for your stage.

What good looks like, in order

Pulling the threads together, here is the sequence that takes a SaaS sender from chaos to a brand that mailbox providers trust.

1. Inventory every sender. List every system that sends mail "as you", including the forgotten ones: status pages, error trackers, calendar invites, the CRM a sales rep wired up last quarter. The DMARC checker plus a few days of p=none reports will surface sources you did not know existed.
2. Design subdomains by stream. Separate transactional, marketing and any customer-generated mail onto their own subdomains so reputation and SPF lookups stay isolated.
3. Configure SPF per subdomain, keeping each record under 10 lookups, ending in ~all until verified.
4. Set up DKIM with a distinct selector per system, 2048-bit where possible, and write down your rotation plan.
5. Publish DMARC at p=none with rua reporting, read the reports, and fix every failing legitimate source before tightening.
6. Walk each stream to quarantine, then reject, fastest on transactional, more cautiously on bulk, using sp= to protect subdomains by default.
7. Add MTA-STS and TLS-RPT, then BIMI once you are enforced.
8. Monitor continuously, because a vendor's IP change, an expired DKIM key, or a customer's bad list can break a stream overnight, and at SaaS volume that is revenue.

The honest summary for a software company: email authentication is not a one-off DNS chore, it is operational infrastructure that needs the same change management and monitoring you give your production systems. The subdomain split is the lever that makes the rest manageable, because it turns "our email reputation" into several independent things you can reason about and protect separately.

If you would rather not hand-manage selectors, SPF lookups, policy ramps and per-customer delegation, that is exactly the work DMARC Engine does for you: it takes each of your sending domains and subdomains safely from p=none to p=reject with no outage, hosts the SPF, DKIM, MTA-STS and BIMI records, and watches them with change alerts so a broken stream pages you rather than your customers. Start by checking where you stand today with the DMARC checker, then see the managed approach under products and monitoring.