Email Authentication Checklist for SaaS Platforms

Give each tenant a dedicated subdomain (for example, customer.example.com) or allow bring-your-own-domain to isolate reputation and simplify DMARC alignment. This reduces cross-tenant blast radius when a sender's reputation dips.

Document whether alignment must exactly match the From domain (strict) or a subdomain (relaxed). Strict alignment enhances anti-spoofing for regulated customers, while relaxed reduces breakage in forwarding scenarios.

Use a custom bounce domain aligned with the visible From or its subdomain so SPF can pass alignment. This is essential when your MTA handles bounces and your app relies on inbound bounce parsing.

Issue unique DKIM selectors and keys per tenant to compartmentalize risk and enable staged key rotation. Store key metadata in your tenant config model for automated deployments.

If your platform forwards inbound mail, implement Sender Rewriting Scheme to preserve SPF and validate ARC headers when available. This prevents false DMARC failures for forwarded customer email.

Persist SPF, DKIM, and DMARC outcomes at message-level next to MIME metadata and webhook delivery status. Include fields for alignment and selector so customers can filter and audit.

Keep SPF lookups under the limit of 10 and avoid overly broad ~all for production senders. Validate includes for any ESPs and ensure your return-path domain points to authorized IPs.

Configure MX and SPF for a bounce domain tied to your MTA and align it to the visible From domain. This ensures DMARC SPF alignment while keeping bounces routable to your inbound parser.

Use selectors like sYYYYMM for schedule-based rotation and bind them to tenant IDs in your config. Longer keys reduce risk and predictable selectors simplify rollovers.

Avoid long TTLs on TXT records so you can roll DKIM keys or SPF includes quickly during incidents. A 5-15 minute TTL balances cache efficiency and agility.

Start with p=none, rua, and ruf recipients that your system can parse, then ramp to quarantine or reject. DMARC reports feed your monitoring and tenant-facing analytics.

Sign zones and watch for DS mismatches that could break TXT visibility. DNSSEC protects DKIM keys and SPF content from tampering in transit.

Publish MTA-STS and TLS-RPT records for your sending and receiving hosts to enforce TLS and collect delivery telemetry. This strengthens channel security alongside authentication.

Set d= to the tenant's domain or aligned subdomain and include i= where needed for scoping. Verify that templating or footer injection does not mutate signed headers post-signing.

Use relaxed/relaxed for resilience to whitespace or minor MIME variations introduced by downstream relays. Test that your MIME generator produces deterministic headers and boundaries.

Ensure the envelope sender uses your aligned return-path domain so DMARC can pass on SPF even when DKIM fails. This also keeps bounces flowing into your inbound API for status updates.

Lock the order and casing of signed headers and avoid post-signing additions like List-Unsubscribe or tracking headers. If required, sign after injection or whitelist only stable headers.

Publish new selectors before switching signers, then deprecate the old record after cache expiry. Automate rollovers per tenant to reduce manual error.

Require DNS-based verification before allowing a tenant to send using a custom domain. This avoids unauthorized use and increases DMARC pass rates.

Extract SPF, DKIM, and DMARC results from inbound MIME and store them alongside the message object. Normalize vendor-specific tokens so webhooks and APIs stay consistent.

Run DKIM verification against the received headers and body canonicalization to confirm a pass or fail. Record the selector, d= domain, and reason codes for client debugging.

Evaluate From alignment against SPF and DKIM outcomes to flag spoofing attempts. Expose a boolean field like dmarc_aligned in webhook payloads for easy filtering.

If ARC is present, assess chain validity to avoid false negatives when intermediaries modify messages. Include arc_status and instance count in API responses.

Normalize header folding, CRLF line endings, and quoted-printable whitespace to avoid false DKIM fails. Reject malformed structures or surface a clear failure reason in logs.

Include spf_result, dkim_result, dmarc_result, aligned_from, and selectors in your webhook schema. This lets downstream apps route and quarantine before deeper processing.

Add a stable event_id derived from Message-ID and body hash to each webhook. This prevents duplicate processing when retries occur.

Retry transient webhook failures with capped backoff and sign payloads using HMAC for verification. Document expected 2xx acknowledgment behavior for clients.

Allow customers to define rules, for example drop or quarantine when dmarc_result = fail, or escalate to a review queue. Apply actions before delivering attachments to reduce risk.

Strip or hash fields like Authentication-Results that could leak infrastructure while still sending normalized results. Maintain the original in secure storage for audits.

Introduce new authentication properties behind a schema version and provide a migration window. This keeps downstream integrations stable while you expand capabilities.

Provide REST endpoints where clients can query messages by dmarc_aligned or dkim_selector. This helps teams that cannot host webhooks but still need secure triage.

Run jobs that fetch and lint SPF, DKIM, and DMARC TXT records for each tenant or sending domain. Fail builds on lookup count overages, syntax errors, or missing selectors.

Send test messages and collect Authentication-Results to confirm pass rates before releasing changes. Track by template and tenant to catch DKIM breakage from new content logic.

Ingest XML reports, attribute to tenants, and surface pass, fail, and alignment rates in dashboards. Alert when a tenant's fail rate spikes above thresholds.

Where policy allows, consume failure samples to debug spoofing and misconfigurations. Protect PII by storing these samples in restricted logs.

Notify on DKIM permerror, key not found, or sudden SPF temperror rates that indicate DNS outages. Tie alerts to a runbook that includes rollback to prior selectors.

Log who generated, read, or rotated DKIM private keys and keep immutable records. This supports compliance and speeds incident response.