Email Deliverability for SaaS: SPF, DKIM and DMARC Made Simple

Email Deliverability for SaaS: SPF, DKIM and DMARC Made Simple — cover image

Few things frustrate a new SaaS customer more than a signup that never arrives. The verification email sits in spam, the password reset vanishes, the invoice is never seen. Support tickets pile up with the same line: "I did not get your email". Behind many of these cases is a short list of DNS records and sending habits that nobody on the team owns.

This guide explains email deliverability in plain terms for founders and developers. You will learn what SPF, DKIM and DMARC do, how to set them up in a safe order, how to separate your mail streams, and how to monitor reputation so problems are caught before customers notice.

Why Email Still Matters for Product Teams

Even in an age of in-app messaging and chat, email remains the backbone of account lifecycle: verification, magic links, receipts, alerts and security notices. If those fail, activation and revenue suffer silently. Unlike a bug that throws an error, a deliverability problem leaves no stack trace. It appears as lower activation, more support requests and customers who assume your product is broken.

Mailbox providers have also raised the bar. Large providers expect authenticated mail, low complaint rates and easy unsubscribes for bulk senders. Teams that treat email as an afterthought may find that delivery degrades without any code change on their side.

The Three Records You Need to Understand

SPF: who may send

Sender Policy Framework is a DNS TXT record that lists the servers and services allowed to send mail using your domain in the envelope sender. A typical record names your email provider and ends with a rule for everything else. Two common pitfalls: having more than one SPF record on the same domain (only one is valid), and exceeding the limit of ten DNS lookups by chaining too many includes.

DKIM: proof of authenticity

DomainKeys Identified Mail attaches a signature to each message using a private key held by your sending service. Receivers fetch the matching public key from DNS and verify it. If the message was changed in transit or sent by an impostor, the check fails. Most providers give you one or more CNAME or TXT records to add. Use long keys where supported and rotate them occasionally.

DMARC: policy and visibility

Domain-based Message Authentication, Reporting and Conformance ties the other two together. It requires that SPF or DKIM passes and aligns with the domain shown in the visible From address. It also tells receivers what to do on failure (none, quarantine or reject) and where to send aggregate reports. Those reports are a gift: they reveal every system sending mail as your domain, including ones you forgot, like an old CRM or a marketing tool someone signed up for.

A Real-World Example: The Missing Invoice Emails

Picture a hypothetical B2B SaaS that sends signup confirmations through one provider, invoices through its billing platform and newsletters through a third tool. Everything runs from the root domain. The team adds a new marketing campaign to a purchased list, and complaints rise. Within days, signup confirmations begin landing in spam for some mailbox providers because reputation is shared across all streams on the domain. Invoices are marked suspicious because the billing platform was never added to SPF and has no aligned DKIM.

The fix is not mysterious. The team inventories every sender, adds the billing platform to authentication, moves marketing to a subdomain with its own reputation, starts DMARC in monitoring mode and cleans the list. After a period of warm, consistent sending, delivery stabilises. The lesson: deliverability is the sum of authentication, reputation and behaviour, and each can be managed. If you are building a product where billing email matters, our guide to SaaS dunning and failed payment recovery shows why reliable messaging protects revenue.

Step-by-Step: Setting Up Authenticated Email

  1. Inventory every sender. List each tool that sends email as your domain: application mailer, billing, support desk, CRM, marketing platform, internal alerts. Ask each team, and use DMARC reports later to catch what was missed.
  2. Separate streams. Use distinct subdomains, for example one for transactional mail and another for marketing. Keep personal mailboxes on the main domain.
  3. Configure SPF per sending domain. Publish a single record that includes only the services actually used. Keep an eye on the lookup limit.
  4. Enable DKIM for every service. Add the provider's records, then verify signing by sending a test and reading the headers.
  5. Publish DMARC in monitoring mode. Start with a policy of none and a reporting address. Use a reporting tool or service to read the XML summaries in a friendly format.
  6. Fix alignment issues. Make sure the domain in the From header aligns with the domain authenticated by SPF or DKIM. Many failures come from third-party tools signing with their own domain.
  7. Tighten policy gradually. After reports look clean for a few weeks, move to quarantine for a small percentage, then to a higher percentage, and finally to reject.
  8. Add list hygiene and unsubscribe handling. Honour opt-outs quickly, include a working one-click unsubscribe on bulk mail, and remove hard bounces immediately.
  9. Monitor reputation. Register your domains with the postmaster tools offered by major mailbox providers and watch complaint rates, authentication results and spam indicators.
  10. Document ownership. Name one person responsible for DNS changes and review sending sources whenever a new tool is adopted.

