Your New SaaS Tool Sends Email. Use This Onboarding Checklist First.

A new SaaS tool is usually introduced with good intentions. Marketing wants automation. Finance wants smoother invoices. Support wants ticket notifications. Product wants cleaner lifecycle messaging.

Then someone clicks “connect domain”, copies an SPF include into DNS, and starts sending.

That is how email authentication debt accumulates.

Most DMARC and deliverability problems do not begin with a malicious actor. They begin with an ungoverned sender launch.

The rule: no platform sends first and gets reviewed later

If a new tool will send mail using your brand, the launch should be treated like a controlled infrastructure change.

That does not mean a month of bureaucracy. It means a short checklist with named ownership.

Step 1: define what the tool is allowed to send

Before touching DNS, answer:

• Is this tool sending marketing, billing, support, or product mail?
• Which team owns the content?
• Which team owns the domain configuration?
• Which visible From address will it use?
• Which reply-to mailbox will receive responses?

If nobody owns those answers, do not proceed.

Step 2: decide whether it should use the root domain or a subdomain

Many tools should not send from the same domain identity used for executive mail and finance conversations.

A subdomain is often the cleaner choice when:

• the tool is marketing-focused
• the mail volume is high
• the sender reputation profile differs from corporate mail
• the tool is run by a separate team

Examples:

• news.example.co.za for campaigns
• billing.example.co.za for invoice notifications
• updates.example.co.za for product mail

This gives you clearer boundaries for authentication, reputation, and reporting.

Step 3: review SPF impact before adding anything

Do not paste an include into DNS without checking the current SPF record.

Ask:

• Are we already close to the 10-lookup SPF limit?
• Is this include actually required for the chosen sending mode?
• Does another tool already cover this mail path?
• Is a dedicated subdomain safer than touching the root record?

SPF changes should be intentional. One more include is often what turns a merely messy record into a broken one.

Step 4: enable DKIM before the first live send

If the platform supports DKIM, enable it before launch, not after the first complaint.

DKIM matters because:

• it gives DMARC a more reliable alignment path
• it survives some routing scenarios SPF does not
• it makes sender identity more resilient when infrastructure changes

Do not settle for “the platform supports DKIM somewhere”. Verify it is configured for the exact domain or subdomain you will use.

Step 5: publish or review DMARC for the sending domain

The question is not only whether a DMARC record exists somewhere in the organisation. The question is whether the chosen sending domain is covered appropriately.

Check:

• what the current DMARC policy is
• whether the subdomain inherits the right behaviour
• where aggregate reports are going
• who will review the new sender once traffic starts

Adding a sender without looking at DMARC is how “temporary” exceptions become permanent risk.

Step 6: run a controlled pre-launch test

Send test messages to a small set of monitored mailboxes.

Validate:

• visible From address is correct
• reply path behaves as expected
• SPF passes or aligns as intended
• DKIM signs and validates
• DMARC passes
• links, branding, and unsubscribe behaviour are correct

This should happen before real customers see the tool.

Step 7: monitor the first live traffic

The launch is not complete when the first message is sent. It is complete when the first week of sending looks normal.

Review:

• DMARC reports for the new sender
• bounce patterns
• complaint patterns
• support tickets triggered by the mail
• any mailbox filtering anomalies

This is where you catch the issues that do not show up in a test mailbox.

Step 8: document ownership and retirement conditions

Every sender should have:

• a business owner
• a technical owner
• the authenticated domain or subdomain it uses
• the DNS records that support it
• a clear retirement path when the tool is no longer needed

Without that, old senders linger in SPF, DKIM selectors stay live unnecessarily, and DMARC analysis gets noisier over time.

A short approval gate you can reuse

Before any tool is allowed to send as your domain, someone should be able to confirm all of this in one place:

1. sending purpose is defined
2. domain or subdomain choice is approved
3. SPF impact reviewed
4. DKIM enabled and validated
5. DMARC coverage confirmed
6. pre-launch tests passed
7. owners assigned
8. post-launch monitoring scheduled

That is enough process for most teams. Anything less is usually too little.

Why this matters even for “small” tools

The low-volume sender is often the one that gets least attention. That is exactly why it becomes a hidden risk.

A forgotten HR tool, a survey platform, or a finance add-on can:

• weaken SPF
• fail DMARC quietly
• create phishing confusion for recipients
• damage trust in legitimate mail

Every sender inherits your brand. Every sender deserves review.

Final takeaway

The cleanest way to manage email security is not fixing broken authentication after the fact. It is preventing unaudited senders from launching in the first place.

Treat every new SaaS sender as a change event. Decide the domain model, validate SPF and DKIM, confirm DMARC coverage, test, monitor, and document ownership.

If your current environment has grown tool by tool without that discipline, a sender inventory is the right place to start before the next platform goes live.