DMARC Analyzer

TL;DR

• DKIM is the load-bearing alignment mechanism for transactional email, not SPF. Most ESPs (SendGrid, Mailgun, Amazon SES, SparkPost) rewrite the envelope MAIL FROM to a bounce-handling domain under their control, so SPF aligns with that domain rather than with your visible From: header. DKIM with a custom-domain selector is what makes DMARC pass.
• Every ESP has its own DKIM selector convention. SendGrid uses s1._domainkey + s2._domainkey (rotating pair); Mailgun uses mailo._domainkey (newer) or mta._domainkey (legacy); Amazon SES Easy DKIM uses three random <token>._domainkey CNAMEs; Postmark uses a date-named selector TXT record; SparkPost uses scph0316._domainkey; Mailjet uses mailjet._domainkey; Resend uses resend._domainkey.
• Publish all CNAMEs as the ESP instructs, then verify with dig. A typical verification command is dig +short cname s1._domainkey.your-domain.com for SendGrid or dig +short txt mailo._domainkey.your-domain.com for Mailgun.
• Use a dedicated subdomain for transactional mail - transactional.example.com, mail.example.com, or mg.example.com isolates reputation from corporate mail (Workspace / M365) and marketing mail. Independent DMARC policy via the np= / sp= tags lets the apex ramp p=reject while a subdomain remains at p=none during ESP onboarding.
• Configure a custom Return-Path / bounce subdomain (em.your-domain.com, bounces.your-domain.com, or mailo.your-domain.com) as a CNAME to the ESP's bounce hostname to enable SPF alignment as a SECONDARY path - DKIM remains primary. SendGrid, Mailgun, and Amazon SES all support this; Postmark handles bounces internally so the custom Return-Path step is not applicable.
• The Feb 2024 Google / Yahoo bulk-sender requirements mandate DMARC at p=quarantine or stricter for senders above 5000 messages/day. Transactional senders routinely exceed this threshold; deferred deliverability or bulk foldering at scale is the consequence of missing DMARC alignment.
• Watch the SPF 10-DNS-lookup limit (RFC 7208 section 4.6.4) when adding multiple ESP includes to the apex SPF record. include:sendgrid.net + include:mailgun.org + include:amazonses.com + include:_spf.google.com already consumes 4-6 lookups before counting redirects. Dedicated subdomains per ESP keep each SPF record under the limit.
• The DMARC Analyzer dashboard surfaces per-source-IP alignment per ESP via source_ip_detail.php + reporter_detail.php. Use it to verify each ESP's outbound IP range is producing aligned messages before advancing the DMARC policy.

1. What this guide covers

This guide is the operator walkthrough for deploying SPF, DKIM, and DMARC on a domain whose transactional email is sent by a third-party Email Service Provider (ESP). The page covers the ten most-deployed ESPs in 2026:

• Twilio SendGrid - the largest transactional-email platform by volume. Authenticated Domain CNAMEs at em.<your-domain>, s1._domainkey.<your-domain>, s2._domainkey.<your-domain>.
• Mailgun (Sinch) - the developer-focused API platform with regional EU / US infrastructure. DKIM CNAME at mailo._domainkey.<your-domain> (newer accounts) or mta._domainkey / pic._domainkey (legacy).
• Amazon SES (Simple Email Service) - the AWS transactional-email platform. Easy DKIM generates three random <token>._domainkey CNAMEs pointing to <token>.dkim.amazonses.com. Optional custom MAIL FROM at mail.<your-domain>.
• Postmark (ActiveCampaign) - transactional-only, optimized for fast delivery and high inbox placement. DKIM published as a TXT record (NOT a CNAME) at <selector>._domainkey.<your-domain> where the selector is the literal date or the Sender Signature name.
• SparkPost (MessageBird) - the enterprise transactional platform with bring-your-own-infrastructure deployment. DKIM CNAME at scph0316._domainkey.<your-domain>.
• Mailjet (Sinch) - the European transactional-email platform with EU-residency guarantees. DKIM CNAME at mailjet._domainkey.<your-domain>.
• Sendinblue / Brevo - the European all-in-one (transactional + marketing) platform. DKIM CNAME at mail._domainkey.<your-domain> and a TXT record at brevo-code:<hash> for domain verification.
• Resend - the developer-API platform built by the React Email team. DKIM CNAME at resend._domainkey.<your-domain>.
• MailerSend - the transactional-and-marketing platform with Inbound Routing support. DKIM CNAMEs at mlsend._domainkey.<your-domain> and mlsend2._domainkey.<your-domain>.
• Mandrill (Mailchimp transactional) - the transactional add-on to the Mailchimp marketing platform. DKIM uses the Mailchimp domain authentication CNAMEs at k1._domainkey.<your-domain> and k2._domainkey.<your-domain>.

Beyond these ten the same universal pattern applies to Pepipost / Netcore, Elastic Email, SocketLabs, SMTP2GO, Mailtrap, SES Lite, and any other ESP that supports custom-domain authentication: a DKIM CNAME (or TXT) at an ESP-specified selector pointing to the ESP's key infrastructure, optional Return-Path / bounce subdomain CNAME, and an SPF include at the apex.

Companion pages: the four mailbox-provider deployment guides (DMARC for Google Workspace, DMARC for Microsoft 365, DMARC for cPanel & Shared Hosting, DMARC for Plesk, DirectAdmin, ISPConfig) cover the OUTBOUND MTA you control. This page covers the OUTBOUND MTA an ESP runs for you.

2. Why transactional email needs different DMARC handling

Transactional email differs from mailbox-provider outbound mail in three ways that fundamentally change the DMARC deployment surface.

2.1 Envelope MAIL FROM rewriting (the SPF alignment break)

When you send mail through Google Workspace, Microsoft 365, or your own Postfix / Exim MTA, the envelope MAIL FROM (RFC 5321 section 4.1.1.2) and the visible header From: (RFC 5322 section 3.6.2) are typically the same domain - your-domain.com sends on behalf of your-domain.com, and SPF aligns natively. When you send mail through an ESP, the ESP rewrites the envelope MAIL FROM to a domain it controls (typically bounces.sendgrid.net, bounce.mailgun.org, or <region>.amazonses.com) so the ESP can handle delivery failures via its own bounce-processing infrastructure. SPF authentication passes for the ESP's bounce domain against the ESP's published SPF record - but DMARC's identifier alignment requirement compares the SPF-authenticated domain against the header From: domain, and the two no longer match.

Result: the message passes SPF authentication but fails SPF alignment, which fails DMARC unless DKIM alignment succeeds independently.

2.2 Shared signing infrastructure (the DKIM custom-domain requirement)

By default an ESP signs every outbound message with its own signing domain (d=sendgrid.net, d=mailgun.org, d=amazonses.com). This satisfies the ESP's deliverability but does NOT align with your header From: domain - the receiver sees a DKIM signature valid for the ESP, but DMARC requires the DKIM d= to match (in relaxed alignment) or exactly equal (in strict alignment) your-domain.com.

The fix is custom-domain DKIM: you publish a CNAME at the ESP-specified selector under your-domain.com pointing to the ESP's key infrastructure. The ESP signs your outbound messages with d=your-domain.com s=<esp-selector>, the receiver follows the CNAME to fetch the public key from the ESP, and DKIM aligns with the header From:. The private key never leaves the ESP - the CNAME delegation is purely a public-key-lookup redirection.

2.3 Feb 2024 Google / Yahoo bulk-sender requirements

Effective February 2024, Google and Yahoo require senders above 5000 messages/day to Gmail / Yahoo Mail to publish DMARC at p=quarantine or stricter, maintain SPF + DKIM alignment, configure one-click unsubscribe per RFC 8058, keep complaint rates below 0.1 percent, and use a custom Return-Path / bounce domain. Transactional senders routinely exceed 5000 messages/day in production deployments. Failing the bulk-sender requirements results in:

• Deferred delivery (4xx temp-fail) at receiver scale, raising your apparent latency to end users.
• Bulk-folder routing for messages that pass the spam filter but fail the bulk-sender checks - users never see the password reset because Gmail filed it under Promotions.
• Outright reject (5xx perm-fail) when the Feb 2024 requirements are missed badly enough - typically only when DMARC is at p=none AND SPF / DKIM are both unaligned.

DMARC alignment for transactional email is no longer a security-only concern; it is a deliverability requirement at scale.

3. The SPF alignment trap

The most common DMARC failure mode for transactional email is SPF passes but DMARC fails. Operators see SPF=pass in the Authentication-Results header, assume DMARC will follow, and are surprised when aggregate reports show DMARC=fail. The trap is the difference between SPF AUTHENTICATION and SPF ALIGNMENT.

3.1 SPF authentication vs SPF alignment

SPF authentication (RFC 7208) asks: does the connecting client IP appear in the SPF record published at the envelope MAIL FROM domain? For an ESP-routed message the envelope domain is the ESP's bounce domain (e.g. bounces.sendgrid.net), the connecting IP is an ESP outbound IP, and the SPF record published at the ESP's bounce domain includes that IP. SPF authentication passes.

SPF alignment (RFC 7489 section 3.1.1) asks: does the SPF-authenticated domain match the header From: domain? For the same message the SPF-authenticated domain is bounces.sendgrid.net and the header From: is your-domain.com. The two domains do not share an organizational domain, so SPF alignment fails - even in DMARC's relaxed alignment mode (aspf=r), which only requires sharing the organizational domain after Public Suffix List trimming.

Result: SPF=pass + SPF-not-aligned + (DKIM=pass or DKIM=fail) -> DMARC=pass only if DKIM aligns, otherwise DMARC=fail.

3.2 Reading the trap in aggregate reports

In an RFC 7489 aggregate (RUA) report the trap surfaces as a record with policy_evaluated.dmarc=fail but auth_results.spf.result=pass AND auth_results.spf.domain set to the ESP's bounce domain (bounces.sendgrid.net, bounce.mailgun.org, amazonses.com) rather than your header From: domain. The DMARC Analyzer dashboard surfaces this via the source IP detail view, which shows the SPF-authenticated domain alongside the alignment verdict for every source IP. The fix is either configure custom-domain DKIM (primary) or configure a custom Return-Path / bounce subdomain (secondary, enables SPF alignment).

3.3 Custom Return-Path closes the SPF gap

Some ESPs (SendGrid, Mailgun, Amazon SES) let you configure a custom Return-Path / bounce subdomain: you publish a CNAME at em.your-domain.com (SendGrid), mailo.your-domain.com (Mailgun), or mail.your-domain.com (Amazon SES custom MAIL FROM) pointing to the ESP's bounce infrastructure. The ESP then sets the envelope MAIL FROM to your custom bounce subdomain instead of its own, so the SPF-authenticated domain becomes a subdomain of your organizational domain and SPF alignment passes natively. The SPF record at the bounce subdomain typically includes the ESP via include: mechanism. Section 6 below documents the per-ESP setup; section 4 documents the DKIM path which is the primary fix.

4. The DKIM alignment path (custom-domain CNAME-delegated DKIM)

