DMARC Analyzer

TL;DR

• SaaS senders are marketing-automation platforms - Salesforce Marketing Cloud (SFMC), HubSpot, Marketo, Mailchimp, ActiveCampaign, Klaviyo, Constant Contact, Brevo Marketing, Pardot, and Kit. The marketer builds bulk campaigns through a graphical UI; the platform sends to a contact list via the platform's IP infrastructure with your From: domain. DMARC alignment rides primarily on custom-domain DKIM, not SPF.
• The Feb 2024 Google / Yahoo bulk-sender requirements are the universal anchor. Senders above 5000 messages per day to Gmail or Yahoo Mail must publish DMARC at p=quarantine or stricter, custom- domain DKIM aligned to the From: domain, RFC 8058 List-Unsubscribe-Post one-click unsubscribe, and maintain a complaint rate below 0.3 percent. Failure to meet all four conditions triggers throttling, deferrals, or bulk- foldering at scale.
• List-Unsubscribe-Post (RFC 8058) is load-bearing. Every SaaS sender platform publishes the header pair by default for bulk campaigns, but the operator must verify it is enabled (some platforms hide the toggle behind a Compliance mode or Bulk sender mode setting). The header pair is List-Unsubscribe: <https://...>, <mailto:...> + List-Unsubscribe-Post: List-Unsubscribe =One-Click.
• Engagement-based reputation is the DMARC-orthogonal lever. Receivers track open rate, click rate, reply rate, and complaint rate per sending subdomain. Sub-10 percent open rate or sub-1 percent click rate triggers throttling even when DMARC, SPF, and DKIM all pass. List hygiene (double opt-in, sunset policy, bounce scrubbing) is a DMARC prerequisite.
• Subdomain segmentation is mandatory, not optional. Use marketing.example.com, news.example.com, hello.example.com, or em.example.com for SaaS-sent marketing campaigns. Independent DMARC policy via the np= / sp= tags lets the apex ramp p=reject while a marketing subdomain remains at p=none during platform onboarding.
• Per-platform DKIM selector conventions vary widely. SFMC uses <bu-selector>._domainkey (Business Unit ID); HubSpot uses hs1-<portal-id>._domainkey + hs2-<portal-id>._domainkey; Marketo uses k1._domainkey + k2._domainkey; Mailchimp uses k1._domainkey + k2._domainkey; ActiveCampaign uses dk._domainkey; Klaviyo uses klaviyo._domainkey; Constant Contact uses k1._domainkey + k2._domainkey; Brevo Marketing uses mail._domainkey; Pardot uses <org-alias>._domainkey.
• Dedicated IP pool warm-up takes 30 to 50 days. Send only to the most engaged contacts (last 90 days) during warm-up. The canonical ramp doubles every other day from ~50 messages on Day 1 to steady state. Klaviyo, Mailchimp, ActiveCampaign, Constant Contact automate warm-up; SFMC, HubSpot, Marketo require manual ramp scheduling.
• The DMARC Analyzer dashboard surfaces every per-source-IP alignment outcome so the operator can see exactly which SaaS platform is aligning cleanly and which is not - critical for diagnosing platform-migration windows and multi-platform marketing estates.

1. What this guide covers

This guide is the deployment companion for DMARC on marketing-automation SaaS platforms. It documents the configuration steps, per-platform DKIM selector conventions, RFC 8058 List-Unsubscribe-Post one-click unsubscribe requirements, engagement-based reputation thresholds, dedicated-IP-pool warm-up cadence, and subdomain segmentation strategy that distinguish SaaS-sender DMARC alignment from transactional-email DMARC alignment (covered in the sibling guide DMARC for Transactional Email).

Platforms covered (10):

• Salesforce Marketing Cloud (SFMC, formerly ExactTarget) - enterprise marketing-automation suite with per-Business-Unit Sender Authentication Package (SAP).
• HubSpot Marketing Hub - mid-market marketing automation with portal-scoped DKIM selectors.
• Adobe Marketo Engage - enterprise B2B marketing automation with k1 / k2 rotating DKIM selectors.
• Mailchimp (Intuit) - SMB-to-mid bulk-email platform with k1 / k2 CNAME-delegated DKIM at dkim.mcsv.net.
• ActiveCampaign - marketing-automation + CRM with dk._domainkey single-selector DKIM.
• Klaviyo - ecommerce-focused marketing platform with klaviyo._domainkey selector and bounce CNAME at em._domainkey.
• Constant Contact (Endurance / Newfold Digital) - SMB email marketing with k1 / k2 rotating DKIM selectors.
• Brevo (formerly Sendinblue, marketing side) - marketing-automation + transactional-API platform. This page covers the marketing side; transactional is in the sibling guide.
• Salesforce Pardot (now Account Engagement) - B2B marketing automation within the Salesforce ecosystem; per-org-alias DKIM selector.
• Kit (formerly ConvertKit) - creator-economy email-newsletter platform with per-account DKIM CNAMEs.

The universal pattern (sections 2-6) applies to every SaaS sender; the per-platform walkthroughs (section 7) document each platform's specific UI navigation, selector convention, and verification step.

2. Why SaaS senders need a different DMARC strategy

SaaS senders differ from transactional ESPs in five fundamental ways that drive DMARC strategy:

1. Volume profile. Transactional ESPs send one message per recipient per application event (password reset, receipt, magic link). Volume scales with user actions; a typical SaaS application generates 10-100 transactional messages per active user per month. SaaS senders send one campaign per audience segment per scheduled or journey-triggered cadence. Volume scales with audience size; a 100,000-contact list with weekly campaigns generates 400,000 messages per month. The Feb 2024 Gmail / Yahoo bulk-sender requirements (5000 messages/day) rarely apply to transactional traffic but almost always apply to marketing traffic.
2. Engagement-based reputation. Receivers track open rate, click rate, reply rate, and complaint rate per sending subdomain. Transactional mail enjoys high baseline engagement (recipients expect and action password resets, receipts, magic links). Marketing mail's engagement is inherently lower because recipients did not request each specific campaign. Receivers throttle senders with sub-10 percent open rate even when DMARC, SPF, and DKIM all pass. Marketing mail requires explicit list- hygiene discipline that transactional mail does not.
3. List-Unsubscribe-Post (RFC 8058) is mandatory. The Feb 2024 Gmail / Yahoo bulk-sender requirements mandate one-click unsubscribe via the List-Unsubscribe-Post header pair for senders above 5000 messages per day. Transactional messages typically do not require unsubscribe (they are operational notifications); marketing messages always do. Every SaaS sender platform documented on this page publishes both headers by default, but the operator must verify activation.
4. Dedicated IP pool warm-up. Marketing volume on a fresh dedicated IP requires a 30-50 day ramp from ~50 messages on Day 1 to the steady-state volume. Transactional volume rarely needs warm-up because triggered low-volume traffic patterns are accepted from new IPs more readily than bulk campaigns. The page covers the warm-up cadence in section 9.
5. Subdomain segmentation is mandatory. Marketing reputation is fundamentally incompatible with corporate / transactional reputation because of the engagement / complaint rate gap. SaaS senders MUST be on a dedicated subdomain with independent DMARC policy via np= / sp= tags. The page covers segmentation strategy in section 6.

3. The Feb 2024 Gmail / Yahoo bulk-sender requirements

Effective Feb 1, 2024, Gmail and Yahoo Mail enforce a unified set of requirements for senders above 5000 messages per day to their users. The threshold counts across all subdomains at the organizational-domain level (per the Public Suffix List), so any non-trivial SaaS-sender program qualifies.

The four mandatory conditions:

Penalties for non-compliance scale with severity:

• Missing one condition - rate limiting, deferred delivery, occasional bulk-foldering.
• Missing two or more conditions - sustained bulk-foldering, increasing delivery latency, eventual hard rejection with SMTP 421/550 codes.
• Complaint rate above 0.3 percent - throttled within hours; full recovery requires sustained list-hygiene improvement plus engagement-based segmentation over weeks.

Gmail's enforcement reference: Google Workspace Admin Help - Email sender guidelines. Yahoo's enforcement reference: Yahoo Postmaster. Microsoft applies similar but less strictly enforced requirements via SNDS and the Junk Mail Reporting Program.

4. RFC 8058 List-Unsubscribe-Post one-click unsubscribe

RFC 8058 defines the List-Unsubscribe-Post header that accompanies List-Unsubscribe (RFC 2369) to enable one-click unsubscribe. The canonical header pair:

List-Unsubscribe: <https://example.com/unsubscribe?token=abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

How the one-click flow works:

1. The receiver (Gmail, Yahoo, Microsoft) sees the List-Unsubscribe-Post header and surfaces a one-click Unsubscribe button in the inbox UI (Gmail shows it inline next to the sender name; Yahoo shows it in the message-options menu).
2. When the recipient clicks the button, the receiver POSTs an empty body to the URL in the List-Unsubscribe header. The POST body is empty; the receiver does NOT navigate the user to the URL in a browser tab.
3. The sender's unsubscribe endpoint receives the POST, validates the token (HMAC signature or per-recipient opaque ID), and removes the recipient from active sends.
4. Per Gmail and Yahoo policy, the sender must action the unsubscribe within 2 business days. Continued sending after the deadline triggers a sustained complaint-rate spike and throttling.

Verification command (replace marketing@example.com with a recent bulk-campaign recipient address you control):

# Show the headers of the most recent marketing message
mu show -i marketing@example.com 1 | grep -i List-Unsubscribe

Both headers must appear. If only List-Unsubscribe appears without List-Unsubscribe-Post, the receiver falls back to a confirmation-page flow (not one-click) and the sender is not compliant with the Feb 2024 bulk-sender requirements.

5. Engagement-based reputation thresholds

Receivers track engagement metrics per sending subdomain (and per sending IP for dedicated-IP senders). The operational thresholds below summarise the Gmail Postmaster Tools and Yahoo Postmaster aggregated signals; the page presents them as bands rather than hard cutoffs because the thresholds are advisory and receiver-specific.

A marketing program in the throttle-risk band on any metric will see inbox-placement degradation even when DMARC, SPF, and DKIM all pass. The DMARC alignment surface is necessary but not sufficient for marketing inbox placement.

Open rate is the most-watched metric because of Apple Mail Privacy Protection (MPP) skew. MPP pre-fetches images for all recipients, which inflates open rate by ~30 percent on Apple Mail audiences. Receivers (Gmail, Yahoo) discount the MPP-inflated open rate when computing reputation, so the operator should rely on click rate and reply rate as the engagement signal of record.

6. Subdomain segmentation strategy

SaaS senders MUST publish under a dedicated subdomain. The recommended naming convention:

The dedicated-subdomain pattern enables five operational benefits:

1. Reputation isolation. Marketing traffic builds a distinct sender reputation. A degraded marketing subdomain does not compromise transactional delivery (password resets, receipts) or corporate mail.
2. Independent DMARC policy. The organizational domain can ramp p=reject while marketing.example.com remains at p=none during platform onboarding. Use the np= tag at the organizational domain to set non-existent subdomain policy distinct from sp= (existing subdomain) policy.
3. Operational clarity. The marketing team verifies alignment on their subdomain without coordinating with the security team owning the apex.
4. Audit trail. Aggregate reports filtered by subdomain make it immediately clear which class of mail is failing alignment.
5. Migration safety. Switching from Mailchimp to ActiveCampaign means re-authenticating only the marketing subdomain, not the entire estate.

DMARC record at the marketing subdomain (during platform onboarding):

# _dmarc.marketing.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ri=3600; fo=1"

DMARC record at the organizational domain (covers the apex and any subdomain without its own DMARC record):

# _dmarc.example.com
"v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com; pct=100; adkim=r; aspf=r"

The subdomain-specific _dmarc.marketing.example.com record OVERRIDES the organizational sp= for that subdomain, so the marketing subdomain can remain at p=none while everything else stays at p=reject. Once the marketing subdomain is fully aligned, delete the subdomain-specific record and let the organizational sp=reject take over.

7. Per-platform DKIM setup walkthroughs

Each subsection documents the literal UI navigation path, the selector convention, the CNAME / TXT records to publish, and the verification step.

7.1 Salesforce Marketing Cloud (SFMC, formerly ExactTarget)

UI path: Marketing Cloud Setup > Email Studio > Setup > Sender Authentication Package (SAP).

Authentication artefact: the SAP bundles three components - per-Business-Unit DKIM keys, a custom Reply-To domain, and a custom Return-Path / bounce domain. The SAP must be configured per Business Unit; if your tenant has multiple Business Units sending mail, each one needs its own SAP.

Steps:

1. Open Setup > Email Studio > Setup > Sender Authentication Package, click Configure for the Business Unit, enter your sending domain (e.g. cloud.example.com), submit.
2. Salesforce provisions the SAP within ~24 hours and emails the DNS records to publish.
3. Publish the records: CNAME at <bu-selector>._domainkey.cloud.example.com pointing to the SFMC DKIM hostname, SPF include (v=spf1 include:cust-spf.exacttarget.com ~all) at the sending subdomain apex, CNAME for the custom Return-Path (e.g. bounces.cloud.example.com CNAME bounce.exacttarget.com).
4. Salesforce verifies the records and activates the SAP.
5. Publish DMARC at _dmarc.cloud.example.com: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com.

7.2 HubSpot Marketing Hub

UI path: Settings (gear icon) > Website > Domains and URLs > Connect a domain > Email sending domain.

Selector convention: hs1-<portal-id>._domainkey + hs2-<portal-id>._domainkey (portal ID is your HubSpot account ID, typically a 6-8 digit number).

Records to publish: two CNAMEs at the selectors above pointing to HubSpot's DKIM key infrastructure, plus SPF include (v=spf1 include:_spf.hubspotemail.net ~all) and an optional MX record for bounce handling.

Verification: return to HubSpot after publishing, click Verify. HubSpot resolves the CNAMEs typically within minutes and marks the domain Connected.

List-Unsubscribe-Post: enabled by default for all bulk sends; verify in the campaign Send Settings panel.

7.3 Adobe Marketo Engage

UI path: Admin (top nav) > Email > SPF / DKIM.