Reputation: The Part DNS Cannot Fix

Authentication proves who you are. Reputation reflects how recipients treat you. Providers watch complaint rates, bounce rates, spam trap hits, engagement and consistency of volume. Sudden jumps, such as going from a few hundred emails a day to tens of thousands after a launch, look suspicious. Warm up gradually when adding a new domain or sending service.

Engineering Practices for Reliable Transactional Email

Treat email like any other external dependency. It can fail, throttle, bounce and duplicate. Build with that in mind.

Monitoring and Troubleshooting Checklist

When someone reports missing mail, work through a consistent list. First, confirm the message was accepted by your provider and check its event log. Second, look at the authentication results in the received message headers. Third, check whether the recipient's domain is blocking you by reading the bounce message. Fourth, examine recent changes: new tools, DNS edits, volume spikes or template changes. Fifth, check your standing in provider postmaster dashboards. Writing this as a runbook saves hours and turns each incident into a reusable fix.

For ongoing assurance, set up automated alerts when bounce or complaint rates exceed a threshold you choose, and send a seed test to a few mailboxes after every template or DNS change. Pair this with the practices in our article on web app error monitoring and alert triage so email health is visible beside application health.

Common Setup Mistakes Worth Checking Today

Several errors appear again and again in audits. A domain publishes two SPF records instead of one, so neither is honoured. A team adds a new marketing tool but forgets to authenticate it, so its mail fails DMARC alignment once the policy tightens. DKIM keys are generated but never published for the correct selector. A DMARC reporting address points to a mailbox nobody reads, so the reports that would reveal problems are ignored. Finally, someone moves to a strict policy before reviewing reports and accidentally blocks legitimate invoices. A quick review against this list, repeated every quarter, catches most of these before customers do.

Key Benefits of Getting Email Right

Conclusion

Email deliverability is a mix of three things: proving your identity with SPF, DKIM and DMARC, earning a good reputation through clean lists and steady sending, and engineering your product so messages are queued, tracked and retried. None of it is glamorous, yet it quietly decides whether customers can sign in, pay and trust you.

If your product has email problems or you are planning a new SaaS platform, explore our SaaS development services or contact the Mavani Solution team. We can audit your setup and build a dependable messaging layer.

Frequently Asked Questions

What do SPF, DKIM and DMARC actually do?
SPF lists which servers may send mail for your domain. DKIM adds a cryptographic signature that proves a message was not altered and came from an authorised sender. DMARC tells receiving servers what to do when SPF or DKIM checks fail and sends you reports about it.
Should transactional and marketing emails use the same domain?
It is usually wiser to separate them, for example using a subdomain for marketing. That way a spam complaint spike from a campaign is less likely to damage the reputation of the stream that carries password resets and receipts.
What DMARC policy should we start with?
Begin with a monitoring policy (p=none) and read the reports to find legitimate senders you forgot. Once everything passes, move gradually to quarantine and then reject, as confidence grows.
Why do our emails go to spam even with correct DNS records?
Authentication is necessary but not sufficient. Reputation, complaint rates, list quality, sudden volume spikes, spammy content and broken unsubscribe handling can all push messages to spam even when records are correct.
Do we need a dedicated IP address?
Not for most early-stage products. A reputable provider's shared pool is usually fine at low volume. A dedicated IP can help at sustained high volume, but it must be warmed up carefully and maintained.