DKIM alignment is the load-bearing DMARC pass mechanism for transactional email. The custom-domain DKIM pattern is universal across every ESP: you publish a CNAME (or TXT, in Postmark's case) at an ESP-specified selector under your-domain.com, the ESP signs every outbound message with d=your-domain.com s=<esp-selector>, and DKIM aligns with the header From:.

4.1 How CNAME-delegated DKIM works

1. You request domain authentication at the ESP admin UI (typically Settings > Sender Authentication, Domain Settings, or Verified Identities depending on the ESP).
2. The ESP generates a key pair internally and publishes the public key in DNS under its own control - at e.g. s1.domainkey.u12345.wl001.sendgrid.net (the actual hostname varies per ESP and per account).
3. The ESP gives you a CNAME to publish at <esp-selector>._domainkey.your-domain.com pointing to its public-key hostname.
4. You publish the CNAME at your DNS provider (Cloudflare, Route 53, Google Domains, your registrar's DNS panel, etc.).
5. The ESP signs every outbound message with DKIM-Signature: v=1; a=rsa-sha256; d=your-domain.com; s=<esp-selector>; ....
6. The receiver fetches the public key by looking up <esp-selector>._domainkey.your-domain.com, which CNAMEs to the ESP's hostname, which returns the actual TXT record with the public key.
7. DKIM verifies successfully with d=your-domain.com, which aligns with the header From: domain, which makes DMARC pass.

4.2 Why CNAME delegation instead of a direct TXT record

Some ESPs (Postmark, Sendinblue / Brevo) publish the DKIM key as a direct TXT record you copy and paste into DNS. Others (SendGrid, Mailgun, Amazon SES) use CNAME delegation. CNAME delegation has one large operational advantage: the ESP can rotate the underlying key without your involvement. The CNAME target remains stable; the TXT record at the other end of the CNAME chain is what changes when the ESP rotates. Direct-TXT publication requires you to update DNS every time the ESP rotates, which is rarely automated and introduces a rotation-coordination overhead. For high-volume senders CNAME delegation is the operationally safer choice.

4.3 Why DKIM signatures survive forwarding (mostly)

DKIM signatures are computed over the message body (or a canonical form of it - see help_dkim_explained.php for the canonicalization deep dive) and over a selected subset of headers. As long as the body is not modified, the signature survives forwarding intact - so an ESP-signed message that gets forwarded to a personal address still passes DKIM verification at the forwarding hop. SPF on the other hand always breaks on forwarding because the connecting client IP at the forwarding hop is the forwarder's IP, not the original ESP's IP. This is a second reason DKIM is the load-bearing mechanism for transactional email: forwarded messages still pass DMARC via DKIM where they fail via SPF.

4.4 ARC seals preserve forwarded alignment

For mailing-list and aggressive-rewrite forwarders that DO modify the body (subject-line prefixes, footer injection), DKIM verification breaks at the forwarder. ARC (RFC 8617) - the Authenticated Received Chain - lets the forwarder vouch for the original DMARC verdict via an ARC-Seal + ARC-Authentication-Results + ARC-Message-Signature header trio. The receiver evaluates the ARC chain when the direct DMARC fails. Most major receivers (Gmail, Microsoft, Yahoo) honour valid ARC chains. See help_arc_explained.php for the ARC deep dive.

5. Per-ESP DKIM setup walkthroughs

Every ESP exposes the same fundamental custom-domain DKIM pattern through a different UI. The literal selector names and CNAME targets below are verified against each ESP's official documentation as of May 2026. Always confirm the exact values in the ESP admin UI before publishing - some ESPs assign per-account or per-region tokens that differ from the literals here.

5.1 Twilio SendGrid

1. Sign in to SendGrid, open Settings > Sender Authentication and click Authenticate Your Domain.
2. Select your DNS provider from the dropdown (Cloudflare, GoDaddy, Route 53, etc.) and enter your sending domain (e.g. example.com or the recommended dedicated subdomain transactional.example.com).
3. SendGrid generates three CNAMEs:
   • em####.your-domain.com (custom Return-Path / bounce subdomain - the literal token em#### is account- specific).
   • s1._domainkey.your-domain.com (first DKIM selector).
   • s2._domainkey.your-domain.com (second DKIM selector - SendGrid rotates between s1 and s2 so both must always resolve).
4. Publish all three CNAMEs at your DNS provider, then return to SendGrid and click Verify. SendGrid resolves the CNAMEs and marks the domain authenticated.
5. Optionally enable Link Branding in the same UI to publish two more CNAMEs (url####.your-domain.com + 54321.your-domain.com) so click-tracking URLs route through your subdomain instead of sendgrid.net. Link Branding improves deliverability but is not strictly required for DMARC alignment.

Verify DKIM externally:

dig +short cname s1._domainkey.your-domain.com
# expect: s1.domainkey.u12345.wl001.sendgrid.net.
dig +short cname s2._domainkey.your-domain.com
# expect: s2.domainkey.u12345.wl001.sendgrid.net.
dig +short cname em1234.your-domain.com
# expect: u12345.wl001.sendgrid.net.

5.2 Mailgun

1. Sign in to Mailgun, open Sending > Domain Settings, click Add New Domain, enter your sending domain (Mailgun strongly recommends a dedicated subdomain such as mg.example.com for SPF-record isolation), and choose your region (US or EU).
2. Mailgun displays the DNS records to publish:
   • SPF: TXT v=spf1 include:mailgun.org ~all at the domain apex (or the subdomain if using one).
   • DKIM: CNAME mailo._domainkey.<domain> pointing to mailo.domainkey.u12345.eu.mailgun.org (newer accounts use mailo; older accounts use mta or pic - the Mailgun UI shows the literal selector).
   • MX (optional, only if you receive mail via Mailgun's inbound routing): 10 mxa.mailgun.org + 10 mxb.mailgun.org.
   • CNAME tracking (optional): email.<domain> pointing to mailgun.org.
3. Publish all records, then click Verify DNS Settings - Mailgun resolves and marks the domain Active.
4. If using a subdomain, publish DMARC at _dmarc.mg.example.com as well as (or instead of) the apex; the subdomain-policy sp= tag at the apex covers the subdomain when no explicit per-subdomain DMARC record exists.

Verify DKIM externally:

dig +short txt mailo._domainkey.your-domain.com
# expect: a long base64 public key starting with v=DKIM1; k=rsa; p=...

5.3 Amazon SES (Easy DKIM)

1. Sign in to the AWS console, switch to the region you send from (us-east-1, eu-west-1, ap-south-1, etc. - SES is region-scoped). Open Amazon SES > Verified identities and click Create identity.
2. Choose Domain, enter your sending domain, tick Use a custom MAIL FROM domain (recommended - enables SPF alignment), enter mail.your-domain.com (or any subdomain), and tick Easy DKIM (the default).
3. SES generates three CNAMEs of the form <token>._domainkey.your-domain.com pointing to <token>.dkim.amazonses.com. The three tokens are random strings unique to your identity - do not edit them.
4. For custom MAIL FROM, SES additionally requires:
   • MX 10 feedback-smtp.<region>.amazonses.com at mail.your-domain.com.
   • TXT v=spf1 include:amazonses.com ~all at mail.your-domain.com.
5. Publish all records at your DNS provider. SES verifies within minutes (occasionally hours during AWS DNS-propagation slowdowns) and marks the identity Verified and DKIM Successful.
6. Move your identity out of the SES sandbox via the Request Production Access form - in sandbox mode you can only send to other verified addresses, which is fine for testing but not for production.

Verify DKIM externally:

dig +short cname xxxxxxxxxxxxxxxxxxxx._domainkey.your-domain.com
# expect: xxxxxxxxxxxxxxxxxxxx.dkim.amazonses.com.
# (repeat for each of the 3 tokens shown in the SES console)

5.4 Postmark

1. Sign in to Postmark, open your Server, click Sender Signatures > Add Domain or Add Signature, and enter your sending domain.
2. Postmark displays the DNS records to publish. Unlike SendGrid / Mailgun / SES, Postmark publishes DKIM as a TXT record (NOT a CNAME) - you copy the full base64 public key from the Postmark UI and paste it into your DNS provider as the TXT value at <selector>._domainkey.your-domain.com. The selector is typically the literal date Postmark generated the key (e.g. 20240315) or a fixed pm selector for some accounts.
3. SPF: publish TXT v=spf1 a mx include:spf.mtasv.net ~all at the domain apex.
4. Return Path: Postmark handles bounces internally and does NOT support a custom Return-Path / bounce subdomain. SPF alignment therefore relies on the apex SPF record rather than on a subdomain CNAME - Postmark's envelope MAIL FROM is pm-bounces.<your-domain> which IS aligned natively because the bounce domain is at your-domain.
5. Click Verify Signature - Postmark resolves the DKIM TXT record and marks the signature verified.

Verify DKIM externally:

dig +short txt 20240315._domainkey.your-domain.com
# expect: a long base64 public key starting with v=DKIM1; k=rsa; p=...

5.5 SparkPost

1. Sign in to SparkPost, open Configuration > Sending Domains, click Add a Sending Domain, enter your sending domain.
2. SparkPost displays a DKIM CNAME at scph0316._domainkey.your-domain.com pointing to scph0316.domainkey.sparkpostmail.com (the literal scph0316 is the SparkPost-default selector; enterprise accounts can specify custom selectors).
3. SPF: SparkPost recommends TXT v=spf1 include:sparkpostmail.com ~all at the apex.
4. Custom bounce domain (optional): publish a CNAME at bounce.your-domain.com pointing to sparkpostmail.com.
5. Verify - SparkPost resolves DNS within minutes.

5.6 Mailjet

1. Sign in to Mailjet, open Senders & Domains, click Add a sending domain, enter your sending domain.
2. Mailjet displays:
   • SPF: TXT v=spf1 include:spf.mailjet.com ?all at the apex.
   • DKIM: a CNAME at mailjet._domainkey.your-domain.com pointing to mailjet.domainkey.mailjet.com.
3. Click Check now. Mailjet verifies within minutes.

5.7 Sendinblue / Brevo

1. Sign in to Brevo (formerly Sendinblue), open Senders & IPs > Domains, click Add a domain, enter your sending domain.
2. Brevo displays:
   • Brevo code: a TXT record at the apex of the form brevo-code:<hash> for domain ownership verification.
   • SPF: TXT v=spf1 include:spf.brevo.com -all at the apex (Brevo recommends -all not ~all).
   • DKIM: a TXT record at mail._domainkey.your-domain.com containing the full base64 public key Brevo generated.
   • DMARC: a TXT record at _dmarc.your-domain.com - Brevo will recommend a starter policy of v=DMARC1; p=none; rua=mailto:dmarc@brevo.com but you should point rua= at YOUR mailbox so DMARC Analyzer ingests the reports, not Brevo.
3. Publish all four records, then click Authenticate this domain.

5.8 Resend

1. Sign in to Resend, open Domains, click Add Domain, enter your sending domain and choose the region (us-east-1 or eu-west-1).
2. Resend displays:
   • SPF: TXT v=spf1 include:amazonses.com ~all at send.your-domain.com (Resend uses Amazon SES infrastructure under the hood, so the SPF include is amazonses.com).
   • DKIM: a CNAME at resend._domainkey.your-domain.com pointing to resend.amazonses.com (single selector, no rotation pair).
   • MX (for bounces): 10 feedback-smtp.<region>.amazonses.com at send.your-domain.com.
   • DMARC: a TXT record at _dmarc.send.your-domain.com with at minimum v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com.
3. Publish all records and click Verify DNS Records.

5.9 MailerSend

1. Sign in to MailerSend, open Domains, click Add Domain, enter your sending domain.
2. MailerSend displays:
   • SPF: TXT v=spf1 include:_spf.mlsend.com ~all at the apex.
   • DKIM: two CNAMEs at mlsend._domainkey.your-domain.com and mlsend2._domainkey.your-domain.com pointing to MailerSend's key infrastructure.
   • Tracking (optional): CNAME at email.your-domain.com for click-tracking links.
   • Custom Return-Path: CNAME at mta.your-domain.com for SPF alignment via custom bounce domain.
3. Click Verify Domain.

5.10 Mandrill (Mailchimp transactional)

1. Sign in to Mailchimp, open the Transactional API / Mandrill product, then open Settings > Domains & Tracking.
2. Mandrill uses the same domain authentication CNAMEs as the Mailchimp marketing product:
   • SPF: TXT v=spf1 include:spf.mandrillapp.com ?all at the apex.
   • DKIM: two CNAMEs at k1._domainkey.your-domain.com and k2._domainkey.your-domain.com pointing to dkim.mandrillapp.com and dkim2.mandrillapp.com.
   • Tracking (optional): CNAME at mail.your-domain.com.
3. Click Verify Domain.

5.11 Other ESPs

Beyond the ten ESPs documented above, the same universal pattern applies. Look for the Domain Authentication / Sender Authentication / Verified Identities / Domains page in the ESP's admin UI, publish the CNAMEs (or TXT records) they generate, verify with dig +short cname <selector>._domainkey.your-domain.com, and proceed to DMARC publication. The 10 ESPs above cover roughly 90 percent of the transactional-email volume in production deployments; the remaining 10 percent (Pepipost / Netcore, Elastic Email, SocketLabs, SMTP2GO, Mailtrap, IBM Cloud Email Service, etc.) follow the same pattern with different selector literals.

6. Return-Path / custom bounce domain configuration (SPF alignment)

DKIM alignment is sufficient for DMARC to pass. SPF alignment is the bonus second path. For senders pursuing the Feb 2024 Google / Yahoo bulk-sender requirements, having BOTH SPF and DKIM aligned is the recommended configuration - Google explicitly mentions both in its Email sender guidelines.

6.1 The custom Return-Path mechanic

The ESP sets the envelope MAIL FROM (also called the bounce address or Return-Path) to a subdomain you control instead of one the ESP controls. You publish a CNAME at the subdomain pointing to the ESP's bounce-handling hostname:

• SendGrid: em####.your-domain.com -> u12345.wl001.sendgrid.net (the em#### token is generated per-account).
• Mailgun: the dedicated sending subdomain itself (mg.your-domain.com) acts as the bounce domain - no separate Return-Path CNAME needed.
• Amazon SES: the custom MAIL FROM domain (mail.your-domain.com) with the MX + SPF records described in section 5.3.
• SparkPost: bounce.your-domain.com -> sparkpostmail.com.
• MailerSend: mta.your-domain.com as Custom Return-Path.

Postmark, Mailjet, Brevo, Resend, and Mandrill do not expose a separate custom Return-Path configuration - their default envelope MAIL FROM is either pre-aligned (Postmark via pm-bounces.your-domain.com) or relies on DKIM alignment alone.

6.2 Verifying SPF alignment after custom Return-Path setup

After publishing the custom Return-Path CNAME and waiting for DNS propagation, send a test message and inspect the Authentication-Results header at the receiver. The expected line shape is:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@your-domain.com header.s=s1 header.b="...";
       spf=pass (google.com: domain of bounces+1234@em1234.your-domain.com
       designates 167.89.123.45 as permitted sender)
       smtp.mailfrom=bounces+1234@em1234.your-domain.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com

The key indicators are smtp.mailfrom=...your-domain.com (envelope domain is a subdomain of your organizational domain) and dmarc=pass. The Email Header Analyzer on DMARC Analyzer parses this block and highlights alignment passes / failures via includes/EmailHeaderParser.php.

7. Subdomain segmentation strategy

The dedicated-subdomain pattern is the recommended architecture for transactional email at scale. Three motivations:

7.1 Reputation isolation

Receivers track sender reputation per organizational domain AND per subdomain. A transactional subdomain (transactional.example.com, mail.example.com, mg.example.com) accrues high-engagement reputation (password resets and 2FA codes get clicked, receipts get archived, and complaint rate stays low). Corporate mail (example.com apex via Workspace / M365) accrues normal-engagement reputation. Marketing mail (news.example.com via SendGrid Marketing or Mailchimp) accrues lower-engagement, higher-complaint reputation. Isolating each class behind its own subdomain means one campaign's bad day does not drag the transactional subdomain's reputation down - transactional deliverability stays stable.

7.2 Independent DMARC policy via np= / sp=

RFC 7489 defines sp= (subdomain-policy) which sets the DMARC policy for all subdomains of the organizational domain. RFC 9091 (formerly DMARCbis) introduces np= (non-existent-subdomain-policy) which sets policy for subdomains that do NOT have their own DMARC record. The tag deep dive covers each. Practical use:

• At the apex, publish v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@your-domain.com once corporate and transactional alignment are both clean.
• During ESP onboarding, publish an explicit per-subdomain DMARC record at _dmarc.transactional.your-domain.com with p=none so the apex sp=reject does not block your in-flight ESP setup.
• Once the transactional subdomain is clean, remove the subdomain-specific record and let the apex sp= tag take over - one canonical apex DMARC record covers every subdomain.

7.3 SPF 10-DNS-lookup limit relief

RFC 7208 section 4.6.4 caps SPF DNS lookups at 10 per evaluation. include: mechanisms each consume one lookup (plus the lookups in the included record). include:_spf.google.com is 3 lookups; include:sendgrid.net is 1-2; include:mailgun.org is 1; include:amazonses.com is 1. A sender with Workspace + SendGrid + Mailgun + SES at the apex hits 6-7 lookups before any custom infrastructure. Dedicated subdomains per ESP keep each SPF record under the limit:

; apex: corporate (Workspace) only
example.com.   TXT  "v=spf1 include:_spf.google.com ~all"

; transactional subdomain: SendGrid only
transactional.example.com.   TXT  "v=spf1 include:sendgrid.net ~all"

; marketing subdomain: Mailgun only
news.example.com.   TXT  "v=spf1 include:mailgun.org ~all"

7.4 Operational clarity

Each team owns a subdomain. The corporate security team owns the apex DMARC record; the application team owns the transactional subdomain; the marketing team owns the marketing subdomain. DNS-record changes are independent. Aggregate-report investigation is scoped to a subdomain. ESP onboarding does not require coordinating with security to ramp the apex.

8. Step-by-step rollout (SPF -> DKIM -> p=none -> ramp -> p=reject)

1. Pick a sending domain (recommended: a dedicated subdomain such as transactional.your-domain.com or mail.your-domain.com).
2. Configure ESP custom-domain DKIM per section 5 - publish the CNAME (or TXT) at the ESP-specified selector, verify with dig, click Verify in the ESP UI.
3. Configure custom Return-Path / bounce subdomain per section 6 - optional but recommended for full alignment coverage.
4. Publish SPF at the sending domain with the ESP's include mechanism. Verify with dig +short txt <domain>.
5. Send a test message to a Gmail / Microsoft / Yahoo address you control. Open the message and view the Authentication-Results header (in Gmail: Show Original; in Outlook web: ... > View > View message source). Verify dkim=pass with header.i=@your-domain.com and ideally spf=pass with smtp.mailfrom=...your-domain.com (or any aligned envelope).
6. Publish DMARC at p=none at _dmarc.your-domain.com (or at _dmarc.transactional.your-domain.com for a subdomain-only rollout). Minimum record: v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com.
7. Wait 2-6 weeks and read aggregate (RUA) reports via DMARC Analyzer. Verify alignment pass rate is 95+ percent for the ESP's source IPs. Investigate any gaps via the source IP detail view + report detail view.
8. Advance to p=quarantine for 4-12 weeks, with optional pct=25 through pct=100 ramp. Monitor for ANY new alignment failures from senders that newly appeared in aggregate reports.
9. Advance to p=reject once quarantine has been clean for one full sender-rotation cycle (typically 4 weeks). Keep pct at 100 (the default).
10. Maintain: read aggregate reports weekly per the monitoring guide. Investigate any new source-IP drift via the sender-inventory diff workflow documented there.

9. Bounce handling and feedback loops

9.1 Why bounce handling matters for DMARC

Bounce handling is operationally adjacent to DMARC because uncorrected bounces drive your complaint rate up, which drives your sender reputation down, which causes receivers to bulk-folder or delay your mail even when DMARC is correctly aligned. The Feb 2024 Google / Yahoo bulk-sender requirements set a complaint rate cap of 0.1 percent (one complaint per 1000 delivered messages). Exceeding that cap is a deliverability blocker.

9.2 ESP bounce-handling endpoints

Every major ESP exposes a webhook or HTTP API for bounce notifications. Subscribe your application to receive bounces and suppress addresses immediately after a hard bounce or spam complaint.

• SendGrid: Settings > Mail Settings > Event Webhook with events bounce, dropped, spamreport, unsubscribe.
• Mailgun: Sending > Webhooks with events permanent_fail, temporary_fail, complained, unsubscribed.
• Amazon SES: configure an SNS topic per Configuration Set with event types Bounce, Complaint, Reject. The SES Feedback Forwarding option is OFF by default for production accounts - use SNS.
• Postmark: Servers > <your-server> > Webhooks with events Bounce, SpamComplaint, SubscriptionChange.

9.3 Feedback loops (FBL)

Major receivers (Yahoo, AOL / Verizon Media, Microsoft via SNDS) expose a Feedback Loop that forwards spam complaints back to senders. ESPs subscribe to these on your behalf and surface complaints via the bounce-handling webhook. You do NOT need to register your domain with each receiver's FBL individually; that is the ESP's responsibility. Verify your ESP's FBL coverage in the ESP's documentation - SendGrid, Mailgun, SES, Postmark all automatically subscribe.

9.4 Suppression-list hygiene

Keep an internal suppression list of every address that has ever hard-bounced or complained. Re-attempting delivery to those addresses drives complaint rate up and reputation down. Every ESP also maintains a suppression list internally - SES, SendGrid, Mailgun, and Postmark all block sends to addresses on their internal list. Cross-check your application's list against the ESP's list periodically.

10. Dedicated IP vs shared IP authentication implications

10.1 Shared IP pools

By default every ESP places new accounts on a shared IP pool - your outbound mail leaves alongside hundreds or thousands of other ESP customers' mail from the same IP. Shared IP advantages: zero IP warmup required, the ESP handles reputation maintenance, you can ramp volume up and down freely. Shared IP disadvantages: your sender reputation is influenced by every other customer on the pool, so a high-complaint customer in the same pool can degrade your deliverability.

DMARC alignment works identically on shared and dedicated IPs - the IP does not change DKIM / SPF alignment. The Authentication-Results header will show the shared IP in the spf=pass verification, but that is irrelevant to alignment.

10.2 Dedicated IPs

Available on most ESPs (SendGrid Advanced, Mailgun Foundation, SES dedicated IPs, SparkPost Enterprise, Postmark Dedicated IP add-on) for an additional fee. Dedicated IPs must be warmed up - typically 30-60 days of progressively increasing volume so the receiver reputation engines learn your IP behaves well. Volume schedules vary; Mailgun and SES publish recommended warmup curves.

Dedicated IP advantages: your reputation is yours alone, large senders can hit higher receiver-side throughput limits. Disadvantages: warmup is mandatory; small senders (under 100k messages/month) cannot accumulate enough volume to maintain a reputation signal and end up worse off than on shared. Dedicated IP only makes sense above roughly 500k messages/month sustained.

10.3 Multiple dedicated IPs and IP rotation

Above 1M messages/month some senders run multiple dedicated IPs with weighted rotation - each IP carries a fraction of the load, receivers track each one independently, and isolation between transactional / marketing / notification traffic classes becomes practical. SendGrid, Mailgun, SES all support multi-IP pools with weighted routing.

DMARC alignment is unaffected by IP rotation. Each IP signs with the same DKIM key (because the key is per-domain, not per-IP) and the envelope MAIL FROM remains constant.

11. Multi-ESP estates

Many senders run multiple ESPs in parallel - SendGrid for marketing, Postmark for transactional, AWS SES for notification mail. The DMARC alignment surface scales linearly: each ESP needs its own custom-domain DKIM CNAMEs, each ESP signs with its own selector, and DMARC requires only ONE valid aligned signature per message to pass.

11.1 DKIM selector coexistence

Publishing s1._domainkey.your-domain.com + s2._domainkey.your-domain.com (SendGrid) + mailo._domainkey.your-domain.com (Mailgun) + <token>._domainkey.your-domain.com (Amazon SES, three of them) all at the same time is fine - each ESP signs messages with its own selector, the receiver looks up only the selector named in each message's DKIM-Signature header s= field, and unrelated selectors do not interfere.

11.2 SPF aggregation (or subdomain segmentation)

SPF is the bottleneck. Aggregating all ESPs into a single apex SPF record hits the 10-DNS-lookup limit fast. The recommended architecture is subdomain segmentation per section 7 - one ESP per subdomain, one SPF record per subdomain, each well under the limit.

If you must aggregate at the apex (e.g. because your stack uses a single From: domain across all sender categories), use an SPF flattening service that periodically resolves each include: mechanism into the underlying ip4 / ip6 ranges and republishes the resulting flat record. SPF flattening services include EasyDMARC SPF Flattening, dmarcian SPF Surveyor, Cloudflare Email Routing SPF Flattening, and self-hosted scripts. Note: flattening introduces fragility because the ESP's IP ranges change over time without notice, so the flattening service must run on a schedule (daily or weekly) and the operator must monitor it. The recommended approach is subdomain segmentation, not flattening.

11.3 Multi-ESP failover

For deliverability resilience some senders route the same message class through two ESPs - primary on SendGrid, failover on Amazon SES. DMARC alignment works the same way: both ESPs sign with custom-domain DKIM, both pass DMARC independently, and the receiver verifies whichever signature is present. The failover logic lives in your application or in an SMTP routing layer (Postal, Haraka, etc.); it is transparent to DMARC.

12. Common transactional-email DMARC mistakes

1. Trusting SPF=pass without alignment. The most common cause of transactional-email DMARC failure. SPF passes for the ESP's bounce domain but does not align with your header From:. Custom-domain DKIM is the fix.
2. Publishing only one of the SendGrid DKIM selectors. SendGrid rotates between s1._domainkey and s2._domainkey; if only one resolves, messages signed with the other selector fail DKIM verification. Always publish both.
3. Forgetting to enable DKIM at the ESP sub-account level. Large SendGrid / Mailgun deployments use sub-accounts (one per business unit or per product line); DKIM is configured per sub-account, not globally. Publishing the parent account's CNAMEs does not authenticate the sub-account's outbound mail.
4. Putting the DMARC record at the wrong subdomain. _dmarc.transactional.example.com covers From: foo@transactional.example.com only. From: foo@example.com from the SAME ESP requires DMARC at _dmarc.example.com with sp= or np= set appropriately - the per-subdomain record does not cover the apex.
5. Ramping to p=reject before clean alignment. The 2-6 week p=none observation period is not optional. Skipping it means legitimate transactional mail bounces or quarantines at receivers, which users notice immediately (missing password resets are escalations).
6. Forgetting the SPF 10-DNS-lookup limit when adding the second ESP. Workspace + SendGrid = ~5 lookups; adding Mailgun + SES pushes you past 10 and SPF breaks with permerror. Subdomain segmentation (section 7) avoids this.
7. Sending from a domain that does not match the ESP-authenticated domain. If you authenticate example.com in SendGrid but send with From: alerts@notify.example.com, DKIM signs with d=example.com (in relaxed alignment that aligns OK with notify.example.com), but if SendGrid's config requires strict alignment or pins d=notify.example.com you need to authenticate the subdomain separately.
8. Pointing rua= at the ESP's recommended fallback (dmarc@brevo.com, dmarc@mailgun.org, etc.). The ESP receives the reports instead of you. Always point rua= at your mailbox or your DMARC analytics platform (DMARC Analyzer, dmarcian, EasyDMARC, Valimail) so the reports flow to you.
9. Leaving SPF at ?all or +all. The neutral (?all) and pass-all (+all) qualifiers tell receivers to ignore SPF authentication outcomes, which is the opposite of what you want. Always use ~all (softfail) or -all (hardfail). For DMARC-enforced domains -all is strictly correct - if your SPF includes are exhaustive, mail from any other IP should hardfail.
10. Disregarding bounce notifications. Hard bounces and spam complaints not removed from your sender list drive complaint rate up and reputation down. Reputation degradation cascades into deliverability degradation even when DMARC is perfectly aligned. Subscribe to the ESP's bounce webhook per section 9.

13. Troubleshooting

13.1 ESP marks domain as Pending / Verification Failed

Most common cause: DNS propagation delay. CNAME records typically propagate in 1-15 minutes but some DNS providers cache for hours. Wait, then re-click Verify. If still failing, inspect the record value with dig and compare against the ESP's expected value byte-for-byte.

13.2 Aggregate reports show DKIM=fail at high rate

Three likely causes:

1. The ESP's CNAME chain is broken. Confirm with dig +trace <selector>._domainkey.your-domain.com - the trace should resolve through the ESP's hostname to a TXT record containing v=DKIM1; k=rsa; p=.... If the CNAME chain terminates at a NXDOMAIN, the ESP rotated keys and the CNAME target is stale - re-authenticate the domain in the ESP UI.
2. Sub-account DKIM not enabled (SendGrid / Mailgun multi-account deployments). Configure DKIM at the sub-account level in the ESP UI.
3. Message body modified after signing. Mailing lists / forwarders / spam filters sometimes add footers or modify subjects. DKIM canonicalization (see help_dkim_explained.php) determines tolerance. ARC (section 4.4) recovers DMARC alignment through aggressive forwarders.

13.3 Aggregate reports show DMARC=fail with SPF=pass + DKIM=pass

This signals an alignment problem, not an authentication problem. Inspect the report's auth_results block:

• If spf.domain is the ESP's bounce domain (bounces.sendgrid.net, bounce.mailgun.org, amazonses.com): SPF passed but did not align. Configure custom Return-Path (section 6) OR rely on DKIM alignment - check the next bullet.
• If dkim.domain is the ESP's signing domain (sendgrid.net, mailgun.org, amazonses.com): DKIM passed but did not align - the ESP signed with its own d= instead of yours. Configure custom-domain DKIM (section 5) and verify the ESP UI shows the domain as authenticated.

13.4 New IP appears in aggregate reports with high volume

Either an ESP added IPs to its outbound pool (legitimate drift - update your sender inventory) or an unauthorized sender is spoofing your domain (file spoofing - investigate via the source IP detail view + report detail view). The monitoring guide documents the weekly sender-inventory-diff workflow that routes new IPs to one of the two outcomes.

13.5 ESP says DKIM is verified but receiver shows DKIM=fail

The ESP verifies the CNAME at publication time but does not continuously re-verify. If the CNAME target hostname later becomes unreachable (the ESP rotates infrastructure, your DNS provider has an outage, etc.), the receiver's DKIM lookup fails. Re-test the CNAME chain with dig +trace, contact ESP support if the target appears stale.

13.6 Diagnostic toolkit

• Email Header Analyzer (header_analyzer.php) - parses Authentication-Results and DKIM-Signature headers via includes/EmailHeaderParser.php; identifies the signing domain, the selector, and the alignment verdict for any single message. The first tool to reach for when an end user reports a missing transactional email.
• Domain Security Checker (domain_checker.php) - live DNS lookups for SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, CAA via includes/DnsChecker.php; verifies every CNAME chain.
• DNS Record Generator (dns_generator.php) - generates syntactically-correct DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, CAA records when onboarding a new ESP.
• Aggregate report drill-down (reporter_detail.php + source_ip_detail.php + reports_detail.php) - navigates RFC 7489 aggregate reports ingested via includes/DmarcParser.php.
• Forensic / failure-sample drilldown when individual messages are spoofed - forensic reports ingested via includes/ForensicReportParser.php.
• dig at the command line: dig +short cname <selector>._domainkey.your-domain.com, dig +short txt _dmarc.your-domain.com, dig +trace <selector>._domainkey.your-domain.com.

14. Frequently asked questions

How do I set up DMARC for SendGrid?

Five steps. (1) Sign in to SendGrid, open Settings > Sender Authentication, click Authenticate Your Domain, choose your DNS provider, and enter your sending domain (e.g. example.com or transactional.example.com). (2) SendGrid generates a set of CNAMEs typically rooted at em.<your-domain>, s1._domainkey.<your-domain>, and s2._domainkey.<your-domain>. Publish all three CNAMEs at your DNS provider (Cloudflare, Route 53, Google Domains, etc.) - the em.<your-domain> CNAME is the custom Return-Path for SPF alignment, the s1 and s2 CNAMEs are the rotating DKIM key pair for DKIM alignment. (3) Return to SendGrid and click Verify; SendGrid resolves the CNAMEs and marks the domain authenticated. (4) Publish DMARC at _dmarc.<your-domain> with v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain> to start collecting aggregate reports. (5) After 2-6 weeks of clean reports advance p=quarantine then p=reject. SendGrid signs every message with s=s1 or s=s2 alternating, so both selectors must resolve at all times - never delete one without rotating to the new pair first.

How do I set up DMARC for Mailgun?

Five steps. (1) Sign in to Mailgun, open Sending > Domain Settings, click Add New Domain, enter your sending domain (e.g. mg.example.com or transactional.example.com - Mailgun strongly recommends a dedicated subdomain), and choose your region (US or EU). (2) Mailgun displays the DNS records you must publish: a TXT record at the domain apex for SPF (v=spf1 include:mailgun.org ~all - or include:mailgun.org and your own ip4: ranges if you also send from your own infrastructure), a CNAME at mailo._domainkey.<your-domain> (newer DKIM selector; older Mailgun accounts use mta._domainkey or pic._domainkey - check the Domain Settings page for the literal name), and optionally MX records if you also receive mail via Mailgun. (3) Publish all records at your DNS provider, then click Verify DNS Settings - Mailgun resolves the records and marks the domain Active. (4) Publish DMARC at _dmarc.<your-domain> (or _dmarc.mg.<your-domain> for the subdomain) with v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain>. (5) After 2-6 weeks of clean reports advance to p=quarantine then p=reject.

How does Amazon SES Easy DKIM work for DMARC?

Amazon SES Easy DKIM publishes a 2048-bit DKIM key automatically when you verify a sending identity (a domain or a subdomain). Five steps. (1) Sign in to the AWS console, open SES > Verified identities, click Create identity, choose Domain, enter your sending domain, and tick Use a custom MAIL FROM domain (recommended). (2) Tick Easy DKIM (the default) - SES generates three CNAMEs of the form <token>._domainkey.<your-domain> pointing to <token>.dkim.amazonses.com (the tokens are random strings unique to your identity, do not edit them). The custom MAIL FROM option requires an additional MX record (10 feedback-smtp.<region>.amazonses.com) and a TXT SPF include (v=spf1 include:amazonses.com ~all) at your chosen MAIL FROM subdomain. (3) Publish all 3 DKIM CNAMEs + MAIL FROM records at your DNS provider, then wait for AWS to verify (typically minutes, occasionally hours). (4) Publish DMARC at _dmarc.<your-domain> with v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain>. (5) Advance to enforcement after clean reports. Easy DKIM auto-rotates keys every quarter; the CNAMEs do not change - they always point to SES, which controls the underlying private key behind the scenes.

How do I set up DMARC for Postmark?

Postmark uses Sender Signatures (per-address) and per-domain DKIM. Four steps. (1) Sign in to Postmark, open the Server you send from, click Sender Signatures > Add Domain or Add Signature, enter your sending domain (e.g. example.com or transactional.example.com). (2) Postmark displays the DKIM TXT record - a long base64 public key at <selector>._domainkey.<your-domain> where <selector> is typically the literal date Postmark generated the key (e.g. 20240101 or pm._domainkey). Publish the TXT record at your DNS provider exactly as shown (Postmark publishes the actual public key as a TXT value, NOT a CNAME - this is a deliberate design choice for verification simplicity). Also publish a TXT SPF include at the domain apex: v=spf1 a mx include:spf.mtasv.net ~all. (3) Click Verify Domain in Postmark - it resolves the DKIM TXT record and marks the signature verified. (4) Publish DMARC at _dmarc.<your-domain> with v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain>, then advance to enforcement after clean reports.

Why does my transactional email pass SPF but fail DMARC?

Almost always because SPF passes for the ESP infrastructure but the envelope MAIL FROM domain (5321.From) does not align with your visible header From: (5322.From). ESPs typically rewrite the envelope MAIL FROM to an ESP-controlled bounce domain (bounces.sendgrid.net for SendGrid, bounce.mailgun.org for Mailgun, <region>.amazonses.com for Amazon SES) so the ESP can handle delivery failures. SPF checks that bounce domain against the ESPs SPF record, which passes - but DMARC requires alignment of the SPF-authenticated domain with the header From: domain, which fails because the bounce domain does not match your-domain.com. Fix: configure custom-domain DKIM at the ESP (CNAMEs at <selector>._domainkey.<your-domain> pointing to the ESPs key infrastructure) so DMARC aligns via DKIM regardless of envelope rewriting. Optionally also configure a custom Return-Path / bounce subdomain (em.<your-domain> CNAME to the ESPs bounce hostname) so SPF aligns too, but DKIM alignment is the load-bearing mechanism for transactional email.

Should I use a dedicated subdomain for transactional email?

Yes - the dedicated-subdomain pattern (e.g. transactional.example.com, mail.example.com, mg.example.com) is the recommended architecture for transactional email at scale. Three benefits. (1) Reputation isolation: transactional traffic (high engagement, low complaint rate) builds a distinct sender reputation from corporate mail (employees emailing externally, often with attachments) and marketing mail (lower engagement, higher complaint rate). Receivers track reputation per subdomain, so isolating each class of mail prevents one bad day from degrading the others. (2) Independent DMARC policy via the np= / sp= tags: the organizational domain can ramp p=reject while a subdomain remains at p=none during ESP onboarding. (3) Operational clarity: every team can verify alignment for their subdomain without coordinating with the security team owning the apex. Cost: requires the ESP to authenticate the subdomain (one set of CNAMEs per subdomain) and your DNS provider to publish per-subdomain records. Tradeoff is worth it above ~5000 transactional messages/day or whenever the Feb 2024 Gmail / Yahoo bulk-sender thresholds apply.

How do I handle DMARC when I use multiple ESPs at the same time?

Each ESP needs its own custom-domain DKIM CNAMEs published in your DNS, all under distinct selectors. SendGrid uses s1._domainkey and s2._domainkey; Mailgun uses mailo._domainkey; Amazon SES uses three random tokens; Postmark uses a date-named selector. Publishing all four sets of CNAMEs simultaneously is fine - each ESP signs messages with its own selector, and DMARC requires only ONE valid DKIM signature aligned with the header From: 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 ESPs in a single SPF record at the apex, but watch the 10-DNS-lookup limit (RFC 7208 section 4.6.4) - SendGrid + Mailgun + Amazon SES + your own MTA already consumes 4-6 lookups before counting redirects. Use a dedicated subdomain per ESP (transactional.example.com on SendGrid, marketing.example.com on Mailgun, etc.) to keep each SPF record under the limit and isolate reputation.

Do I need DMARC at p=reject if I only send transactional email?

Yes, especially for transactional email. Three reasons. (1) Transactional messages (password resets, 2FA codes, magic links, payment receipts) are high-value spoofing targets because they trigger user action - a forged password-reset email lands in the same inbox as a legitimate one, and only DMARC enforcement blocks the forgery at receiver level. (2) The Feb 2024 Google / Yahoo bulk-sender requirements explicitly mandate DMARC at p=quarantine or stricter for senders above 5000 messages/day to Gmail / Yahoo Mail; transactional senders routinely exceed this threshold. (3) At p=none receivers DELIVER spoofed messages to the inbox - DMARC at p=none gives you reporting visibility but provides zero blocking. Operators should treat p=reject as the production-ready end state and treat p=none as a temporary alignment-debug stop on the rollout path. The DMARC Analyzer dashboard walks the operator through the ramp via the rollout guide help_dmarc_policy_rollout.php and the troubleshooting loop help_dmarc_troubleshooting.php.

15. Related guides

• DMARC explained - the central DMARC primer covering the DMARC ecosystem, the RFC 7489 specification, and the policy progression p=none → p=quarantine → p=reject.
• DMARC record tags explained - every tag in the DMARC DNS record including the sp= and np= tags used in subdomain segmentation (section 7).
• DMARC alignment explained - identifier alignment (the SPF/DKIM-domain-matches-From: rule) which is the SPF-alignment trap discussed in section 3.
• DMARC policy rollout - the operational migration from p=none through p=quarantine to p=reject; the rollout cadence in section 8 follows this guide.
• DMARC deployment checklist — the TRANSACTIONAL-ESP-PER-ENDPOINT- DEPLOYMENT-CHECKLIST-EXECUTION companion to this transactional-email deployment reference. Where THIS page documents the transactional-sender deployment workflow across ESP integrations (per-ESP SPF include-token publication, per-ESP DKIM CNAME-delegated signing-key publication, per-ESP envelope-from / header-from alignment coordination, per-ESP bounce / suppression / feedback-loop ingestion), the DMARC-deployment-checklist is the CANONICAL GREEN-PATH WORKFLOW transactional- mail operators execute PER-CUSTOMER-DOMAIN with multi-ESP-integration-specific coordination requirements layered on top. Four per-transactional-checklist-execution- coordination dimensions: (i) PHASE-1-SPF- PREREQUISITE-AT-MULTI-ESP-INCLUDE-CHAIN (the checklist's Phase 1 SPF-prerequisite- verification step requires the transactional operator to enumerate every ESP-published include chain — SendGrid sendgrid.net ~7 lookups, Mailgun spf.mailgun.org ~5, Amazon SES amazonses.com ~3, Postmark _spf.mtasv.net ~3 — and stay under the RFC 7208 §4.6.4 ten-DNS-query budget; the per-customer- domain apex SPF authoring is structurally constrained by the cumulative include- chain expansion), (ii) PHASE-1-DKIM- PREREQUISITE-AT-PER-ESP-CNAME-DELEGATED- SIGNING-KEY (the checklist's Phase 1 DKIM- prerequisite step requires per-ESP CNAME- delegated signing-key publication coordination — per-ESP selector s= + per-ESP signing-domain d= coordination across the multi-ESP fanout the checklist's audit step must enumerate), (iii) PHASE-2-RUA-PUBLICATION- AT-PER-ESP-AUTHENTICATION-RESULTS- INGESTION (the checklist's Phase 2 RUA- publication step provides per-ESP Authentication-Results visibility into per-ESP DKIM-signing-domain alignment outcomes — the per-customer-domain aggregation point captures per-ESP evidence rows the checklist's audit step uses to verify Phase 1 prerequisites), (iv) PHASE-3-THROUGH-PHASE-5-RAMP-AT-PER- ESP-DELIVERABILITY-BASELINE (the checklist's Phase 3-5 ramp progression requires per-ESP deliverability baseline coordination — a single ESP's IP-pool reputation regression can produce per-ESP DMARC=fail rows that block the ramp advancement even when the per- customer-domain DMARC authoring is correct; the per-ESP support-channel escalation workflow is layered on top of the checklist's ramp progression). Critical when transactional-mail operators executing per-customer-domain DMARC deployment need the canonical green-path step-by-step workflow reference layered on top of the multi- ESP integration topology — the DMARC- deployment-checklist is the operator- facing workflow driver this transactional- email deployment page contextualises per-ESP-fanout-specific coordination.
• DMARC policy modes (p=none / p=quarantine / p=reject) - the PER-ENDPOINT-TIER-SELECTION companion to this transactional-email deployment reference. Where THIS page documents the five-ESP roster (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost) and the per-ESP DKIM-via-API delegation model AND the sub- 30-second-delivery-window business-criticality constraint that distinguishes transactional from marketing traffic, the DMARC-policy-modes spoke is the PER-ENDPOINT POLICY-TAG SELECTION REFERENCE documenting the four-phase phased- enforcement-ramp every transactional ESP- endpoint MUST follow at cutover. The TRANSACTIONAL-ENDPOINT-DEPLOYMENT-PHASE-VS- POLICY-TAG-SELECTION cross-reference establishes FOUR structurally-distinct transactional- endpoint cutover 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 1–2 weeks of transactional-ESP onboarding when the operator is inventorying the per-endpoint legitimate-sender population (which application service publishes which transactional template through which ESP endpoint) AND the per-ESP egress IP-pool rotation surface AND any sibling-domain unauthorised egress legacy-application code paths surface; 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 the per-endpoint DKIM-pass / SPF-pass / alignment-pass status the transactional operator must close in Phase 1 BEFORE ramping to soft-quarantine; (ii) Phase 2 Triage with p=quarantine + pct=10 percentage-ramp per endpoint — 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 transactional operator progressively closes the per-ESP DKIM-via-API / 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 — CRITICAL for transactional because soft-quarantine of a password-reset OTP into a customer's spam folder PRODUCES immediate helpdesk-ticket spike and SLA violation); (iii) Phase 3 Soft-Enforcement with p=quarantine + pct=100 full-sample steady-state per endpoint — the FINAL soft-quarantine tier where 100% of receiver evaluations apply the soft- quarantine action and the transactional operator'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 transactional operator's per-endpoint enforcement has graduated to the canonical post-deployment steady state; the DMARC-policy-modes spoke documents the p=reject + sp=reject coordination (mandatory for transactional because the transactional-template subdomain population — notify.brand.com, mail.brand.com, orders.brand.com, receipts.brand.com, support.brand.com — is precisely the surface attackers spoof for password-reset and 2FA-OTP phishing; only sp=reject closes the unauthorised subdomain-spoof gap the transactional surface inherently exposes). Pair this page (the transactional-ESP per- endpoint deployment coordination reference) with the DMARC-policy-modes spoke (the per- phase policy-tag selection reference) when authoring the per-endpoint four-phase cutover runbook — the spoke documents the per-phase exit-criteria gates and the pct= / sp= coordination the transactional operator MUST sequence correctly to avoid prematurely advancing to a stricter tier before the per- ESP authorisation coverage gates close.
• DMARC aggregate (RUA) reports - the RFC 7489 section 7.2 XML schema. ESP alignment verdicts surface here.
• DMARC forensic (RUF) reports - per-message failure samples for spoofing investigation.
• DMARC troubleshooting - the diagnostic loop for any DMARC failure surfaced via monitoring; includes the SaaS sender / custom DKIM scenarios.
• DMARC myths and misconceptions - the TRANSACTIONAL-ESP-DEPLOYMENT-AS- PER-MISCONCEPTION-CANONICAL-INSTANCE companion to this transactional-email DMARC-deployment guide. Where THIS page documents the eight API-driven transactional-ESP deployment topologies (SendGrid / Mailgun / Amazon SES / Postmark / Mailjet / SparkPost / Mandrill / Resend) and their per-ESP DKIM-CNAME-delegation / SPF-include / alignment-configuration patterns, the myths-and-misconceptions spoke is the STAKEHOLDER-EDUCATION-AGAINST- TRANSACTIONAL-EMAIL-FALSE-MENTAL-MODELS reference that debunks the operator-side misconceptions specific to transactional- sender contexts. The TRANSACTIONAL-EMAIL- MISCONCEPTION-DEBUNKING cross-reference establishes FOUR structurally-distinct dimensions where the myths spoke debunks operator-side misconceptions about the transactional-ESP-deployment decisions THIS page documents: (i) "transactional email is internal / system-generated so doesn't need DMARC protection" misconception → debunked by the TRANSACTIONAL-MESSAGES- ARE-THE-HIGHEST-VALUE-SPOOFING-TARGETS class — operators new to transactional-email DMARC frequently treat password-reset / 2FA / order- confirmation / receipt / shipping-status messages as "internal system mail" that doesn't warrant the rollout-investment of DMARC-at-reject; the myths spoke documents the per-recipient-action threat model where transactional messages are the HIGHEST-VALUE spoofing targets precisely BECAUSE they trigger immediate user action — a forged password-reset email or 2FA-bypass-OTP lands in the same inbox as a legitimate one and only DMARC-at-reject enforcement blocks the forgery at the receiver-side — debunking the operator's "transactional = low- threat-tier" mental model with the per-recipient-action-trigger-elevates- threat-tier operational truth this page's eight-ESP deployment-pattern catalogue underpins; (ii) "p=none gives me 'monitoring protection' for the transactional traffic stream" misconception → debunked by the ZERO-RECEIVER-SIDE- ENFORCEMENT-AT-p-NONE-AGAINST-FORGED- TRANSACTIONAL-MESSAGES class — operators completing the per-ESP DKIM-CNAME / SPF-include / alignment configuration steps THIS page documents frequently stop the rollout at p=none believing they have "monitoring-tier protection"; the myths spoke documents the RFC 7489 §6.3 receiver-side semantics where p=none produces ZERO receiver-side enforcement against forged messages — Gmail / Microsoft 365 / Yahoo / Apple iCloud deliver spoofed transactional messages with p=none identically to messages with no DMARC record at all — debunking the operator's "p=none provides monitoring-tier protection" mental model that masks the protect- the-transactional-traffic-stream- against-spoofing-requires-p=reject operational truth this page's eight- ESP-deployment catalogue is the publisher-side instrument for; (iii) "DKIM-via-ESP-API equals DKIM-aligned-for-DMARC" misconception → debunked by the DKIM-d-DOMAIN-FROM- ESP-DEFAULT-DIVERGES-FROM-HEADER-FROM- ORGANIZATIONAL-DOMAIN class — operators completing the per-ESP API- based DKIM-signing configuration frequently believe that "DKIM signing enabled at the ESP = DMARC-aligned- DKIM-verdict at the receiver"; the myths spoke documents the receiver- side adkim= alignment evaluation where the DKIM-Signature header's d= tag must match the From: header organizational domain — by default, ESPs sign with their own DKIM key (d=sendgrid.net, d=mailgun.org, d=amazonses.com, etc.) which produces dkim=pass but dkim- alignment=fail unless the publisher executes the per-ESP DKIM-CNAME- delegation step this page documents — debunking the operator's "DKIM- enabled-at-ESP = DMARC-DKIM-aligned" mental model with the per-ESP-DKIM-CNAME-delegation-is- load-bearing-for-alignment operational truth this page's per-ESP CNAME-record specimens are the publisher-authoring instrument for; (iv) "Feb-2024 Google/Yahoo bulk-sender requirements only apply to marketing senders, not transactional" misconception → debunked by the 5000-MESSAGES-PER-DAY-THRESHOLD-APPLIES- TO-COMBINED-PER-DOMAIN-VOLUME-INCLUDING- TRANSACTIONAL class — operators running transactional-only sending operations frequently believe the Feb-2024 Gmail/Yahoo bulk-sender requirements (DMARC at p=quarantine or stricter for senders >5000 messages/day to Gmail or Yahoo Mail) only apply to marketing-style senders; the myths spoke documents the per-domain-volume-aggregation rule where transactional traffic counts toward the 5000 msg/day threshold identically to marketing — high- volume transactional senders (every major e-commerce, SaaS platform, fintech operator) routinely exceed the threshold via password-reset + order-confirmation + shipping-status + 2FA-OTP combined daily volume per sending domain — debunking the operator's "transactional is exempt" mental model with the combined-per- domain-volume-aggregation operational truth that gates per- ESP-tenant deliverability to Gmail and Yahoo Mail this page's eight-ESP deployment catalogue is the publisher-side compliance instrument for. Read the myths-and- misconceptions spoke alongside this transactional-email-DMARC-deployment guide when onboarding new transactional senders, when escalating per-ESP deployment- decisions to non-technical stakeholders, or when correcting operator-side false-mental-models that drive incorrect ESP-selection / DKIM-CNAME-skip / alignment-skip decisions — the spoke is the canonical stakeholder-education reference whose four myth-debunking dimensions directly map to the per- ESP-deployment decisions THIS page's eight-transactional-ESP catalogue is the publisher-authoring instrument for.
• DMARC monitoring & reporting analysis - operational monitoring discipline including the weekly sender-inventory diff that catches ESP source-IP drift.
• Email deliverability fundamentals - the operational-outcome companion to this transactional-email page. Where this page documents transactional-sender DMARC authentication (DKIM via API-based ESPs, SPF include / 10-DNS-lookup budget, alignment configuration), the deliverability page documents the broader inbox-placement control stack that determines whether the password-reset / order-confirmation / receipt / shipping-status notification actually lands in the recipient's inbox within the sub-30-second window transactional senders commit to: IP reputation (Sender Score / Talos / Spamhaus ZEN), domain reputation (Google Postmaster Tools / Microsoft SNDS), FCrDNS (forward-confirmed reverse DNS — every mailbox provider rejects mail from IPs without it), Feedback Loop (FBL) registration, hard-bounce + complaint thresholds (the 0.1 % / 0.1 % Gmail + Yahoo 2024 sender-requirements floor), content filtering on transactional templates (greeting / unsubscribe header / plaintext-body parity), throttling / greylisting / tarpitting handling, and the engagement signals every mailbox provider feeds into inbox placement (open / click / forward / reply). Read the deliverability page when transactional mail authenticates correctly (DMARC pass at p=reject) but inbox-placement metrics still degrade — the deliverability page catalogues every beyond-DMARC operator control that the SaaS-ESP documentation rarely covers in one place.
• Email authentication explained - the cluster-intro pillar covering the full SPF + DKIM + DMARC + ARC + BIMI + MTA-STS + TLS-RPT + CAA ecosystem.
• Email authentication glossary - definitions for every term-of-art used on this page (alignment, organizational domain, PSL, RFC 5321 MAIL FROM vs RFC 5322 From:, DKIM selector, AUID, canonicalization, ARC-Seal).
• Email security glossary - the threat-and-defense vocabulary companion to the protocol glossary above. Transactional-email operators see specific threat-vocabulary concerns the glossary defines: BEC / CEO fraud / vendor email compromise (transactional notifications about invoices, payment-confirmations, password- resets, and shipping-status updates are the canonical BEC pretexts attackers clone — a transactional sender at p=reject blocks direct-domain spoof of its templates), clone phishing (the attack subclass that captures a legitimate transactional notification and replays it with substituted links — every transactional template should be threat-modelled against this), spear phishing targeting the ESP customer-success team (the canonical compromise vector into a dedicated-IP ESP tenant), credential harvesting via spoofed password-reset emails (the attack class transactional senders most often have their brand abused for), look-alike domains / typosquatting / homograph attacks (the registration patterns that route around DMARC enforcement on the legitimate transactional sending domain), OSINT / WHOIS / Shodan reconnaissance (the toolkit attackers use to enumerate which ESP an organisation uses before building a clone-phishing campaign), and the NIST IR lifecycle / indicators of compromise / dwell time vocabulary operators need to consume DMARC aggregate (RUA) reports as a security signal rather than a deliverability signal. Read the security glossary alongside this deployment guide before authoring the threat-model section of your transactional sending design.
• SPF explained - Sender Policy Framework (RFC 7208); the 10-DNS-lookup limit is a recurring concern for multi-ESP deployments (section 11.2).
• SPF DNS TXT-record byte syntax (RFC 7208 §3 tag-list grammar) — the TRANSACTIONAL-ESP-INCLUDE-TOKEN- PUBLICATION-AT-CUSTOMER-DOMAIN-APEX-AS-BYTE- LEVEL-SPF-DNS-TXT-RECORD-AUTHORING-DISCIPLINE companion to this transactional-email DMARC deployment reference. Where THIS page documents the transactional-ESP-side deployment workflow (the per-ESP DKIM signing-domain setup, the per-ESP custom- Return-Path subdomain authoring, the per- ESP feedback-loop registration, the per- ESP-published include: token the customer pastes into their apex SPF record), the SPF DNS syntax reference documents the BYTE-LEVEL AUTHORING DISCIPLINE the customer's authoritative DNS publication of that include: token must satisfy for every receiver-side per-message SPF evaluation across the customer's per-ESP 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 (receivers ignore records without it, collapsing the transactional sender's authorisation to spf=none); (ii) the byte- correct include: token spacing and ordering semantics whose per-receiver parser-tolerance determines whether the include resolves and the per-ESP outbound IP pool is recognised; (iii) the 255-octet per-character-string chunking rule that determines how the customer authors a multi-string SPF record when stacked per- ESP include: tokens combined with the per-tenant primary mailbox include: (e.g., include:spf.protection.outlook.com for M365 or include:_spf.google.com for Google Workspace) exceed a single TXT character-string — a recurring authoring scenario for B2B transactional senders combining a high-volume ESP with their enterprise mailbox provider 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 primary mailbox and a second SPF record for the transactional ESP separately) produces spf=permerror across every receiver evaluating the customer-domain From: authentication — the canonical transactional-sender defect class the per-ESP onboarding documentation must explicitly guard against. Read this WITH the transactional-email deployment reference when the per-ESP onboarding workflow's "merge our include: token into your apex SPF record" step moves to the customer's authoritative-DNS team: the transactional-email page documents WHICH ESP-published 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 forwarding issues (the second-hop break) — the AUTO-FORWARDED-BY-RECIPIENT-MAILBOX- RULE-AS-PRIMARY-FORWARDING-FAILURE-PATTERN- FOR-TRANSACTIONAL-MAIL companion documenting the recipient-side mailbox-rule auto- forwarding scenario (Gmail "Forwarding and POP/IMAP" to a personal Gmail address, Outlook / Exchange Online server-side rules that redirect to alternate domains, corporate- to-personal vacation forwarders, university- alumni @alumni.example.edu permanent-forward aliases) that is the SINGLE DOMINANT forwarding-loss pattern transactional ESP- egressed mail encounters in production because transactional mail (receipts, password-reset, security-alerts, invoices, shipping-notifications, account-activity emails) is precisely the mail class recipients most aggressively set up auto-forwarding rules to ensure they receive everywhere. Where THIS page documents the per-ESP TAG-VALUE-SELECTION CONSTRAINTS for transactional senders (SendGrid / Mailgun / SES / Postmark / SparkPost DKIM-CNAME- delegation patterns, the aspf=relaxed / adkim=relaxed identifier-alignment configuration, the per-ESP DMARC-record- publication discipline, the transactional- vs-marketing dual-record-publication strategy), the SPF-forwarding-issues spoke is the FORWARDING-FAILURE-CONSUMER companion documenting WHY transactional ESPs MUST architect their outbound mail to produce a DKIM-aligned-pass-survivable signature even when the recipient mailbox subsequently auto-forwards the message. The four-axis TRANSACTIONAL-ESP-VS-RECIPIENT-MAILBOX-RULE- FORWARDING comparison exposes the structurally- distinct AUTO-FORWARDED-BY-RECIPIENT roles: (i) transactional mail is more likely than marketing or bulk mail to be subjected to recipient-side mailbox-rule auto-forwarding because recipients aggressively configure forwarding to ensure they receive transactional notifications (password resets, security alerts, shipping updates) on multiple devices/addresses — the auto-forwarder rewrites the envelope MAIL FROM to the recipient mailbox's own domain, collapsing SPF-aligned-pass into SPF-aligned-fail at the final receiver; (ii) the transactional ESP's DKIM signature must survive the auto- forwarder's body modifications (no list-footer addition, but the auto-forwarder may add a Resent-From: header chain and re- wrap MIME boundaries) — the forwarding-issues spoke catalogues the body- modification patterns mailbox-rule auto- forwarders apply that determine whether the ESP's DKIM signature breaks at the body-canonicalization boundary; (iii) recipient-mailbox-rule forwarding is INVISIBLE to the transactional ESP's outbound Authentication-Results stream — the ESP only observes Authentication-Results at its own outbound MTA's egress point, never at the final auto-forwarded-to receiver; aggregate- report rows for forwarded delivery surface in a DIFFERENT recipient-domain's RUA than the ESP's outbound-monitored stream; (iv) p=reject rollout on a transactional domain produces measurable false-positive churn at recipients with mailbox-rule auto- forwarding — the rollout-gate criteria documented on this page MUST account for the legitimate-mail-collateral-damage rate the SPF-forwarding-issues spoke characterizes across the four canonical auto-forwarder classes (server-side rules vs client-side rules vs ESP-side legitimate forwarders vs catch-all-mailbox forwarders). Read the SPF- forwarding-issues spoke when architecting a new transactional sending domain's DKIM-CNAME- delegation and aspf/adkim relaxed-vs-strict configuration to ensure auto-forwarded transactional mail produces DMARC-pass-via- DKIM at the final receiver despite SPF-aligned- fail.
• SPF for Microsoft 365 — the TRANSACTIONAL-ESP-COHABITING-WITH- M365-CUSTOMER-DOMAIN-SPF-INCLUDE-LAYERING- DISCIPLINE-FOR-TRANSACTIONAL-RETURN-PATH- AUTHORING-AT-EXCHANGE-ONLINE-RECEIVE-BOUNDARY companion to this transactional-email DMARC deployment reference. Where THIS page documents the per-ESP TAG-VALUE-SELECTION CONSTRAINTS for transactional senders (SendGrid / Mailgun / SES / Postmark / SparkPost DKIM-CNAME-delegation patterns, the aspf=relaxed / adkim=relaxed identifier- alignment configuration, the per-ESP DMARC- record-publication discipline, the transactional-vs-marketing dual-record- publication strategy), the SPF-for- Microsoft-365 spoke is the M365-TENANT- CUSTOMER-SIDE-BASELINE companion documenting WHY transactional ESPs MUST coordinate their per-customer SPF include instructions with the customer's existing M365 SPF record AND the M365-tenant's Exchange Online MX boundary receive behaviour. The four-axis TRANSACTIONAL- ESP-VS-M365-SPF comparison exposes the structurally-distinct M365-TRANSACTIONAL- COHABITATION roles: (i) M365-tenant customers ALREADY have include:spf.protection.outlook.com consuming ~6 of the 10 lookup slots — the TIGHTEST baseline-lookup-headroom envelope among major mailbox-provider cohorts — a transactional ESP onboarding an M365-tenant customer faces only ~4 remaining lookup slots before permerror, vs ~6 for Workspace; the SPF-for-Microsoft-365 spoke documents the baseline spf.protection.outlook.com consumption profile (nested spfa/spfb/spfc cascade) that determines whether the transactional ESP's per-customer SPF include onboarding instruction is even feasible without first flattening or delegating to a subdomain — making M365 tenants the cohort most likely to need SPF-flattening + subdomain-delegation guidance in the ESP's onboarding email; (ii) M365-tenant transactional- mail recipients have the highest auto- forwarding configuration density of any mailbox-provider cohort because enterprise users routinely forward Outlook.com / Exchange Online mail to secondary personal mailboxes via Outlook "Inbox rules" + Exchange Online "Mail flow → Rules" + on-prem-hybrid Exchange transport-rule redirect — making the ESP's DKIM-aligned-pass-survival architecture documented above STRUCTURALLY-CRITICAL for M365-recipient-targeted transactional flows where SPF will collapse to SPF-aligned-fail after the M365-side auto-forward; the SPF-for- Microsoft-365 spoke documents the M365- side auto-forwarding configuration patterns the transactional ESP must architect against; (iii) transactional ESPs sending FROM an M365-tenant customer via SMTP- AUTH / Direct-Send / per-customer send-connector require per-customer envelope-MAIL-FROM coordination with the M365 SPF record — the transactional ESP's bounces.<customer> return-path subdomain authoring discipline must coexist with the customer's existing include:spf.protection.outlook.com publication; the SPF-for-Microsoft- 365 spoke documents the per-customer bounces-subdomain CNAME-vs-MX-vs-A- record authoring conventions transactional ESPs use to allocate return-path identity that aligns to the M365-tenant customer's apex domain; (iv) p=reject rollout on an M365-tenant transactional sending domain produces measurable false-positive churn at M365- recipient cohorts when the transactional ESP's per-customer SPF include is not coordinated with Exchange Online's spf.protection.outlook.com chain — the rollout-gate criteria documented on this page MUST account for the M365-tenant-customer cohort's tighter lookup-budget envelope AND M365-side auto-forwarder density the SPF-for-Microsoft-365 spoke characterizes. Read the SPF- for-Microsoft-365 spoke when onboarding an M365-tenant transactional customer — the spoke is the AUTHORITATIVE per-customer-side M365 SPF-authoring prerequisite that determines whether the transactional ESP's per-customer DMARC-aligned-pass population is even achievable for the M365 cohort, and the transactional ESP'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.
• SPF 10 DNS lookup limit and SPF flattening - the dedicated deep dive on the permerror-on-overlimit failure class. Transactional and marketing ESPs are the #1 contributor to SPF over-budget failures: each ESP include (sendgrid.net, spf.mailgun.org, _spf.salesforce.com, spf.constantcontact.com) costs 1-3 DNS lookups, and 4-5 senders cumulatively burn through the budget. Covers per-provider cost accounting, flattening tradeoffs, and the SPF subdomain delegation pattern (mail.example.com for ESPs, apex for corporate mail) — the canonical remediation for multi-ESP deployments.
• SPF PermError vs TempError — the TRANSACTIONAL-ESP-MULTI-INCLUDE-CHAIN- EXPANSION-PERMERROR-DOWNSTREAM-DIAGNOSTIC companion to this transactional-email DMARC deployment guide. Where THIS page documents the transactional-sender deployment workflow across ESP integrations (per-ESP SPF include-token publication, per-ESP DKIM CNAME-delegated signing-key publication, per- ESP envelope-from / header-from alignment coordination, per-ESP bounce / suppression / feedback-loop ingestion), the permerror-vs- temperror spoke is the focused per-code diagnostic reference transactional-mail operators consult when the per-ESP RUA evidence stream surfaces SPF-failure rows. Four per-transactional-ESP-per-code-root- cause dimensions: (i) PER-ESP-INCLUDE-CHAIN- EXPANSION-PERMERROR attribution (each production-ESP include expands to 5-7 downstream lookups on average — SendGrid's sendgrid.net include expands to ~7, Mailgun's spf.mailgun.org to ~5, Amazon SES's amazonses.com to ~3, Postmark's _spf.mtasv.net to ~3 — stacking three or more ESPs at the customer apex routinely exhausts the ten-query budget and produces PermError on EVERY transactional message; the spoke's lookup-audit workflow + per-ESP subdomain- delegation pattern esp1.example.com / esp2.example.com at the customer's apex is the canonical multi-ESP remediation reference), (ii) PER-ESP-MACRO- EXPANSION-PERMERROR attribution (RFC 7208 §7 macro-expansion failures in ESP-published include chains — invalid %{i} / %{s} / %{l} macro-letter combinations, recursive include: chains exceeding the nested expansion limit — all PERMANENT operator-side ESP-coordination remediation REQUIRING per-ESP support-channel escalation when the macro grammar is ESP-published-not- customer-published), (iii) PER-ESP-TEMPERROR- VIA-ESP-NAMESERVER-OUTAGE attribution (transactional ESPs publish their include chains via ESP-managed nameservers — Mailgun / SendGrid / Mailjet outages produce TempError on every customer using that ESP until the outage resolves; per-receiver per-source-IP correlation distinguishes self-resolving outages from persistent ESP- nameserver regressions REQUIRING per-ESP support-channel escalation), (iv) PER-ESP- PER-RECEIVER-INTERPRETATION-VARIANCE coordination (Gmail and Microsoft 365 both fail-OPEN on TempError but treat PermError as hard SPF-fail feeding DMARC evaluation per RFC 7489 §5.6.2 — multi-ESP transactional senders whose receiver mix spans both must factor per-receiver-interpretation variance into the per-ESP onboarding risk-assessment because adding a new ESP that pushes the include chain over budget silently cascades into legitimate-transactional-mail rejection at PermError-as-hard-fail receivers). Critical when this transactional- email guide's per-ESP deployment ramp reaches an SPF permerror or temperror symptom in the per-ESP RUA evidence stream — the spoke's per-code diagnostic ladder is the canonical next step in the transactional-ESP SPF-failure triage workflow.
• DKIM explained - DomainKeys Identified Mail (RFC 6376); the canonicalization deep dive informs the body-modification troubleshooting in section 13.2.
• DKIM alignment with DMARC — the TRANSACTIONAL-ESP-VS-D=-TENANT- ALIGNMENT-AUDIT companion to this transactional-sender (SendGrid, Mailgun, Postmark, Amazon SES, SparkPost, Mailchimp Transactional / Mandrill, Twilio SendGrid, Postmark Bounce) DMARC deployment reference. Where THIS page documents the transactional-sender DKIM-d=-cohabitation patterns at the per-ESP egress layer (ESP-default d=mail.<esp-domain> vs operator-configured d=<tenant-domain> via per-ESP CNAME-publication mechanics or DNS-zone-API-managed DKIM key provisioning), the DKIM-alignment-with- DMARC spoke documents the PER-MODE BYTE- SHAPE EVALUATION CONTRACT each per-tenant DKIM signature MUST satisfy for the receiver's DMARC-disposition verdict to fire dkim-aligned-pass: strict-alignment (adkim=s) requires byte-identical d=<tenant-domain> vs Header-From-tenant-domain (a strict- alignment publisher running an ESP-default d=mail.esp.com WILL produce dkim=pass but the DMARC verdict will fire dkim=unaligned); relaxed-alignment (adkim=r, the DMARC default) requires Organizational-Domain match per the PSL-anchored eTLD+1 algorithm (mail.tenant.com d= aligns with tenant.com Header-From under relaxed but not strict). The per-tenant operator- configured DKIM-publication step (CNAME per-ESP / DNS-zone-API per-tenant) IS the DKIM-alignment-prerequisite this guide's ESP-cohabitation troubleshooting depends on — without the DKIM-alignment-with- DMARC spoke a transactional-sender operator reading THIS page knows the ESP publishes a DKIM signature on their behalf, but not WHICH alignment-mode evaluation contract the per-tenant d= tag MUST satisfy for the per-receiver DMARC-disposition verdict to fire dkim-aligned-pass — this link closes that ESP-cohabitation-to-alignment- contract resolution gap at the per-ESP- per-tenant DKIM-d=-authoring-decision layer.
• DKIM-Signature header anatomy — the TRANSACTIONAL-ESP-PER-MESSAGE- DKIM-SIGNATURE-HEADER-BYTE-CORRECTNESS companion to this transactional-sender deployment guide. Where THIS page documents the per-message DKIM-d=-authoring-decision contract at the transactional-ESP signing boundary (SendGrid, Mailgun, SES, Postmark, Mandrill, Twilio SendGrid, Mailjet), 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 transactional message reaching the user's inbox. The TRANSACTIONAL-ESP-PER-MESSAGE-SIGNATURE- TAG-DELIVERABILITY-GATE cross-reference establishes FOUR structurally-distinct per-message DKIM-Signature-header deliverability-gate dimensions whose violation deflects time-sensitive transactional mail to spam-folder or produces outright reject — the worst-case outcome for OTP / MFA / password-reset / order-confirmation business utility: (i) d=-tag per-message tenant attribution correctness — the transactional ESP's per-customer signing service MUST emit d=<customer-organisational- domain> (not d=<esp-relay-domain> and not d=<esp-bounce-subdomain>) for each customer's transactional mail-stream so the receiver-side DKIM-Signature header anatomy documented by the spoke resolves the per-customer authoritative-domain attribution required for the customer-side DMARC adkim=r/s alignment THIS page documents as the deliverability prerequisite for transactional mail; (ii) s=-tag per-message selector correctness — the transactional ESP-imposed selector naming convention emits per-customer s= bytes that the receiver-side DKIM-verifier looks up at <s=>._domainkey. <d=> — a per-customer s= mismatch between signed-transactional-message header and customer-side DNS-publication produces dkim=permerror on the spoke's documented receiver-side parse contract, and per-OTP-message dkim=permerror spikes deflect OTP delivery to spam-folder during the OTP's 5-minute business-utility window — a deliverability-breaking outcome unique to time-sensitive transactional mail; (iii) h= and bh= per-OTP-message content-preservation correctness — the transactional ESP's per-message signing service MUST include From: and Subject: in the h= list (covering the receiver-MUA-displayed identity attribution AND the time-sensitive OTP / order-confirmation / password-reset subject-line content) AND emit a SHA-256 bh= body-hash that matches the canonicalized-body bytes the receiver-side DKIM-verifier recomputes — per-message h= coverage gaps (ESP forgets to include From: in h= for a customer's OTP 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 AT THE TIME the OTP / MFA / password- reset / order-confirmation message must deliver to be useful; (iv) b=-tag per-message signature bytes + a=-tag per-customer algorithm correctness + t=-tag per-OTP-message-timestamp correctness — the transactional ESP's per-customer 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 AND t=<unix-timestamp> whose per-OTP-message timestamp correctness affects DKIM-replay-attack defense (per the DKIM replay attacks spoke linked above) — per-customer a=-tag drift (ESP rotates from rsa-sha256 to ed25519-sha256 without per-customer-DNS-publication coordination) or per-OTP-message b= bytes computed against a stale private-key version breaks the spoke's documented receiver-side cryptographic-verification contract uniquely impacting time-sensitive transactional mail. Pair this page (the transactional-sender deployment guide) with the DKIM-Signature header-anatomy spoke (the per-message signature-header byte-grammar reference) when diagnosing a per-OTP / per-MFA / per-password-reset / per-order-confirmation deliverability failure on transactional- ESP-originated mail — the spoke documents the canonical compliant tag-list byte-layout whose violation at any of the FOUR per-message signature-tag- deliverability-gate dimensions produces the receiver-side verification failure that breaks the d=<customer-domain> alignment contract THIS page documents as the load-bearing time-sensitive transactional-mail deliverability prerequisite.
• DKIM replay attacks — the TRANSACTIONAL-OTP-MFA-PASSWORD-RESET- SHORT-LIFETIME-BOUNDS-REPLAY-WINDOW-FLOOR companion reference. Where THIS page documents the transactional-ESP deployment surface (SendGrid, Mailgun, Postmark, Amazon SES, SparkPost, Mailjet outbound relays signing per-tenant d= messages for one-time-passcode emails, password-reset confirmations, two-factor-authentication challenges, e-commerce order receipts, and appointment reminders), the DKIM-replay- attacks spoke documents the RFC 6376 §6.2.2 attack class in which an attacker captures a legitimately-signed transactional message from its receive-side delivery path and re- injects the byte-identical signed corpus either to (i) the same recipient with phish intent or (ii) different recipients with identity-theft intent. The TRANSACTIONAL- EMAIL-SPECIFIC CONNECTION is that the ATTACK-VALUE of a replayed OTP/MFA/password- reset message is structurally bounded by the BUSINESS-UTILITY WINDOW of the original time-sensitive payload: an OTP delivered at 09:00:00 with a 5-minute validity window ceases to have attacker-value at 09:05:01, a password-reset token typically expires at 15 minutes, a 2FA challenge at 30 seconds — producing a NATURALLY SHORT REPLAY WINDOW FLOOR that the transactional sender's DKIM operator-discipline must MATCH-OR-EXCEED via the RFC 6376 §3.5 x= expiration timestamp tag, the per-selector rotation cadence, the l=-tag avoidance (the body-length-limit tag is itself a replay-extension-attack vector — appending attacker-controlled content beyond l=<n> bytes preserves the signature), and the receiver-side DKIM- Signature header tracking documented on the DKIM-replay-attacks spoke. Transactional ESP operators MUST publish DKIM signatures with x= values tighter than the underlying business-utility window (typically 15-60 minutes for OTP/MFA pipelines, 24 hours maximum for password-reset and order- confirmation flows) — without x=, the signature is replay- valid indefinitely and the receiver-side DKIM verifier has no protocol-level signal to expire the signature, leaving only the application-layer business-window timestamp check (inside the OTP-bearing receiver application, not the receiving MTA) as the replay-mitigation surface. Read this before publishing DKIM x= tags on transactional mail-streams — the DKIM- replay-attacks page is the canonical RFC 6376 §6.2.2 attack reference whose mitigation primitives the transactional-sender DKIM- deployment discipline must internalize.
• Reverse DNS & PTR records - the IP-level outbound-identity proof. Transactional ESPs handle PTR for their shared-IP pools automatically (SendGrid sendgrid.net, Mailgun mailgun.org, Postmark pm-bounces.net, Amazon SES regional pools), but dedicated-IP customers — Amazon SES Dedicated IPs, SendGrid Pro / Premier Dedicated IPs, Postmark Dedicated IPs, SparkPost Dedicated IPs, Mailgun Dedicated IPs — must coordinate PTR with the ESP via the per-provider customer portal before sending live traffic, or face immediate delivery failure to Gmail (550-5.7.25), Microsoft 365 (550 5.7.1 Client host blocked), and Yahoo (553 5.7.1 [BL21]). The forward-confirmed-reverse-DNS (FCrDNS) validation rule requires PTR(ip) = hostname AND A(hostname) = ip in both directions. Amazon SES Dedicated IP Pool customers must explicitly submit a PTR-update request via AWS Support (per the SES Dedicated IPs documentation); SendGrid Dedicated IP customers configure em.example.com reverse DNS via the SendGrid Sender Authentication wizard. Missing PTR on a dedicated IP is a Day-0 production-outage cause for transactional senders.
• ARC explained - Authenticated Received Chain (RFC 8617); the alignment-preserving mechanism for forwarded mail discussed in section 4.4.
• BIMI explained - Brand Indicators for Message Identification; transactional senders with clean DMARC at p=reject are the canonical BIMI candidates.
• MTA-STS explained - SMTP transport security; complements DMARC by ensuring TLS to the destination receiver.
• TLS-RPT explained - SMTP TLS Reporting (RFC 8460).
• MTA-STS vs DANE for SMTP - the head-to-head COMPARISON of the two SMTP transport-security standards (RFC 8461 MTA-STS vs RFC 7672 DANE for SMTP). Read once authentication is running and you turn to transport security: transactional ESPs (SendGrid, Mailgun, Postmark, Amazon SES, SparkPost, Mailjet) overwhelmingly support MTA-STS on their outbound relays but rarely publish TLSA records for DANE, so the choice of standard for receivers depends on which ESPs you delegate sending to. The comparison documents the trust-model asymmetry (web-PKI vs DNSSEC), the RFC 7672 §1.3 coexistence rule (DANE preferred when TLSA validates; MTA-STS fallback otherwise), and the per-provider receiver-support matrix so senders can pick the standard that actually deploys against the dominant inbox-receiver landscape (Gmail, Microsoft 365, Yahoo, Apple iCloud).
• MTA-STS policy syntax — the PER-TRANSACTIONAL-ESP-COHORT-PER- DOMAIN-MTA-STS-POLICY-FILE-BODY-LINE- GRAMMAR-AUTHORING-DISCIPLINE companion reference. Where THIS page documents the transactional-email authentication deployment workflow (per-ESP-vendor include:<esp-spf-macro> SPF authoring per RFC 7208 §5.2, per-ESP-vendor DKIM CNAME-signing-key delegation, per-ESP-vendor DMARC RUA/RUF aggregation), the MTA-STS-policy-syntax spoke is the BYTE-SHAPE-OF-THE-POLICY- FILE-BODY reference documenting the RFC 8461 §3.2 line-grammar publishers instantiate at https://mta-sts.<domain>/.well-known/mta-sts.txt to extend the per-ESP-vendor authentication-discipline coverage to the TRANSPORT-LAYER receive-side MTA-STS policy. Four per-ESP-authoring dimensions the spoke addresses: (1) per-ESP-vendor inbound-MX hostname enumeration in the policy file's mx: allow-list — the SaaS-ESP transactional sender's publisher domain typically publishes ITS OWN MTA-STS policy listing the publisher domain's INBOUND MX (e.g. the corporate receiver behind the transactional-from- domain) rather than the ESP-vendor's OUTBOUND relays — but a co-located receive-and-send transactional deployment (publisher uses the same domain for both marketing-from and corporate-mail-to) requires the mx: allow-list to cover the corporate inbound MX hostnames Microsoft 365 / Google Workspace / Amazon WorkMail / Zoho Mail present at the publisher's MX records; (2) mode progression discipline for transactional publishers — the transactional-publisher's deployment cadence requires mode: testing during initial publication so the TLS-RPT aggregate-evidence stream surfaces per-receiver per-day TLS failures WITHOUT blocking transactional delivery, followed by mode: enforce after the TLS-RPT failure rate falls below the publisher's risk-tolerance threshold — the spoke documents the per-mode behaviour difference at sender-MTA enforcement time and the operational coupling between the publisher's MTA-STS mode flip and the per-ESP-vendor DKIM-aligned- pass-rate floor; (3) max_age cache-TTL choice for transactional publishers — the publisher's per-month per-ESP- vendor cutover cadence (adding a new transactional-ESP vendor mid-month, decommissioning a legacy ESP vendor, cross-vendor migration) determines the max_age: seconds value published — too-long means stale receiver-MTA caches retain obsolete allow-lists during cutover; too-short means receivers re-fetch the policy daily — the spoke documents the cache- TTL bounds-check RFC 8461 §3.2 imposes on the publisher's cutover-cadence scheduling; (4) _mta-sts.<domain> TXT-record id= versioning — the policy file body changes (new ESP-vendor inbound-MX added, mode flip, max_age tightening) must be paired with an id= bump in the _mta-sts.<domain> TXT-record so receivers respecting the policy detect the change and invalidate their cached copy — the spoke documents the id=-keyed cache- invalidation contract receivers implement against the publisher's policy file body. Read the MTA-STS-policy- syntax spoke alongside this page when scoping the per-transactional-ESP-cohort TRANSPORT-LAYER deployment — the publisher's MTA-STS policy file body grammar is the load-bearing cross-protocol coordination surface between the per-ESP-vendor DKIM-signing discipline THIS page documents and the receive-side TLS-enforcement-coverage guarantee RFC 8461 §3.2 byte-grammar delivers.
• CAA records explained - Certification Authority Authorization (RFC 8659).
• DMARC for Google Workspace - the companion deployment guide for corporate mail when employees send via Workspace.
• DMARC for Microsoft 365 - the companion deployment guide for corporate mail on M365.
• DMARC for Hybrid Exchange (on-prem + M365) - the hybrid-topology companion to the cloud-only M365 guide. Transactional ESPs (SendGrid, Mailgun, Postmark, Amazon SES, SparkPost, Mailjet) routing through a hybrid Exchange topology produce the canonical dual-signer DKIM + relay-loop problem documented on that page: the ESP signs at the API edge, then either Exchange Online or the on-prem Edge Transport re-signs with a different key OR the Default Frontend Connector strips the signature before re-delivery. NDR 5.4.6 relay loops surface when the connector topology cycles transactional mail back through the same hop. Read when your transactional alignment passes at the ESP boundary but fails at the corporate mailbox endpoint.
• DMARC for cPanel & Shared Hosting - the companion deployment guide for cPanel outbound mail (when your hosting also sends mail).
• DMARC for Shared Hosting: Plesk, DirectAdmin, ISPConfig - the companion deployment guide for non-cPanel shared hosting; the SaaS-relay CNAME-delegated DKIM escape hatch in section 5b of that page is the same pattern documented here.
• Multi-domain DMARC strategy - the TRANSACTIONAL-ISOLATION-PORTFOLIO-CONSTRAINT companion to this transactional-email deployment guide. Where THIS page documents the PER-ESP authentication stack (DKIM via API-based ESPs, SPF include / 10-DNS-lookup budget, alignment configuration, ESP-bounce- domain pattern), the multi-domain- strategy spoke documents the PORTFOLIO-COORDINATION decision framework that becomes load-bearing the moment a transactional sender adopts the canonical SUBDOMAIN-ISOLATION pattern the Gmail / Yahoo / Microsoft 2024 sender- guidelines effectively codify: transactional mail on a separate sending subdomain from corporate mail from marketing mail. The subdomain-isolation pattern produces a 3-to-5-domain portfolio per operator: (i) the apex (example.com) for corporate Workspace / M365 employee mail with its own _dmarc.example.com at p=reject + sp=reject, (ii) the transactional subdomain (mail.example.com or t.example.com) for the password-reset / receipt / order- confirmation / shipping-notification stream sent via SendGrid / Mailgun / Postmark / Amazon SES with its own _dmarc.mail.example.com record at p=reject, (iii) the marketing subdomain (news.example.com) for Mailchimp / Klaviyo / HubSpot / Marketo / Salesforce Marketing Cloud bulk-sending with its own _dmarc.news.example.com at p=reject, (iv) the bounces subdomain (bounces.example.com) for the ESP-managed Return-Path / RFC 5321 MAIL FROM authentication domain that the operator delegates the MX for to the ESP, (v) optional per-product subdomains (support.example.com, billing.example.com) for operators with multi-product SaaS operations whose per-product transactional streams need independent reputation isolation. The multi-domain spoke documents the load-bearing Public Suffix List (PSL) organisational-domain boundary that governs which transactional subdomains the apex's sp= tag actually covers (every subdomain under the apex's registered organisational-domain is covered by the apex's sp=), the np= tag (RFC 9091) for explicit non-existent-subdomain policy that hardens the apex-organisational-domain surface against attacker-spoofing of invented-subdomain rendezvous addresses, and the per-transactional-subdomain independent ramp the operator runs in parallel to the apex's ramp (each subdomain's p=none → p=quarantine → p=reject ramp is independently scheduled because each sends through a STRUCTURALLY-DIFFERENT authentication stack — apex via Workspace / M365, mail.* via SendGrid, news.* via Mailchimp, bounces.* via the ESP's bounce- processing infrastructure). Read the multi-domain spoke at the moment of publishing the SECOND DMARC record in the portfolio — the portfolio-coordination decision framework is the load-bearing reference for the transactional-email subdomain-isolation pattern that modern bulk-sender requirements effectively mandate.
• DMARC for SaaS senders - the TRANSACTIONAL-VS-MARKETING- SAAS-SENDER-COMPLEMENT companion to this transactional-email DMARC deployment guide. Where THIS page documents the API-driven per-message transactional send pattern (SendGrid, Mailgun, Postmark, Amazon SES) where each outgoing message is a distinct HTTP POST committing to a sub-30- second password-reset / order- confirmation / shipping-status delivery SLA, the SaaS-senders spoke documents the SIBLING multi-tenant marketing-automation pattern (HubSpot, Mailchimp, Marketo, Pardot, Constant Contact, Salesforce Marketing Cloud, Klaviyo, Iterable, Braze) where the SaaS platform schedules and sends BATCH campaigns from a shared platform-owned outbound IP pool with per-tenant DKIM-CNAME delegation + per-tenant SPF-include authorisation. The two patterns share the same underlying DMARC-alignment infrastructure (the customer's d= domain in the DKIM-Signature must align with the RFC 5322 From: domain for DMARC pass; the customer's SPF record must include: the platform's authorisation token) but differ on operational cadence (transactional: 24/7 per-event push; marketing: scheduled campaign blasts) and on the BULK-SENDER-REQUIREMENTS consumer-side compliance surface (marketing-automation tenants face the Feb 2024 Gmail / Yahoo / Apple unsubscribe-header / complaint-rate / domain-reputation requirements at much higher scrutiny than per- message transactional senders). Read the SaaS-senders spoke alongside this page when an operator's outbound mail flow includes BOTH transactional (THIS page) AND marketing-automation (SaaS-senders spoke) channels and the operator needs to author a per-channel sender-inventory entry for the DMARC RUA-report reconciliation workflow this page documents in section 8.
• DKIM for Microsoft 365 - the TRANSACTIONAL-ESP-VS-M365- EXCHANGE-ONLINE-DUAL-DKIM-SIGNING-AT- EGRESS-AND-RELAY-BOUNDARY companion reference. Where THIS page documents the transactional-ESP DKIM-publication and DMARC-alignment workflow (per-ESP d= signing domain, CNAME delegation of the ESP's selector, RUA aggregate report monitoring of per-ESP alignment-pass rates), the DKIM-for-Microsoft-365 spoke documents the EXCHANGE-ONLINE-TENANT-SPECIFIC DKIM publication mechanics that produce a SECOND DKIM signature on any transactional message routed through Exchange Online's connector- relay path (a common topology when the organisation's primary mail infrastructure is M365 but a third-party ESP handles transactional sends). The receiver sees TWO DKIM- Signature headers — the ESP's d=mail.esp.example signature applied at the ESP egress, AND Microsoft's d=<tenant-domain> signature applied at the Exchange Online relay boundary via the selector1/selector2 tenant CNAME infrastructure — the latter is what produces DKIM-alignment on the organisation's protected domain even when the ESP's d= is a non-aligned shared signing domain. Read the M365-DKIM spoke alongside this page when designing the transactional-ESP integration on a domain whose primary mail infrastructure is M365 — the Microsoft-relay-applied DKIM is the DMARC-alignment-producing path when the ESP itself signs with a non-aligned shared signing domain.
• DKIM for Google Workspace - the TRANSACTIONAL-ESP-VS-GOOGLE- WORKSPACE-SMTP-RELAY-DUAL-DKIM-SIGNING- AT-EGRESS-AND-RELAY-BOUNDARY companion reference. Where THIS page documents the transactional-ESP DKIM-publication and DMARC-alignment workflow (per-ESP d= signing domain, CNAME delegation of the ESP's selector, RUA aggregate report monitoring of per-ESP alignment-pass rates), the DKIM-for-Google-Workspace spoke documents the WORKSPACE-TENANT- SPECIFIC DKIM publication mechanics that produce a SECOND DKIM signature on any transactional message routed through Google Workspace's SMTP-relay path (a common topology when the organisation's primary mail infrastructure is Workspace but a third-party ESP handles transactional sends — Workspace's SMTP-relay service documented at smtp-relay.gmail.com applies the tenant's configured DKIM signing before egressing to Internet receivers). The receiver sees TWO DKIM-Signature headers — the ESP's d=mail.esp.example signature applied at the ESP-egress, AND Google's d=<tenant-domain> signature applied at the Workspace SMTP-relay boundary via the OPERATOR- published <selector>._domainkey.<domain> TXT record (operator-generated key, operator-controlled rotation, manual single-selector model — distinct from M365's CNAME-delegation tenant-managed key infrastructure). The latter is what produces DKIM-alignment on the organisation's protected domain even when the ESP's d= is a non-aligned shared signing domain. Read the Workspace-DKIM spoke alongside this page when designing the transactional- ESP integration on a domain whose primary mail infrastructure is Google Workspace — the Workspace-relay-applied DKIM is the DMARC-alignment-producing path when the ESP itself signs with a non-aligned shared signing domain, AND the operator-controlled key custody model means the operator (not Google) owns the key rotation cadence for the SMTP-relay signature.
• SPF qualifiers explained - the TRANSACTIONAL-EMAIL-HIGH-VOLUME- SINGLE-VENDOR-ESP-INTEGRATION-ALL- MECHANISM-QUALIFIER-POSTURE companion reference. Where THIS page documents the transactional-email-ESP integration architecture (operator delegates a transactional-mail-flow subdomain to a single ESP / operator inventories the complete authorised-IP space of that ESP via the ESP's published SPF macro / operator publishes a tight per- transactional-subdomain SPF record covering ONLY the ESP's macros), the SPF-qualifiers spoke documents the FOUR RFC 7208 §4.6.2 QUALIFIER PREFIXES and the load-bearing all-mechanism qualifier choice that is OPERATIONALLY EASIEST to TIGHTEN to -all Fail in the transactional-email use case compared to mixed-flow primary-mail- domain deployment. Transactional-email single-vendor ESP integration is the canonical SPF use case where -all SHOULD be the deployment-day-1 default, because the per-subdomain authorised-IP-space is FULLY KNOWABLE from the ESP's published SPF macro plus the operator's own MTA IP range (if any) — there is NO LATENT DARK-MATTER authorised-sender population the way there is in the operator's primary @<organisation>.com domain where forgotten-vendor integrations, departmental shadow-IT senders, and ESP-provider migrations create authorised-sender-inventory uncertainty. The transactional- subdomain SPF record can ship with -all on deployment-day-1 with high confidence that no legitimate transactional mail-flow will be inadvertently rejected, because the ESP is the SINGLE AUTHORISED SENDER for the subdomain by architectural construction. The qualifier spoke also documents the anti-pattern where transactional ESPs recommend ~all in their getting-started documentation (rationally hedging against customer- support cost of -all rejecting customer's own mail) — for transactional-subdomain deployments operators SHOULD override the ESP's recommendation and tighten to -all because the architectural-construction guarantee of single-vendor authorisation STRUCTURALLY ELIMINATES the ~all-recommendation-rationale. Read the qualifier spoke alongside this page when authoring the SPF section of the transactional-subdomain deployment plan — the -all choice is the operationally-tight default for transactional-subdomain SPF that is rarely articulated as a deliberate choice in ESP-provider getting-started documentation.
• BIMI VMC certificates deep dive - the TRANSACTIONAL-BRANDED- RECEIPT-NOTIFICATION-BIMI- DISPLAY-VMC-PRECONDITION companion reference. Where THIS page documents the transactional-email DMARC deployment playbook (per- transactional-subdomain SPF with -all hard- fail qualifier, single-vendor DKIM signing with per-ESP selector, DMARC p=reject on the transactional subdomain — the deployment- day-1-defensible posture for high-volume single-vendor ESP integrations), the BIMI-VMC-certificates spoke is the authoritative reference for the DOWNSTREAM BRANDED-INBOX- INDICATOR DISPLAY ENABLEMENT step transactional senders SHOULD pursue immediately after the DMARC p=reject rollout is complete and the per-vendor aggregate-report feed is healthy. The transactional-subdomain mail- flow is the CANONICAL BIMI- DISPLAY-TARGET POPULATION because: (i) recipients ACTIVELY OPEN transactional receipts / shipping- confirmations / 2-factor- authentication codes / account-state notifications (vs marketing email which recipients increasingly archive without reading); (ii) the branded-inbox indicator dramatically improves the receipt- recognition signal (recipients confidently distinguish a legitimate Amazon-order- confirmation from a phishing Amazon-impersonation when the legitimate one carries the verified Amazon mark and the phishing one does not); (iii) the deployment- day-1 DMARC p=reject posture this page documents is the BIMI-MINIMUM-POLICY- PRECONDITION (BIMI requires p=quarantine or p=reject at the publisher's apex domain). The VMC certificate is an EXTENDED- VALIDATION X.509 certificate issued by one of two currently-operating VMC- issuing CAs (DigiCert and Entrust) binding the publisher's TRADEMARK- REGISTERED MARK to the publisher's DOMAIN per the publisher's BIMI-RECORD- DECLARED l= SVG-URI authoring step. Transactional senders operating on per-vendor subdomains (typically orders.<domain> / receipts.<domain> / notifications.<domain> / auth.<domain>) face the VMC-procurement SCOPE QUESTION: whether to procure ONE apex-domain VMC and rely on receiver-side BIMI organisational-domain fallback, OR procure per-subdomain VMCs for the transactional subdomains carrying the highest- recipient-engagement traffic — the VMC-certificates spoke catalogues both deployment topologies with per-receiver compatibility notes. Read the BIMI-VMC- certificates spoke alongside this transactional- email page when authoring the post-DMARC-rollout observability-and-display roadmap — the transactional- subdomain mail-flow this page hardens at the authentication layer is the CANONICAL BIMI-DISPLAY-TARGET for the brand-conversion- metric-improvement BIMI provides.
• DKIM canonicalization — the TRANSACTIONAL-ESP-PER-MESSAGE- MUTATION-PIPELINE-CANONICALIZATION-CHOICE companion to this transactional-email DMARC deployment reference. Where THIS page documents the high-volume single- vendor ESP integration pattern (Mailchimp / SendGrid / Mailgun / Postmark / SparkPost / Amazon SES API-driven send paths) + per-tenant DKIM selector publication + bounce-domain CNAME delegation, the DKIM-canonicalization spoke is the PER-MESSAGE BODY-AND-HEADER canonicalization choice whose `c=` tag value (the four RFC 6376 §3.4 combinations: `simple/simple`, `simple/relaxed`, `relaxed/simple`, `relaxed/relaxed`) is the load-bearing DKIM-signature SURVIVAL primitive at FOUR per-ESP mutation classes the transactional- ESP-signed message traverses before reaching the receiver's inbox: (i) ESP TRACKING-PIXEL + LINK-WRAPPING INJECTION at the per-message ESP egress layer modifies the message body POST-DKIM- SIGNING when the ESP runs its open-tracking and click-tracking instrumentation — many ESPs (Mailchimp, SendGrid, Mailgun, HubSpot) inject a per-message 1x1 transparent GIF tracking pixel for open tracking AND wrap every clickable URL in a per-recipient redirector URL (`https://click.<esp>.com/.../<tracking-id>`) AFTER per-template rendering but BEFORE DKIM signing — the ESP must therefore sign the FINAL post-instrumentation body, but if the ESP's instrumentation runs per-recipient (per-message customisation) the signing canonicalization choice determines whether per-recipient body variants share a single signature or require per-recipient resigning; (ii) ESP PER-RECIPIENT PERSONALISATION-MERGE-FIELD SUBSTITUTION produces per-recipient body bytes that must be signed AFTER substitution — when the operator's per-message API request payload uses ESP merge-field syntax (e.g. SendGrid's `{{first_name}}`, Mailchimp's `*|FNAME|*`, Mailgun's `%recipient.first_name%`), each delivered message has a different body byte sequence; the ESP must sign per-recipient (no signature reuse across recipients possible), and the canonicalization choice determines whether body modifications introduced by downstream forwarders (mailing-list, alias- redirect, SaaS-tenant filtering) survive the receiver's verification; (iii) ESP UNSUBSCRIBE-LINK INJECTION at the per-tenant compliance layer adds the RFC 8058 `List-Unsubscribe` header AND a per-recipient unsubscribe URL in the message body POST-DKIM-SIGNING when the ESP enforces CAN-SPAM / GDPR / CASL compliance — the `List-Unsubscribe` and `List-Unsubscribe-Post` headers MUST be in the signed `h=` list for the receiver's one-click-unsubscribe button-click to succeed (Gmail / Yahoo Feb 2024 bulk-sender requirements); the canonicalization choice determines whether the receiver's downstream intermediary modifications to these headers (mailing-list rewrite, forwarder header-modification) survive DKIM verification; (iv) RECEIVER- SIDE MIME-PART RE-ENCODING + Content-Transfer-Encoding RE-ENCODING at the per-receiver inbox-pipeline layer MUTATES THE MESSAGE BODY POST-DKIM-SIGNING for messages routed through certain anti-spam appliances or per-tenant content-filters — when a receiver re-encodes 8bit-MIME message parts to 7bit / Quoted-Printable / Base64 (RFC 2045 §6 transfer-encoding) for downstream intermediary compatibility, the body byte sequence changes — `c=*/simple` body canonicalization fails verification; `c=*/relaxed` body canonicalization may or may not survive depending on the specific re-encoding; per RFC 6376 §3.4 the canonicalization choice is the operator's survival-vs-strict-integrity tradeoff. Read the DKIM-canonicalization spoke alongside this transactional-email DMARC deployment reference when authoring the per-tenant ESP integration's DKIM-signing configuration — the spoke is the canonical RFC 6376 §3.4 reference whose four canonicalization combinations determine the transactional-ESP-signed message's per-receiver DKIM-pass rate against the per-message ESP mutation pipeline + the receiver-side intermediary mutation pipeline this page's tenant-deployment topology together produce.
• Business Email Compromise (BEC) defence — the financial-loss threat scenario whose most lucrative pretexts (fake invoice, fake shipping update, fake password reset, fake 2FA prompt) impersonate exactly the transactional-email categories this page catalogues. DMARC enforcement at p=reject on the transactional sending domains documented here is the load-bearing application-layer defence that prevents an attacker from spoofing a legitimate ESP-signed transactional message the recipient is conditioned to trust.
• How attackers bypass weak DMARC — the TRANSACTIONAL-ESP-VENDOR- COMPROMISE-AS-VENDOR-EMAIL-COMPROMISE- BYPASS-CLASS-AT-FOUR-TRANSACTIONAL- ESP-EGRESS-PATH-VS-22-TECHNIQUE-BYPASS- CATALOGUE-COVERAGE-DIMENSIONS companion to this transactional-email deployment reference. Where THIS page documents the eight canonical transactional-ESP deployments (SendGrid, Mailgun, Amazon SES, Postmark, Mailjet, SparkPost, Mandrill, Resend) and the per-customer DKIM-CNAME-delegation discipline, per- ESP-pool include: cascade, per-customer return-path bounce-domain delegation, and per-message t=/x= replay-protection that defines the publisher-side authentication discipline for time-sensitive OTP / MFA / password- reset / order-confirmation messages, the attacker-bypass spoke is the OFFENSIVE- PERSPECTIVE 22-TECHNIQUE-CATALOGUE companion documenting which transactional- ESP-specific attack vectors the per-ESP publication discipline THIS page documents must defeat. Concretely, the spoke documents FOUR transactional-ESP- egress-path vs 22-technique-bypass- catalogue coverage dimensions: (i) per-ESP-vendor account-takeover producing LEGITIMATE customer-domain DKIM-CNAME-signed forged-payload traffic — the attacker-bypass spoke documents how a compromised transactional-ESP customer-account (credential phishing of the ESP web- portal login, API-key exfiltration from a leaked .env file) emits forged- payload mail through the customer- domain's own CNAME-delegated DKIM signing infrastructure — the per- message DKIM verification produces dkim=pass aligned with the customer-domain and DMARC p=reject CANNOT block the attack — the attacker-bypass spoke names this as authentication-evasion- class technique #11 (vendor-account- takeover at the application-layer signer) and provides the SOC analyst with the per-ESP-vendor account- security audit and credential-rotation cadence mitigation pathway; (ii) per-ESP-pool shared-IP-cohort SPF-pass extension to co-tenant adversaries — the attacker- bypass spoke documents how a publisher who appends include:<esp-pool> to their SPF record without per-ESP IP-pool audit cryptographically extends the SPF-pass verdict to every co-tenant in the shared ESP outbound pool — when a co-tenant is compromised or runs a sub-tenanted reseller business serving adversaries, the per-source-IP spf=pass verdict aligns with the customer-domain's envelope- MAIL-FROM rewrite — the attacker-bypass spoke names this as alignment-evasion- class technique #5 (shared-IP-pool co- tenant SPF-pass extension) and provides the SOC analyst with the per-ESP-pool per-publisher per-tenant reputation audit and per-customer dedicated-IP mitigation pathway; (iii) per- ESP CNAME-delegation race during DKIM key rotation producing transient attacker-controllable key-substitution window — the attacker-bypass spoke documents how a transactional- ESP-managed DKIM key rotation that coordinates new key publication BEFORE the customer-domain's per-resolver- cache positive-cache window has aged out creates a per-receiver transient window where the receiver-fetched key bytes diverge from the per-message signing key — an attacker with receiver-resolver-cache control can substitute attacker-controlled key bytes during the rotation window — the attacker-bypass spoke names this as infrastructure-evasion-class technique #20 (transient-rotation-window substitution) and provides the SOC analyst with the dual-selector overlap- window publication-discipline mitigation pathway; (iv) per- message t=/x= replay-protection tag-absence producing receiver-side replay-attack bypass surface — the attacker-bypass spoke documents how a transactional-ESP that does NOT emit t= (signature-timestamp) and x= (signature-expiry) tags on per-message DKIM signatures produces messages susceptible to RFC 6376 §6.2.2 replay attacks — an attacker who captures a legitimate password-reset / OTP message can re-emit it days/weeks later and the receiver-side cryptographic verification still produces dkim=pass — the attacker- bypass spoke names this as authentication-evasion-class technique #10 (DKIM-replay-attack via missing- t=/x=-tags) and provides the SOC analyst with the per-ESP per-message signature-tag- publication audit mitigation pathway. Read the attacker-bypass spoke ALONGSIDE this transactional-email deployment reference to understand which per-ESP-egress-path attacker- bypass technique class each transactional-ESP-specific publication discipline THIS page documents structurally defeats vs structurally leaves open as a residual attack vector — the spoke is the AUTHORITATIVE offensive-perspective catalogue the per-ESP publication discipline THIS page documents is the publisher-side defense against.
• DMARC reporting pipeline — the PER-TRANSACTIONAL-ESP-SOURCE-IP- RUA-SEGMENT-AS-LOAD-BEARING-PUBLISHER- SIDE-PER-ESP-DELIVERABILITY- OBSERVABILITY-EVIDENCE companion to THIS transactional-email DMARC reference. Where THIS page documents the per-transactional-ESP authentication- publication discipline (SendGrid / Mailgun / Postmark / Amazon SES / SparkPost / Mandrill / per-ESP include:-cascade publication, per-ESP CNAME-delegated DKIM selector chain, per-ESP custom-Return-Path subdomain), the DMARC-reporting-pipeline spoke is the receiver-side TELEMETRY infrastructure documenting how the rua-aggregate-XML stream partitions the per- transactional-ESP source-IP segment at FOUR per-transactional-ESP-to-rua- segment-attribution dimensions: (i) per-transactional-ESP source-IP pass-rate rua-segment — the reporting-pipeline spoke documents how the rua-aggregate-XML per-row source_ip field partitions the per-ESP source-IP pool (SendGrid 167.89.0.0/17, Mailgun 69.72.32.0/19, Postmark 184.173.0.0/16, Amazon SES per-region IP pools) into the per-ESP per-source-IP pass-rate evidence the per-ESP deliverability decision THIS page's per-ESP publication discipline depends on; (ii) per-transactional-ESP DKIM d= attribution rua-segment — the reporting- pipeline spoke documents how the rua-aggregate-XML auth_results.dkim.domain field surfaces the per-ESP CNAME- delegated DKIM d= attribution that the per-ESP signing-identity inventory THIS page documents depends on; (iii) per-transactional-ESP SPF MAIL-FROM-alignment rua-segment — the reporting-pipeline spoke documents how the rua-aggregate-XML per-row auth_results.spf.domain field surfaces the per-ESP custom- Return-Path subdomain SPF alignment that the per-ESP envelope-MAIL-FROM publication discipline THIS page documents depends on; (iv) per-transactional-ESP unauthorised-sender shadow-IT discovery rua-segment — the reporting-pipeline spoke documents how the rua-aggregate-XML per- source-IP discovery feed surfaces un-inventoried transactional-ESP senders (shadow-IT marketing teams, forgotten test-environment ESP accounts, leftover post-migration ESP credentials) the per-ESP publication-inventory THIS page's per-ESP discovery workflow depends on. Read THIS page when ARCHITECTING the per-transactional- ESP authentication-publication discipline; read the DMARC- reporting-pipeline spoke when ARCHITECTING the rua-stream infrastructure that surfaces the per-ESP source-IP / DKIM d= / SPF MAIL-FROM- alignment / shadow-IT-discovery evidence the per-ESP publication discipline THIS page documents depends on.
• BIMI SVG Tiny PS requirements - the PER-PUBLISHER-PER-TRANSACTIONAL- DOMAIN-DISPLAY-LAYER-LOGO-PUBLICATION- PRIMITIVE-AT-THE-HIGHEST-BRAND-VALUE- INBOX-RENDER-USE-CASE companion to this transactional-email reference. Where THIS page documents the per-publisher per-transactional-domain SPF / DKIM / DMARC publication discipline (per-ESP signing-platform DKIM d= publication, per-publisher per- transactional-domain SPF-include of per- ESP infrastructure, per-publisher per- transactional-domain DMARC p=quarantine|reject + per- ESP-rua publication, per-publisher per- ESP signing-infrastructure DKIM-alignment discipline for per-message DMARC-aligned- pass on transactional mail-streams), the BIMI-SVG-Tiny-PS-requirements spoke is the per-publisher per-transactional- domain display-layer publication- discipline reference whose per-publisher per-transactional-mail-stream BIMI- display-eligibility is the LOAD-BEARING downstream commercial-conversion KPI for the per-publisher per-transactional- domain publication discipline THIS page documents at FOUR per-publisher per- transactional-mail-stream BIMI-display- eligibility coupling dimensions: (i) per-publisher per-transactional- domain p=quarantine or p=reject + per-message DMARC-aligned-pass as load-bearing BIMI- display-eligibility prerequisite for high-value transactional mail-streams (receipts / order confirmations / shipping notifications / password resets / 2FA codes / account-security alerts) - per RFC 9077 §3, BIMI display- eligibility requires per-publisher per- domain DMARC enforcement at p=quarantine or p=reject plus per-message DMARC-aligned-pass; per-publisher per- transactional-domain enforcement posture the per-publisher per-transactional- domain publication discipline THIS page documents establishes is the LOAD- BEARING per-publisher per-transactional- domain BIMI-display-eligibility prerequisite for the canonical highest- commercial-value brand-trust inbox- render use cases (per-publisher per- transactional-mail-stream receipts, order confirmations, shipping notifications, password resets, two-factor authentication codes, account-security alerts, payment receipts) where per-publisher per- transactional-domain BIMI logo display drives per-recipient brand-trust + open- rate + click-through-rate + perceived legitimacy at the moment of per-message inbox triage; (ii) per-publisher per-transactional-ESP (SendGrid / Postmark / Mailgun / Amazon SES / Mandrill / SparkPost) signing- infrastructure DKIM-pass-rate as upstream determinant of per-publisher per-transactional-mail-stream BIMI- display-coverage - per- publisher per-transactional-ESP signing- infrastructure per-message DKIM-aligned- pass-rate the per-publisher per-ESP d=-tag publication discipline THIS page documents produces is the LOAD-BEARING upstream determinant of per-publisher per-transactional-mail- stream BIMI-display-eligibility - per- publisher per-ESP signing-infrastructure DKIM-pass-rate variance directly collapses per-publisher per- transactional-mail-stream BIMI-display- coverage at the per-receiver inbox render boundary the per-publisher per- transactional-domain SVG Tiny PS profile the BIMI-SVG-requirements spoke documents the publisher operationalised publication of; (iii) per- publisher per-transactional-domain BIMI SVG Tiny PS publication as load-bearing per-publisher per-transactional-mail- stream brand-trust signal at the order- confirmation / shipping / password- reset / receipt inbox-render layer - per-publisher per-transactional-domain BIMI SVG Tiny PS profile publication (the l=<svg-url> tag publication in per-transactional-domain BIMI DNS record pointing to HTTPS-served Tiny PS SVG matching the per-publisher per-transactional-domain brand logo) operationalises the per-publisher per- transactional-mail-stream brand-trust display-layer signal at Gmail + Apple Mail + Yahoo + Fastmail inbox triage boundary - per-publisher per- transactional-mail-stream BIMI logo rendering in the inbox-triage envelope- preview surface produces measurable per- publisher per-transactional-mail-stream brand-recall lift, open-rate lift, click-through-rate lift, phishing- suspicion reduction, and password-reset / 2FA-code per-message-authenticity confidence lift; (iv) per- publisher per-transactional-mail-stream BIMI-display-coverage as load-bearing per-publisher commercial-conversion KPI downstream of per-publisher per- transactional-domain publication discipline - per-publisher per- transactional-mail-stream BIMI-display- coverage KPI directly drives per- publisher per-transactional-mail-stream commercial-conversion KPI suite (per- order-confirmation per-recipient open- rate driving per-order post-purchase engagement, per-shipping-notification per-recipient open-rate driving per- delivery customer-support load reduction, per-password-reset per- recipient open-rate driving account- recovery success-rate, per-2FA-code per- recipient open-rate driving per-account security-posture compliance) the per- publisher per-transactional-domain publication discipline THIS page documents operationalises - per- publisher per-transactional-mail-stream BIMI-display-coverage variance directly drives per-publisher per-transactional- mail-stream commercial-conversion KPI variance the per-publisher per- transactional-domain publication discipline THIS page documents produces. Read the BIMI-SVG-requirements spoke alongside this transactional- email reference when planning per- publisher per-transactional-domain BIMI deployment whose per-message display- eligibility is directly gated by the per-publisher per-transactional-domain SPF / DKIM / DMARC publication discipline THIS page documents establishes, and when investigating per-publisher per-transactional-mail- stream BIMI-display-coverage variance whose upstream root-cause is per- publisher per-transactional-ESP signing- infrastructure per-message dkim-pass- rate variance or per-publisher per- transactional-domain DMARC enforcement- posture publication discipline the per- publisher per-transactional-domain publication discipline THIS page documents structurally drives.
• DKIM failures explained — the RFC 6376 §3.9 DKIM-VERDICT-CLASS- TAXONOMY-AS-LOAD-BEARING-PER-TRANSACTIONAL- ESP-WORKLOAD-FAILURE-MODE-CLASSIFICATION- SURFACE companion to this per-transactional- ESP-workload-deployment-pattern catalogue. Where THIS page documents the per- transactional-ESP-workload-profile failure- mode catalogue (shared-MTA relay-rewriting body-modification at SendGrid / Mailgun / Amazon SES + on-behalf-of-tenant d=<esp-domain> default + tenant-managed DKIM CNAME-delegation propagation-window + per-customer-stream IP-rotation and selector-rotation cadence ABOVE the receiver-side DNS-cache TTL), the DKIM-failures-explained spoke is the UPSTREAM RFC 6376 §3.9 receiver-side DKIM- verdict-class taxonomy whose four verdict keywords are the load-bearing classification surface every per-transactional-ESP failure- mode catalogued on THIS page surfaces as at four DKIM-verdict-class-to-transactional- ESP-failure-mode coupling dimensions: (i) shared-MTA relay-rewriting body-modification surfaces as the per- message bodyhash-mismatch verdict at the receiver — SendGrid link-tracking URL substitution, Mailgun open-pixel injection, Amazon SES footer-appending, and per-ESP character-set renormalization all produce body-octet drift BETWEEN the publisher signing point and the receiver verification point, whose canonical receiver-side verdict is the bodyhash-mismatch failure- class THIS DKIM-failures spoke documents as the bh-tag-vs-receiver-recomputed-body- hash inequality; (ii) on-behalf-of- tenant d=<esp-domain> default surfaces as dkim=pass+ DMARC-unaligned producing the per-message DMARC=fail despite the per-message DKIM- verdict-class being pass — the per-transactional-ESP-defaults-to-its-own- signing-domain pattern produces the cross-protocol failure mode the DKIM- failures catalogue documents AS a verdict- class but does not exhaustively diagnose at the per-transactional-ESP-workload attribution dimension THIS page provides; (iii) tenant-managed DKIM CNAME- delegation propagation-window surfaces as the per-message temperror verdict at the receiver — receiver-side CNAME-chase-and-TXT-fetch during the per- ESP CNAME publication mid-propagation window produces transient DNS-retrieval failures whose canonical receiver-side verdict is the temperror failure-class THIS DKIM-failures spoke documents as the per-receiver-fault transient public-key-fetch-failure class; (iv) per-customer-stream IP- rotation and selector-rotation faster than receiver-side DNS-cache TTL surfaces as the per-message permerror verdict at the receiver — per-transactional- ESP per-customer-stream selector-rotation at sub-TTL cadence produces stale- public-key-cache lookups whose canonical receiver-side verdict is the permerror failure-class THIS DKIM-failures spoke documents as the per- publisher-fault permanent DKIM-evaluation failure-class at the selector-rotation cutover boundary. Read the DKIM-failures- explained spoke ALONGSIDE this per- transactional-ESP-workload-deployment- pattern catalogue whenever an operator attributing a per-transactional-domain per-source-IP DKIM-failure-rate spike needs the per-message DKIM verdict-class taxonomy whose four failure-class verdicts are the load-bearing classification surface every per-transactional-ESP failure-mode the per-transactional-ESP- workload-profile catalogue on THIS page structurally amplifies.
• DKIM key rotation — the PER-PUBLISHER-PER-SELECTOR-KEY- ROTATION-OPERATIONAL-DISCIPLINE-AS-LOAD- BEARING-PER-TRANSACTIONAL-ESP-PER-CUSTOMER- STREAM-ROTATION-CADENCE-PUBLICATION- DISCIPLINE companion to this per- transactional-ESP-workload deployment- pattern catalogue. Where THIS page documents the per-transactional-ESP- workload deployment-pattern catalogue (SendGrid / Mailgun / Amazon SES / Postmark / Mailjet / SparkPost / Mandrill / Resend per-customer-stream IP-rotation and selector-rotation at cadences faster than the receiver-side DNS-cache TTL), the DKIM-key-rotation spoke is the UPSTREAM per-publisher per-selector key-rotation operational-discipline reference every per-transactional-ESP per-customer-stream rotation-cadence catalogue THIS page documents structurally consumes at four per-ESP-stream-rotation coupling dimensions: (i) per-ESP per- customer-stream dual-selector zero- downtime overlap-window-must-exceed- receiver-side-DNS-cache-TTL discipline as load-bearing per-stream rotation-cutover primitive — every per- transactional-ESP per-customer-stream selector-rotation cadence faster than the per-receiver DNS-cache TTL produces stale- public-key-cache lookups whose canonical receiver-side verdict is the per-stream dkim=permerror class; the per-publisher per-selector overlap-window- must-exceed-receiver-side-DNS-cache-TTL discipline THIS DKIM-key-rotation spoke documents is the load-bearing per-ESP per-customer-stream rotation-cutover primitive that prevents the per-stream permerror amplification THIS page catalogues; (ii) per-ESP per- customer-stream selector-namespace lifecycle vocabulary discipline as per- ESP-stream rotation-orchestration primitive — per-transactional- ESP per-customer-stream selector namespaces (SendGrid sN._domainkey per stream; Mailgun mailo._domainkey per stream; Amazon SES amazonses._domainkey per region; Postmark 20XX-XX-XX._domainkey per rotation epoch) the per-publisher per- selector namespace-lifecycle discipline THIS DKIM-key-rotation spoke documents is the operational-discipline reference every per-ESP per-customer-stream rotation-orchestration primitive consumes; (iii) per-ESP per- customer-stream cryptographic-strength- upgrade discipline as per-ESP-stream rotation-floor-enforcement primitive — per-transactional- ESP per-customer-stream selector ships with default cryptographic strength (SendGrid 2048-bit RSA default, Amazon SES 2048-bit RSA default, Mailgun 2048-bit RSA default) per the per- publisher per-rotation 1024-to-2048-bit upgrade discipline THIS DKIM-key-rotation spoke documents — the per-ESP per- customer-stream cryptographic-strength- floor-enforcement primitive prevents per- stream dkim=policy verdict emergence at receivers enforcing the RFC-8301 baseline; (iv) per-ESP per-customer-stream publish-new-selector- FIRST-then-rotate-signing-key discipline as per-ESP-stream rotation-propagation- window primitive — per- transactional-ESP per-customer-stream selector publication MUST precede the per-stream signing-key rotation cutover by at least the per-receiver DNS- propagation-window (typically minutes to hours depending on receiver DNS- infrastructure) per the per-publisher per-rotation publish-FIRST discipline THIS DKIM-key-rotation spoke documents — the per-ESP per-customer-stream rotation-propagation-window primitive prevents per-stream dkim=temperror verdict emergence during the per-rotation DNS- propagation-window. Read the DKIM-key- rotation spoke ALONGSIDE this per- transactional-ESP-workload deployment- pattern catalogue whenever an operator diagnosing a per-transactional-domain per-source-IP DKIM-failure-rate spike post-per-stream-selector-rotation needs the per-publisher per-selector key-rotation operational-discipline catalogue whose four discipline dimensions are the load-bearing per-ESP- stream rotation-cutover primitives the per-transactional-ESP-workload-profile catalogue THIS page documents structurally consumes.
• DKIM selectors explained — the PER-ESP-CANONICAL-SELECTOR- NAMESPACE-PUBLICATION-PRIMITIVE- REFERENCE companion to this per- transactional-ESP deployment-pattern catalogue. Where THIS page documents the per-ESP per-customer-stream transactional-workload deployment topology and its per-ESP per-stream SPF-include / CNAME-delegated-DKIM / per-stream alignment-verdict surface, the dkim_selectors_explained spoke documents the DKIM-SELECTOR-NAMESPACE PRIMITIVE the per-transactional-ESP operator delegates per-customer at the <sel>._domainkey.<customer-domain> CNAME-delegation level: the per-ESP canonical selector catalogue (SendGrid's s1 / s2, Mailgun's mta / k1, Postmark's 20240101-style date- keyed selectors, Amazon SES's per-region per-config-set selectors, Mailchimp's k1, Mandrill's mandrill, Brevo's mail), the dual-selector rotation publishing- window mechanics, and the seven selector-publication failure modes the per-ESP-platform operator and per-customer must coordinate. FOUR structurally-distinct PER-ESP- CANONICAL-SELECTOR-NAMESPACE- PUBLICATION dimensions the per- transactional-ESP-workload-profile deployment THIS page documents operationally consumes: (i) per-ESP canonical selector identity AS LOAD-BEARING-PER- CUSTOMER CNAME-DELEGATION TARGET — every transactional ESP THIS page catalogues publishes per- customer per-stream DKIM via the per-ESP CNAME-delegation pattern (s1._domainkey.<customer-domain> IN CNAME s1.domainkey.u123456.wl.sendgrid.net); the per-ESP CANONICAL SELECTOR IDENTITY (s1, k1, mta, mandrill, etc.) the per-customer zone publishes is the canonical per-ESP selector-namespace the selectors-explained spoke catalogues; without the correct per-ESP canonical selector identity the per-customer CNAME-delegation is structurally broken and the per- row aggregate-report auth_results.dkim.result=permerror emerges across the per-transactional- stream traffic; (ii) per- ESP-per-customer CNAME-delegated DKIM rotation AS LOAD-BEARING-DUAL- SELECTOR-PUBLISHING-WINDOW-OWNED-BY- THE-ESP-OPERATOR-NOT-THE-CUSTOMER DISCIPLINE — when the transactional-ESP rotates its per- platform DKIM key, the per-ESP operator publishes a NEW per- selector (typically a versioned identity like SendGrid's s2, Postmark's next-date-keyed selector, or Amazon SES's next per-config-set selector) while the OLD per-selector remains CNAME-resolvable per the dual-selector publishing-window mechanics the selectors-explained spoke documents — but the rotation cadence is OWNED by the per-ESP operator NOT the per-customer operator, so the per-customer zone-managed CNAME-record publication must anticipate the per-ESP rotation schedule the selectors-explained spoke catalogues; (iii) per- transactional-stream multi-signer custody-isolation AS LOAD-BEARING- PER-CUSTOMER-PER-ESP-SELECTOR- DISAMBIGUATION INVARIANT — the per-customer outbound mail- flow can stack MULTIPLE transactional ESPs (SendGrid for receipts + Postmark for password- resets + Mailgun for shipping- notifications); the per-row aggregate-report auth_results.dkim.selector field must disambiguate which per- ESP signed which per-stream message, which depends on each per-ESP canonical selector being distinct from every other per-ESP canonical selector the per- customer per-stream traffic invokes; the per-customer multi- signer custody-isolation invariant the selectors-explained spoke documents (one selector per signer-infrastructure instance; no selector-reuse across operator- distinct signers) is the canonical per-customer attribution-discipline the per-transactional-ESP stacked- deployment requires; (iv) per-ESP selector- publication failure-mode catalogue AS LOAD-BEARING-PER-STREAM dkim=permerror ROOT- CAUSE TAXONOMY — the seven selector-publication failure modes the selectors-explained spoke enumerates (NXDOMAIN on selector CNAME-target, stale t=y still emitted by the per-ESP platform, empty p= emergency revocation by the per-ESP operator, truncated p= from the per-ESP TXT-record publication, key- rotation mid-cutover gap during a per-ESP rotation, selector-reuse across operator-distinct per-ESP signers, SERVFAIL on per-ESP delegated-selector zone) are the canonical per-transactional- stream dkim=permerror root-cause taxonomy the per- transactional-ESP-workload deployment audit THIS page catalogues must diagnose at the per-ESP CNAME-delegation level. Read the dkim_selectors_explained spoke ALONGSIDE this per- transactional-ESP deployment- pattern catalogue when authoring the per-ESP per-customer CNAME- delegation row in the per- transactional-domain DKIM- publication audit-checklist — the spoke is the canonical PER- ESP-CANONICAL-SELECTOR-NAMESPACE- PUBLICATION-PRIMITIVE REFERENCE the per-transactional-ESP deployment depends on at the per- customer CNAME-delegation level.
• SPF for Google Workspace — the PER-WORKSPACE-CUSTOMER- TENANT-COHABITING-WITH- TRANSACTIONAL-ESP-PER-CUSTOMER- DOMAIN-SPF-INCLUDE-STACKING- DISCIPLINE companion to this transactional ESP deployment reference. Where THIS page documents the per-transactional- ESP customer-domain SPF authoring discipline (per-customer-domain apex SPF record authoring an include:<esp-domain> token authorizing the ESP's outbound IP pool, the per-ESP per-customer CNAME-delegation publication, the per-customer DMARC-alignment posture across primary corporate + transactional envelope-domains, the RFC 7208 §4.6.4 ten-DNS-lookup ceiling consumption across per-ESP include stacking), the spf_for_ google_workspace spoke documents the per-Workspace-customer-tenant SPF-publication discipline that every transactional ESP integration with a Workspace- hosted customer-domain must coordinate with at FOUR per- Workspace-customer-domain multi- include-cascade coordination dimensions: (i) per- Workspace-customer-domain apex SPF record AUTHORING include:_spf.google.com + include:<esp-domain> DUAL-INCLUDE STACKING as LOAD- BEARING multi-egress per-source- IP authorization-publication coordination — every Workspace-tenant customer integrating a transactional ESP must publish a multi-include SPF cascade authorising both the Workspace Google-managed outbound IP-pool AND the per-ESP outbound IP-pool; the spf_for_ google_workspace spoke documents the per-Workspace-customer- domain DUAL-INCLUDE STACKING publication discipline whose preservation IS the load-bearing publication-prerequisite every per-transactional-ESP per- Workspace-customer deployment THIS page catalogues depends on; (ii) per-Workspace- customer-domain RFC 7208 §4.6.4 ten-DNS-lookup ceiling consumption BUDGET-DISCIPLINE across include:_spf.google.com (3-5 lookups) + include:<esp- domain> (1-3 lookups per ESP) multi-include stacking AS STRUCTURAL-OVERFLOW-RISK DISCIPLINE — Workspace's per-tenant include:_spf.google.com cascade itself consumes 3-5 of the ten-DNS-lookup ceiling budget; per-customer multi-ESP stacking (e.g., SendGrid for transactional + Mailgun for marketing + Amazon SES for bounces) routinely overflows the budget producing spf=permerror; the spf_for_google_workspace spoke documents the per- Workspace-customer-domain ceiling-overflow remediation disciplines (per-ESP subdomain delegation, SPF-flattening services, per-stream envelope- domain isolation) every per- transactional-ESP per-customer publication deployment THIS page catalogues must coordinate with; (iii) per- Workspace-customer-domain Routing Recipients Send-As Outbound-Gateway egress-IP-pool AUTHORIZATION-COMPLEMENTARY-TO- per-transactional-ESP-egress- IP-pool AUTHORIZATION across envelope-domain boundaries — Workspace tenants frequently configure both Gmail-direct- egress (covered by include:_spf.google.com) AND outbound-gateway-relay egress (covered by per-customer ip4: literals or per-ESP include: tokens); the spf_for_google_ workspace spoke documents the per-Workspace-customer-domain per-envelope-domain authorization-coordination discipline complementary to the per-transactional-ESP per- envelope-domain authorization- publication discipline THIS page documents; (iv) per- Workspace-customer-domain DMARC- rua-aggregate per-source-IP-per- disposition-row attribution across the Workspace-direct- egress per-source-IP segment AND per-transactional-ESP per-source-IP segment AS PER- WORKSPACE-CUSTOMER-DEPLOYMENT OBSERVABILITY-FEEDBACK-LOOP — every per-Workspace-customer- tenant publishing a multi- include SPF cascade receives rua-aggregate-XML evidence partitioning the per-source-IP attribution across the Workspace-direct-egress segment AND the per-transactional-ESP segment; the spf_for_google_ workspace spoke documents the per-Workspace-customer-tenant observability-feedback-loop whose per-source-IP attribution IS the load-bearing publisher- side observability evidence the per-ESP authentication- publication discipline THIS page documents depends on. Read the spf_for_google_workspace spoke alongside this per- transactional-ESP deployment- pattern catalogue when authoring the per-Workspace-customer- domain multi-include cascade SPF record — the spoke is the canonical PER-WORKSPACE- CUSTOMER-TENANT-COHABITING- WITH-TRANSACTIONAL-ESP-PER- CUSTOMER-DOMAIN-SPF-INCLUDE- STACKING-DISCIPLINE REFERENCE every per-transactional-ESP per- Workspace-customer-tenant deployment THIS page catalogues structurally depends on at the per-Workspace-customer-domain publication-discipline boundary.
• Email spoofing (the seven canonical techniques) — where THIS page documents the per-publisher per-ESP per-customer- stream DMARC deployment discipline (per-tenant signing-domain publication + per-customer SPF include-cascade + per-customer DKIM-CNAME-delegation + per-stream alignment posture), the email- spoofing spoke documents the seven canonical attacker techniques whose per-message exploit-class targets the transactional-email surface THIS page architectures the defense of. FOUR structurally-distinct PER- SPOOFING-TECHNIQUE-TO-TRANSACTIONAL- EMAIL-EXPLOIT-CLASS coupling dimensions the email-spoofing spoke operationally documents: (i) RFC 5322 From: forgery as load-bearing attacker primitive whose per-publisher DMARC p=reject + per-customer DKIM alignment is the defense- layer the transactional-email deployment catalogue THIS page documents architectures — the canonical direct-domain spoofing attack where the attacker sets From: receipts@< publisher-domain> in their unauthorized message is EXACTLY the attack class that per-publisher DMARC p=reject on the transactional-email-bearing domain blocks at receiver-side DMARC-policy enforcement; (ii) display-name spoofing as load-bearing attacker primitive AGAINST WHICH transactional-email operators have NO protocol-level defense and must rely on receiver- side anti-phishing heuristics + per-publisher brand-consistency- in-Subject-line user-education discipline — the attacker sets From: "Bank of Example" <attacker@gmail.com > with a legitimate SPF / DKIM / DMARC posture for gmail.com but an unauthorized display-name; THIS page's per-stream brand-consistency operator-discipline IS the load-bearing user-side defense layer; (iii) lookalike- domain registration + IDN homograph + cousin-domain registration as load-bearing attacker primitives WHOSE per-publisher per-domain DMARC deployment catalogue THIS page documents CANNOT defend against — attacker-controlled domains have legitimate DMARC posture for their own zone — these three spoofing techniques operate OUTSIDE the per-publisher DMARC deployment surface THIS page catalogues; transactional-email operators must coordinate defensive registration of confusable / cousin / IDN- homograph variants of their primary brand-domain at the registrar-layer as a per-domain- portfolio publication discipline ORTHOGONAL to the per-publisher per-ESP DMARC deployment THIS page architectures; (iv) subdomain takeover via abandoned DNS as load-bearing attacker primitive against per-customer-domain transactional- email infrastructure — when a per- ESP CNAME-delegation target's DNS record gets stale and the underlying ESP-side hosted-zone gets reclaimed by an attacker who registers it — this spoofing technique IS the operational risk class the per-publisher per-ESP per-customer CNAME-delegation lifecycle THIS page's deployment catalogue documents the rotation-cadence + decommission-cleanup discipline of. Read the email-spoofing spoke ALONGSIDE this transactional- email deployment catalogue whenever the operator scopes a per-publisher per-domain transactional-email security baseline — the seven canonical spoofing techniques the email- spoofing spoke catalogues materially define the threat surface this transactional-email deployment catalogue architects the per-stream per-tenant defense-in-depth posture for.
• Phishing protection — the TRANSACTIONAL-EMAIL-AS-HIGHEST- VALUE-PHISHING-TARGET-CLASS companion reference. Where THIS page documents the per-transactional-ESP per-customer- domain DMARC deployment discipline (per-tenant signing-domain publication + per-customer SPF include:<esp-spf-macro> cascade + per-customer DKIM-CNAME- delegation + per-stream alignment posture), the phishing-protection spoke is the PER-PUBLISHER-PER-DOMAIN- PHISHING-ATTACK-THREAT-MODEL companion whose per-transactional-publisher per- customer-domain anti-phishing posture the transactional DMARC publication discipline directly supports. Four transactional-email anti-phishing coupling dimensions the spoke addresses: (1) per-transactional- publisher per-customer-domain display- name spoofing deterrence on OTP / MFA / password-reset / order- confirmation streams — attackers forge the RFC 5322 From: display-name to read "PayPal Security <attacker@evil.tld>" impersonating the per-transactional-publisher OTP sender — the per-ESP CNAME-delegated DKIM-aligned-pass evidence + per- customer-domain SPF-aligned-pass evidence at the receiver-side cryptographically distinguishes legitimate transactional mail from attacker-controlled lookalike-domain OTP-phishing mail, defeating the canonical OTP-phishing-pattern attack class; (2) per-transactional- publisher per-customer-domain lookalike-domain registration deterrence on high-value transactional streams — attackers register paypa1.com (numeral "1" replacing "l"), paypal.support (vanity TLD), or paypal-security.com (hyphenated lookalike) imitating the per-transactional-publisher customer domain — the per-customer-domain DMARC-aligned-pass publication discipline produces the per-publisher per-domain cryptographic-authentication primitive the per-receiver per-domain lookalike-domain-attack-campaign empirical-detection pipeline consumes to flag per-receiver per-day lookalike- domain per-message anomalies; (3) per- transactional-publisher per-customer- domain subdomain-takeover deterrence on transactional subdomains — attackers exploit abandoned transactional subdomains (decommissioned otp.<customer> subdomain, decommissioned billing.<customer> subdomain, dangling DNS-record transactional subdomain) to send subdomain-takeover-attack mail under the publisher's transactional- subdomain umbrella — the per-customer- domain sp=-tag subdomain- policy publication discipline THIS page documents is the per-publisher per-subdomain anti-takeover primitive defeating subdomain-takeover-attack- class spoofing on transactional subdomains; (4) per-publisher per- domain per-source-IP per-day DMARC- aligned-fail-rate spike as empirical- detection signal — the per- transactional-publisher per-customer- domain DMARC RUA aggregate-report stream surfaces per-receiver per-day per-source-IP per-publisher per-day DMARC-aligned-fail-rate spikes as the literal empirical-detection signal for active per-publisher per-customer- domain spoofing-attack-campaigns impersonating the transactional sender; the per-message RUF ARF diagnostic- block stream from per-domain ruf= publication enables per-attack-campaign forensic-evidence- collection for SOC incident-response. Read the phishing-protection spoke when MOTIVATING the per-transactional- publisher per-customer-domain DMARC publication discipline as the load- bearing per-publisher per-domain cryptographic anti-phishing primitive whose receiver-side enforcement closes the per-publisher per-domain phishing- attack-campaign attack surface on the highest-PII-density transactional mail stream every operator owns.
• TLS-RPT DNS record syntax (RFC 8460 §3 byte-by-byte) — where THIS page documents the per-publisher per-ESP per-customer- stream DMARC application-layer deployment discipline architecting the per-stream per-tenant defense- in-depth posture for the highest- PII-density transactional email surface, the TLS-RPT-record-syntax spoke documents the transport- layer publication discipline whose per-publisher per-domain JSON- report aggregate-evidence stream is the LOAD-BEARING transport- layer compliance KPI the Gmail / Yahoo 2024 Bulk Sender Requirements per-publisher cross-receiver TLS-handshake-success-rate floor enforcement boundary consumes as the per-publisher per-domain deliverability-outcome determinant. FOUR structurally-distinct TRANSACTIONAL-EMAIL-TLS-COMPLIANCE coupling dimensions the TLS-RPT- record-syntax spoke operationally documents: (i) per- publisher per-domain _smtp._tls TXT-RR publication discipline as load- bearing transport-layer compliance primitive for the Gmail / Yahoo 2024 Bulk Sender Requirements 100%-encryption-rate floor at the per-publisher cross-receiver boundary — the per- publisher per-domain _smtp._tls TXT-RR publication discipline is the load-bearing transport-layer compliance reporting primitive whose per-publisher per-domain cross-receiver TLS-pass-rate evidence stream is the LOAD- BEARING transport-layer compliance- determinant the per-receiver 2024 Bulk Sender Requirements per-publisher cross-receiver TLS- handshake-success-rate floor enforcement boundary materially consumes; (ii) per- publisher per-domain TLS-RPT JSON- report aggregate-evidence stream as load-bearing transport-layer per-MX-host per-failure-class observability primitive for the per-publisher per-ESP per-customer per-stream transactional-email deployment infrastructure THIS page catalogues — every per-publisher per-ESP per- customer-stream transactional-email deployment THIS page documents materially depends on the per-MX- host per-failure-class TLS-RPT JSON-report evidence stream to observe per-MX-host per-failure- class transport-layer compliance regressions BEFORE the per-publisher cross-receiver TLS-handshake- success-rate floor enforcement boundary translates them into per- publisher per-domain deliverability- outcome degradation; (iii) per-publisher per-domain TLS-RPT rua mailbox URI publication discipline as load-bearing structural-parallel to per- publisher per-domain DMARC rua mailbox URI publication discipline at the per-publisher per-domain application-layer reporting primitive THIS page architectures — every per-publisher per-domain transactional-email deployment THIS page architectures requires the per-publisher per-domain rua mailbox URI for receiving DMARC aggregate-XML evidence; the per-publisher per-domain TLS-RPT rua mailbox URI publication discipline the TLS-RPT-record- syntax spoke documents is the structurally-parallel transport- layer rua-mailbox-publication- discipline primitive composing the cross-OSI-layer per-publisher per-domain reporting framework; (iv) per-publisher per- domain TLS-RPT publication discipline as load-bearing transport-layer complement to the per-publisher per-ESP per-customer-stream defense-in-depth posture THIS page architectures the application-layer SPF + DKIM + DMARC + ARC + List-Unsubscribe- POST stack of — the per-publisher per-domain transactional-email defense-in- depth posture THIS page documents the per-stream per-tenant architecture of must coordinate the per-publisher per-domain TLS-RPT publication discipline as the load-bearing transport-layer compliance reporting primitive whose JSON-report aggregate- evidence stream is the structural- parallel transport-layer compliance-determinant complementing the application-layer SPF + DKIM + DMARC + ARC + List-Unsubscribe- POST stack THIS page architectures the per-stream per-tenant deployment of. Read the TLS-RPT- record-syntax spoke ALONGSIDE this transactional-email deployment catalogue whenever the per-publisher per-domain transactional-email defense-in- depth posture extends to a cross-OSI-layer compliance framework — the TLS-RPT-record- syntax publication-discipline IS the load-bearing transport-layer compliance-reporting primitive whose per-publisher per-domain cross-receiver TLS-pass-rate distribution evidence-stream is the load-bearing transport-layer compliance-determinant the per- publisher per-domain transactional- email per-stream per-tenant deployment catalogue THIS page architectures materially depends on at the per-publisher cross- receiver 2024 Bulk Sender Requirements compliance boundary.
• DKIM troubleshooting - the PER-ESP-PER-CUSTOMER-DOMAIN PER-SELECTOR DKIM-VERIFICATION-FAILURE- DIAGNOSTIC-PLAYBOOK companion to this transactional-email per-ESP per- customer-domain deployment reference. Where THIS page documents the per-ESP per-customer-domain DKIM-publication discipline (SendGrid em-prefixed per-customer-domain CNAME-chain to SendGrid-managed selector hosts, Mailgun pic._domainkey / krs._domainkey per-customer-domain CNAME-delegation, Amazon SES per- identity SES-signed CNAME-chain, Postmark per-server-token CNAME publication, SparkPost per-customer- domain scphXX selector publication) at the per-ESP per-customer-domain CNAME-delegated signer boundary, the DKIM-troubleshooting spoke is the per-ESP per-customer-domain per- selector failure-mode investigation playbook documenting the FIVE per- receiver DKIM-verifier verdict states a per-ESP per-customer-domain operator encounters when reading the per-receiver Authentication-Results evidence stream or per-publisher RUA aggregate-report payload: (i) dkim=none at the per- receiver verdict line indicating the per-customer-domain outbound message carried NO DKIM-Signature header at all - per-ESP per-customer-domain failure mode where the ESP-side signer is not yet activated against the per-customer-domain CNAME (still in pending-verification state), the customer-domain CNAME-publication is missing one or more of the ESP-mandated per-selector CNAME RRs, or the per-ESP outbound-mail-flow is being routed via a non-signing secondary SMTP relay that strips the DKIM-Signature header in-flight; (ii) dkim=temperror indicating the per-receiver verifier could not complete the per-selector public-key DNS-lookup within the per-receiver evaluation-budget window - per-ESP per-customer-domain failure mode where the per-customer- domain CNAME-chain at the customer- side authoritative nameserver is suffering per-RR-TTL propagation lag, the ESP-managed upstream selector- host TXT-record-publication endpoint SERVFAILs under per-receiver query load, or the per-customer-domain authoritative nameserver does not return the CNAME-target-resolved TXT record because the customer published an A-record at the selector host instead of a CNAME; (iii) dkim=permerror indicating the per-receiver verifier successfully retrieved the per- selector public-key TXT-record but could not parse it - per-ESP per- customer-domain failure mode where the per-customer-domain CNAME points at the wrong per-ESP selector hostname (typo-introduced s1._domainkey vs s2._domainkey mismatch between the ESP-issued CNAME-targets and what the customer actually published), the customer- domain authoritative nameserver truncated the CNAME-target TXT past the 255-byte single-string boundary without proper multi-string quoting, or the ESP-side TXT carries the p=-revocation marker from an old per-customer-domain signer key-rotation pass; (iv) dkim=fail indicating the per-receiver verifier retrieved a parseable per-selector public-key but the per-message body-hash or signature-hash did NOT verify - per-ESP per-customer-domain failure mode where the per-ESP outbound mail-flow post-signature modification (per-ESP open-tracking pixel-injection, per-ESP click- tracking link-rewrite of every URL in the per-message body, per-ESP List-Unsubscribe header injection at the per-customer-domain campaign- send boundary) invalidates the canonicalized body-or-header hash the DKIM-signature committed to; (v) dkim=pass + aligned=false at the DMARC-alignment-evaluator line indicating the DKIM signature itself verified BUT the d=-tag value of the DKIM-Signature header does NOT match the per-customer-domain From: header organizational domain under the per-publisher adkim= alignment- strictness setting - per-ESP per- customer-domain failure mode where the ESP signs with the ESP's own operational d=-domain (sendgrid.net / mailgun.org / amazonses.com / postmarkapp.com) rather than the per-customer-domain operator's organizational domain because the per-customer-domain signed-by-domain feature was not yet enabled at the per-customer- domain provisioning boundary. Read THIS page when PROVISIONING the per-ESP per-customer-domain CNAME- delegated DKIM-signer at the customer-domain authoritative nameserver; read the DKIM- troubleshooting spoke when INVESTIGATING per-ESP per-customer- domain per-selector DKIM- verification failures surfaced in per-receiver Authentication-Results headers or per-publisher RUA aggregate-report rows.
• Email Header Analyzer - single-message diagnosis tool for transactional-email alignment investigation. Built on includes/EmailHeaderParser.php.
• Domain Security Checker - live DNS lookups for DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, CAA via includes/DnsChecker.php.
• DNS Record Generator - generate syntactically-correct DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, CAA records when onboarding a new ESP.
• SPF mechanisms explained (RFC 7208 §5) - the per-mechanism left-to-right evaluation grammar reference that every transactional-ESP onboarding decision structurally depends on. Onboarding a new transactional sender (SendGrid, Mailgun, Postmark, SES, Mailchimp Transactional, etc.) almost always involves appending the ESP's include:spf.<esp>.tld to the publishing domain's SPF record — but each ESP's include: consumes 1 DNS lookup PLUS the cost of every nested mechanism in the ESP's published SPF record. Common transactional-ESP include: costs measured at publication time: SendGrid 4 lookups, Mailgun 3 lookups, Postmark 2 lookups, Amazon SES 3 lookups, Mailchimp 3 lookups — stacking three transactional ESPs plus the publisher's own corporate include: for Microsoft 365 or Google Workspace routinely crosses the RFC 7208 §4.6.4 10-DNS-lookup hard ceiling, at which point every receiver returns spf=permerror on EVERY message regardless of which ESP actually sent it. Read THIS page when ONBOARDING a new transactional ESP; read the SPF-mechanisms-explained spoke when AUDITING the cumulative per-publisher lookup-budget arithmetic across the stack of include: mechanisms the onboarded ESP fleet has accumulated, and when DECIDING whether SPF flattening or per-sender subdomain delegation (marketing.<publisher>.tld / tx.<publisher>.tld with its own dedicated SPF record) is needed to keep the per-publisher per- subdomain lookup count under the 10- lookup ceiling.
• DKIM best practices — the canonical DKIM publication-and- rotation discipline reference (the per- publisher per-selector RSA-2048-minimum key-size baseline per Feb 2024 bulk-sender requirements, the dual-selector rotation- overlap window discipline, the rsa-sha256 vs ed25519-sha256 algorithm-choice decision matrix, the per-domain organisational-domain-aligned d=- tag publication discipline, the per- publisher per-selector private-key custody-vs-ESP-delegation policy) whose per-publisher per-domain canonical deployment-discipline IS the LOAD-BEARING deployment-playbook reference every per- transactional-ESP-onboarding tutorial THIS page documents structurally depends on at the per-publisher per-domain DKIM publication-and-rotation correctness boundary. The composition operates through FOUR operationally-distinct per- transactional-ESP per-publisher per- selector DKIM-operational-discipline dimensions: (i) per-transactional-ESP per-publisher per-selector DKIM key-size floor — the canonical RSA-2048-minimum baseline (the Feb 2024 Gmail / Yahoo Bulk Sender Requirements floor) is the per-transactional-ESP per-publisher per- domain DKIM-key-publication baseline every transactional ESP MUST publish AND every per-publisher per-domain operator MUST verify on every onboarded transactional-ESP-published per-selector TXT-RR; the DKIM-best-practices spoke documents the per-selector RSA-2048 key- generation procedure AND the per- publisher per-selector key-strength audit discipline; (ii) per-transactional- ESP per-publisher per-selector dual- selector rotation-overlap-window discipline — the canonical 24-72-hour- overlap window during which both the OLD selector AND the NEW selector are simultaneously published is the LOAD- BEARING per-publisher per-domain DKIM- aligned-pass-rate-continuity primitive every per-transactional-ESP key-rotation cycle THIS page documents structurally depends on for zero per-publisher per- receiver DKIM-aligned-pass-rate regression during rotation; the spoke documents the per-selector overlap- window publication-and-retirement playbook; (iii) per-transactional-ESP per-publisher per-selector private-key custody-vs-ESP-delegation policy — the canonical per-transactional-ESP per-publisher per-domain DKIM private- key custody decision matrix (per- publisher per-domain key-generation + per-ESP per-selector public-key-only publication via CNAME-delegation vs per-ESP-generated per-publisher per- domain key-pair with per-ESP private- key custody) determines the per- publisher per-domain DKIM-signing- portability posture and the per- transactional-ESP-onboarding-and- offboarding operational burden; the spoke documents the per-publisher per- domain key-custody-vs-delegation decision tree; (iv) per-transactional- ESP per-publisher per-selector algorithm-choice (rsa-sha256 vs ed25519-sha256) — the canonical RFC 6376 §3.6.1 per-selector a=-tag algorithm-choice decision matrix gates per-publisher per-receiver DKIM-aligned-pass-rate compatibility across the receiver- ecosystem's per-receiver-implementation ed25519-sha256 support coverage; the spoke documents the per-selector dual- algorithm publication discipline (one rsa-sha256-selector + one ed25519- sha256-selector) that maximises per- publisher per-receiver DKIM-aligned- pass-rate coverage during the multi- year ed25519-sha256 receiver- ecosystem-adoption ramp. Read THIS page when ONBOARDING the per- publisher per-transactional-ESP-cohort DMARC publication-discipline; read the DKIM-best-practices spoke when AUDITING the per-publisher per- transactional-ESP per-selector DKIM- publication-and-rotation-discipline correctness that the per-publisher per-domain DMARC composite-verdict at the receiver materially depends on.
• DKIM DNS-record byte syntax - the PER-ESP-DKIM-DNS-PUBLICATION- DISCIPLINE companion to this transactional-email DMARC deployment reference. Where THIS page documents the per-publisher per-transactional- ESP-cohort DKIM-selector publication workflow (the ESP-managed CNAME chains at per-publisher per-ESP per-selector <esp-selector>._domainkey.<publisher-domain> delegated to the ESP-maintained per-selector TXT-record-byte payload — SendGrid's s1._domainkey and s2._domainkey CNAMEs, Mailgun's k1._domainkey CNAME, Postmark's 20180529._domainkey CNAME, Amazon SES's three SES-managed selector._domainkey CNAMEs, Mailchimp's k1._domainkey and k2._domainkey CNAMEs), the DKIM DNS-syntax spoke documents the RFC 6376 §3.6.1 per-tag byte- grammar reference every receiver-side DKIM verifier consumes when validating EITHER the per-publisher's own-infrastructure-signed message OR the per-ESP-signed message — the v=DKIM1 version tag, the k=rsa key-type tag, the p=<base64-pubkey> public-key bytes, the optional h= hash-algorithm constraint, the s=email service-type tag, the t= flags tag, and the 255-octet character-string-fragmentation rule. Pair this transactional-email deployment guide with the DKIM-DNS- syntax spoke when verifying that EVERY per-publisher per-ESP per- selector CNAME chain resolves to a terminal TXT record whose byte grammar matches the RFC 6376 §3.6.1 contract - the per-publisher per-ESP per- selector terminal TXT-record byte- grammar compliance is the STRUCTURAL receiver-side verification PREREQUISITE every per-publisher per-ESP-signed outbound message depends on for the dkim=pass verdict that gates the per-message per-receiver DMARC-aligned-pass-rate floor this transactional-email deployment guide's per-publisher per-transactional-ESP- cohort DMARC enforcement coverage STRUCTURALLY DEPENDS on.
• SPF mechanism tokens: include vs ip4 vs a vs mx - the PER-TRANSACTIONAL-ESP-COHORT- SPF-INCLUDE-MACRO-AUTHORING-DISCIPLINE companion to this transactional-email deployment reference. Where THIS page documents the per-publisher per-domain per-transactional-ESP-cohort outbound mailflow topology (per-publisher per- domain operator integrates with one or more transactional ESPs - SendGrid, Mailgun, Postmark, SparkPost, Amazon SES, Mandrill - each requiring the per- publisher per-domain operator publish the ESP-vendor-published SPF-include- macro in the per-publisher per-domain SPF record to authorise the ESP-vendor- managed outbound SMTP egress source-IP pool), the SPF-mechanism-token-choice spoke is the PER-PUBLISHER-PER-DOMAIN- PER-TRANSACTIONAL-ESP-COHORT-SPF- INCLUDE-MACRO-AUTHORING-DISCIPLINE companion documenting the per-publisher per-domain per-mechanism-token authoring decision-matrix the per-publisher per- domain operator MUST compose at FOUR per-transactional-ESP-cohort per- mechanism-token-choice dimensions: (i) per-transactional-ESP-cohort per-publisher per-domain include:<esp-spf-macro> token authoring discipline per RFC 7208 §5.2 - the per-publisher per-domain operator MUST author per- publisher per-domain SPF record mechanism token include:sendgrid.net / include:mailgun.org / include:spf.mtasv.net (Postmark) / include:sparkpostmail.com / include:amazonses.com per RFC 7208 §5.2 to authorise the per-transactional-ESP-cohort vendor- published outbound SMTP egress source- IP macro that the per-receiver-side per-message SPF-evaluation per RFC 7208 §5 mechanism-evaluation discipline consumes to emit the per-message SPF- aligned-pass verdict the per-receiver per-message DMARC verdict materially depends on; (ii) per-publisher per-domain per-transactional-ESP- cohort SPF RFC 7208 §4.6.4 ten-DNS- lookup-budget compound-include macro- cascade-discipline - the per- publisher per-domain operator MUST audit the per-publisher per-domain SPF record per-transactional-ESP- cohort include:-macro cascade against the RFC 7208 §4.6.4 ten-DNS-lookup-budget that each per- ESP-cohort include: token consumes PLUS the recursive DNS- lookup-budget of EACH per-ESP-vendor- published macro chain (e.g. include:sendgrid.net recursively expands to MULTIPLE per- SendGrid-tenant-published include- macros, each consuming its own per- chain DNS-lookup-budget allocation), to avoid the per-publisher per-domain SPF-permerror verdict-emission at the per-receiver-side per-message SPF- evaluation boundary when the per- publisher per-domain per-transactional- ESP-cohort compound-include cascade EXCEEDS the per-RFC-7208-§4.6.4 ten- DNS-lookup-budget; (iii) per- publisher per-domain per-transactional- ESP-cohort macro-cascade-expansion observability via DMARC Analyzer Domain Security Checker live SPF lookup discipline - the per- publisher per-domain operator MUST use the DMARC Analyzer Domain Security Checker live SPF lookup (whose DnsChecker.php backend recursively expands per-publisher per-domain SPF include:-chains and emits per-publisher per-domain per-chain DNS- lookup-count consumption diagnostics) to verify per-publisher per-domain per- transactional-ESP-cohort SPF-record mechanism-token portfolio composition does not breach the per-RFC-7208-§4.6.4 ten-DNS-lookup-budget BEFORE deploying the per-publisher per-domain SPF-record edit; and (iv) per-publisher per-domain per-transactional-ESP-cohort per-day per-publisher per-day per- source-IP SPF-aligned-pass-rate-floor monitoring as per-mechanism-token- choice readiness-verification observability - the per- publisher per-domain operator MUST track per-receiver per-day per- publisher per-day per-transactional- ESP-cohort per-source-IP SPF-aligned- pass-rate-floor as the empirical- observability proxy for the per- publisher per-domain per-transactional- ESP-cohort per-mechanism-token-choice- composition authoring-discipline correctness BEFORE ramping per- publisher per-domain DMARC policy to p=quarantine / p=reject enforcement. Pair this transactional-email deployment guide with the SPF- mechanism-token spoke when AUTHORING the per-publisher per-domain per- transactional-ESP-cohort SPF-record mechanism-token portfolio - the SPF- mechanism-token spoke is the PER- TRANSACTIONAL-ESP-COHORT-SPF-INCLUDE- MACRO-AUTHORING-DISCIPLINE REFERENCE whose per-publisher per-domain per- transactional-ESP-cohort per- mechanism-token-choice decision-matrix the per-publisher per-domain operator structurally depends on to compose the per-transactional-ESP-cohort SPF authorisation footprint THIS page's per-publisher per-transactional-ESP- cohort DMARC enforcement-coverage architecture materially requires.
• TLS-RPT report format - the PER-TRANSACTIONAL-ESP-COHORT-PER- CUSTOMER-DOMAIN-TRANSPORT-LAYER-JSON- AGGREGATE-REPORT-FORMAT companion to this transactional-email DMARC deployment reference. Where THIS page documents the per-customer-domain per-transactional-ESP-cohort DMARC enforcement-coverage architecture (per-customer-domain SPF include:-cascade authoring for SendGrid/Mailgun/Postmark/SparkPost/ SES, per-customer-domain CNAME-delegated DKIM selectors at the per-ESP-managed signing-key-publication chain, per-customer-domain DMARC TXT-record publication driving the per-tenant p=quarantine / p=reject enforcement on OTP/MFA/password-reset/order- confirmation transactional streams) and surfaces the receiver-side per-day per-source-IP DMARC-aligned-pass evidence the operator consumes from the per-customer-domain rua= aggregate-XML stream, the TLS-RPT report-format spoke documents the STRUCTURALLY-PARALLEL per-receiver per-publisher per-day RFC 8460 §4 JSON aggregate-report byte-grammar the per-customer-domain _smtp._tls.<customer-domain> endpoint receives whose per-failure result-type enum (starttls-not-supported, certificate-host-mismatch, certificate-expired, sts-policy-fetch-error, sts-webpki-invalid) is the receiver-side transport-layer observability primitive transactional- ESP-cohort egress STARTTLS handshake outcomes surface to. Pair this transactional-DMARC reference with the TLS-RPT-report-format spoke at FOUR per-transactional-ESP-cohort per- customer-domain TLS-RPT-JSON-consumer dimensions: (i) per-ESP-cohort per-customer-domain per-receiver per- day JSON-report ingestion as transport- layer-observability stream parallel to the per-customer DMARC aggregate-XML stream - each per-customer-domain _smtp._tls.<customer-domain> published rua=mailto: endpoint receives per-day JSON aggregate-reports from every receiver processing transactional-ESP outbound mail under MTA-STS or DANE policy and the report-format spoke's byte-grammar reference enables per-receiver per-day per-policy-evaluation parsing the transactional-platform operator structurally requires for per-customer- domain transport-layer evidence stream consumption; (ii) per-failure result-type enumeration as per-customer-domain per-receiver per- day silent-failure attribution catalogue at the per-transactional-ESP- cohort egress boundary - the spoke's per-failure result-type enum lets operators distinguish receiver-side starttls-not-supported (peer receiver lacks STARTTLS) from per-customer-domain sts-policy-fetch-error (per-customer mta-sts.<customer-domain> policy file unreachable from peer receiver), per-customer-domain certificate-host-mismatch (per-customer mta-sts.txt mx: allow-list specifies a per-ESP receive MX whose presented certificate is for a different hostname), per-customer-domain sts-webpki-invalid (per-ESP receive MX presents a certificate from an untrusted root chain or expired intermediate) at the per-receiver-per-customer-domain granularity without which every transactional STARTTLS-failure attribution collapses to opaque "STARTTLS failed"; (iii) per- customer-domain per-receiver per-day summary.total-successful-session-count / total-failure-session-count as per-customer-domain MTA-STS-mode- progression-readiness empirical input - the spoke's per-day per-MX-host successful-vs-failed STARTTLS session-count aggregation is the LOAD-BEARING empirical-readiness gate the per-customer-domain operator uses to advance per-customer-domain MTA-STS policy from testing to enforce across the transactional-ESP-cohort customer portfolio (per-customer-domain total-failure-session-count baseline must be sustained-low at the per-receiver-per-day level before flipping to per-customer-domain enforce mode); and (iv) per-failure sending-mta-ip / receiving-mx-hostname / failure-reason-code as per-customer-domain per-receiver per- day per-ESP-cohort cross-receiver consistency-deviation incident-triage primitive - when one receiver shows sustained certificate-host-mismatch on per-customer-domain transactional traffic from a specific sending-mta-ip in the SendGrid/Mailgun/Postmark/SparkPost/SES cohort while peer receivers show clean STARTTLS, the per-failure attribution lets per-customer operators attribute the failure to a specific receiving-MX- hostname vs a per-ESP cohort certificate misconfiguration. Pair THIS transactional-email DMARC deployment reference with the TLS-RPT- report-format spoke when designing the per-transactional-ESP-cohort per- customer-domain cross-protocol-pillar observability discipline that fuses the per-customer DMARC RUA-XML message- layer evidence stream with the per- customer TLS-RPT-JSON transport-layer evidence stream into the unified per- customer-domain authentication-and- encryption-posture observability surface every production-grade transactional-platform deployment STRUCTURALLY DEPENDS on for per- customer-domain OTP/MFA/password-reset deliverability closure.
• MTA-STS for Microsoft 365 Four transactional-ESP-to-M365-MTA-STS cross-provider coordination dimensions: (i) per-message OTP / MFA / password-reset transactional class as time-sensitive delivery target where MTA-STS-policy-fetch failures cause silent same-cycle bounces — when the recipient M365 tenant's MTA-STS HTTPS policy host suffers a cert-chain failure (expired cert, hostname mismatch, CAA-permitted-CA renewal break), the transactional ESP's sending MTA in MTA-STS-aware mode reports a sts-policy-fetch-error to TLS-RPT and either falls back to opportunistic-STARTTLS (degrading transport security but preserving delivery) or hard-bounces the per-message OTP within the user's password-reset retry window; (ii) per-transactional-ESP outbound IP-pool reputation interaction with per-M365-tenant MX TLS-handshake-cert-trust evaluation — when the M365 tenant's MTA-STS policy-file mx:-directive list authorises only *.mail.protection.outlook.com hostname patterns (the canonical EOP MX hostname namespace), the per-transactional-ESP-managed bounce-domain MX (envelope MAIL-FROM rewriting at SendGrid / Mailgun / Amazon SES / Postmark) is OFF-PATH from the recipient's MTA-STS contract — the transactional ESP's STARTTLS handshake to the M365 MX is what the M365 MTA-STS policy actually gates, not the per-ESP-managed return-path infrastructure; (iii) per-ESP-managed outbound IP-pool STARTTLS-handshake-cert-presentation discipline as TLS-RPT-observed quality signal — every transactional ESP outbound IP-pool that does not present a chain-validating cert at the recipient's STARTTLS handshake causes the M365 MX to log a per-source-IP starttls-not-supported failure into the per-tenant TLS-RPT JSON stream, which the M365 customer's deliverability team uses to deauthorise misbehaving ESPs at the per-tenant accept-list boundary; (iv) per-customer-domain DKIM-CNAME-delegation cohabitation with per-M365-tenant MTA-STS enforcement — when the transactional ESP customer (sending OTPs to M365-hosted recipients) is also AN M365 tenant in its own right, the customer-domain operator publishes BOTH outbound DKIM-CNAME records (for transactional-ESP signing under the customer-domain d=) AND inbound MTA-STS records (for receiving customer-side mail at the customer's M365 tenant), and per-RR cadence drift between these two parallel publication disciplines produces correlated transactional outbound and inbound deliverability regressions the unified operator team must coordinate. Read the M365 MTA-STS spoke alongside this transactional-email guide when the transactional sender is targeting M365-hosted recipient populations (B2B enterprise customer bases skewed toward Exchange Online), when planning the transactional ESP's outbound STARTTLS handshake-cert-presentation discipline to satisfy per-recipient-tenant MTA-STS enforce-mode contracts, or when investigating per-customer-domain OTP/MFA/password-reset deliverability drops correlating with recipient-tenant TLS-RPT sts-policy-fetch-error patterns.
• MTA-STS for Google Workspace — the Workspace-tenant twin of the M365 MTA-STS reference above: when the transactional ESP targets Google-Workspace-hosted recipient populations, the recipient Workspace tenant's enforce-mode MTA-STS policy (mx: *.google.com allow-list at https://mta-sts.<workspace-domain>/.well-known/mta-sts.txt) is the load-bearing transport-layer delivery gate for OTP/MFA/password-reset mail. The transactional ESP's outbound IP-pool must present a chain-validating STARTTLS certificate to the Workspace inbound MX or the message is downgraded/deferred; per-recipient-tenant TLS-RPT then logs the per-source-IP failure the deliverability team uses to deauthorise misbehaving ESPs. Read the Workspace and M365 MTA-STS spokes together when sizing the transactional sender's STARTTLS-cert-presentation discipline across both major enterprise mailbox providers.
• MX records explained — the TRANSACTIONAL-ESP-CUSTOMER-DOMAIN-MX-RR- AS-BOUNCE-AND-REPORT-LOOPBACK-PREREQUISITE companion to this transactional-email deployment reference. Where THIS page documents the transactional-sender deployment workflow across ESP integrations (per-ESP SPF include-token publication, per-ESP DKIM CNAME-delegated signing-key publication, per-ESP envelope-from / header-from alignment coordination, per-ESP bounce / suppression / feedback-loop ingestion), the MX-records spoke is the APEX-MX-RR-PUBLICATION reference transactional-mail operators consult when verifying the customer-domain apex MX RRset remains continuously resolvable so the per-ESP-managed bounce- domain return-path routing AND the per- customer-domain DMARC aggregate / forensic report cron can actually deliver back to the customer mailbox. Three structurally- distinct transactional-ESP-MX-RR-coordination dimensions emerge: (i) per-customer-domain apex MX RR continuity gates whether receiver-generated DMARC aggregate reports can reach the customer's rua=mailto: mailbox — a mis-edited apex MX drops the DMARC observability the transactional sender relies on to gate per-customer-domain policy ramps; (ii) ESP-rewritten bounce-domain VERP MX (the per-ESP-managed Return-Path host the customer's domain delegates to the ESP via subdomain CNAME / NS delegation) is OFF-PATH from the customer's apex MX — the customer's transactional sender posture depends on BOTH publications being independently resolvable; (iii) every Edit DNS Zone MX-record edit on the customer's apex domain that mis-orders preference values between primary and failover MX hosts silently breaks BOTH inbound mail delivery AND the publisher's per-domain DMARC reporting loopback, turning the customer's rua= / ruf= tags into silently-discarded configurations the transactional sender's deliverability team cannot observe.
• DKIM cryptography basics — the TRANSACTIONAL-ESP-PER-CUSTOMER-DOMAIN- CNAME-DELEGATED-SIGNING-KEY-CRYPTOGRAPHIC- PRIMITIVE-CHOICE-AS-LOAD-BEARING-CRYPTOGRAPHIC- TRUST-POSTURE companion to this transactional- email deployment reference. Where THIS page documents the transactional-sender deployment workflow across ESP integrations (per-ESP SPF include-token publication, per-ESP DKIM CNAME-delegated signing-key publication, per-ESP envelope-from / header-from alignment coordination, per-ESP bounce / suppression / feedback-loop ingestion), the DKIM- cryptography-basics spoke is the CRYPTOGRAPHIC-PRIMITIVE-CHOICE reference the transactional-mail customer-domain operator consults when verifying the per-ESP-generated signing-key satisfies the per-customer-domain cryptographic-strength floor. Four per- transactional-ESP cryptographic-coordination dimensions: (i) PER-ESP-DEFAULT-KEY-SIZE-VS- CUSTOMER-DOMAIN-CRYPTOGRAPHIC-FLOOR (every ESP defaults to RSA-2048 per RFC 8301 §3 but the per-customer-domain operator must verify the published p= tag chunked per RFC 1035 §3.3.14 actually carries a 2048- bit modulus rather than a legacy 1024-bit modulus inherited from an earlier ESP-account provisioning generation); (ii) PER-ESP- OPTIONAL-ED25519-VS-CUSTOMER-DOMAIN-RECEIVER- COMPATIBILITY (Ed25519 per RFC 8463 produces smaller TXT-record payloads avoiding EDNS0 truncation but is not yet universally supported across the receiver population — transactional senders cannot unilaterally upgrade to Ed25519 without bounded-A/B receiver-compatibility-window measurement); (iii) PER-ESP-PER-CUSTOMER-DOMAIN-CNAME- DELEGATION-TRUST-BOUNDARY (the per-ESP- managed signing-key generation happens inside the ESP's HSM / KMS infrastructure; the customer-domain operator's CNAME delegation transfers per-message signing authority to the ESP's per-tenant key custody — the underlying cryptographic-primitive choice IS load-bearing trust-perimeter the customer cannot independently audit); (iv) PER-RECEIVER-PER-RECURSIVE-RESOLVER-TXT-RR- FETCH-SURVIVAL-WINDOW (RSA-2048 p= public-key payloads at ~395 bytes plus DKIM-tag-list overhead fit within EDNS0 4096-byte UDP responses; legacy RSA-1024 ESPs producing ~215-byte public keys are smaller still; future RSA-3072 or RSA-4096 upgrades would tip into TCP-fallback territory the cryptography-basics primer documents the per-key-size budget for). Read the DKIM-cryptography-basics spoke alongside this transactional-email guide when ONBOARDING a new ESP integration whose per-customer-domain CNAME-delegated signing- key generation default needs cryptographic- primitive verification, when MIGRATING between transactional ESPs across cryptographic-primitive default disparities, or when AUDITING per-customer-domain DKIM- signing posture against per-receiver per- domain cryptographic-strength compliance floors.
• RFC 7489 - DMARC - the foundational DMARC specification.
• RFC 7208 - SPF - Sender Policy Framework, including the section 4.6.4 10-DNS-lookup limit referenced in sections 7.3 and 11.2.
• RFC 6376 - DKIM - DomainKeys Identified Mail signatures.
• RFC 8617 - ARC - Authenticated Received Chain.
• RFC 8601 - Authentication-Results - the header format every receiver uses to stamp its verdict.
• RFC 8058 - One-Click Unsubscribe - the List-Unsubscribe POST mechanism required by the Feb 2024 Gmail / Yahoo bulk-sender requirements.
• 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 verifying your transactional email 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 ESPs are aligning cleanly and which are not; the per-reporter drilldown (reporter_detail.php) shows which receivers (Google, Microsoft, Yahoo, La Poste, Mail.ru) are receiving your authenticated transactional mail. The header_analyzer.php tool (built on includes/EmailHeaderParser.php) diagnoses single-message alignment when a user reports a missing password reset. The domain_checker.php tool (built on includes/DnsChecker.php) live-resolves every CNAME chain so you can confirm a new ESP's DKIM setup before sending the first message. Forensic (ruf) failure samples land via upload.php through includes/ForensicReportParser.php for spoofing investigation.

Check my domain configuration Sign up — Free plan