Selector convention: k1._domainkey + k2._domainkey (rotating pair, same convention as Mailchimp and Constant Contact - do NOT confuse Marketo's k1/k2 CNAMEs with those vendors).

Records to publish: two CNAMEs pointing to Marketo-supplied DKIM hostnames (typically <random>.dkim.mktomail.com), SPF include (v=spf1 include:mktomail.com ~all), custom Branding Domain CNAME for SPF alignment (e.g. mkto.example.com CNAME mkto-lon01.com).

List-Unsubscribe-Post: Marketo handles it automatically when the operator enables Unsubscribe in the email template; verify in Email Editor 2.0 > Email Settings > Compliance.

7.4 Mailchimp (Intuit)

UI path: Account avatar dropdown > Domains > Authenticate (next to your sending domain).

Selector convention: k1._domainkey CNAME dkim.mcsv.net + k2._domainkey CNAME dkim2.mcsv.net (rotating pair).

SPF include: v=spf1 include:servers.mcsv.net ~all.

Verification: Mailchimp resolves the CNAMEs and marks the domain Authenticated with a green checkmark when DKIM + SPF both resolve.

List-Unsubscribe-Post: automatic for all campaigns; cannot be disabled (correct compliance default for bulk marketing).

7.5 ActiveCampaign

UI path: Settings > Advanced > Mail Sender (Domain Authentication tab).

Selector convention: dk._domainkey (single selector, not a rotating pair).

Records to publish: CNAME at dk._domainkey.<your-domain> pointing to ActiveCampaign's DKIM key hostname, SPF include (v=spf1 include:_spf.activecampaign.com ~all), optional bounce CNAME for SPF alignment.

Verification: ActiveCampaign resolves the CNAME and marks the domain Authenticated; the UI shows the resolution status in real time.

7.6 Klaviyo

UI path: Account > Settings > Domains and Hosting (or Email > Branded Domain in newer UI).

Selector convention: klaviyo._domainkey (single selector) plus a bounce CNAME at em._domainkey.<your-domain>.

Records to publish: CNAME at klaviyo._domainkey.<your-domain> pointing to Klaviyo's DKIM infrastructure, plus the bounce CNAME at em._domainkey, SPF include (v=spf1 include:_spf.klaviyo.com ~all).

Verification: Klaviyo's UI shows a real-time Verified / Not Verified status next to each record.

List-Unsubscribe-Post: auto-enabled for all sends; Klaviyo also handles two-click compliance for SMS-style consent revocation.

7.7 Constant Contact

UI path: My Profile (account name dropdown) > Domain Settings > Authenticate a Domain.

Selector convention: k1._domainkey + k2._domainkey (rotating pair, same naming as Mailchimp but different CNAME targets pointing to Constant Contact's DKIM infrastructure).

SPF include: v=spf1 include:_spf.constantcontact.com ~all.

Verification: Constant Contact resolves the CNAMEs and marks the domain Authenticated.

7.8 Brevo (formerly Sendinblue, marketing side)

UI path: Senders & IPs > Domains > Add a domain (Authenticate).

Selector convention: mail._domainkey (single selector).

Records to publish: CNAME at mail._domainkey.<your-domain> pointing to Brevo's DKIM key infrastructure, plus a Brevo-supplied bounce CNAME for SPF alignment, SPF include (v=spf1 include:spf.sendinblue.com ~all). The Brevo transactional side uses a separate selector chain - see the DMARC for Transactional Email sibling guide for the transactional-specific records.

7.9 Salesforce Pardot (Account Engagement)

UI path: Pardot Admin > Domain Management > Email Sending Domains.

Selector convention: <org-alias>._domainkey where org-alias is your Pardot org identifier; some older accounts use pardot._domainkey.

Records to publish: CNAME at <org-alias>._domainkey.<your-domain> pointing to Pardot's DKIM key infrastructure, SPF include (v=spf1 include:_spf.pardot.com ~all or include:em.salesforce.com for newer Account Engagement orgs), tracker domain CNAME (separate from the email DKIM and required for click tracking).

Pardot's per-org-alias selector is the most surprising convention in the SaaS-sender ecosystem because the selector value rotates with the Salesforce org rename, so a Salesforce org rename forces a Pardot DNS re-authentication.

7.10 Kit (formerly ConvertKit)

UI path: Account Settings > Email > Custom domain.

Selector convention: per-account DKIM CNAMEs generated when the operator adds the sending domain; selectors typically of the form <random>._domainkey with no fixed naming convention.

Records to publish: CNAMEs as Kit's UI displays them, SPF include (v=spf1 include:_spf.convertkit.com ~all or include:_spf.kit.com for newer Kit-branded accounts).

Verification: Kit's UI shows a real-time Verified status next to each record.

8. List hygiene as a DMARC prerequisite

A 0.3 percent complaint rate or a 5 percent hard-bounce rate triggers Gmail / Yahoo throttling regardless of DMARC alignment. List hygiene is therefore a DMARC prerequisite, not an optional deliverability tactic. The five practices that prevent the throttle:

1. Double opt-in. Confirm every new subscriber by sending an opt-in email and requiring a click before adding them to the active list. Double opt-in cuts hard-bounce rate from 5-15 percent (typical for single opt-in) to under 1 percent because typo-laden addresses do not survive the confirmation click. Mailchimp, ActiveCampaign, Klaviyo, and Constant Contact all support double opt-in as a per-list setting.
2. Sunset policy. Stop sending to recipients who have not engaged (opened or clicked) within a 90-180 day window. Receivers track engagement per recipient; continuing to send to dormant addresses degrades the sender's per-domain reputation. The sunset window depends on the campaign cadence: 90 days for weekly senders, 180 days for monthly senders.
3. Bounce scrubbing. Remove hard-bounced addresses immediately (every SaaS platform does this automatically). Address soft bounces after 3-5 consecutive bounces. Hard-bounce rate above 5 percent on any single campaign triggers throttling that persists for days.
4. Complaint handling via FBL feedback loops. Every major receiver (Gmail via FBL participation, Yahoo via the Complaint Feedback Loop, Microsoft via JMRP) sends complaint reports when recipients click the Spam button. Process those reports automatically to remove complaints from active sends within 24 hours. Mailchimp, SFMC, HubSpot, and Marketo handle FBL ingestion automatically.
5. List ownership transparency. Never purchase, rent, or scrape lists. Every SaaS sender platform's terms of service prohibit purchased lists; violations result in account suspension. Purchased lists also have characteristic complaint rates above 2 percent that trigger immediate throttling.

9. Dedicated IP pool warm-up cadence

Marketing volume on a fresh dedicated IP requires a 30 to 50 day ramp from ~50 messages on Day 1 to the steady-state volume. The canonical exponential ramp:

Send only to the most engaged contacts during warm-up - this maximises open rate and click rate while volume is small, so the receiver sees a high-quality sender signal. If you skip warm-up, expect throttling, deferrals, and bulk-foldering for 60-90 days until the IP recovers.

Platform automation support:

• Klaviyo - Smart Send Time + IP Warm-Up Pool (automatic).
• Mailchimp - Send Time Optimization (does not automate warm-up directly but limits Day 1 audience size).
• ActiveCampaign - Predictive Sending + Engaged Audience Filters.
• Constant Contact - basic engagement segmentation.
• SFMC, HubSpot, Marketo - require manual ramp scheduling via the Journey Builder, Workflow, or Smart Campaign respectively.
• Brevo Marketing, Pardot, Kit - manual ramp scheduling.

10. Multi-platform marketing estates

Enterprises commonly run two or three SaaS senders concurrently - SFMC or Marketo for the enterprise marketing program, Mailchimp or ActiveCampaign for an SMB-style segmented program, Klaviyo for ecommerce. Each platform needs its own custom-domain DKIM CNAMEs published in your DNS, all under distinct selectors.

Publishing all sets of CNAMEs simultaneously is fine - each platform signs messages with its own selector, and DMARC requires only ONE valid DKIM signature aligned with the From: header domain to pass. The receiver looks up only the selector named in the DKIM-Signature header s= field of each message, so unrelated selectors do not interfere.

For SPF: include all platforms in a single SPF record at the apex, but watch the 10-DNS-lookup limit (RFC 7208 section 4.6.4) - Mailchimp + Marketo + Klaviyo + your own MTA already consumes 4-6 lookups before counting redirects. Use a dedicated subdomain per platform (marketing.example.com on Mailchimp, mkto.example.com on Marketo, shop.example.com on Klaviyo) to keep each SPF record under the limit and isolate reputation.

11. Rollout cadence

The recommended 6-stage rollout for a new SaaS sender on a new dedicated subdomain:

1. Stage 1 (Day 1-3) - Publish DNS: SPF include, DKIM CNAMEs, custom Return-Path / bounce CNAME, optional MX records. Verify with dig from a different network than your local resolver.
2. Stage 2 (Day 3-7) - Verify in the platform UI: the platform marks the domain Authenticated. List-Unsubscribe-Post enabled in compliance settings.
3. Stage 3 (Day 7-14) - p=none at the marketing subdomain: publish DMARC at _dmarc.marketing.example.com with p=none; rua=mailto:dmarc-reports@example.com. Begin warm-up sends (~50 messages on Day 1 of warm-up to highest-engagement contacts).
4. Stage 4 (Day 14-30) - IP warm-up ramp: follow the exponential ramp from section 9. Monitor aggregate reports for unaligned messages (other SaaS senders accidentally using the marketing subdomain, forwarded mail breaking alignment). Aggregate-report alignment should be >95 percent by Day 30.
5. Stage 5 (Day 30-60) - p=quarantine: advance the marketing subdomain to p=quarantine; pct=10, then ramp pct to 25 / 50 / 75 / 100 over 2-3 weeks. Watch the Google Postmaster Tools spam-rate metric daily.
6. Stage 6 (Day 60+) - p=reject: advance the marketing subdomain to p=reject. At this point the organizational domain's sp=reject can take over (delete the subdomain-specific DMARC record) IF and only if the marketing subdomain is in steady-state alignment >99 percent. Otherwise keep the subdomain-specific record at p=reject for explicit policy visibility.

12. Common SaaS-sender DMARC mistakes

1. Sending marketing from the apex domain. Marketing reputation collapses into corporate / transactional reputation; every complaint against a marketing campaign drags down password-reset deliverability. Always use a dedicated subdomain.
2. Skipping IP warm-up. A sudden ramp from zero to 100,000 messages per day on a fresh dedicated IP triggers receiver throttling for 60-90 days. Follow the section 9 ramp.
3. Missing List-Unsubscribe-Post. The Feb 2024 Gmail / Yahoo bulk-sender requirements mandate the header pair. Missing it triggers throttling regardless of DMARC alignment.
4. Single opt-in. Hard-bounce rates of 5-15 percent on fresh single-opt-in lists trigger immediate throttling. Always use double opt-in.
5. Purchased / rented / scraped lists. Every SaaS platform's terms of service prohibit them; complaint rates above 2 percent will get the account suspended.
6. Ignoring the sunset policy. Sending to dormant contacts (180+ days no engagement) degrades per-recipient reputation and inflates complaint rates.
7. Mixing platforms on one subdomain. Sending Mailchimp campaigns from marketing.example.com while also sending Marketo campaigns from the same subdomain co-mingles reputation across platforms. Use a different subdomain per platform.
8. Forgetting to authenticate before sending. A campaign sent before the platform marks the domain Authenticated signs with the platform's default sender-handled domain (e.g. mail.mailchimp.com), which unaligns with your From: header. Wait for Authenticated status.
9. Hard-coding the wrong SPF include. Each platform has a specific include directive (servers.mcsv.net, _spf.hubspotemail.net, mktomail.com, etc.). Using the wrong include silently sends SPF to permerror after the 10-lookup limit.
10. Ignoring Google Postmaster Tools. Postmaster Tools surfaces the IP reputation, domain reputation, spam rate, and delivery errors that aggregate reports do not. Configure Postmaster Tools at the same time as the platform DKIM authentication and monitor the dashboard weekly.

13. Troubleshooting

The platform shows "Domain not authenticated" even though I published the CNAMEs.

DNS propagation. Wait 5-30 minutes, then click Verify again. Use dig +short cname <selector>._domainkey.<your-domain> @8.8.8.8 to check resolution from a public resolver instead of your local recursive resolver - some recursive resolvers cache NXDOMAIN longer than the TTL.

Aggregate reports show messages failing DKIM alignment even though I authenticated the platform.

The DKIM signature's d= domain does not match the From: header (DMARC alignment). Inspect a sample message in Header Analyzer and check the DKIM-Signature header's d= field. If it points to the platform's default signing domain (e.g. mail.mailchimp.com) the platform is not using your custom domain - re-verify in the platform UI that the domain is marked Authenticated.

I cannot find the List-Unsubscribe headers in raw message source.

Some platforms suppress List-Unsubscribe-Post for transactional-style messages (single-recipient automated sends) even within marketing platforms. For bulk campaigns the header pair should always be present. Verify in the campaign's Compliance / Footer settings that the unsubscribe link is enabled and the campaign type is Marketing (not Transactional).

Aggregate reports show alignment passing but Gmail Postmaster Tools shows my domain reputation as Low.

Engagement-based reputation. Refer to section 5: open rate, click rate, and complaint rate are the levers. Run a re-engagement campaign to the dormant portion of the list, then sunset the non-engagers. Domain reputation typically recovers in 2-4 weeks after sustained engagement improvement.

One campaign showed a sudden complaint-rate spike to 0.5 percent and now all subsequent campaigns are bulk-foldered.

You triggered throttle mode. Three actions: (1) pause the marketing program for 48 hours; (2) audit the offending campaign content for subject-line clickbait, misleading sender names, or non-consensual list segments; (3) resume with a half-rate warm-up (Day 1 = 50 percent of normal steady-state) for the next 7-10 days. Recovery typically takes 2-4 weeks of sustained low complaint rates.

I switched from Mailchimp to ActiveCampaign and now alignment is broken.

You forgot to delete Mailchimp's CNAMEs and publish ActiveCampaign's. Old DKIM CNAMEs do not interfere (each DKIM-Signature resolves only its own selector), but if the old SPF include still points at servers.mcsv.net and the new ActiveCampaign include is missing, every ActiveCampaign message fails SPF and (if DKIM isn't aligned either) fails DMARC. Update the SPF record to remove Mailchimp and add include:_spf.activecampaign.com.

Pardot stopped sending after my Salesforce admin renamed the org.

Pardot's per-org-alias DKIM selector rotates with the org rename. Re-authenticate the domain in Pardot Admin > Domain Management > Email Sending Domains; the new selector will be different. Publish the new CNAME and remove the old one.

My SFMC Business Unit shows "SAP not configured" even though I configured the SAP for the parent Business Unit.

SAP is per Business Unit, not inherited. Each Business Unit needs its own SAP configured separately. Open Setup > Email Studio > Setup > Sender Authentication Package and click Configure for the child Business Unit.

14. Frequently asked questions

How do I set up DMARC for Salesforce Marketing Cloud?

Six steps. (1) In Marketing Cloud, open Setup > Email Studio > Setup > Sender Authentication Package (SAP). The SAP is the bundled domain authentication artefact: custom Reply-To, custom Return-Path, and per-Business-Unit DKIM keys. (2) Click Configure for the Business Unit you send from, enter your sending domain (recommended: a dedicated subdomain like cloud.example.com or email.example.com), and submit. Salesforce will provision the SAP within ~24 hours and email you the DNS records to publish. (3) Publish the records: a CNAME at <bu-selector>._domainkey.<your-domain> pointing to the SFMC DKIM hostname, an SPF include (v=spf1 include:cust-spf.exacttarget.com ~all) at the sending domain apex, and a CNAME for the custom Return-Path (e.g. bounces.<your-domain> CNAME bounce.exacttarget.com) for SPF alignment. (4) Salesforce verifies the records and activates the SAP. (5) Publish DMARC at _dmarc.<your-domain> with v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain>. (6) After 2-6 weeks of clean reports advance to p=quarantine then p=reject. The SAP must be configured per Business Unit; if your tenant has multiple Business Units sending mail, each one needs its own SAP.

How do I set up DMARC for HubSpot?

Five steps. (1) Sign in to HubSpot, click the Settings gear, then Website > Domains and URLs > Connect a domain > Email sending domain. Enter your sending domain (recommended: a dedicated subdomain like marketing.example.com or hello.example.com) and click Next. (2) HubSpot displays the DNS records required: two CNAMEs of the form hs1-<portal-id>._domainkey.<your-domain> and hs2-<portal-id>._domainkey.<your-domain> pointing to HubSpots DKIM key infrastructure, plus an SPF include (v=spf1 include:_spf.hubspotemail.net ~all) and an optional MX record for bounce handling. (3) Publish the records at your DNS provider, then return to HubSpot and click Verify. HubSpot resolves the CNAMEs typically within minutes and marks the domain Connected. (4) Publish DMARC at _dmarc.<your-domain> with v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain>. (5) Advance to p=quarantine then p=reject after clean reports. HubSpots one-click List-Unsubscribe-Post header is enabled by default for all bulk sends; verify in the campaign Send Settings panel.

How do I set up DMARC for Marketo?

Six steps. (1) Sign in to Marketo (Adobe Marketo Engage), click Admin in the top nav, then Email > SPF / DKIM. (2) Marketo generates a pair of DKIM keys with selectors k1 and k2 - publish two CNAMEs at k1._domainkey.<your-domain> and k2._domainkey.<your-domain> pointing to the Marketo-supplied DKIM hostnames (typically of the form <random>.dkim.mktomail.com). (3) Publish an SPF include at your sending subdomain: v=spf1 include:mktomail.com ~all (the dedicated subdomain pattern is mandatory for Marketo at any meaningful volume). (4) Configure the custom Reply-To domain in Admin > Email > Branding Domain - this enables SPF alignment by sending bounces through a CNAME-delegated subdomain you control (e.g. mkto.example.com). (5) Publish DMARC at _dmarc.<your-domain> with v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain>. (6) Marketo handles List-Unsubscribe-Post automatically when the operator enables Unsubscribe in the email template; verify in Email Editor 2.0 > Email Settings > Compliance. Advance to enforcement after clean reports.

How do I authenticate my Mailchimp domain for DMARC?

Five steps. (1) Sign in to Mailchimp (Intuit), open Domains under the account avatar dropdown, click Authenticate next to your sending domain. (2) Mailchimp displays two CNAMEs: k1._domainkey.<your-domain> pointing to dkim.mcsv.net and k2._domainkey.<your-domain> pointing to dkim2.mcsv.net (the rotating pair). Publish both at your DNS provider exactly as shown - the targets are Mailchimp-fixed, the names use your domain. (3) Also publish an SPF include at the sending domain: v=spf1 include:servers.mcsv.net ~all. (4) Return to Mailchimp and click Verify Domain - it resolves the CNAMEs and confirms authentication. The Mailchimp UI marks the domain Authenticated and shows the green checkmark when DKIM + SPF both resolve. (5) Publish DMARC at _dmarc.<your-domain> with v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain>, then advance to enforcement after clean reports. Mailchimps one-click List-Unsubscribe-Post is automatic for all campaigns; the operator cannot disable it, which is the correct compliance default for bulk marketing.

Why does my marketing email get throttled even when DMARC passes?

Three reasons, all upstream of DMARC. (1) Engagement is too low. Receivers (Gmail, Yahoo, Microsoft) track open rate, click rate, reply rate, and complaint rate per sending subdomain - they throttle senders with sub-10 percent open rate or sub-1 percent click rate even when DMARC, SPF, and DKIM all pass. The fix is list hygiene: send only to engaged contacts, sunset cold contacts after 90-180 days of no engagement, segment by engagement tier. (2) Complaint rate above 0.3 percent. Gmail and Yahoo throttle aggressively above this threshold; the fix is double opt-in, prominent unsubscribe, content relevance. (3) Hard bounce rate above 5 percent. Receivers interpret high hard bounces as a sign of list scraping or list rental; the fix is single opt-in confirmation, regular bounce scrubbing, sunset policy. DMARC alignment is necessary but not sufficient for marketing inbox placement; the page covers all three engagement levers with specific operational thresholds.

Should I use a dedicated subdomain for marketing email?

Yes - the dedicated-subdomain pattern (e.g. marketing.example.com, news.example.com, hello.example.com, em.example.com) is non-optional for SaaS senders at any meaningful volume. Five benefits. (1) Reputation isolation: marketing traffic (lower engagement, higher complaint rate than transactional) builds a distinct sender reputation. A degraded marketing subdomain does not compromise transactional delivery (password resets, receipts) or corporate mail (Workspace, M365). (2) Independent DMARC policy via the np= / sp= tags: the organizational domain can ramp p=reject while marketing.example.com remains at p=none during SaaS onboarding or migration between platforms. (3) Operational clarity: the marketing team can verify alignment on their subdomain without coordinating with the security team owning the apex. (4) Audit trail: aggregate reports filtered by subdomain make it clear which class of mail is failing alignment. (5) Migration safety: switching from Mailchimp to ActiveCampaign means re-authenticating only marketing.example.com, not the entire estate. The dedicated-subdomain pattern is documented in section 6 of this guide.

What is List-Unsubscribe-Post and is it required for marketing email?

Yes - RFC 8058 List-Unsubscribe-Post (one-click unsubscribe) is mandatory for senders above 5000 messages per day to Gmail or Yahoo Mail since Feb 2024. The header pair is List-Unsubscribe: <https://example.com/unsubscribe?token=abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe> + List-Unsubscribe-Post: List-Unsubscribe=One-Click. When the receiver renders the inbox-level Unsubscribe button (Gmails one-click prompt), the receiver POSTs an empty body to the URL in the List-Unsubscribe header to action the unsubscribe without a confirmation page. The sender must process the POST and remove the recipient from active sends within 2 business days per Gmail and Yahoo policy. Every SaaS sender platform documented on this page publishes both headers by default for bulk campaigns, but the operator must verify they are enabled (some platforms hide the toggle behind a Compliance mode or Bulk sender mode setting). The 5000-messages-per-day threshold counts across all subdomains at the organizational level, so any non-trivial marketing program qualifies.

How long does dedicated IP warm-up take for marketing email?

Plan for 30 to 50 days from a cold IP to the full steady-state volume. The canonical ramp is exponential: Day 1 50 messages, Day 2 100, Day 3 500, Day 4 1000, Day 5 5000, Day 6 10000, Day 7 20000, then doubling roughly every other day until you reach steady state. Receivers (Gmail, Yahoo, Microsoft) interpret a sudden ramp from zero to 100,000 messages per day as the spam pattern; the warm-up gradient lets the receiver build a sender reputation incrementally. Send only to the most engaged contacts during warm-up (last-90-days engagement, not the full list) - this maximises open rate and click rate while volume is small, so the receiver sees a high-quality sender signal. If you skip warm-up, expect throttling, deferrals, and bulk-foldering for 60-90 days until the IP recovers. Klaviyo, Mailchimp, ActiveCampaign, and Constant Contact include warm-up automation features (Gradual Send, Warm-Up Pool); SFMC, HubSpot, Marketo require manual ramp scheduling.

15. Related guides

• DMARC for Transactional Email - sibling sender-type deployment guide covering API-based ESPs (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost).
• DKIM failures explained — the SAAS-PLATFORM-MANAGED-DKIM-CUSTODY- DIVERGENCE-FAILURE-CLASS-CATALOGUE companion to this SaaS-sender deployment reference. Where THIS page documents the SaaS-sender DKIM-deployment topology (the platform-managed CNAME-delegated DKIM signing identity at k1._domainkey.<customer-domain> pointing to dkim.<platform>.com, the per-customer-tenant Sender Profile signing-identity boundary, the shared- IP-pool egress topology, the platform- managed key-rotation cadence operator- invisible to the customer-tenant), the DKIM-failures-explained spoke is the FAILURE-CLASS-TAXONOMY companion documenting WHY the per-customer-tenant SaaS-egress mail-stream surfaces specific dkim=fail / dkim=permerror / dkim=temperror / dkim=none verdicts at the receiver-side Authentication-Results header AND in the per-row auth_results.dkim.result field of per-customer-tenant RUA aggregate-report XML. Concretely, the spoke documents FOUR SaaS-platform- DKIM-failure-class-attribution dimensions: (i) CNAME-delegation- NXDOMAIN as the canonical SaaS-platform- onboarding-incomplete DKIM failure class — when the customer- tenant operator fails to publish the platform-mandated CNAME records at k1._domainkey.<customer-domain> (or accidentally deletes them during DNS-zone migration), the receiver-side selector lookup returns NXDOMAIN and surfaces as dkim=permerror (no key for signature) for every platform-egressed message under the customer-tenant Sender Profile — the spoke documents this class distinctly from generic selector-DNS failure because the remediation is platform-vendor- managed (the platform's onboarding dashboard surfaces the missing-CNAME check); (ii) platform-managed key-mid-rotation cryptographic mismatch as the SaaS-platform-key-custody DKIM failure class — when the platform rotates its DKIM key (operator- invisible to the customer-tenant) and the platform-side rotation race produces signed messages with selector1 referenced by s= but the published TXT under selector1 has already been overwritten with selector2's public key, receivers verify the signature against the wrong public key and produce dkim=fail (signature did not verify) — the spoke documents the cryptographic-mismatch class as a distinct failure-class from CNAME- NXDOMAIN because the operational signal is "intermittent DKIM failures during platform-managed key-rotation windows" rather than "systematic DKIM failures across all platform-egressed mail"; (iii) platform-injected footer body-hash divergence as the SaaS-marketing-platform-content- modification DKIM failure class — when the platform's tracking-pixel injection or unsubscribe-footer rewriting happens AFTER the platform applies its own DKIM signature (a platform-implementation defect, not a customer-tenant configuration error), the receiver-side body-hash recomputation of the canonicalized body diverges from the platform-signed bh= tag — the spoke documents this body- hash-mismatch class because the platform-vendor-side remediation requires SaaS-platform engineering escalation (the customer-tenant cannot fix it via their own DNS or platform- dashboard configuration); and (iv) shared-IP-pool unsigned-egress as the SaaS-platform-degraded-mode DKIM-none failure class — when the platform's signing service fails open and emits unsigned messages from the customer-tenant Sender Profile (rare but documented in SaaS-platform incident post-mortems), the receiver- side Authentication-Results surfaces dkim=none rather than dkim=fail — distinct from a configuration error because the platform-side telemetry signals an incident, not a customer-tenant misconfiguration. Read the DKIM- failures-explained spoke alongside this SaaS-sender deployment reference when the per-customer-tenant RUA aggregate- report inventory surfaces unexpected DKIM verdicts — the spoke provides the receiver-side verdict-class taxonomy the SaaS-platform-managed key-custody topology this page documents produces in per-customer-tenant report rows.
• DMARC for Google Workspace - mailbox-provider deployment guide for corporate mail (the platform that complements SaaS senders for non-marketing traffic).
• DMARC for Microsoft 365 - mailbox-provider deployment guide for corporate mail in the Microsoft ecosystem.
• DMARC for Hybrid Exchange (on-prem + M365) - the hybrid-topology deep dive for organisations running Exchange-Online + Exchange-on-premises coexistence. Critical for SaaS-sender deployment when marketing/transactional mail flows through the corporate hybrid topology: SaaS senders combined with hybrid Exchange produce the canonical dual-signer DKIM cycle (the SaaS-sender adds its DKIM signature, then Exchange Online or the on-prem Edge Transport re-signs with a DIFFERENT key, producing inconsistent d= domains across hops). Read this when your SaaS-sender DKIM aligns at the SaaS edge but fails alignment at the corporate mailbox endpoint - the hybrid-Exchange topology is the most-common cause.
• DMARC for cPanel - mailbox-provider deployment guide for SMB senders on cPanel-managed hosting.
• DMARC for Shared Hosting - mailbox-provider deployment guide for Plesk, DirectAdmin, ISPConfig.
• Multi-domain DMARC strategy - the operational playbook for the multi-tenant / multi-brand sending topology every SaaS marketing platform produces by design. SaaS senders are multi-domain by nature: HubSpot Marketing Hub, Mailchimp, Klaviyo, Marketo, Pardot, Salesforce Marketing Cloud, and Constant Contact all let one tenant configure dozens of sending-domain "sending profiles" — each with its own DKIM CNAME delegation under a distinct registrable domain. The multi-domain page documents the four- pattern decision framework that maps onto SaaS-sender deployments: single-org-many- brands (one customer, multiple brand domains — the canonical SaaS-sender customer profile), many-orgs-one-tenant (the MSP / agency reseller pattern where one SaaS-sender account hosts mail for many independent customer brands), acquired-domain wind-down (the post-acquisition consolidation pattern where a SaaS marketing platform hosts sunset brand domains during the transition), and parked-domain enforcement (the p=reject; sp=reject; aspf=s; adkim=s record every never-sending brand domain should carry). Each SaaS- sender sending domain needs its own _dmarc.<domain> TXT record with brand-aware RUA aggregator routing (so each customer's DMARC reports flow to the brand-team inbox, not the SaaS provider's IT inbox), per-domain DKIM selector inventory ( k1._domainkey.customer-a.com vs k1._domainkey.customer-b.com), and the per-domain organizational-domain boundary (the Public Suffix List stops at each registrable domain — sibling brand domains do NOT share DMARC policy propagation by default). Read once you understand the per-provider deployment patterns on this page and need the cross-domain coordination playbook for the multi-tenant topology.
• DMARC policy modes (p=none / p=quarantine / p=reject) - the PER-TENANT-PER-SENDING-DOMAIN- ENFORCEMENT-TIER-SELECTION companion to this SaaS-sender deployment reference. Where THIS page documents the API-driven egress topology across the canonical five-ESP roster (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost) and the per-ESP DKIM-CNAME delegation model whose sending-domain ownership boundary maps onto the per-tenant SaaS customer relationship, the DMARC-policy- modes spoke is the PER-SENDING-DOMAIN POLICY- TAG SELECTION REFERENCE documenting the four- phase phased-enforcement-ramp every SaaS customer MUST follow at each sending domain. The SAAS-SENDER-DEPLOYMENT-PHASE-VS-POLICY-TAG- SELECTION cross-reference establishes FOUR structurally-distinct SaaS-sender onboarding stages each binding a specific RFC 7489 §6.3 policy-tag choice: (i) Phase 1 Discovery (p=none; pct=100; no sp= override) — the observation-only baseline phase during the FIRST 2–4 weeks of SaaS-sender onboarding when the operator is still inventorying the per-ESP egress IP-pool rotation surface and the per-customer DKIM- CNAME propagation status across the apex sending domain and any sibling brand domains the SaaS customer authorises for outbound send; the DMARC-policy-modes spoke documents the p=none contract that receivers report-without-acting against the aggregate-report feed surfacing both the ESP egress IP pool AND any sibling-domain unauthorised egress the SaaS customer discovers during this phase; (ii) Phase 2 Triage with p=quarantine + pct=10 percentage-ramp per sending domain — the FIRST enforcement tier where receivers DO act (soft-quarantine to spam folder) but the pct= percentage-applicability sampling tag (RFC 7489 §6.3) constrains the receiver-side action to a 10% / 25% / 50% / 75% sample as the SaaS customer progressively closes the per-ESP DKIM-CNAME / SPF-include authorisation gaps; the DMARC-policy-modes spoke documents the pct= sampling algorithm receivers apply during this phase and the per-percentage exit- criteria gate (DMARC-fail rate below per- percentage floor before advancing to the next ramp tier); (iii) Phase 3 Soft- Enforcement with p=quarantine + pct=100 full-sample steady-state per sending domain — the FINAL soft- quarantine tier where 100% of receiver evaluations apply the soft-quarantine action and the SaaS customer's aggregate-report feed transitions from a "ESP-onboarding discovery" phase to a "steady-state legitimate-flow regression-detection" phase; the DMARC-policy-modes spoke documents the p=quarantine exit-criteria gate (sustained DMARC-pass rate above the per- ESP floor for 14+ consecutive days before advancing to p=reject); (iv) Phase 4 Hard-Enforcement with p=reject + pct=100 + mandatory sp=reject subdomain- policy override per sending domain — the FINAL hard-enforcement tier where receivers reject DMARC-fail messages at SMTP 5xx response time and the SaaS customer's per-domain enforcement has graduated to the canonical post-deployment steady state; the DMARC-policy-modes spoke documents the p=reject + sp=reject coordination (mandatory for both apex and all sibling subdomains because SaaS-marketing traffic frequently uses subdomain-rotation patterns to defeat reputation-throttling defences — sp=reject is the ONLY defence against the attacker-bypass class of cousin-subdomain spoof attacks the SaaS marketing surface inherently exposes). Pair this page (the SaaS-sender per-ESP deployment coordination reference) with the DMARC-policy-modes spoke (the per-phase policy-tag selection reference) when authoring the per-customer per-sending-domain four- phase cutover runbook — the spoke documents the per-phase exit-criteria gates and the pct= / sp= coordination the SaaS customer's brand team MUST sequence correctly to avoid prematurely advancing to a stricter tier before the per- ESP authorisation coverage gates close.
• DMARC records tag-by-tag - reference for every DMARC tag (p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri).
• DMARC alignment - deep dive on adkim / aspf, strict vs relaxed, the organizational domain and the Public Suffix List.
• DKIM alignment with DMARC — the SAAS-MULTI-TENANT-PER-CUSTOMER-DKIM- ALIGNMENT-CONTRACT companion documenting the DKIM-side identifier-alignment computation (RFC 7489 §3.1.1, adkim=r vs adkim=s, the Public Suffix List organizational-domain extraction algorithm, the multiple-signature "any aligns wins" rule, the M365 onmicrosoft.com gotcha, the Workspace gappssmtp.com gotcha, the SPF-vs-DKIM asymmetry under forwarding, subdomain semantics edge cases) whose per-customer-sending-domain correctness is the SINGLE most important technical contract the SaaS marketing platform must enforce on behalf of each customer before that customer's portfolio domain can safely advance to p=reject. Where THIS page documents the SaaS-sender deployment architecture (HubSpot Marketing Hub / Mailchimp / Klaviyo / Marketo / Pardot / Salesforce Marketing Cloud / Constant Contact / SendGrid / Mailgun / Amazon SES per-tenant onboarding, per-customer DKIM CNAME delegation, per-customer SPF include: macros, per-customer From: domain configuration), the DKIM-alignment-with- DMARC spoke is the PER-CUSTOMER-ALIGNMENT- CONTRACT companion documenting the byte- level d=-aligned signature computation the SaaS platform MUST produce for each customer's sending domain — and the per-customer consistency the SaaS platform operator must enforce at onboarding across every customer tenant. The four-axis SAAS-MULTI-TENANT-VS-PER-CUSTOMER-DKIM- ALIGNMENT-CONTRACT comparison exposes the structurally-distinct SAAS-PLATFORM- OPERATOR-DUTY roles: (i) the SaaS platform MUST publish DKIM keys per-customer with d= aligning to each customer's sending-domain organisational domain — NOT the SaaS platform's own organisational domain — a SaaS-sender that signs every customer's outbound mail with the platform's default d=sendgrid.net / d=mailgun.org / d=mlsend.com produces DKIM-pass-but-DMARC-unaligned outcomes for every customer; the platform MUST provision per-customer DKIM CNAME delegation (typically k1._domainkey.<customer- domain> CNAME to a platform- controlled key) before that customer's portfolio domain can advance past p=none; (ii) customer onboarding MUST verify the per-customer DKIM CNAME is published and resolving BEFORE allowing the customer to send mail from their domain through the platform — a common SaaS-platform bug is to allow onboarding to complete without DKIM CNAME verification, producing customer mail that DKIM-fails entirely until the customer's IT team publishes the missing CNAME days or weeks later (during which the customer's domain is at p=reject rejecting all marketing mail at every DMARC-aware receiver); (iii) the many-orgs-one-tenant MSP / agency pattern — where one SaaS-platform account hosts mail for N independent customer brands — produces per-customer DKIM-alignment- verification scaling pressure that the platform MUST automate via per-brand DNS-resolution polling; if even one of N brands' DKIM CNAME stops resolving (DNS-provider change, accidental deletion, registrar lapse), the platform's outbound mail for that brand loses alignment immediately and silently until the next inbox-quality monitoring cycle catches the spike in bounces; (iv) the customer's organisational domain extraction via Public Suffix List determines which d= values align under adkim=r relaxed mode — a customer sending from marketing.brand-a.com with the platform signing as d=mail.brand-a.com aligns via PSL-organisational-domain extraction to the same brand-a.com organisational domain; but a customer sending from customer-a.shop where the platform signs with the platform's d=<platform>.com does NOT align under any adkim= mode — the customer-onboarding wizard MUST validate this alignment-mathematically before completing customer onboarding. Read the DKIM-alignment-with-DMARC spoke when authoring the SaaS-platform per- customer onboarding-validation contract: it documents the precise byte-level alignment computation every customer- sending-domain DKIM signature must pass for that customer's portfolio domain to reach p=reject safely.
• DKIM selectors explained — the SAAS-MULTI-TENANT-PER-CUSTOMER- SELECTOR-ISOLATION companion to this SaaS-sender deployment guide. Where THIS page documents the SaaS-platform- side per-customer DMARC-deployment orchestration surface, the DKIM- selectors-explained spoke documents FOUR per-customer-isolation patterns the SaaS-platform multi-tenant key- management infrastructure structurally enforces at the selector owner-name layer: (i) the per-customer- domain dedicated selector inventory — multi-tenant SaaS platforms publish a per-customer selector at the customer's own DNS zone (typical patterns: sm._domainkey.<customer> for SendGrid, s1._domainkey.<customer> for Mailchimp, k1._domainkey.<customer> for ConvertKit) so each customer's DKIM signing identity is structurally isolated from every other customer of the same SaaS platform — preventing cross-tenant signature replay, cross-tenant key compromise spread, and cross-tenant attribution ambiguity in receiver-side DKIM verification; (ii) the per-customer independent rotation cadence — because each customer's selector is published at the customer's own DNS zone, the SaaS platform can rotate any customer's key independently without affecting other customers — and any compromised customer's key can be revoked at the customer's owner-name without burning the platform-wide signing identity, structurally the opposite of the shared-selector deployment pattern where one key compromise burns every co-tenant; (iii) the per-customer dual-selector overlap for zero-downtime rotation — sophisticated SaaS platforms maintain TWO published selectors per customer (e.g., k1._domainkey + k2._domainkey) so key rotation publishes the new key under the inactive selector, waits for DNS propagation, then switches the active selector — all within the customer's own DNS zone, all transparent to the customer's downstream receivers, and (iv) the per-customer audit- trail attribution at the selector layer — every signed message carries the customer-specific s=<customer-selector> tag in its DKIM-Signature header, making per-customer signed-volume accounting, per-customer signing- error attribution, and per-customer key-usage forensics directly observable at the receiver-side evidence layer (RUA per-message auth_results/dkim/selector and forensic-stream verbatim signed- header capture). Pair this SaaS- sender deployment guide (the platform-side multi-tenant DMARC orchestration surface) with the DKIM-selectors-explained spoke (the per-key publication-discipline reference) for the multi-tenant platform key-management architecture every SaaS marketing / transactional / notification platform structurally depends on for safe customer- isolation and customer-side deliverability-and-attribution outcomes.
• DMARC policy rollout - the p=none -> quarantine -> reject migration cadence.
• DMARC aggregate reports - reading the RUA XML schema from your SaaS senders' aggregate-report stream.
• DMARC forensic reports (RUF / AFRF) — the SAAS-MULTI-TENANT-CNAME-DELEGATED- DMARC-PUBLISHING-AS-PER-TENANT-RUF-AFRF- EVIDENCE-STREAM-AUTOMATION-SURFACE companion to this SaaS-sender DMARC deployment playbook. Where THIS page documents the SaaS-platform-operated CNAME-delegated DMARC-record-publishing pattern (every customer-tenant publishes _dmarc.<tenant-domain> as a CNAME pointing into the SaaS platform's centrally-managed DMARC-record infrastructure), the DMARC-forensic- reports (RUF) spoke documents the per- message AFRF evidence-stream the SaaS platform centrally ingests AND fans-out per-customer-tenant for per-tenant incident-response workflows. The SAAS-MULTI-TENANT-CNAME-DELEGATED-DMARC- PUBLISHING-AS-PER-TENANT-RUF-AFRF- EVIDENCE-STREAM-AUTOMATION-SURFACE cross-reference establishes FOUR structurally-distinct multi-tenant-RUF- AFRF-architecture dimensions: (i) CNAME-delegated-ruf-tag-points-to- platform-operated-AFRF-collector-mailbox- AT-per-tenant-AFRF-evidence-stream- ingestion-layer dimension — each customer-tenant's CNAME-delegated DMARC record THIS page documents publishes a ruf=mailto:dmarc-afrf+<tenant- id>@platform-collector.example tag value pointing at the SaaS platform's centrally-operated AFRF-collector mailbox with a per-tenant identifier in the local-part; the platform's AFRF-ingestion infrastructure parses the per-tenant identifier from the local-part to attribute each incoming AFRF envelope to the correct customer-tenant for per- tenant evidence-stream aggregation; (ii) cross-domain-AFRF-emission- opt-in-record-publication-at- platform-domain-AT-per-tenant-cross- domain-opt-in-orchestration-layer dimension — RFC 7489 §7.1 requires the AFRF-receiving domain to publish a <tenant-domain>._ report._dmarc.<platform-domain> opt-in record before receivers will emit AFRF to a cross-domain address; the SaaS platform's customer-onboarding automation THIS page documents must AUTOMATICALLY publish the per-tenant cross-domain opt- in record on the platform-domain side as each new customer-tenant onboards, OR the per-tenant AFRF evidence stream is STRUCTURALLY SUPPRESSED at the receiver- side emission gate before any per- message AFRF envelope is generated; the AFRF cross-domain opt-in record is the LOAD-BEARING precondition for the per-tenant evidence-stream infrastructure THIS page documents the CNAME-delegated DMARC publication of; (iii) per- tenant-AFRF-evidence-stream-fan-out-to- customer-side-incident-response-portal- AT-customer-side-evidence-visibility- layer dimension — the SaaS platform's centrally-ingested AFRF envelopes contain the per-tenant message/rfc822 embedded part with the original customer-tenant's From: forgery / Reply-To: redirection / payload-bearing content; the SaaS platform's per-tenant incident-response portal MUST fan-out the per-tenant AFRF evidence to the customer-tenant's own SIRT for BEC incident response / FBI IC3 reporting / criminal-prosecution evidence preservation — the per-tenant fan-out architecture is the LOAD- BEARING customer-visibility-side artifact of the CNAME-delegated DMARC publishing pattern THIS page documents the publisher-side automation of; (iv) GDPR-Art-28-processor-agreement- scrutiny-AT-platform-side-PII-processing- AT-AFRF-embedded-message-rfc822-third- party-PII-content-AT-per-tenant-data- residency-and-cross-border-transfer- layer dimension — AFRF envelopes embed the OFFENDING message's complete bytes including third-party PII (sender / recipient email addresses / message body) the AFRF-collector ingests; the SaaS platform's centrally-operated AFRF-collector is a GDPR Art 28 processor of customer-tenant PII as well as third-party PII, requiring per- tenant data-residency controls / cross-border-transfer Standard Contractual Clauses / per-tenant retention-policy enforcement THIS page's customer-onboarding automation must orchestrate at the platform- operated AFRF-collector infrastructure layer. Read this RUF-forensic-reports spoke alongside THIS SaaS-sender DMARC deployment playbook when authoring the per-tenant AFRF-evidence-stream infrastructure the platform's CNAME- delegated DMARC-publishing pattern produces.
• MX records explained — the SAAS-PLATFORM-CUSTOMER-TENANT- DOMAIN-MX-ORCHESTRATION companion to this SaaS-sender DMARC deployment playbook, and the DNS-RR-LAYER infrastructure-automation reference for the four MX-dependent SaaS-platform features THIS page documents the DMARC-policy-side of. SaaS platforms operating a multi-tenant marketing / transactional / customer-engagement platform orchestrate MX records on the customer-tenant domain across FOUR STRUCTURALLY-DISTINCT MX-orchestration surfaces: (i) inbound-parse- webhook MX delegation — the SaaS-platform-provided inbound-parse feature (SendGrid Inbound Parse, Mailgun Routes, Postmark Inbound, Twilio SendGrid Inbound) requires the customer to publish an MX RR on a customer-tenant subdomain (typically parse.example.com IN MX 10 mx.sendgrid.net.) so receiver- side MTAs deliver inbound mail to the SaaS-platform's MX target, which then triggers the customer-side webhook with the parsed message body; the mx-records spoke documents the byte-grammar of this MX RR; (ii) RUA-mailbox-domain MX for aggregate-report delivery — when the SaaS-platform offers per-tenant DMARC-as-a-service the platform manages a per-tenant RUA mailbox (e.g., rua=mailto:t12345@dmarc-rua. saas-platform.com), and the dmarc-rua.saas-platform.com domain requires functional MX RRs for receiver-side MTAs to deliver per-tenant per-day aggregate XMLs; (iii) custom-return-path bounce- ingestion MX — the per-tenant bounce-message return path (bounces.example.com IN MX 10 mx-bounces.saas-platform.com.) the SaaS-platform's tenant subdomain custom-return-path feature publishes to ingest receiver-side bounce messages into the platform's per-tenant suppression- list and reputation-feedback loop; (iv) customer-domain "null MX" anti-pattern per RFC 7505 (example.com IN MX 0 .) — when a tenant accidentally configures a null MX on their organisational domain, the SaaS-platform's RUA-mailbox cannot receive aggregate reports for that tenant and the tenant's domain-reputation feedback loop falls silent. The mx-records spoke is the AUTHORITATIVE DNS-RR-CLASS reference for the four MX-orchestration surfaces the SaaS-platform's customer- onboarding wizard guides the tenant through during the per-tenant infrastructure provisioning that THIS page documents the DMARC-policy-side of. Pair this page (the SaaS-sender DMARC deployment playbook) with the mx-records spoke (the per-tenant MX-orchestration infrastructure-automation DNS-RR-LAYER reference) when designing the SaaS-platform's customer-onboarding wizard that orchestrates the per-tenant DNS-RR publication discipline THIS page presupposes when documenting the SaaS-tenant DMARC deployment surface.
• DMARC troubleshooting - cross-cutting failure diagnosis loop.
• DMARC monitoring - ongoing operational discipline (KPIs, alert thresholds, anomaly detection).
• DMARC myths and misconceptions — the SAAS-TENANT-DEPLOYMENT-AS-MYTH- EXPOSURE-SURFACE companion documenting the operator-facing 18-myth catalogue whose most-encountered myths surface directly on the multi-tenant SaaS- egress deployment surface THIS page documents. Where THIS page documents the SaaS-sender DMARC deployment playbook (tenant SPF-include cascade across Mailchimp / Constant Contact / SendGrid / Postmark / Mailgun / Klaviyo / Customer.io / Iterable / Braze / ActiveCampaign / HubSpot / Marketo / Salesforce-Marketing-Cloud / Amazon- SES, the per-platform DKIM-CNAME delegation patterns whereby the SaaS platform owns the selector keys and the tenant publishes the CNAME pointer, the per-platform Bounce-Domain-Friendly- From-Header configuration that determines whether the tenant's DMARC record covers the SaaS-egress mail, the per-platform deliverability-warm-up procedure when introducing a new SaaS-sender into an existing DMARC- enforced domain, and the per-platform Feb-2024-Gmail-Yahoo-bulk-sender- requirement compliance procedure), the myths-and-misconceptions spoke documents the 18-myth catalogue whose SaaS-tenant-deployment-relevant myths consistently surface in SaaS-onboarding operator conversations: Myth #3 "I have SPF and DKIM so I do not need DMARC" is the canonical misconception among SaaS-platform engineering teams who view their per-tenant SPF-include and DKIM-CNAME configuration as the deliverability contract — without DMARC alignment to the visible From: header (which their tenants control), every SaaS-platform's legitimately-signed DKIM signature becomes ammunition for cousin-domain attackers who control a different DKIM-signing domain. Myth #7 "Going straight to p=reject is fine if my records look right" is the canonical misconception among operators onboarding their first SaaS-platform sender into an existing p=reject domain — every SaaS-platform has long-tail edge cases (transactional-event-triggered mail from a Customer.io broadcast where the platform's bounce-domain Friendly-From configuration is subtly different, webhook-driven receipt mail from Iterable whose DKIM-CNAME selector publication has not yet propagated) that produce a fast-onboard-then- immediate-reject-storm with the observer-side RUA bounce-rate signature that the rollout-cadence spoke catalogues as a Week-N rollback trigger. Myth #11 "Deploying DMARC will break my mailing lists" is the canonical misconception when the SaaS-tenant deploys a transactional platform that includes a list-unsubscribe relay (HubSpot Marketing Hub email sequences, Mailchimp regular campaigns, Klaviyo flow campaigns) that operate as mailing-list-style relays — the DMARC-alignment-aware platforms (the modern SaaS ESPs) preserve DMARC alignment via DKIM-d= signing on the tenant's authoring domain, while the ARC-aware mailing-list relays (legacy listservers, internal company-owned Mailman-style relays) restore alignment via an ARC-Authentication- Results header rather than DKIM-d=. The myths-page Myth #11 refutation argument structurally distinguishes the two cases, and the SaaS-sender operator-facing surface is the deployment context where the distinction becomes operationally-load-bearing. Read the myths-and-misconceptions catalogue alongside this SaaS-sender deployment playbook when onboarding a new SaaS platform into an existing DMARC- enforced domain — the catalogue's Myth #3, #7, and #11 refutation arguments map directly onto the SaaS-tenant deployment mechanics THIS page documents. Closes the DMARC-deployment-cluster ↔ DMARC-pillar myth-refutation bridge whereby the SaaS-tenant deployment surface THIS page documents is the canonical operator-facing EXPOSURE SURFACE for the operator-facing myth-refutation catalogue the myths spoke maintains.
• Email deliverability fundamentals - the broader operational-outcome surface every SaaS-sender deployment is ultimately judged against. Where this page documents the DMARC-layer authentication that SaaS senders must configure (DKIM CNAME delegation, SPF include / lookup-budget, alignment), the deliverability page documents the full inbox-placement control stack that determines whether authenticated mail actually lands in the inbox: IP reputation (Sender Score / Talos / Spamhaus ZEN), domain reputation (Google Postmaster Tools / Microsoft SNDS), Feedback Loop (FBL) registration (Yahoo / Microsoft / Comcast / Cox / AT&T / Telstra / La Poste), list hygiene (the 0.1 % hard-bounce + 0.1 % complaint thresholds Gmail and Yahoo enforce after the 2024 sender requirements update), content filtering, throttling / greylisting / tarpitting, IP-warmup cadence, and the engagement signals (open / click / forward / reply / delete- without-read) every mailbox provider feeds into its inbox-placement decision. SaaS senders running on dedicated IPs own all seven control surfaces; SaaS senders on shared IPs share four with the ESP but still own list-hygiene + content + engagement. Read the deliverability page once your SaaS-sender DMARC deployment passes alignment at p=reject but inbox placement still degrades — the deliverability page catalogues every beyond-DMARC operator concern that the SaaS-platform documentation rarely covers in one place.
• Email authentication ecosystem - cluster-intro pillar above all per-standard pages.
• Email authentication glossary - canonical definitions for every term used in this guide.
• SPF explained - the SPF pillar covering the 10-DNS-lookup limit, includes, and the permerror failure mode.
• SPF DNS TXT-record byte syntax (RFC 7208 §3 tag-list grammar) — the SAAS-MULTI-TENANT-INCLUDE-CASCADE- PUBLICATION-AT-CUSTOMER-DOMAIN-APEX-AS-BYTE- LEVEL-SPF-DNS-TXT-RECORD-AUTHORING-DISCIPLINE companion to this SaaS-multi-tenant DMARC deployment reference. Where THIS page documents the SaaS-platform-side coordination playbook (the per-platform include: token catalogue include:_spf.salesforce.com / include:sendgrid.net / include:_spf.google.com / include:spf.mandrillapp.com / include:_spf.mailjet.com the SaaS-platform documentation hands to the customer to merge into the customer's apex SPF record), the SPF DNS syntax reference documents the BYTE-LEVEL AUTHORING DISCIPLINE the customer's authoritative DNS publication must satisfy for every receiver-side per-message SPF evaluation across the customer's per-vendor outbound IP pool to evaluate to spf=pass: (i) the canonical v=spf1 version-prefix that distinguishes the SPF TXT record from arbitrary TXT records; (ii) the byte-correct include: token spacing and ordering semantics whose per-receiver parser-tolerance determines whether the include resolves or collapses to spf=permerror; (iii) the 255-octet per-character-string chunking rule that determines how the customer authors a multi-string SPF record when the cumulative byte-length of stacked per-vendor include: tokens exceeds a single TXT character-string — the canonical SaaS-multi-tenant scenario where a customer combines Salesforce Marketing Cloud + SendGrid + Google Workspace + a per-tenant custom Return- Path include: at the same apex; (iv) the one-SPF-record-per-domain constraint per RFC 7208 §3.2 whose violation (publishing one SPF record for the M365/Workspace primary mailbox and a second SPF record for the SaaS marketing-platform separately) produces spf=permerror across every receiver evaluating the customer-domain From: authentication — a recurring SaaS-cohabiting customer defect class the per-vendor onboarding playbook must explicitly guard against. Read this WITH the SaaS-senders deployment reference when the customer-onboarding workflow's "merge our include: token into your apex SPF record" step moves to the customer's authoritative-DNS team: the SaaS-senders page documents WHICH token to publish, the SPF DNS syntax reference documents the BYTE-LEVEL HOW to merge it without collapsing the customer's apex SPF record to spf=permerror.
• SPF for Google Workspace - the SAAS-MULTI-TENANT-PLATFORM-COHABITING- WITH-WORKSPACE-CUSTOMER-DOMAIN-SPF-INCLUDE- LAYERING-DISCIPLINE-FOR-CUSTOM-RETURN-PATH- AUTHORING-AT-WORKSPACE-RECEIVER-EGRESS companion to this SaaS-multi-tenant DMARC deployment reference. Where THIS page documents the SaaS-platform-side deployment playbook (custom-domain DKIM signing via the per-platform delegated-DKIM CNAMEs, the shared-IP-pool cross-tenant reputation isolation, the multi-customer onboarding flow, the per-tenant SPF include token the customer adds to THEIR domain), the SPF-for-Workspace spoke is the WORKSPACE-TENANT-CUSTOMER-SIDE companion documenting WHY the SaaS platform's SPF-include onboarding instructions must coordinate with the customer's existing Workspace SPF record. The four-axis SAAS-SENDER-VS-WORKSPACE-SPF comparison exposes the structurally-distinct WORKSPACE-COHABITATION roles: (i) Workspace tenants ALREADY have include:_spf.google.com as the load-bearing baseline token consuming one of the 10 lookup slots — a SaaS platform onboarding a Workspace- tenant customer cannot assume zero baseline lookup-budget consumption; the SPF-for-Workspace spoke documents the baseline _spf.google.com consumption profile (~4 lookup slots, varying with Google's published SPF cascade) that determines headroom for additional per-SaaS include tokens; (ii) Workspace-tenant customers cohabiting with MULTIPLE SaaS senders (Mailchimp + Salesforce + HubSpot + Marketo + Klaviyo + SendGrid) routinely hit the 10-DNS-lookup permerror class — the SPF-for-Workspace spoke documents the SPF-flattening-via-CIDR / SPF-delegation- via-subdomain / per-SaaS-sending-subdomain carve-out patterns the Workspace-tenant operator must apply to keep cumulative lookup cost under 10 when stacking multiple SaaS platforms; (iii) Workspace SMTP-relay-from- outside-Workspace integration patterns require per-SaaS-sender envelope-MAIL- FROM coordination with the Workspace SPF record — SaaS platforms ingesting outbound mail from Workspace-tenant on-prem / partner infrastructure via SMTP-relay must ensure the envelope-MAIL-FROM domain SPF-aligns to the From-header Workspace-tenant domain, requiring per-SaaS authoring discipline the SPF-for-Workspace spoke documents; (iv) Workspace-tenant customers using a SaaS platform's delegated-DKIM signing still need the SaaS platform's SPF include added to the Workspace baseline — even when the SaaS platform achieves DMARC-aligned-pass via custom-d= DKIM signing, the SPF-aligned-pass side requires include-token-layering on the Workspace SPF record that the SPF-for-Workspace spoke documents. Read the SPF-for-Workspace spoke alongside this SaaS-senders DMARC reference when onboarding a Workspace-tenant customer — the spoke is the AUTHORITATIVE per-platform-customer-side SPF-authoring prerequisite that determines whether the SaaS platform's customer-domain DMARC- aligned-pass population is even achievable for the Workspace cohort, and the SaaS platform's onboarding documentation must reference the SPF-for-Workspace spoke for any customer whose MX records resolve to aspmx.l.google.com or sibling Workspace MX endpoints.
• SPF for Microsoft 365 - the SAAS-MULTI-TENANT-PLATFORM-COHABITING- WITH-M365-CUSTOMER-DOMAIN-SPF-INCLUDE- LAYERING-DISCIPLINE-FOR-CUSTOM-RETURN-PATH- AUTHORING-AT-EXCHANGE-ONLINE-RECEIVER-EGRESS companion to this SaaS-multi-tenant DMARC deployment reference. Where THIS page documents the SaaS-platform-side deployment playbook (custom-domain DKIM signing via the per-platform delegated-DKIM CNAMEs, the shared-IP-pool cross-tenant reputation isolation, the multi-customer onboarding flow, the per-tenant SPF include token the customer adds to THEIR domain), the SPF-for-Microsoft-365 spoke is the M365-TENANT-CUSTOMER-SIDE companion documenting WHY the SaaS platform's SPF-include onboarding instructions must coordinate with the customer's existing M365 SPF record. The four-axis SAAS-SENDER-VS-M365-SPF comparison exposes the structurally-distinct M365-COHABITATION roles: (i) M365 tenants ALREADY have include:spf.protection.outlook.com as the load-bearing baseline token consuming ~6 of the 10 lookup slots — a SaaS platform onboarding an M365-tenant customer starts from a STRUCTURALLY-TIGHTER baseline-lookup-budget envelope than the Workspace cohort (~6 vs ~4 lookup slots consumed); the SPF-for- Microsoft-365 spoke documents the baseline spf.protection.outlook.com consumption profile (nested spfa + spfb + spfc cascade, varying with Microsoft's published SPF cascade) that determines headroom for additional per-SaaS include tokens — the M365 customer cohort is the higher-risk-of-permerror cohort the SaaS platform's onboarding pipeline MUST detect and route to lookup- budget-conservative include patterns; (ii) M365-tenant customers cohabiting with MULTIPLE SaaS senders (Mailchimp + Salesforce + HubSpot + Marketo + Klaviyo + SendGrid) hit the 10-DNS-lookup permerror class STRUCTURALLY-EARLIER than equivalent Workspace cohorts — the SPF-for-Microsoft-365 spoke documents the SPF-flattening-via-CIDR / SPF- delegation-via-subdomain / per-SaaS- sending-subdomain carve-out patterns the M365-tenant operator must apply to keep cumulative lookup cost under 10 when stacking multiple SaaS platforms — typically the M365 operator can stack 2-3 SaaS sender includes before hitting permerror, vs 4-5 for Workspace; (iii) M365 SMTP-AUTH / Direct-Send / Connector-based integration patterns require per-SaaS-sender envelope-MAIL-FROM coordination with the M365 SPF record — SaaS platforms ingesting outbound mail from M365-tenant on-prem-hybrid / partner infrastructure via Exchange Online connector or SMTP-AUTH must ensure the envelope-MAIL-FROM domain SPF-aligns to the From-header M365-tenant domain, requiring per- SaaS authoring discipline the SPF-for-Microsoft-365 spoke documents — INCLUDING the on-prem-hybrid send-connector-egress IP authoring case that has no Workspace analogue; (iv) M365-tenant customers using a SaaS platform's delegated- DKIM signing still need the SaaS platform's SPF include added to the M365 baseline — even when the SaaS platform achieves DMARC- aligned-pass via custom-d= DKIM signing (and Exchange Online's per- custom-domain DKIM-CNAME-delegation is published), the SPF-aligned-pass side requires include-token-layering on the M365 SPF record that the SPF-for-Microsoft-365 spoke documents. Read the SPF-for- Microsoft-365 spoke alongside this SaaS-senders DMARC reference when onboarding an M365-tenant customer — the spoke is the AUTHORITATIVE per- platform-customer-side SPF-authoring prerequisite that determines whether the SaaS platform's customer-domain DMARC-aligned-pass population is even achievable for the M365 cohort, and the SaaS platform's onboarding documentation must reference the SPF-for-Microsoft-365 spoke for any customer whose MX records resolve to *.mail.protection.outlook.com or sibling Exchange Online MX endpoints.
• DKIM explained - the DKIM pillar covering selector conventions, key rotation, and signature verification.
• DKIM DNS-TXT-record byte syntax — the SAAS-RELAY-PLATFORM-DELEGATED-DKIM- SELECTOR-NAMING-VARIANCE-IMPOSED-ON- CUSTOMER-AUTHORITATIVE-DNS-PUBLICATION companion to this SaaS-sender DMARC deployment reference. Where THIS page documents the multi-tenant SaaS platform per-tenant d= attribution contract (which is what makes customer- side p=reject deployable on SaaS-relay-platform-originated mail), the DKIM-DNS-syntax spoke is the per-tag byte-grammar reference whose RFC 6376 §3.6.1 compliance is the receiver-side DNS-lookup prerequisite for every SaaS-relay-signed message. The SAAS-PLATFORM-IMPOSED-SELECTOR-NAMING- VARIANCE cross-reference establishes FIVE structurally-distinct per-platform DKIM- DNS-publication patterns whose byte- grammar conformance must match the spoke's canonical layout: (i) SendGrid authenticated-domain dual-selector pattern — publishes two CNAME records (s1._domainkey.<customer- domain> CNAME s1.domainkey.u<sub- user-id>.wl<list-id>.sendgrid. net + matching s2) whose terminal SendGrid-managed TXT record must conform to the DKIM-DNS-syntax spoke's v=DKIM1; k=rsa; p=... byte-layout; (ii) Mailgun domain-verification single-selector pattern — publishes one TXT record at mta._domainkey.<mail- subdomain> carrying the Mailgun- generated public-key payload whose v=DKIM1 sentinel + k= rsa + p=<base64-pubkey> byte-format the DKIM-DNS-syntax spoke documents as the canonical RFC 6376 §3.6.1 compliant layout; (iii) Amazon SES Easy-DKIM triple-CNAME pattern — publishes three CNAME records (<token-1>._domainkey. <customer-domain> CNAME <token-1>.dkim.amazonses.com, and two siblings) whose terminal AWS-managed TXT records carry the SES- managed 1024-bit or 2048-bit RSA public-key payload at the amazonses.com zone leaf; the DKIM-DNS-syntax spoke documents the per-tag byte-grammar the AWS-managed terminal records conform to; (iv) Postmark domain-verification single-selector pattern — publishes one TXT record at 20231201pm._domainkey.<customer- domain> with the Postmark- generated payload that must satisfy the spoke's documented v=DKIM1; k= rsa; p=... byte-grammar — a common error is when customers manually wrap the long p=<base64-pubkey> value in double-quotes across multiple TXT-record strings without RFC 7208 §3.3 compliant string-concatenation, producing a malformed receiver-side parse; (v) Marketo / HubSpot / Mailchimp / Klaviyo signing-domain customisation patterns — each platform publishes platform-specific selector names and CNAME-target conventions whose terminal TXT records all converge on the same RFC 6376 §3.6.1 byte-grammar the DKIM-DNS-syntax spoke documents as the canonical receiver-side parse contract. Pair this page (the SaaS-tenant DMARC deployment reference) with the DKIM-DNS-syntax spoke (the per-tag byte-grammar compliance reference) when diagnosing a customer-side dkim=permerror spike on SaaS-relay-platform-originated mail — the spoke documents the canonical compliant byte-layout whose violation at any of the FIVE platform-specific publication patterns produces the receiver-side resolution-or-parse- failure that breaks the d=<customer-domain> alignment contract THIS page documents as the load-bearing p=reject-deployability prerequisite.
• DKIM-Signature header anatomy - the SAAS-MULTI-TENANT-PER-MESSAGE- DKIM-SIGNATURE-HEADER-BYTE-CORRECTNESS companion to this SaaS-sender DMARC deployment reference. Where THIS page documents the multi-tenant SaaS-platform per-tenant d= attribution contract at the customer-domain DNS publication layer, the DKIM-Signature header-anatomy spoke is the per-message signature-header byte-grammar reference whose RFC 6376 §3.5 tag-list compliance is the receiver-side parse prerequisite for every SaaS-platform-signed message. The SAAS-MULTI-TENANT-PER-TENANT- SIGNATURE-TAG-CORRECTNESS cross-reference establishes FOUR structurally-distinct per-message DKIM-Signature-header tag- correctness dimensions whose violation breaks the customer-side p=reject deployment contract: (i) d=-tag per-tenant attribution correctness — the SaaS-platform's per-tenant signing service MUST emit d=<customer-domain> (not d=<saas-platform- domain>) for each customer's outbound mail-stream so the receiver- side DKIM-Signature header anatomy documented by the spoke resolves the per-tenant authoritative-domain attribution required for DMARC alignment — a per-tenant d= misconfiguration breaks alignment regardless of byte-correctness elsewhere; (ii) s=-tag per-tenant selector correctness — the SaaS-platform-imposed selector naming convention (SendGrid s1 s2, Mailgun mta, SES <token-N>, Postmark 20231201pm) emits per-tenant s= bytes that the receiver-side DKIM-verifier looks up at <s=>._domainkey. <d=> — a per-tenant s= mismatch between signed- message header and customer-side DNS-publication produces dkim=permerror on the spoke's documented receiver-side parse contract; (iii) h=-tag per-tenant header-coverage correctness and bh=-tag per-message body-hash correctness — the SaaS-platform's per-message signing service MUST include From: in the h= list (RFC 6376 §3.5 mandatory) and emit a SHA-256 bh= body-hash that matches the canonicalized-body bytes the receiver-side DKIM-verifier recomputes — per-tenant h= coverage gaps (e.g. SaaS platform forgets to include From: in h= for a customer's mail-stream) or per-message bh= body-hash mismatches (downstream MTA modifies body bytes post-signing) break the spoke's documented per-tag verification contract; (iv) b=-tag per-message signature bytes and a=-tag per-tenant algorithm correctness — the SaaS-platform's per-tenant private-key signing service emits per-message b=<base64-signature> bytes computed over the canonicalized header-set and body-hash, with a=rsa-sha256 (or a=ed25519-sha256) per platform-policy — per-tenant a=-tag drift (platform rotates from rsa-sha256 to ed25519-sha256 without per-customer-DNS-publication coordination) or per-message b= bytes computed against a stale private-key version breaks the spoke's documented receiver-side cryptographic-verification contract. Pair this page (the SaaS- tenant DMARC deployment reference) with the DKIM-Signature header-anatomy spoke (the per-message header-byte- grammar reference) when diagnosing a customer-side dkim=fail spike on SaaS-platform-originated mail — the spoke documents the canonical compliant tag-list byte-layout whose violation at any of the FOUR per-tenant signature-tag-correctness dimensions produces the receiver-side verification failure that breaks the d=<customer-domain> alignment contract THIS page documents as the load-bearing p=reject-deployability prerequisite.
• DKIM canonicalization - the MULTI-TENANT-SAAS-PLATFORM- PER-TENANT-CANONICALIZATION-DEFAULT- DISCIPLINE-AS-PREREQUISITE-FOR-CONSISTENT- PER-CUSTOMER-DMARC-PASS-RATE companion to this SaaS-sender DMARC deployment reference. Where THIS page documents the multi-tenant SaaS-platform sender pattern (per-tenant d= attribution, per-tenant s= selector rotation, per-tenant key isolation, per-tenant ESP-relay-vs-direct-egress topology choice), the DKIM-canonicalization spoke is the BYTE-LEVEL-PROTOCOL- MECHANICS companion documenting the FOUR canonicalization-pair choices (c=simple/simple, c=simple/relaxed, c=relaxed/simple, c=relaxed/relaxed) the SaaS platform's outbound-signer must consistently apply across every tenant + every transactional template + every marketing campaign to produce the stable DKIM-verification outcomes the customer's DMARC-pass-rate evidence stream depends on: (i) SaaS platforms typically default to c=relaxed/relaxed because the relaxed body canonicalization survives the LARGEST-CLASS of downstream modifications (mailing-list footers, transport- layer line-ending normalisation, forwarder whitespace-noise) — a SaaS platform that mixes c=relaxed/relaxed for some tenants and c=simple/simple for other tenants produces VARIABILITY in the per-tenant DMARC-pass-rate evidence that confounds the customer's retrospective analysis (the customer observing "my SendGrid traffic has 99.2% DMARC-pass but my Mailchimp traffic has 96.4% — why" may not immediately attribute the gap to canonicalization-pair inconsistency); (ii) some transactional ESP templates include per-recipient-personalised content (tracking pixels, click-tracking URL-rewrites, dynamic-content per-recipient unsubscribe-tokens) that the ESP injects AT SEND-TIME after the template-level DKIM-Signature is computed — c=relaxed/relaxed admits the per-recipient personalisation without breaking the bodyhash IF the personalised content is below the l= body-length limit (an EXPLICIT body-length tag that bounds the hashed prefix), while c=simple/simple does NOT survive any per- recipient modification regardless of l= tag presence; (iii) SaaS-platform header- canonicalization choice (the first half of the c= pair) determines whether per-customer header-rewriting (Subject: substitution, From: per-template configuration, Reply-To: injection of customer-domain bounce-handler address) breaks the signature when the customer's Workspace/M365 receive-side re-orders or modifies headers — c=*/relaxed survives whitespace + case + folded-continuation normalisation; c=*/simple breaks on any byte change; (iv) SaaS platforms must document the per-tenant canonicalization-pair choice in their tenant-facing DKIM- publication guide so the customer can author the published TXT record's k= + h= tag values consistent with the platform's signing-side choice, and so the customer's downstream investigation of any DKIM-failure RUF row can attribute the failure to a specific canonicalization-pair- survival-class. Read the DKIM- canonicalization spoke alongside this SaaS-sender deployment reference when designing the SaaS-platform-side DKIM-signing pipeline (canonicalization-pair default selection, per-tenant override surface, downstream modification-survival-class documentation), or when investigating a per-customer DMARC-pass-rate anomaly that may be attributable to per-tenant canonicalization-pair drift in the SaaS platform's signing infrastructure.
• Reverse DNS & PTR records - the IP-level outbound-identity proof that complements DKIM's cryptographic outbound-identity proof. SaaS senders sending from dedicated IPs (Mailchimp Dedicated IP, HubSpot Dedicated IP, Klaviyo Dedicated IP, Salesforce Marketing Cloud Sender Authentication Package) MUST coordinate a matching PTR record with their IP provider or face delivery failure to Gmail (canonical bounce 550-5.7.25 or 550-5.7.1 [IP] No PTR record), Microsoft 365 (canonical bounce 550 5.7.1 Service unavailable; Client host [IP] blocked), and Yahoo (canonical bounce 553 5.7.1 [BL21]). The forward-confirmed-reverse-DNS (FCrDNS) rule that every major receiver applies requires that PTR(ip) = hostname AND A(hostname) = ip — both directions, not just one. SaaS-sender deployers running on shared IPs are exempt (the SaaS provider manages PTR for the entire shared-IP pool) but dedicated-IP customers own the coordination.
• ARC explained - Authenticated Received Chain (RFC 8617) for forwarded marketing mail.
• BIMI explained - Brand Indicators for Message Identification (logos in the inbox) - requires DMARC at p=quarantine or stricter.
• BIMI SVG Tiny PS file-format requirements — the SaaS-multi-tenant brand-logo-pipeline companion to the BIMI-explained entry above - the SaaS-sender pattern this page documents (where a single SaaS platform sends mail on behalf of many brand-tenant customers) has a STRUCTURAL BIMI-deployment complication that single-tenant DMARC operators do NOT encounter: the SaaS platform must support per-tenant SVG-Tiny-PS file-format validation in the brand-logo asset-upload pipeline because the BIMI record published by each customer-tenant's domain points at the SaaS-hosted logo URL via the l= tag — meaning the SaaS platform is operationally responsible for ensuring every brand-tenant customer's uploaded logo conforms to the SVG Tiny PS 1.2 profile constraints (no scripts, no animations, no external resources, no embedded metadata, square aspect ratio, baseProfile="tiny-ps" attribute present) before the l=-pointed URL is published. Without this per-tenant SVG validation in the SaaS asset-upload pipeline, individual brand-tenant customers will publish BIMI records pointing at non-conformant SVGs that fail at the mailbox-provider rendering stage — and the BIMI rendering-failure cascades back into the brand-tenant customer's deliverability-program in ways the SaaS platform's support team must diagnose and resolve at scale. Operators reading this SaaS-sender DMARC guide to design the multi-tenant authentication plane need the BIMI-SVG-requirements spoke as the TECHNICAL-FILE-FORMAT companion documenting: the SVG Tiny PS 1.2 profile constraints (which features are allowed and which are forbidden), the square-aspect-ratio viewBox="0 0 SIZE SIZE" requirement, the baseProfile="tiny-ps" document-element attribute, the ~32 KB unminified / ~8 KB minified file- size operational target (which the SaaS platform's asset-upload pipeline enforces as a hard ceiling against attempted oversize uploads), the application/svg+xml / image/svg+xml MIME-type Content-Type response header the SaaS platform's CDN edge must serve, and the canonical validation tools (BIMI Group's SVG validator, Cloudflare's BIMI inspector, Mailhardener's BIMI lookup tool) the SaaS platform's brand-tenant onboarding flow should programmatically invoke before accepting a logo upload. Read this spoke when designing the per-tenant BIMI-logo-upload-and-validation pipeline that the SaaS platform's brand-tenant self-service flow exposes — the SVG-requirements spoke is the authoritative reference for the format gate the SaaS platform must enforce per upload, and structurally distinct from the BIMI-protocol-walkthrough primer (BIMI-explained) which covers the publishing-domain-side DNS-record publication rather than the SaaS-platform-side per-tenant logo-asset validation pipeline.
• MTA-STS explained - SMTP MTA Strict Transport Security for transport-layer encryption.
• MTA-STS for Google Workspace - the SAAS-PLATFORM-OUTBOUND-FROM- SAAS-EGRESS-TO-WORKSPACE-RECEIVER-MX- PATH-TLS-ENFORCEMENT-AT-WORKSPACE-MX- RECEIVE-BOUNDARY companion to this DMARC-for-SaaS-senders multi-tenant ESP deployment guide. Where THIS page documents the per-platform SaaS-sender integration cookbook from the SENDER (SaaS platform + customer-domain) perspective — including the per-platform include: token, per-tenant DKIM-CNAME selector publication, per-platform custom-domain- signing feature names and DNS timelines — the Workspace MTA-STS spoke is the RECEIVER-SIDE companion documenting the Workspace-tenant MTA-STS publication mechanics SaaS- platform outbound MTAs must honor at TLS-policy enforcement time when delivering to Workspace-hosted recipients. SaaS marketing platforms (HubSpot, Mailchimp, Klaviyo, Marketo, Pardot, SFMC, Constant Contact) operating high-volume shared-IP pools produce a substantial fraction of outbound traffic landing at aspmx.l.google.com + alt{1,2,3,4}.aspmx.l.google.com and at Workspace-hosted custom-domain recipients — every such delivery requires the SaaS outbound MTA to resolve the recipient's MTA-STS policy (TXT-record id=-keyed cache lookup + HTTPS policy-file fetch), validate the policy's mx: allow-list against the recipient's resolved MX, enforce the policy's mode: (none / testing / enforce), and respect the policy's max_age: cache lifetime. SaaS-platform misconfiguration of the outbound MTA's MTA-STS implementation (typically: not respecting mode: enforce, falling through to plaintext SMTP on STARTTLS- unavailable, or caching policies beyond max_age resulting in stale-policy enforcement during recipient MX-inventory rollovers) produces SaaS-sender deliverability incidents EXCLUSIVELY for the Workspace-receiver subset of customer recipients — distinct from the M365- receiver MTA-STS path. Read the Workspace MTA-STS spoke alongside this page when scoping SaaS-platform outbound MTA TLS-policy compliance to Workspace receivers, particularly when diagnosing SaaS-customer-reported delivery failures to gmail.com recipients that exhibit STARTTLS- related signatures in the Authentication-Results or in the receiver's TLS-RPT-reported failure catalogues.
• MTA-STS vs DANE — the SAAS-PLATFORM-PER-CUSTOMER-DOMAIN- TRANSPORT-LAYER-PROTOCOL-CHOICE companion reference. Where THIS page documents the SaaS-sender DMARC deployment workflow (per-customer-domain DKIM-CNAME-delegated signing for per-platform sender identity, per-customer-domain include:<platform-spf-macro> authorisation, per-customer-domain _dmarc.<customer> RUA aggregation publishing under the platform's DMARC-reporting infrastructure), the MTA-STS-vs-DANE spoke is the BINARY- TRANSPORT-LAYER-PROTOCOL-CHOICE companion each per-customer-domain transport-security publication discipline MUST resolve across four multi-tenant protocol-choice dimensions: (1) per-customer-domain DNSSEC coverage constraint — DANE STRUCTURALLY requires DNSSEC on the customer-domain's parent zone AND on the customer-domain's MX hostnames' parent zones; SaaS-sender platforms typically host their canonical sending-MX infrastructure on parking zones (AWS Route53, Google Cloud DNS, Cloudflare DNS) that are NOT DNSSEC-signed by default, which STRUCTURALLY rules out DANE for the platform's outbound-MX infrastructure and forces MTA-STS as the only viable transport-security protocol for the platform's outbound-relay layer; (2) per- customer-receiver-population enforcement coverage — the per-customer-domain receiver-population mix (consumer mail delivered to Gmail / Yahoo / Microsoft 365 / Apple iCloud where MTA-STS enforcement is dominant; B2B European mail delivered to t-online.de / GMX / web.de / posteo.de / mail.de where DANE enforcement is dominant; B2B North American mail delivered to Microsoft 365 / Google Workspace where MTA-STS enforcement is dominant) determines whether the per- customer-domain transport-security publication discipline favours MTA-STS or DANE — the spoke documents the per- receiver enforcement-coverage matrix the per-customer-domain protocol-choice decision-tree consumes; (3) RFC 7672 §1.3 coexistence rule — when a per-customer- domain publisher chooses to operate BOTH MTA-STS AND DANE simultaneously (typical for B2B publishers with mixed European + North American receiver populations), the RFC 7672 §1.3 coexistence-and-precedence rule applies: DANE-validating receivers prefer DANE; receivers that fail to DNSSEC-validate the TLSA records fall back to MTA-STS — the spoke documents the receiver-side fallback-precedence ordering the dual-protocol coexistence imposes on per-customer-domain transport-failure- signal interpretation; (4) per-customer- domain MX-publication-discipline divergence — DANE TLSA records key on the _25._tcp.mx.<customer-domain> record AT EACH publish-side MX hostname's DNSSEC-signed zone; MTA-STS policy files key on the mta-sts.<customer-domain> HTTPS-policy-host AT EACH PER-CUSTOMER- DOMAIN apex — the publication-discipline divergence between per-MX-hostname-keyed DANE and per-customer-domain-keyed MTA-STS is the load-bearing per-publisher authoring discipline the SaaS-sender platform must orchestrate per-customer- domain. Read the MTA-STS-vs-DANE spoke alongside this page when scoping the per- customer-domain transport-security publication discipline — the binary MTA-STS-vs-DANE choice and the per- customer-receiver-population enforcement coverage are the load-bearing transport- layer publication decisions the SaaS- sender platform MUST resolve per-customer- domain before the per-customer-domain receiver-side TLS-enforcement coverage guarantee can be declared operational.
• DANE for SMTP explained - the PER-SAAS-PLATFORM-PER-CUSTOMER-DOMAIN- DNSSEC-ANCHORED-DANE-TLSA-RR-PUBLICATION- DEEP-DIVE companion to this SaaS-senders reference. Where the MTA-STS-vs-DANE comparison entry above documents the binary protocol-CHOICE decision-tree at deployment time, the DANE-explained spoke documents the PROTOCOL-INTERNALS of the DANE TLSA-RR publication side at FOUR per-SaaS-customer- domain DANE-vs-MTA-STS-coexistence coupling dimensions: (i) per-SaaS-platform per-customer-domain DNSSEC-signed TLSA-RR publication discipline as DNSSEC-ANCHORED- PEER-PAIR to per-customer-domain MTA-STS Web-PKI-anchored publication discipline at the per-customer-MX trust-anchor publication moment — DANE roots cryptographic trust in the per-publisher per-domain DNSSEC chain (per-zone DS records at the parent zone delegating to per-zone DNSKEY records at the publisher zone signing per-MX-host TLSA-RR sets) while MTA-STS roots trust in the public Web-PKI two-leaf certificate chain served from the per- publisher mta-sts.<domain> HTTPS endpoint, but BOTH publish per-MX cryptographic-trust-binding evidence the receiver-side STARTTLS-enforcement evaluator consults at delivery-attempt time, and the SaaS-platform's per-customer- domain transport-security workflow must coordinate the per-customer DNSSEC-coverage precondition (DANE) AND the per-customer HTTPS-endpoint serving discipline (MTA-STS) when both protocols are deployed per RFC 7672 §1.3 (DANE preferred when TLSA validates; MTA-STS fallback otherwise); (ii) per-SaaS-customer-domain DANE TLSA- RR rotation cadence COUPLED to per-customer MX TLS server-certificate rotation cadence at the per-MX cert-renewal moment as STRUCTURAL-PARALLEL to per-customer DKIM <selector>._domainkey TTL-bounded rotation overlap-window the application-layer key-rotation discipline THIS SaaS-senders page documents — each per-MX TLS server-cert renewal event REQUIRES the SaaS platform to pre-publish the NEW TLSA-RR matching the new cert (usage 3 / DANE-EE, selector 1 / SPKI, matching-type 1 / SHA-256) BEFORE the cert renewal cutover, and the OLD TLSA-RR must remain published through the per-zone TTL- bounded cache-eviction window AFTER the cutover — structurally paralleling the per-customer DKIM rotation overlap-window coordination (new selector published + DKIM signer cutover + old selector depublished after TTL elapsed) the per- customer application-layer rotation discipline this SaaS-senders page presupposes; (iii) per-SaaS-customer-domain per-receiver-population DANE-vs-MTA-STS enforcement-coverage divergence as PER- RECEIVER-POPULATION protocol-coverage coordination discipline parallel to per- SaaS-customer per-receiver-population DMARC-policy-mode-ramp coordination discipline this page documents — German receivers (Strato, Deutsche Telekom, Mailbox.org), Dutch receivers (XS4ALL, KPN Mail), and Czech receivers (Seznam) enforce DANE TLSA-validation dominantly, while Gmail / Microsoft 365 / Apple iCloud / Yahoo enforce MTA-STS dominantly (with growing DANE adoption at Microsoft 365 since 2022) — the per-SaaS-customer-domain transport-layer publication discipline must coordinate both protocols per-receiver-population coverage priority just as the per-SaaS-customer per-receiver-population DMARC policy-mode- ramp coordination this page presupposes coordinates per-customer p=none → p=quarantine → p=reject phase-advancement decisions across the per-receiver- population DMARC-enforcement coverage; and (iv) per-SaaS-customer per-day TLS-RPT JSON-aggregate-report per-MX DANE- validation-failure evidence stream as TRANSPORT-LAYER per-MX observability complement to per-customer per-day DMARC RUA XML-aggregate-report per-source-IP application-layer authentication-verdict observability the per-SaaS-customer application-layer authentication-coverage diagnostic stream THIS page documents depends on — the per-customer TLS-RPT JSON-aggregate-report "result-type": "validation-failure" + "failure-reason-code": "dane-mismatch" rows emit per-receiver per-MX DANE TLSA- validation-failure evidence directly observable in the per-customer TLS-RPT ingestion pipeline, complementing the per- customer DMARC RUA per-source-IP application-layer DKIM-pass / SPF-pass verdict rows the SaaS-platform's per- customer-domain diagnostic playbook consumes — together both streams compose the per-SaaS-customer cross-layer observability-stack (per-customer transport- layer DANE/MTA-STS evidence + per-customer application-layer DKIM/SPF/DMARC evidence) the SaaS-platform's per-customer-domain operations team must correlate to maintain per-customer per-receiver-population end-to-end authentication-coverage guarantees. Pair THIS SaaS-senders reference with the DANE-explained spoke when designing the per-SaaS-platform per- customer-domain transport-layer publication discipline that bounds the per-customer per-receiver-population cross-layer cryptographic-trust-anchor coverage across both the DNSSEC-anchored DANE TLSA-RR publication surface AND the Web-PKI- anchored MTA-STS HTTPS-endpoint publication surface.
• TLS-RPT explained - SMTP TLS Reporting for transport-failure diagnostics.
• CAA records explained - DNS-level CA authorisation for the certificates that protect the unsubscribe URL domain.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the MULTI-TENANT-ESP-INCLUDE-CASCADE- BUDGET-ENGINEERING-AT-CUSTOMER-DOMAIN- APEX companion to this DMARC-for-SaaS- senders multi-tenant ESP deployment guide. Where THIS page documents the per-platform integration patterns SaaS senders use (DKIM key delegation, Return-Path subdomain delegation, custom-MAIL-FROM authoring, shared-IP- pool reputation isolation), the SPF-lookup-limit spoke is the UPSTREAM-BUDGET-CONSTRAINT companion documenting the RFC 7208 §4.6.4 10- DNS-query budget that EVERY SaaS- platform include-token consumed at the customer-domain apex SPF record must accommodate. Four structurally-distinct SAAS-MULTI-TENANT-VS-SPF-LOOKUP-BUDGET operational classes the spoke covers that THIS SaaS-sender reference intentionally elides: (i) per- platform-include lookup-cost accounting for SaaS-sender stacks — the spoke documents the empirically- measured lookup cost of each major ESP / SaaS-platform include token (Mailchimp's servers.mcsv.net consumes ~2-3 lookups, SendGrid's sendgrid.net consumes ~2-4 lookups, Mailgun's mailgun.org consumes ~2-3 lookups, Postmark's spf.mtasv.net consumes ~2 lookups, plus the customer's own Workspace / M365 baseline of ~3-5 lookups) — the operator-side accounting reference SaaS-integration engineers MUST consult before recommending an include-token addition to a customer-domain SPF record; (ii) recursive include-cascade resolution model for stacked SaaS platforms — the spoke documents the depth-first traversal the receiver's evaluator performs across the customer-domain's include cascade, accumulating lookup-count across every nested layer; this is the canonical failure-emergence topology for SaaS-multi-tenant customer-domain SPF records that stack 3+ platform includes — the cumulative cascade exceeds the 10- query budget invisible to the customer-domain SPF author who only sees the top-level include count; (iii) void-lookup secondary- cap exposure from stale ESP-platform include references — the spoke documents the RFC 7208 §4.6.4 secondary cap that fails the SPF check with permerror when more than 2 lookups return empty (NXDOMAIN / NoData) results; SaaS-multi-tenant customer-domain SPF records accumulate stale include tokens (former platform vendors no longer operating, includes pointing at DNS records the vendor deleted) that silently push the customer- domain past the 2-void-lookup secondary cap; (iv) four- remediation-path decision-framework for multi-tenant SaaS-customer- domain SPF — the spoke documents the operator-recommended order of remediation (lookup-audit via dig +short / kitterman.com SPF Surveyor before any other action → subdomain delegation to push platform-specific includes off the apex → sender consolidation by removing platforms the customer no longer uses → MONITORED SPF flattening with a daily regeneration pipeline as last resort because flattened records lose the ability to track ESP-platform IP changes automatically) — the framework SaaS-integration engineers MUST apply when a customer-domain SPF record breaches the budget. Required reading once a SaaS-multi-tenant integration adds the platform's include token to a customer-domain SPF record — the spoke's per- platform lookup-cost accounting + budget-overrun-remediation framework MUST inform the integration authoring discipline BEFORE the include token is published to DNS.
• include: vs ip4:/ip6: vs a: vs mx: SPF mechanism choice — the SAAS-MULTI-TENANT-PER-INTEGRATION- MECHANISM-CHOICE-DECISION-MATRIX companion to this DMARC-for-SaaS-senders multi-tenant ESP deployment guide. Where THIS page documents the per-platform SaaS-sender integration cookbook (DKIM key delegation, Return-Path subdomain delegation, custom- MAIL-FROM authoring, shared-IP-pool reputation isolation), the include-vs-ip4- vs-a-vs-mx spoke is the PER-MECHANISM- CHOICE-DECISION-MATRIX companion documenting the four canonical SPF mechanism types whose per-mechanism-choice decision every SaaS-integration-onboarding workflow MUST walk to choose the right mechanism for each per-tenant sender population. The SAAS- MULTI-TENANT-VS-MECHANISM-CHOICE-DECISION- MATRIX cross-reference establishes FOUR structurally-distinct dimensions where the spoke's per-mechanism reference is the load-bearing decision input for SaaS- integration authoring: (i) include: token for each ESP / SaaS-platform integration — the canonical case for every external- platform sender — the spoke documents the include-cascade recursion semantics (each level the receiver follows consumes 1 DNS lookup against the §4.6.4 ten-lookup budget) and the per-platform publication contract (each ESP / SaaS platform maintains its own servers.mcsv.net / spf.protection.outlook.com / _spf.google.com / amazonses.com include-token the publisher concatenates) — for the SaaS-sender authoring workflow, the include: mechanism is the DEFAULT-FIRST- CHOICE for every external-platform integration because it delegates per- platform IP-allocation-management to the platform operator (the platform rotates IPs internally without the customer needing to re-author the SPF record); (ii) ip4: + ip6: literal CIDR for in-house on-prem MTA egress — the budget-saving alternative when the publisher owns the egress infrastructure — the spoke documents the ip4:/ip6: literal CIDR block semantics (each ip4: or ip6: term costs 0 DNS lookups against the §4.6.4 budget, making them the budget- efficient choice for publisher-owned infrastructure) — for the SaaS-sender authoring workflow, the ip4:/ip6: choice is the BUDGET-CONSERVATION mechanism for the customer's in-house on-prem MTA (corporate Postfix, on-prem Exchange, legacy mail-relay) whose static IP allocation the customer manages directly without per-platform rotation concerns, freeing the budget for ESP / SaaS- platform include: tokens; (iii) a: mechanism for legacy MTA whose A record is the egress IP — the 1-lookup-cost simple-deployment shortcut — the spoke documents the a: mechanism semantics (the receiver resolves the a:<hostname> A-record and compares the message envelope-source IP against the resolved IP, consuming 1 DNS lookup against the §4.6.4 budget) — for the SaaS-sender authoring workflow, the a: mechanism is the LEGACY-CONVENIENCE choice for small deployments where the customer's mail.<domain> host is both the mail-server hostname and the egress IP, eliminating the need to explicitly list the IP (the spoke documents the per-mechanism reference for when this shortcut is appropriate vs when ip4: literal is preferable for budget-or-clarity reasons); (iv) mx: mechanism for self-receive-and-send domain topology — the bidirectional-MTA domain pattern — the spoke documents the mx: mechanism semantics (the receiver resolves the mx:<domain> MX-record-list and uses the resolved MX hosts as the authorized egress IPs, consuming 1 lookup for MX + 1 per MX host resolved against the §4.6.4 budget) — for the SaaS-sender authoring workflow, the mx: mechanism is the BIDIRECTIONAL-MTA convention for customer domains whose inbound MX infrastructure is ALSO the outbound egress infrastructure (typical of small-business on-prem Exchange deployments) — the spoke documents the per-mechanism reference for when mx: is the natural fit vs when explicit ip4: literal is the more defensive choice to avoid receiver- side MX-rotation-cache-staleness false-fail scenarios. Read the include-vs-ip4-vs-a-vs-mx spoke alongside this SaaS-sender DMARC deployment guide when authoring the customer-domain apex SPF record for each per-tenant onboarding — the spoke is the canonical mechanism- choice decision-matrix reference whose four mechanism-type dimensions directly map to the per-integration- per-tenant SPF-authoring decisions this SaaS-sender deployment guide documents.
• SPF permerror vs temperror - the MULTI-TENANT-ESP-INCLUDE-CASCADE- LOOKUP-EXHAUSTION-PERMERROR-TRIGGER companion to this DMARC-for-SaaS-senders multi-tenant ESP deployment guide. Where THIS page documents the per-platform SaaS-sender integration cookbook (the per-platform include: token the customer adds to authorise the SaaS platform's outbound SPF, the per-tenant DKIM-CNAME selector publication pattern, the per-platform custom-domain-signing feature names and DNS-publication timelines), the permerror-vs-temperror spoke is the RECEIVER-SIDE-OUTCOME- CATALOGUE companion documenting the FOUR distinct receiver-side SPF outcomes the SaaS-include-cascade produces at the evaluator: (i) permerror — the canonical and structurally- permanent outcome when the cumulative per-SaaS-platform-include lookup-cost (HubSpot 4, Mailchimp 3, Marketo 3, Salesforce Marketing Cloud 5, Klaviyo 2, Iterable 4, Braze 3, Constant Contact 5, Pardot 3, Outreach.io 2, SalesLoft 2, Intercom 3) plus the Workspace-native include:_spf.google.com (which itself costs 4-5 lookups in recursive expansion) or the M365-native include:spf.protection.outlook.com (3 lookups recursive) breaches the 10-lookup ceiling — every receiver returns spf=permerror and DMARC treats it as alignment-fail; (ii) temperror — the TRANSIENT outcome when any SaaS- platform's authoritative nameserver times out during the recursive evaluation; DMARC engines vary in treatment (Google retries, Microsoft defers); (iii) pass — the desired outcome when the customer's flattened or budget-managed SPF record evaluates below the 10-lookup ceiling and the sending IP matches an authorised mechanism; (iv) fail — the outcome when the SPF record evaluates within budget but the sending IP is not authorised (a SaaS-platform-rotated-outbound-IP case that requires reaching out to the SaaS platform's customer-success team to confirm the canonical outbound IP set). Read the permerror- vs-temperror spoke alongside this page when a customer's SPF record is approaching the 10-lookup ceiling due to the SaaS-include cascade THIS page documents and they need the receiver-side outcome catalogue to author the per-receiver behaviour section of the SaaS-platform integration runbook.
• SPF forwarding issues (the second-hop break) — the SAAS-PLATFORM-BOUNCE-HANDLER- AND-FEEDBACK-LOOP-RELAY-FORWARDER- INDUCED-SPF-BREAK-AT-CUSTOMER-DOMAIN- EGRESS companion to this SaaS-multi- tenant DMARC reference. Where THIS page documents the multi-tenant SaaS- platform DMARC deployment surface (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost, Mailjet, ConvertKit, Marketo, HubSpot, Mailchimp, Klaviyo) and the per- customer-domain SPF / DKIM / DMARC publication orchestration the platform coordinates, the SPF-forwarding- issues spoke documents the FORWARDER- INDUCED SECOND-HOP SPF-BREAK PATTERN that the SaaS platform's OWN multi- hop relay infrastructure produces at the customer-domain's receiver-side aggregate-report stream. FIVE structurally-distinct SAAS-PLATFORM- RELAY-VS-FORWARDER-INDUCED-SPF-BREAK operational classes the spoke catalogues that THIS SaaS-multi- tenant reference cross-references but does not byte-grammar enumerate: (i) per-customer bounce-handler MTA second-hop SPF break — when the customer's outbound message bounces at the recipient receiver-MX, the bounce DSN re-enters the SaaS- platform's per-customer bounce- handler MTA (at bounces.<platform> or similar) which re-emits the bounce notification from the platform's bounce-handler IP-pool — NOT in the customer-domain's primary outbound IP-pool — producing per-bounce-DSN spf=fail rows at the customer-domain's receiver-side aggregate-report stream; (ii) per-customer feedback-loop- relay MTA second-hop SPF break — ISP-FBL (Yahoo / AOL / Hotmail feedback-loop) complaint reports flow to the SaaS-platform's per- customer feedback-loop-relay MTA (at fbl.<platform> or platform-side ARF-processing infrastructure) which then forwards the ARF-formatted complaint payload to the customer's RUF mailbox producing forwarder-hop spf=fail rows on the customer-domain's authentication- results header; (iii) per- customer suppression-list-management forwarder SPF break — the platform's per-customer suppression- list-distribution forwarder relays bounce-rate and complaint-rate summaries through the platform's admin-relay MTA to the customer's admin mailbox, producing per- notification spf=fail rows; (iv) per-customer engagement-feedback bot-relay SPF break — recipient-side engagement-feedback bots (unsubscribe confirmations, click-tracking callbacks, list-membership updates) relay through the platform's bot- relay infrastructure producing forwarder-hop SPF-fail rows; (v) SRS / rewritten-MAIL-FROM as platform-side structural remediation for forwarder-induced SPF-fail rows — the SaaS platform's per-customer bounce-handler / FBL- relay / suppression-relay infrastructure SHOULD implement Sender Rewriting Scheme at every forwarder hop, rewriting the envelope MAIL FROM to a platform-controlled domain whose SPF record authorises the forwarder-MTA IP-pool, restoring SPF-aligned-pass at the customer- domain's receiver-side aggregate- report stream. Read the SPF- forwarding-issues spoke alongside this SaaS-multi-tenant DMARC reference when the customer-domain's aggregate-report stream shows a chronic background level of spf=fail rows that appear to originate from infrastructure adjacent to but NOT IN the platform's primary outbound IP-pool — the spoke's forwarder- topology catalogue is the diagnostic reference that disambiguates platform- side forwarder-relay-MTA fan-out (SPF-aligned-pass via SRS rewriting is the remediation) from actual spoofing-attempt-attack fan-out (DMARC-policy-enforcement is the remediation).
• TLS-RPT record syntax — the MULTI-TENANT-SAAS-PLATFORM-PER- CUSTOMER-DOMAIN-TLS-RPT-PUBLICATION- ORCHESTRATION companion reference. Where THIS page documents the SAAS- SENDER MULTI-TENANT-ESP-INTEGRATION pattern (per-tenant DKIM-CNAME selector publication, per-tenant SPF- include token with per-platform quantified lookup costs, per-tenant d=-domain-alignment remediation), the TLS-RPT-record-syntax spoke is the BYTE-LEVEL CANONICAL REFERENCE for the per-customer-domain TLS-RPT publication workflow the SaaS platform's customer-onboarding automation must produce alongside the DKIM-CNAME and SPF-include orchestration: each customer's _smtp._tls.<customer-domain> TXT record must publish v=TLSRPTv1; rua=mailto:tls- rpt@saas-platform.example (or a per-customer HTTPS endpoint) so the SaaS platform's centralised TLS-RPT aggregation infrastructure receives per-receiver transport-encryption failure reports across the entire customer fleet. The SaaS platform's customer-onboarding flow therefore produces THREE per-customer DNS records: (i) the DKIM-CNAME selector (page-level documented), (ii) the SPF-include token (page-level documented), (iii) the TLS-RPT _smtp._tls TXT record per the byte-syntax reference on the TLS-RPT-record-syntax spoke. Read the TLS-RPT-record-syntax spoke alongside this page when authoring the SaaS- platform customer-onboarding playbook — this page gives the per-tenant DKIM+SPF orchestration logic, the TLS-RPT-record-syntax spoke gives the per-tenant TLS-RPT TXT-record byte- level reference the playbook must produce for transport-encryption visibility across the multi-tenant customer fleet.
• DKIM for Microsoft 365 - the SAAS-PLATFORM-PER-CUSTOMER- DOMAIN-CNAME-DELEGATION-TO-M365- TENANT-DKIM-INFRASTRUCTURE-PATTERN- REFERENCE companion reference. Where THIS page documents the SaaS-platform per-customer-domain DMARC + DKIM + SPF + TLS-RPT orchestration playbook (per-tenant CNAME publication sequencing, per-tenant aggregate- report aggregation endpoint, multi- tenant signing-key rotation discipline, customer-onboarding verification workflow), the DKIM-for- Microsoft-365 spoke documents the CANONICAL CNAME-DELEGATION pattern the SaaS-platform playbook either MIRRORS or MUST INTEGRATE WITH. M365's selector1._domainkey.<customer-domain> → selector1-<tenant>._domainkey.<onmicrosoft.com> delegation is the industry-canonical pattern for per-customer-domain DKIM with platform-managed keys — the SaaS platform's own per-customer CNAME delegation (esp._domainkey.<customer-domain> → esp-<customer-id>._domainkey.esp-shared.example) follows the same shape, and when the SaaS customer ALSO routes inbound / relay mail through M365, the platform's outbound-signing selector must COEXIST with the customer's selector1/selector2 M365 signatures without collision. Read the M365-DKIM spoke alongside this page when authoring the SaaS-platform customer-onboarding playbook — the M365 CNAME-delegation pattern is the de-facto template for per- customer-domain DKIM publication and the coexistence reference when the customer's domain ALSO runs through M365 Exchange Online.
• DKIM for Google Workspace - the SAAS-PLATFORM-PER-CUSTOMER- DOMAIN-WORKSPACE-COEXISTENCE companion documenting the parallel CANONICAL Workspace-tenant DKIM-publication pattern the SaaS-platform per-customer-domain DKIM-orchestration playbook either MIRRORS (when SaaS platform itself runs Workspace-style tenant-managed signing) or MUST INTEGRATE WITH (when the SaaS customer's domain ALSO routes mail through Google Workspace and the SaaS platform's signing must coexist with the Workspace tenant's google._domainkey signature). Documents FOUR Workspace-parallel coexistence dimensions (Workspace's canonical google._domainkey.<customer-domain> TXT-record publication pattern as the industry-canonical reference for per- customer-domain DKIM with platform- managed keys — the SaaS platform's own per-customer esp._domainkey.<customer-domain> CNAME delegation follows the same shape, and when the SaaS customer ALSO routes outbound mail through Workspace the platform's outbound-signing selector MUST COEXIST with the Workspace tenant's google._domainkey TXT-record signature at the SAME author-domain; Workspace's per-tenant DKIM-key-rotation cadence — Workspace Admin Console EXPOSES the google._domainkey public key for operator-initiated rotation, and the SaaS-platform per-customer DKIM-rotation discipline MUST publish a parallel rotation-cadence baseline so per-customer Workspace + per-customer SaaS-platform keys age IN COORDINATION rather than DIVERGE; Workspace's per-tenant 2048-bit key-size baseline vs SaaS- platform per-customer key-size selection — Workspace publishes 2048-bit RSA as the default key-size, which the SaaS- platform per-customer DKIM-key infrastructure SHOULD also adopt to avoid per-customer Workspace-RSA-2048 + SaaS-platform-RSA-1024 cryptographic-strength asymmetry the receiver-side reputation model may observe; per-tenant Workspace + per- customer SaaS-platform parallel DKIM signing produces TWO DKIM signatures on the same outbound message — Workspace's d=<customer-domain> s=google AND SaaS-platform's d=<customer-domain> s=esp — both with the SAME Header-From: domain, both ALIGNING against the same author-domain DMARC policy, providing per-customer DEFENSE-IN-DEPTH against single-signature key compromise). Read the Workspace spoke alongside the M365 spoke when authoring SaaS-platform multi-tenant orchestration playbooks that must coordinate with BOTH the M365 and Workspace tenant DKIM infrastructures the SaaS customer fleet runs.
• Business Email Compromise (BEC) — the VENDOR-EMAIL-COMPROMISE-VEC-BEC-SUBTYPE-RISK-AT-SAAS-EGRESS-BOUNDARY companion to this SaaS-platform reference — the VENDOR-EMAIL-COMPROMISE-VEC-BEC- SUBTYPE-RISK-AT-SAAS-EGRESS-BOUNDARY companion documenting the BEC sub-class specifically targeting SaaS-platform egress boundaries and per-customer-domain delegated- signing infrastructure. Where THIS page documents the SaaS-platform multi-tenant DMARC + DKIM + SPF + TLS-RPT orchestration playbook (per-tenant CNAME delegation, per- tenant signing-key custody, per-tenant aggregate-report aggregation, customer- onboarding verification), the BEC spoke documents the VEC (Vendor Email Compromise) sub-class where the SaaS platform's legitimate per-customer-domain DKIM-signing infrastructure becomes the WEAPON in the attack — an attacker who compromises a SaaS-customer's account at the SaaS-platform boundary can send DMARC-aligned mail from the legitimate customer's authenticated domain that DKIM-verifies on the SaaS- platform's per-customer selector and aligns on the customer's organizational domain. The cryptographic authentication infrastructure THIS page documents is the FOUNDATIONAL layer the VEC threat exploits, requiring out-of-band controls (SaaS-platform per- customer abnormal-volume rate-limiting, unusual-recipient-pattern detection at send-time, per-customer-tenant credential- rotation discipline) that complement the in-band DMARC pass the platform's signing infrastructure produces. Read THIS multi- tenant orchestration page WITH the BEC reference when authoring the SaaS-platform's customer-account-compromise incident- response runbook — the BEC spoke catalogues the four attack sub-techniques (exact-domain spoofing closed by tenant DMARC enforcement, lookalike-domain registration requiring sibling-domain monitoring, display-name spoofing requiring envelope-vs-header differential inspection, VEC requiring send-time anomaly detection at the platform egress boundary THIS page operates) whose platform-side mitigations integrate with the per-customer-domain authentication infrastructure this page documents.
• SPF qualifiers explained - the SAAS-PLATFORM-MULTI-VENDOR- CUSTOMER-DOMAIN-SPF-FLAT-LIST-ALL- MECHANISM-QUALIFIER-CHOICE companion reference. Where THIS page documents the SaaS-platform multi-tenant DMARC deployment architecture (the platform operator provisions per-customer-tenant DKIM signing infrastructure / per- customer-tenant SPF macros / customer provisions DNS records pointing at the platform's authentication endpoints), the SPF-qualifiers spoke documents the FOUR RFC 7208 §4.6.2 QUALIFIER PREFIXES whose VALUE-CHOICE on the all mechanism is the LOAD-BEARING PUBLISHER POSTURE every SaaS-platform customer must make a deliberate choice on when authoring the SPF record that aggregates the platform's include: macros with the customer's other authorised senders. The all-mechanism qualifier choice is structurally important for SaaS-platform-customer SPF deployment because a customer with N include: macros pointing at N SaaS-platform-provided SPF macros (one per third-party transactional / marketing / billing / support / CRM provider the customer uses) PLUS the customer's own MTA's IP space REPRESENTS the maximal authorised-IP- space the customer's domain ever sends from; the -all qualifier on the customer's apex SPF record AUTHORITATIVELY DECLARES that NO OTHER IP than those in the flat-list is authorised, giving receivers explicit authority to REJECT at the SMTP layer before DMARC evaluation runs. The opposite choice, ~all SoftFail, is conventionally treated by receivers as monitoring-mode (the receiver records the SoftFail in the Authentication-Results header but delivers the message to inbox), which WINS INBOX DELIVERY FOR ATTACKER MESSAGES delivered from non-authorised IPs against the customer's domain. Reading the qualifier spoke is especially valuable for SaaS-platform- customer onboarding because the per- provider SaaS documentation often recommends specific qualifier postures WITHOUT explaining the qualifier semantics: SaaS providers like SendGrid / Mailgun / Postmark / Amazon SES / SparkPost recommend ~all in their getting- started documentation because the SoftFail-on-non-authorised-IP posture is the safest forward-recommendation the provider can make WITHOUT knowing the customer's full inventory of authorised senders (the provider avoids the customer-support cost of a misconfigured -all rejecting the customer's own legitimate mail). The qualifier spoke documents the deeper trade-off: the customer who has completed the SaaS-multi-vendor authorised-sender inventory and has confirmed all legitimate senders are covered by include: macros SHOULD tighten to -all at the end of the deployment to receive the full SMTP-layer rejection posture against attacker-controlled non- authorised IPs. The qualifier spoke also documents the four less-common prefixes (+ Pass on explicit-authorisation mechanisms, - Fail on explicit- rejection mechanisms, ~ SoftFail on monitoring-mode mechanisms, ? Neutral on observability- only mechanisms) that SaaS-platform operators occasionally use on include: entries to encode SUB-VENDOR observability differentiation within the customer's flat-list — a per-include-mechanism qualifier-posture customisation that is rarely documented but operationally valuable for multi-vendor SaaS customers running >5 third-party sender providers simultaneously.
• BIMI VMC certificates deep dive - the SAAS-MULTI-TENANT-PER- CUSTOMER-DOMAIN-VMC- PROCUREMENT-COMPLEXITY companion reference. Where THIS page documents the SaaS-platform-multi-vendor sender topology — a SaaS customer's apex domain with N include: macros pointing at N third-party SaaS provider SPF macros, per-vendor DKIM signing across multiple providers, DMARC-enforcement rollout coordinated across all providers — the BIMI- VMC-certificates spoke is the authoritative reference for the OPERATIONALLY-HARDER VMC procurement workflow that BOOTSTRAPS BIMI inbox- display eligibility in this topology. In single-tenant SaaS-customer topology (one BRAND-OWNING customer whose mail egresses through one or more SaaS providers BUT IS SIGNED + DELIVERED AS THE CUSTOMER'S DOMAIN), the VMC procurement workflow is: customer registers trademark with USPTO / EUIPO / UKIPO / JPO per jurisdiction, customer audits apex-domain CAA records for DigiCert / Entrust authorisation, then customer applies for VMC at chosen VMC-issuing CA, receives the VMC certificate, finalises the SVG-Tiny-PS file, publishes the default._bimi.<domain> TXT record. In SaaS- PLATFORM-MULTI-TENANT topology where the platform serves N brand-owning customer tenants (typical for Mailchimp, Klaviyo, Constant Contact, Salesforce Marketing Cloud, HubSpot, Mailgun- For-Brands tenant topology), EACH CUSTOMER TENANT'S BRAND-OWNED TRADEMARK-REGISTERED MARK requires PER-TENANT- PROCURED VMC + PER-TENANT- DOMAIN BIMI RECORD — the SaaS platform CANNOT share one VMC across N tenant customers because a VMC binds a SPECIFIC TRADEMARK-REGISTERED MARK to a SPECIFIC DOMAIN per CA/Browser-Forum BR §3.2.2.8 EV validation, and the platform's own domain trademark binding does not transfer to customers' brand marks. The SaaS platform's canonical playbook: (i) platform-side onboarding- flow integrates a VMC- application-broker UX guiding the customer through trademark registration, apex-domain CAA audit, VMC application, SVG-Tiny-PS authoring; (ii) per-tenant operational runbook tracks the N parallel VMC procurement workflows with per-tenant sub-status (trademark- pending, CAA-pre-audit- needed, VMC-application- submitted, VMC-issued, SVG-finalised, BIMI-record- published, receiver-display- verified); (iii) BIMI- record-publication step is per-tenant-domain — at the TENANT'S APEX DOMAIN (default._bimi.<tenant-domain>), NOT at the platform's domain — declaring the tenant-owned SVG-URI and VMC PEM-URL. The BIMI-VMC-certificates spoke catalogues the VMC deployment topologies relevant to multi-tenant SaaS — apex-only-VMC vs per-subdomain VMC vs multi-domain-VMC bundled certificate — with per- receiver compatibility notes and per-topology operational tradeoffs. Read the BIMI-VMC- certificates spoke alongside this SaaS- senders page when the SaaS platform is planning the BIMI-display product-offering tier for brand-owning customer tenants — the VMC procurement workflow is the load-bearing operational complexity this product-offering scales against, and the per-tenant-VMC- procurement playbook is the difference between a successful BIMI-display offering and an operationally-burning- out SaaS-platform support org.
• DMARC deployment checklist — the SINGLE-TENANT-RUNBOOK-CANONICAL- REFERENCE-FOR-N-PARALLEL-EXECUTIONS companion. Where THIS page documents SaaS-platform-side mail-sending posture for the multi-tenant per-customer-domain scenario, the deployment-checklist spoke is the canonical SINGLE-TENANT staged- rollout runbook (monitoring-only p=none → p=quarantine pct=10/25/50/100 → p=reject) from which a SaaS platform's per-customer- domain DMARC-deployment-as-a-service offering executes N PARALLEL INSTANCES with PER-CUSTOMER POSTURE TRACKING. A SaaS platform's tenant-onboarding flow integrates the deployment-checklist spoke's step set as a per-tenant workflow with the following per-tenant state- machine extensions: (i) tenant-customer in onboarding-form-data-collection phase (no DMARC posture yet); (ii) tenant in monitoring-only p=none baseline-measurement phase (aggregate reports flowing to tenant-customer's rua=mailto: mailbox AND to the SaaS platform's per-tenant analytics pipeline); (iii) tenant in p=quarantine pct=N% staged- ramp phase (SaaS platform tracks the per-tenant ramp progress, surfaces warning-flag dashboard widget if a tenant has been at pct=10 for ≥30 days without progressing); (iv) tenant at p=reject enforcement (SaaS platform tracks the per-tenant tenure at enforcement and per-tenant DKIM-failure rate as a leading-indicator of forensic- investigation-needed events). The SaaS platform's per-tenant DMARC-posture- management UI is the deployment- checklist spoke's runbook surfaced as a per-tenant workflow-state dashboard. Read THIS SaaS-senders page WITH the deployment-checklist spoke when designing a SaaS platform's per-tenant DMARC-deployment-as-a-service offering that productises the single-tenant runbook into a per-tenant workflow- state-machine with N parallel executions.
• TLS-RPT JSON report format — the PER-SAAS-CUSTOMER-TLS-RPT- JSON-REPORT-INGESTION-AS-MULTI-TENANT- TRANSPORT-LAYER-OBSERVABILITY-PIPELINE- COMPLEMENT-TO-PER-CUSTOMER-DMARC- AGGREGATE-INGESTION companion to this DMARC-for-SaaS-senders reference. Where THIS page documents the multi- tenant SaaS platform's per-customer DMARC publication orchestration + per-customer DKIM signing-identity delegation + per-customer shared-IP- pool reputation isolation + per- customer rua aggregate-XML ingestion pipeline as a per-tenant workflow- state-machine, the TLS-RPT JSON- report-format spoke is the MULTI- TENANT-TRANSPORT-LAYER-OBSERVABILITY- PIPELINE companion documenting the RFC 8460 §4 JSON report grammar whose per-failure-class catalogue every per-SaaS-customer transport- layer-TLS-failure-observability pipeline must ingest at the same per-tenant scale the per-customer DMARC aggregate-XML pipeline this SaaS-senders page documents operates. The four-axis PER-SAAS-CUSTOMER-DMARC- RUA-XML-VS-TLS-RPT-JSON comparison exposes the structurally-distinct per-customer cross-layer observability-orchestration couplings the SaaS platform must productise: (i) per-SaaS-customer rua aggregate-XML ingestion is multi- tenant-scaled around RFC 7489 §7.2 XML grammar parsing + per-customer- domain attribution + per-customer verdict rollup; per-SaaS-customer TLS-RPT JSON ingestion is multi- tenant-scaled around RFC 8460 §4 JSON grammar parsing + per-customer- domain attribution + per-customer TLS-failure-class rollup — both pipelines must be productised as per-tenant workflow-state-machines with N parallel per-customer executions whose per-customer report-aggregator infrastructure is tenancy-isolated; (ii) the per-SaaS-customer per-tenant _smtp._tls.<customer>.<tld> TXT-RR publication binding the per- customer TLS-RPT report-collector endpoint to the customer domain is the multi-tenant publication- discipline parallel to the per- customer _dmarc.<customer>.<tld> TXT-RR publication binding the per- customer DMARC rua-aggregate-report- collector — SaaS platforms offering DMARC-as-a-service typically must EXTEND the per-customer deployment workflow to include per-customer TLS-RPT publication AND per-customer report-aggregator provisioning to surface every per- customer-domain TLS-handshake failure at the customer's MX boundary; (iii) per-SaaS- customer TLS-RPT JSON reports surface per-receiver TLS-handshake- collapse events at the per-customer MX boundary that the per-customer DMARC rua aggregate-XML does NOT capture (rua reports the AUTHENTICATION outcome AFTER the TLS handshake succeeds; TLS-RPT reports the TRANSPORT outcome whether the authentication-layer ever runs) — multi-tenant SaaS platforms diagnosing per- customer deliverability complaints must cross-reference per-customer TLS-RPT JSON for upstream STARTTLS- availability outcomes that explain zero-rua-row mailflow gaps to the per-customer recipient population; (iv) per-SaaS-customer TLS- RPT JSON-report-format ingestion is the operationally-load-bearing observability primitive for the per-customer _mta-sts.<customer>.<tld> publication contract — SaaS platforms offering per-customer MTA-STS-as-a-service must ingest per-customer TLS-RPT JSON reports to observe whether peer-senders are honouring the per-customer TLS- enforcement contract, whether the per-customer policy-host cert is correctly issued/rotated by the platform-managed CA-issuance flow, and whether per-customer max-age/ mode= publication is consistent with per-customer per-receiver TLS-handshake outcome. Read the TLS-RPT JSON-report-format spoke alongside this SaaS-senders reference when scoping the per- customer cross-layer observability orchestration the SaaS platform's DMARC-as-a-service offering must productise — the spoke documents the per-failure-class JSON-report grammar that surfaces every per- customer transport-layer TLS- handshake outcome the per-customer DMARC rua aggregate-XML observability layer this SaaS- senders page documents cannot directly capture.
• Email Header Analyzer - inspect raw message headers for SPF / DKIM / DMARC / List-Unsubscribe verification on a single message.
• Domain Security Checker - live-resolves your SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA records.
• DNS Record Generator - wizards for SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA records.
• DKIM best practices - the PER-SAAS-CUSTOMER-SIGNING-DISCIPLINE- AS-LOAD-BEARING-DEPLOYMENT-PRACTICE- PRIMITIVE-FOR-MULTI-TENANT-SENDER- ARCHITECTURE companion to this SaaS- sender DMARC architecture reference. Where THIS page architectures the multi- tenant SaaS-sender's per-customer DMARC publication discipline (per-customer CNAME-delegated DKIM, per-customer Return- Path subdomain, per-customer rua endpoint, per-tenant abuse-isolation), the DKIM-best-practices spoke documents the canonical DKIM publication-and- rotation discipline EVERY multi-tenant SaaS sender must operate against at four per-SaaS-customer-DKIM-deployment- practice dimensions: (i) 2048- bit RSA key minimum as the per-SaaS- customer DKIM-key-strength deployment- practice primitive — the spoke documents why the 1024-bit RSA legacy floor is no longer adequate for any new SaaS-customer DKIM provisioning, and how the per-customer CNAME-delegated DKIM publication this page architectures must carry 2048-bit RSA (or Ed25519) keys to survive the receiver-side key-strength scoring this page's deliverability section depends on; (ii) per- SaaS-customer selector-rotation cadence as the per-tenant key-compromise-window deployment-practice primitive — the spoke documents the 90-day-to-12- month selector-rotation cadence catalogued as best-practice, and how the multi-tenant SaaS-sender must operate per-customer selector retirement and republication WITHOUT disrupting the per-customer DMARC-alignment posture this page architectures; (iii) canonicalisation-mode choice as the per- SaaS-customer ARC-survivability deployment-practice primitive — the spoke documents the c=relaxed/relaxed default and the c=simple/simple body-integrity-trade-off, both of which propagate into the per-SaaS-customer signing pipeline this page's per-tenant infrastructure must operate; and (iv) per-SaaS-customer key-material custody as the customer-isolation deployment-practice primitive — the spoke documents the per-tenant private-key isolation discipline (per- customer HSM partitioning, per-customer signing-service tenancy, audit-trail per-customer key access) the multi- tenant SaaS-sender's per-customer abuse- containment posture this page documents depends on. Read the DKIM-best-practices spoke alongside this SaaS-sender DMARC reference when the per-customer DKIM deployment lifecycle needs the canonical deployment-practice discipline catalogue the spoke architectures.
• SPF mechanisms explained — the PER-SAAS-CUSTOMER-SPF-MECHANISM- PUBLICATION-DISCIPLINE companion to this SaaS-sender DMARC reference. Where THIS page documents the multi-tenant SaaS- sender architecture (per-customer d=-tag attribution, per- customer DKIM selector publication, per-customer SPF-include macro for the SaaS-sender's shared egress IP-pool, per-customer DMARC-alignment scoping, per-customer DMARC policy-ramp coordination), the SPF-mechanisms- explained spoke is the RFC 7208 §5 per-mechanism operational reference whose four PER-CUSTOMER-SPF-MECHANISM- PUBLICATION-COUPLING dimensions catalogue the per-customer SPF publication topology every multi- tenant SaaS-sender depends on: (i) per-customer include:<saas-sender> macro-include cascade as load-bearing per-customer authorisation primitive — every multi- tenant SaaS-sender's per-customer SPF deployment workflow asks the customer to add include: with the SaaS-sender's published SPF include domain (e.g. include:_spf.salesforce.com / include:sendgrid.net / include:_spf.google.com) to the per-customer per-domain v=spf1 TXT-RR; the SPF- mechanisms-explained spoke documents the per-include recursive resolution algorithm + 10-DNS-lookup budget accounting + RFC 7208 §4.6.4 permerror handling that every per-customer authorisation cascade consumes — without the per-customer include: mechanism evaluating correctly, the per- customer SaaS-sender mail flow produces per-source-IP spf= fail and breaks the per- customer DMARC-pass rate; (ii) per-customer ip4: / ip6: explicit egress-IP enumeration vs per-customer include: cascade publication-choice — when a SaaS-customer's per-domain SPF record is at risk of exceeding the 10-DNS-lookup budget through stacked include: cascades, the per-customer SPF publication elects either to flatten the SaaS-sender's include: down to its underlying ip4: / ip6: ranges (cost zero lookups but recurring refresh burden as the SaaS-sender rotates egress IPs), or to delegate to a per-subdomain SPF record (split the budget); the SPF-mechanisms- explained spoke documents the per- mechanism cost-vs-no-cost trade- off catalogue the per-customer publication discipline must navigate when stacking the SaaS- sender's include with additional per-customer ESP includes; (iii) per-customer a: / mx: mechanism with shared-IP-cohort risk — the per-customer SPF record's a:<customer> and mx:<customer> mechanisms authorise the per- customer apex A/AAAA RR-set and the per-customer MX RR-set respectively as valid envelope- MAIL-FROM sources, but on a multi-tenant SaaS-sender topology where the per-customer <customer> domain resolves to a shared- outbound MTA cohort, the a: / mx: mechanism authorises a CO-TENANT'S outbound traffic to spoof the per-customer's envelope-MAIL-FROM; the SPF-mechanisms-explained spoke documents the per-mechanism IP-authorisation semantics the per-customer publication discipline must scope correctly on multi-tenant SaaS-sender deployments where shared-IP- cohort spoofing risk is structurally present; and (iv) per-customer -all / ~all / ?all qualifier choice as per-tenant authorisation commitment — the trailing per-customer SPF qualifier (-all hard-fail, ~all soft-fail, ?all neutral) is the per-customer publication- commitment that the multi- tenant SaaS-sender's per- customer DMARC-policy ramp consumes; the SPF-mechanisms- explained spoke documents the per-qualifier publisher commitment semantics (RFC 7208 §5.1 explicit qualifier vs §5.1 implicit ?-default) that the per-customer per-tenant DMARC ramp THIS page's rollout sequence depends on — a per-customer ~all qualifier blocks the per-customer DMARC-ramp from safely advancing past p=quarantine because softfail does not contribute to dispositive DMARC-pass evidence the per-customer programme needs. Read the SPF- mechanisms-explained spoke alongside this SaaS-sender DMARC reference when scoping the per-customer per-domain SPF publication discipline every multi-tenant SaaS- sender's per-customer deliverability programme depends on.
• Phishing protection — the PER-SAAS-CUSTOMER-MULTI-LAYER-ANTI- PHISHING-POSTURE-AS-MULTI-TENANT-DOWNSTREAM- CONSUMER companion to this SaaS-sender DMARC reference. Where THIS page documents the multi-tenant SaaS-sender architecture (per-customer d=-tag attribution, per-customer DKIM selector publication, per-customer SPF-include macro for the SaaS-sender's shared egress IP-pool, per-customer DMARC-alignment scoping, per- customer DMARC policy-ramp coordination), the phishing-protection spoke is the RECEIVER-SIDE ANTI-PHISHING-DEFENCE-STACK CATALOGUE documenting how the per-customer anti-phishing posture is the per-customer downstream consumer of the SaaS-sender's per-tenant DMARC-alignment architecture at FOUR per-SaaS-customer-anti-phishing-control dimensions: (i) per-customer p=reject + DMARC-alignment as per-customer direct-domain-spoofing-bounce anti-phishing control — once a SaaS-customer reaches the per-customer terminal p=reject pct=100 posture with per-customer DKIM d=-alignment to the customer's organisational From-domain, every attacker- originated direct-domain-spoof attempt against THAT SaaS-customer's brand is rejected at receiver-side DMARC evaluation; the phishing-protection spoke catalogues this direct-domain-spoof-defeat AS the canonical receiver-side anti-phishing control class every per-SaaS-customer brand depends on; (ii) per-customer Business Email Compromise (BEC) impersonation defence via DMARC-aligned SaaS-sender attribution — the per-customer DMARC-aligned SaaS-sender attribution chain (per-customer d=-tag DKIM signature plus per-customer Header-From alignment) closes the BEC-impersonation attack surface the phishing-protection spoke catalogues under the executive-impersonation and vendor- impersonation BEC attack classes; the per-SaaS-customer DMARC-alignment architecture THIS page documents is the per-customer message-layer authentication primitive every per-customer BEC-defence programme depends on; (iii) per- customer shadow-IT phishing-exposure discovery via per-SaaS-customer rua- aggregate-report ingestion — the SaaS-sender's per-customer per-source-IP rua-aggregate-report stream surfaces unauthorised per-customer SaaS-tenant usage (customer-marketing-team shadow-IT adoption of unauthorised mailer-services sending mail from the SaaS-customer's From-domain without per-customer authorisation); the phishing-protection spoke catalogues this shadow-IT-discovery AS the canonical receiver-side observability control class every per- SaaS-customer anti-phishing programme depends on; (iv) per-customer BIMI-display eligibility gating via per- SaaS-customer per-tenant DMARC pass-rate accumulation — the per-SaaS- customer 90-day rolling DMARC pass-rate the phishing-protection spoke catalogues as the BIMI-display-eligibility primary control is the per-customer downstream consumer of the per-customer DMARC- alignment ramp THIS page architects; the per-SaaS-customer per-tenant publication- discipline is the load-bearing precondition for the per-customer authenticated brand- logo render at the per-recipient inbox- list surface. Read the phishing-protection spoke alongside this SaaS-sender DMARC reference when scoping the per-SaaS- customer multi-layer anti-phishing posture the multi-tenant SaaS-sender's per-customer DMARC-alignment architecture THIS page documents structurally enables.
• Email security glossary — the MULTI-TENANT-LOOK-ALIKE-AND-BRAND- IMPERSONATION-THREAT-TAXONOMY-VOCABULARY- CATALOGUE companion to this DMARC-for- SaaS-senders deployment-architecture reference. Where THIS page documents the per-SaaS-customer multi-tenant SPF-include cascade, per-customer-CNAME-delegated DKIM signing, per-customer From-domain DMARC-alignment configuration, and per-customer rua= aggregate-evidence ingestion at the per-tenant deployment- topology layer, the glossary spoke catalogues the threat-actor + look-alike-domain + brand-impersonation + phishing-taxonomy vocabulary every per-SaaS-customer per-tenant threat- model consumes at four per-SaaS- customer-deployment-architecture-to- security-vocabulary coupling dimensions: (i) per-SaaS-customer multi-tenant deployment as load-bearing input to the glossary's look-alike-and-impersonation entries (typosquatting, homograph-attack, cousin-domain, combosquatting, lookalike-domain, brand-impersonation, display-name-attack) consumed by the per-SaaS-customer brand- monitoring analyst — the glossary's look-alike-domain catalogue documents the per-look-alike-class taxonomy (Punycode-renderer variants, cousin- TLD registrations, combosquatting modifiers, display-name spoofing patterns) that the per-customer DMARC- alignment architecture THIS page documents structurally cannot defend against (look-alike domains have their own DNS and publish their own SPF/DKIM/DMARC), framing the per- SaaS-customer brand-monitoring + defensive-registration + takedown- service + trademark-enforcement workflow as the necessary companion defense layer to the per-customer From-domain DMARC enforcement this page architects; (ii) per-SaaS- customer multi-tenant supply-chain- phishing-and-conversation-hijacking threat-model as load-bearing input to the glossary's phishing-and-attack- taxonomy entries (phishing, spear-phishing, whaling, bec, ceo-fraud, invoice-fraud, supply-chain-phishing, account-takeover, conversation-hijacking, credential-harvesting) consumed by the per-SaaS-customer incident-response team — the glossary's supply-chain-phishing + conversation-hijacking + account- takeover catalogue documents the per-customer threat-pattern the multi- tenant SaaS-sender's per-customer compromise can cascade into (compromised SaaS-sender account + per-customer From-domain authenticated mail + per-customer conversation-thread social-proof), framing the per-customer DMARC-alignment publication-discipline THIS page architects as one of many controls in the per-SaaS-customer supply-chain risk-management programme the glossary's supplier-risk vocabulary defines; (iii) per-SaaS-customer multi-tenant DMARC-rua and TLS-RPT-JSON evidence-stream as load-bearing input to the glossary's SOC + SIEM + SOAR + XDR + MDR entries (soc, siem, soar, xdr, mdr, threat-hunting, ioc, mttd-mttr, secure-email-gateway) consumed by the per-customer SOC analyst — the glossary's security- operations catalogue documents the per-platform telemetry-ingestion + correlation + automation + response-playbook tradecraft the per- SaaS-customer per-tenant rua-aggregate + TLS-RPT-JSON stream this page architects is the load-bearing per- customer evidence-feed for, anchoring the per-tenant deployment-topology publication discipline to the per- customer SOC + IR consumption pipeline the glossary defines; (iv) per- SaaS-customer multi-tenant defense-in- depth posture as load-bearing input to the glossary's defense-in-depth + zero- trust + phishing-resistant-MFA entries (defense-in-depth, zero-trust, phishing-resistant-mfa, conditional-access, secure-email-gateway, dlp, endpoint-detection-response, browser-isolation) consumed by the per-SaaS-customer security- architect — the glossary's defense- in-depth catalogue documents the per- layer control (perimeter, gateway, endpoint, identity, data, response) the per-SaaS-customer per-tenant DMARC-alignment publication-discipline THIS page architects is one operationally- relevant message-layer control among, anchoring the per-customer multi-tenant deployment-topology to the per-customer cross-layer defensive posture the glossary defines. Read the glossary alongside this DMARC-for-SaaS-senders reference when scoping the per-SaaS- customer multi-tenant threat-model and translating per-customer deployment- topology decisions into the look-alike- defense + supply-chain-risk + SOC + IR + defense-in-depth vocabulary every per-customer downstream analyst consumes.
• DKIM replay attacks — the PER-SAAS-PLATFORM-MULTI-TENANT- SHARED-SIGNING-INFRASTRUCTURE-AND- DELEGATED-PER-CUSTOMER-D-DOMAIN-SIGNING- IDENTITY-AS-LOAD-BEARING-PER-CUSTOMER- REPLAY-ATTACK-SURFACE companion documenting how the per-SaaS-platform multi-tenant per-customer DKIM-signing infrastructure deployment topology THIS page documents the architectural- primitive of structurally expands the per-customer DKIM-replay attack-surface catalogued in the DKIM-replay-attacks spoke at four per-SaaS-platform-multi- tenant-replay-attack-surface coupling dimensions. Where THIS page documents the per-SaaS-platform multi-tenant deployment-topology (per-customer delegated subdomain DKIM-signing identity at mailer._domainkey.<customer-d> CNAME-delegated to the SaaS-platform- managed mailer._domainkey.<saas-platform> TXT-RR, per-customer include:<saas-platform-spf> SPF cascade, per-SaaS-platform shared egress-IP pool with per-customer- delegated d=-domain signing identity, per-SaaS-platform per-customer-onboarded delegation workflow), the DKIM-replay-attacks spoke is the per-message-replay- attack-class threat-model whose per- SaaS-platform multi-tenant architectural characteristics structurally expand the per-customer per-message replay- attack surface at four per-SaaS- platform-multi-tenant-replay-attack- surface coupling dimensions: (i) per-SaaS-platform shared egress- IP pool serves per-customer signed- message bytes that an attacker per- platform tenant can capture and replay across per-customer delegated d=-domain identities the attacker is NOT entitled to send from — the per-SaaS-platform shared egress-IP pool this page documents the per-customer-delegated DKIM-signing architecture of is the load-bearing per-platform attribute whose per-tenant-message-bytes capture-and-replay is the canonical DKIM-replay attack-class the spoke documents; the per-platform attacker (another tenant of the same SaaS platform, or an internal-attacker at the SaaS-platform operations boundary) can capture per-customer signed- message bytes off the shared egress infrastructure and replay them against per-customer-target recipient cohorts the SaaS-platform did NOT originally address; (ii) per- SaaS-platform per-customer-delegated d=-domain signing identity per RFC 6376 §3.5 produces per- customer-org-domain-aligned DKIM-pass verdicts on the replayed message cohort → per-customer-org-domain DMARC-pass on the replayed payload — every per-SaaS-platform per-customer- delegated DKIM-signing identity this page documents the per-customer onboarding workflow of produces per- customer-org-domain-aligned per- message DKIM-pass verdicts that cryptographically survive the replay- hop boundary; the per-customer-org- domain-aligned per-message DMARC-pass on the replayed payload is the per- customer-org-domain threat-class expansion the per-SaaS-platform multi- tenant architecture creates and the DKIM-replay-attacks spoke catalogues; (iii) per-SaaS-platform per- customer-onboarded t=/x=-tag DKIM-signature-publication discipline as load-bearing per-customer-per- message replay-mitigation primitive the SaaS-platform's per-customer signing infrastructure MUST publish for per-customer replay-attack- resistance — every per-SaaS- platform per-customer-delegated DKIM- signing identity this page documents the per-customer onboarding workflow of has the per-platform discretion to emit per-message t=<timestamp> + x=<expiration> signature tags per RFC 6376 §3.5 whose per-receiver validation enforces per-message-signature-time- bounded validity; per-SaaS-platform per-customer-onboarded DKIM-signing infrastructure that publishes x=-bounded signatures constrains the per-customer per- message replay-attack-window the DKIM-replay-attacks spoke documents the threat-model of — making the per-SaaS-platform per-customer- onboarded t=/x=-tag DKIM-signature-publication discipline the load-bearing per-customer per- message per-receiver replay-mitigation primitive the per-customer per-domain DKIM-replay-attack resistance structurally depends on; (iv) per-SaaS-platform per-customer per-receiver per-source-IP aggregate- XML cohort emergence pattern as load- bearing per-platform per-customer replay-attack-cohort-scope detection KPI — when per-customer per- receiver aggregate-XML rows surface per-customer-org-domain DKIM-aligned- pass verdicts at per-source-IP cohorts outside the per-SaaS-platform per- customer authorised shared egress-IP pool, the per-SaaS-platform per- customer monitoring KPI dashboard surfaces the per-source-IP replay- cohort as a per-customer per-domain DKIM-replay-attack-cohort signature the per-SaaS-platform operations team must investigate as a potential cross-tenant-replay-attack incident; the per-SaaS-platform per-customer per-domain monitoring KPI dashboard the per-customer rua-aggregate-XML stream feeds is the load-bearing per- platform-wide replay-attack-scope detection KPI cohort. Read the DKIM- replay-attacks spoke alongside this SaaS-senders deployment guide when scoping per-SaaS-platform per- customer-onboarded t=/x=-tag DKIM-signature publication discipline, per-SaaS-platform per-customer per- source-IP aggregate-XML replay- cohort detection, per-SaaS-platform per-customer per-message AFRF forensic-evidence replay-attack- fingerprint capture, and per-SaaS- platform multi-tenant per-customer- delegated DKIM-signing infrastructure replay-attack-resistance evaluation across the per-SaaS-platform per- customer DKIM-signing topology this page documents the architecture of.
• DKIM key rotation — the PER-CUSTOMER PER-SELECTOR KEY-ROTATION-CADENCE companion to this SaaS-sender DMARC architecture reference. Where THIS page architects the per-SaaS-platform multi-tenant per-customer-delegated DKIM- signing topology (<selector>._domainkey.<customer-domain> CNAME-delegated to <selector>.dkim.<saas-platform-domain>), the DKIM-key-rotation spoke documents the per-selector key-rotation cadence (quarterly-or-faster rotation, old-selector grace-period retention, per-selector revocation discipline) every per-SaaS-platform DKIM-signing infrastructure MUST execute against EACH per-customer delegated selector boundary. Read THIS page when ARCHITECTING the per-SaaS-platform multi-tenant DKIM-delegation topology; read the DKIM-key-rotation spoke when AUTHORING the per-selector rotation cadence that keeps per-customer cryptographic material fresh across the platform's delegated-signer infrastructure.
• DNS propagation timing — the PER-SAAS-PLATFORM-PER-CUSTOMER- DOMAIN-CNAME-DELEGATION-DNS-PROPAGATION- AS-LOAD-BEARING-UPSTREAM-INFRASTRUCTURE- LAYER-PRECONDITION-FOR-PER-CUSTOMER- ONBOARDING-DKIM-VERIFICATION-AND-RUA- OBSERVABILITY companion reference. Where THIS page documents the per-SaaS-platform per-customer-domain master-zone CNAME- delegation publication discipline (the per-customer-domain k1._domainkey.<customer-domain> CNAME-to-dkim.mailchimp.com / hs1-XXX._domainkey. <customer-domain> CNAME-to- HubSpot-managed-signer / m1._domainkey. <customer-domain> CNAME-to- Marketo-managed-signer / klaviyo. _domainkey.<customer-domain> CNAME-to-Klaviyo-managed-signer publication the customer operator publishes at the customer-domain master zone during the per- customer SaaS-platform onboarding workflow), the DNS-propagation spoke documents the per-customer-domain master-zone CNAME- delegation publication's DNS-zone- authoritative-server-to-receiver-side- recursive-resolver propagation-completion timing whose per-receiver-resolver-cache TTL-bounded completion gates whether per- SaaS-platform-signed messages from the per-customer-domain onboarding sequence can be DKIM-verified at receivers, across four per-SaaS-platform-per-customer-domain- CNAME-delegation-publication-to-per-message- verification-and-RUA-observability-coupling dimensions: (i) per-customer- onboarding-CNAME-delegation-propagation- as-upstream-precondition-for-per-customer- DKIM-verification — the per- message DKIM verifier at receiver side resolves the per-customer-domain <selector>._domainkey. <customer-domain> CNAME to the SaaS-platform-managed signer's target zone THEN resolves that target's TXT record to retrieve the SaaS-platform- managed per-customer public key bytes the per-message b= tag must verify against; receiver-side resolver- cache propagation-incompleteness during the per-customer onboarding window produces per-customer per-message dkim=temperror / dkim=permerror verdicts at receivers whose recursive resolvers have not yet propagated the customer-domain master-zone CNAME chain to the SaaS- platform-managed target zone; (ii) per-customer-domain-CNAME-TTL- budget-as-receiver-cache-staleness-window- during-SaaS-platform-key-rotation — the per-customer-domain master-zone CNAME record's TTL value (typically 3600s at the customer's DNS provider) directly bounds the per-receiver-resolver-cache staleness window during which the SaaS-platform's operator-side per-tenant-pool key-rotation sequence (re-pointing the SaaS-platform- managed signer-zone TXT record to a new public-key) produces per-customer per- message dkim=permerror verdicts at receivers whose recursive- resolver cache still holds the prior public-key bytes; (iii) per- customer-pre-send-CNAME-pre-publication- window-discipline — SaaS-platform customer operators publishing the per- customer-domain master-zone CNAME BEFORE invoking the SaaS-platform's per-customer domain-verification workflow MUST WAIT for the per-receiver-resolver-cache propagation-completion window (one TTL cycle at minimum, ideally three for worldwide cache convergence) BEFORE flipping the SaaS-platform's per-customer sending-from-customer-domain switch to start emitting per-customer per-message DKIM-Signature headers with the d=<customer-domain> tag; (iv) per-customer-domain- CNAME-propagation-as-load-bearing-input- to-RUA-evidence-stream-source-IP- attribution-gap-observability — the per-customer-domain RUA evidence stream's per-source-IP attribution gap (shared-tenant-pool source IPs producing per-row spf=pass evidence for the SaaS-platform pool boundary but not the per-customer-domain identity) only becomes observable in the per- customer-domain RUA stream after the per- customer master-zone CNAME delegation has fully propagated AND per-SaaS-platform- signed per-customer messages have been received and aggregated by receivers; per- customer-domain CNAME publication- propagation-window incompleteness produces per-customer-domain RUA evidence-stream anomalies (per-row DKIM-fail / DMARC-fail rows from receivers whose recursive resolvers had not yet propagated the delegation) the per-customer operator must distinguish from authentic per- customer-domain shared-tenant-pool attribution-gap RUA evidence. Read this WITH the per-SaaS-platform multi-tenant deployment reference when the per-customer onboarding-CNAME-publication / SaaS- platform-managed-signer-zone-rotation / per-customer-domain RUA evidence-stream anomaly diagnosis sequence reaches the operator's queue: THIS page documents the per-SaaS-platform per-customer-domain multi-tenant CNAME-delegation publication discipline, the DNS-propagation spoke documents the INFRASTRUCTURE-LAYER propagation-timing discipline whose per- receiver-resolver-cache TTL-bounded completion gates whether per-customer- domain DKIM verification succeeds and whether per-customer-domain shared- tenant-pool RUA evidence-stream observability is authentic vs propagation- window-anomaly-induced.
• DMARC reporting pipeline (RUA aggregate-report end-to-end flow) — the PER-SAAS-SENDER-PER-CUSTOMER-DOMAIN RUA-AGGREGATE-EVIDENCE-STREAM-INGESTION- PIPELINE companion to this SaaS-sender DMARC deployment guide. Where THIS page documents the per-SaaS-sender per-customer- domain DMARC publication workflow (the per-vendor multi-tenant CNAME-delegation publication pattern, the per-customer- domain shared-tenant-pool RUA mailbox configuration, the per-SaaS-vendor authentication-coverage build-out across the customer-domain inventory), the reporting-pipeline spoke is the per-publisher per-receiver per-RUA-mailbox end-to-end evidence-stream ingestion-pipeline reference documenting the six pipeline stages each per-customer-domain DMARC deployment's per-day RUA aggregate-XML evidence stream traverses: (1) per-receiver per-message authentication-result-row capture at the receiver-side Authentication-Results header generation boundary, (2) per-receiver per-RUA-mailbox daily aggregate-XML batching at the receiver-side 24-hour reporting window boundary, (3) per-publisher RUA-mailbox SMTP delivery from the receiver-side outbound DMARC-aggregate-report MTA to the per-publisher RUA mailbox destination published in the rua=mailto:<mailbox> tag of the per-customer-domain _dmarc TXT record, (4) per- publisher RUA-aggregate-XML-parser ingestion at the per-publisher RUA- analyzer ingestion-pipeline boundary, (5) per-publisher per-source-IP per- disposition row analysis at the per- publisher per-customer-domain RUA-row- triage boundary, and (6) per-publisher per-third-party-sender authentication- coverage decision discipline at the per-publisher per-customer-domain DMARC- ramp-step tightening commit boundary. Read THIS page when PUBLISHING per-SaaS- sender per-customer-domain DMARC infrastructure; read the reporting- pipeline spoke when INGESTING per- customer-domain RUA aggregate-XML evidence streams.
• MTA-STS for Microsoft 365 — the LOAD-BEARING per-M365-tenant per- custom-domain PER-M365-TENANT-MTA-STS- PUBLICATION-AS-LOAD-BEARING-TRANSPORT- LAYER-COVERAGE-COMPLEMENT-TO-PER-SAAS- SENDER-PER-CUSTOMER-DOMAIN-APPLICATION- LAYER-SPF-AND-DKIM-AUTHORIZATION- PUBLICATION-DISCIPLINE companion documenting the per-M365-tenant per- custom-domain MTA-STS publication tutorial — specifically the per-tenant per-custom-domain _mta-sts.<d> TXT-RR version + policy ID publication, the per-tenant https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file publication, the per-tenant mode: enforce policy-mode choice that gates the per-receiver-MX STARTTLS-fail-closed enforcement behaviour. Where THIS page documents the per-SaaS-sender per- customer-domain SPF-include delegation + DKIM-CNAME delegation per-third-party- sender APPLICATION-LAYER authorization- publication discipline (the per-SaaS- sender per-customer-domain SPF include:<saas-spf-domain> token publication at the customer-domain apex SPF record, the per-SaaS-sender per-customer-domain DKIM-selector CNAME delegation to the SaaS-managed signing- domain, the per-SaaS-sender per- customer-domain DMARC-aligned-pass evidence-row production discipline), the MTA-STS-for-M365 spoke documents the per-M365-tenant per-custom-domain TRANSPORT-LAYER MTA-STS publication discipline that COMPLEMENTS THIS page's application-layer authorization publication — for M365-hosted customer tenants whose per-customer-domain DMARC coverage is published via the per-SaaS- sender delegation patterns this page documents, the per-tenant MTA-STS publication closes the per-customer- domain transport-layer STARTTLS-fail- closed coverage gap that the application- layer SPF + DKIM authorization publication cannot close. Read THIS page when PUBLISHING the per-SaaS-sender per- customer-domain DMARC + SPF + DKIM APPLICATION-LAYER authorization infrastructure; read the MTA-STS-for- M365 spoke when COMPLEMENTING the per- customer-domain APPLICATION-LAYER authorization publication with the per- M365-tenant per-custom-domain TRANSPORT- LAYER MTA-STS publication discipline at the per-tenant per-custom-domain LAYERED- PROTECTION publication-discipline boundary.
• DMARC attacker bypass techniques — the PER-SAAS-SENDER PER-CUSTOMER-DOMAIN MULTI-TENANT-DKIM-SELECTOR-NAMESPACE-AS- ATTACKER-SUBDOMAIN-CONFUSION-AND-DELEGATION- SCOPE-LEAKAGE-ATTACK-SURFACE threat-model companion to THIS page's per-SaaS-sender per-customer-domain DMARC publication discipline. Where THIS page documents the per-SaaS-sender per-tenant onboarding workflow whose per-customer-domain DKIM selector-delegation (via the per-tenant per-customer-domain CNAME-delegated selector._domainkey.tenant.example.com delegation pattern), per-customer-domain SPF include: mechanism publication, and per-customer-domain DMARC record p= enforcement floor the SaaS sender must guide the per-tenant operator through, the DMARC-attacker-bypass spoke documents the per-attacker per-SaaS- sender per-customer-domain attack surface a multi-tenant selector-namespace publication gap exposes the per-publisher per-customer-domain DMARC enforcement posture to. Two concrete per-SaaS-sender- vs-attacker-bypass coupling axes the attacker-bypass spoke documents: (i) per-SaaS-sender per-customer- domain DKIM-selector-namespace confusion attack — when a per-SaaS-sender publishes its per-tenant DKIM selectors under a per-tenant per-customer-domain CNAME-delegated namespace (e.g. k1._domainkey.tenant.example.com IN CNAME k1.dkim.saasvendor.example.com), an attacker who compromises ANOTHER tenant of the same SaaS vendor can re-emit per- message payloads under the attacker- controlled tenant's signing key but with a forged From-header pointing at the VICTIM tenant's per-customer-domain — because the per-receiver-side DKIM verifier looks up the d= tag against the From-header's per-customer-domain zone, the per-SaaS-sender per-tenant signing-key namespace partitioning determines whether the per-receiver-side verifier discovers the attacker-controlled tenant's key under the victim's per- customer-domain namespace; the attacker- bypass spoke documents the per-SaaS-sender per-customer-domain DKIM-selector-namespace partitioning discipline that closes this attack surface; (ii) per-SaaS- sender per-customer-domain subdomain- takeover attack — when a per- SaaS-sender's per-customer-domain CNAME- delegation points at a now-decommissioned per-vendor DNS zone (the customer offboarded the SaaS but failed to retract the per-customer-domain DNS delegation), an attacker can re-register the dangling per-vendor zone and publish attacker- controlled DKIM selectors under the per- customer-domain namespace — bypassing the per-customer-domain DMARC enforcement posture entirely; the attacker-bypass spoke documents the per-SaaS-sender per- tenant offboarding workflow that closes the per-customer-domain dangling-DNS attack surface at the per-tenant per- customer-domain authorization-publication retraction boundary. Read THIS page when PUBLISHING the per-SaaS-sender per- customer-domain DMARC + SPF + DKIM application-layer authorization infrastructure; read the DMARC-attacker- bypass spoke when MODELING the per- publisher per-customer-domain application- layer DMARC-authentication bypass attack surface a per-SaaS-sender per-tenant multi-tenant selector-namespace publication gap exposes the per-publisher per-customer- domain DMARC enforcement posture to.
• Email spoofing techniques and defenses — the seven-technique email-spoofing attack catalogue companion at four per- SaaS-tenant per-customer-domain vs spoofing-attack-class coupling dimensions.
• Why SPF alone is insufficient
• DKIM cryptography basics — the public-key signature primitive (RFC 6376 plus RFC 8301 crypto-requirements update plus RFC 8463 Ed25519 alternative) underlying every per-SaaS-tenant per-customer-domain DKIM signing deployment THIS SaaS-sender guide documents. Covers RSA-2048 vs Ed25519 key-strength tradeoffs, SHA-256 body and header hashing, the selector._domainkey TXT publication contract, and the 255-byte TXT-segment splitting (RFC 1035 §3.3.14) that RSA-2048 public-key publication requires — the load-bearing per-SaaS-platform cryptographic-primer underlying the per-customer-domain key-rotation and dual-algorithm (RSA + Ed25519) signing-discipline at multi-tenant scale.
• DKIM troubleshooting — the per-publisher per-selector DKIM-verdict-class triage reference companion at four per-SaaS-platform per-customer-domain DKIM-troubleshooting-vs-multi-tenant-deployment coupling dimensions: (i) per-SaaS-platform per-customer-domain DKIM-Signature emission discipline drift (selector-vs-CNAME-target mismatch at <selector>._domainkey.<customer-domain> publication point, stale-DKIM-key-rotation cadence mismatched with per-SaaS-platform signing-key rotation, mis-published v=DKIM1; k=rsa; p=<truncated-base64> byte-grammar crossing RFC 1035 §3.3.14 255-octet character-string boundary) surfaces in per-receiver per-message Authentication-Results header as dkim=permerror / dkim=fail per RFC 8601 §2.7.1 verdict-class whose per-customer-domain per-SaaS-platform root-cause triage the DKIM-troubleshooting decision-tree documents at the per-symptom-class triage-flow; (ii) per-SaaS-platform per-customer-domain DKIM-Signature d= tag publication-decision drift (using per-SaaS-platform default signing-identity like amazonses.com / sendgrid.net / mcsv.net instead of the per-customer-domain CNAME-delegated signing-identity) surfaces in per-receiver per-message dkim=pass-but-DMARC-fail verdict-class per RFC 7489 §3.1.1 alignment-evaluator whose per-customer-domain per-SaaS-platform CNAME-delegation publication-discipline gap the DKIM-troubleshooting reference documents at the dkim=pass-DMARC-fail symptom-flow; (iii) per-SaaS-platform per-customer-domain multi-signature scenarios (per-SaaS-platform's per-customer-domain-CNAME-delegated DKIM-Signature alongside per-SaaS-platform's platform-managed d=<saas-platform>.com DKIM-Signature on the same message) surface in per-receiver per-message DKIM-aligned-pass-rate floor under DMARC composite-verdict-evaluator per RFC 7489 §6.6.2 OR-conjunction whose per-customer-domain per-SaaS-platform multi-signature DKIM-verdict triage the DKIM-troubleshooting multi-signature-scenarios section documents the per-publisher per-selector verdict-class disambiguation of; (iv) per-SaaS-platform per-customer-domain DKIM-key-rotation cadence transitions (overlap-window-publication of next key BEFORE per-SaaS-platform activation cut-over, retirement-via-t=y testing-mode BEFORE TXT-RR deletion) preserve per-customer-domain per-SaaS-platform DKIM-aligned-pass-rate floor across rotation events but require per-receiver per-message verdict-class evidence-driven readiness validation the DKIM-troubleshooting reference documents at the per-verdict-class triage-flow — together the per-SaaS-platform per-customer-domain multi-tenant DKIM publication-discipline THIS page documents AND the per-publisher per-selector DKIM-verdict-class troubleshooting reference the DKIM-troubleshooting spoke documents compose the per-SaaS-platform per-customer-domain composite multi-tenant DKIM-publication-and-verdict-class-triage coordination floor.
• MTA-STS policy syntax — mail your SaaS platform sends to recipients running MTA-STS in enforce mode is dropped if the TLS hop fails, so a multi-tenant sender must understand the _mta-sts.<domain> TXT record and the HTTPS-served policy file's version / mode / mx / max_age fields. Read the policy-syntax spoke to keep customer mail flowing across enforce-mode receivers and to advise tenant domains on publishing their own policy.
• Microsoft SNDS + JMRP monitoring — ESP-style and multi-stream senders live or die by per-IP reputation: SNDS grades every registered sending IP GREEN/YELLOW/RED at Microsoft and JMRP returns each Outlook.com Junk click as an ARF complaint report.

16. Start auditing your SaaS-sender DMARC alignment now

DMARC Analyzer ingests aggregate (rua) reports via includes/DmarcParser.php and surfaces every per-source-IP alignment outcome on the dashboard (index.php). The per-source-IP drilldown (source_ip_detail.php) shows which SaaS senders are aligning cleanly and which are not; the per-reporter drilldown (reporter_detail.php) shows which receivers (Google, Microsoft, Yahoo) are receiving your authenticated marketing mail. The header_analyzer.php tool (built on includes/EmailHeaderParser.php) diagnoses single-message alignment plus List-Unsubscribe presence when a user reports a missing campaign. The domain_checker.php tool (built on includes/DnsChecker.php) live-resolves every CNAME chain so you can confirm a new SaaS sender's DKIM setup before sending the first campaign. Forensic (ruf) failure samples land via upload.php through includes/ForensicReportParser.php for spoofing investigation.

Check my domain configuration Sign up — Free plan