DMARC Analyzer

TL;DR

• This guide covers Plesk, DirectAdmin, ISPConfig, Webmin / Virtualmin, CentOS Web Panel (CWP), and generic no-control-panel shared hosting. For cPanel specifically, see the DMARC for cPanel & Shared Hosting sibling page - cPanel has a different management UI and is the largest single shared-hosting ecosystem, justifying its own guide.
• Plesk auto-configures Postfix outbound but does NOT auto-enable DKIM. Open Mail > Mail Settings > DKIM spam protection (or older Plesk: Tools and Settings > Mail Server Settings > DomainKeys) and enable DKIM. Default selector is default._domainkey (same as cPanel and ISPConfig). SPF is NOT auto-published - add v=spf1 +a +mx ~all manually via Plesk's DNS Settings.
• DirectAdmin auto-configures Exim outbound and the DKIM toggle lives at Email Manager > DKIM. Default selector is x._domainkey (single-character "x" by historical convention - distinct from cPanel's default and Plesk's default). SPF auto-generated as v=spf1 a mx ~all at account creation.
• ISPConfig exposes DKIM at Email > Domain > DKIM; the panel generates the key and prompts the operator to publish the TXT record. Default selector is default._domainkey.
• Generic no-control-panel shared hosting has no self-service DKIM toggle. Three escape hatches: (1) open a support ticket asking the provider to enable DKIM signing; (2) route outbound mail through a SaaS transactional relay (SendGrid, Mailgun, Amazon SES, Postmark) with CNAME-delegated DKIM so alignment works via the relay's signing infrastructure; (3) migrate to a host with a deliverability-focused control panel. Option 2 is the most operator-empowering path because it works for any host.
• Google's Feb 2024 bulk-sender requirements apply to shared- hosting senders too: SPF + DKIM alignment, DMARC at minimum p=none (bulk senders strongly encouraged at p=quarantine or stronger), RFC 8058 one-click List-Unsubscribe, and spam-complaint rate < 0.3% for any domain sending >5000 messages/day to gmail.com or yahoo.com.
• DMARC rollout (universal regardless of panel): v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com first. Ingest reports for 2-6 weeks to inventory every sender. Advance to p=quarantine after every legitimate sender is aligned, then to p=reject. Never skip from p=none to p=reject.
• The operator-empowerment ceiling is the defining shared-hosting constraint. The less featureful your panel, the more DMARC work depends on hosting-provider support or the SaaS-relay escape hatch. For bulk and marketing-scale sending, the recommended pattern is to bypass the host's outbound mail entirely and route through a dedicated transactional relay with reputation isolation.

1. What this guide covers

This is the operator-implementation walkthrough for deploying SPF, DKIM, and DMARC on a domain hosted on the shared-hosting tier other than cPanel. The cluster covers cPanel separately in DMARC for cPanel & Shared Hosting because cPanel is the largest single shared-hosting ecosystem and its UI is sufficiently distinctive to merit a dedicated guide. This page covers the remainder of the shared-hosting market:

• Plesk - the second-largest shared-hosting control panel by market share, dominant in Europe and Russia. Default mail server: Postfix (Plesk Obsidian and newer) or Qmail (legacy Plesk versions on older RHEL-derived servers). DKIM toggle: Mail Settings > DKIM spam protection.
• DirectAdmin - a popular cPanel alternative with a lighter UI and per-account focus. Default mail server: Exim (same as cPanel). DKIM toggle: Email Manager > DKIM.
• ISPConfig - open-source Linux server control panel popular with managed-service-provider (MSP) and German-speaking-market hosts. Default mail server: Postfix + Dovecot. DKIM toggle: Email > Domain > DKIM.
• Webmin / Virtualmin - the veteran Linux server control panel with deep configuration flexibility. Default mail server: Postfix on Virtualmin (Sendmail and Exim are configurable). DKIM toggle: Email Settings > DomainKeys Identified Mail (DKIM).
• CentOS Web Panel (CWP) - free CentOS / RHEL control panel with an Exim mail backend. DKIM toggle: Email > Add new email account and the DKIM block in the per-domain configuration.
• Generic shared hosting WITHOUT a deliverability-focused control panel - the entire population of hosts whose customers have NO self-service DKIM management: just FTP access, phpMyAdmin for databases, a webmail interface, and the hosting provider's support form. This is the LEAST operator-empowered tier and the page dedicates section 5b to the three escape hatches available.

The guide is structured as five sequential deployment steps (SPF → DKIM → DMARC at p=none → alignment fix-up → enforcement) that mirror the canonical DMARC rollout with panel-specific UI paths, syntax, and gotchas.

What this guide does not cover:

• cPanel - covered in DMARC for cPanel & Shared Hosting.
• Microsoft 365 and Google Workspace - covered in DMARC for Microsoft 365 and DMARC for Google Workspace respectively. These are mailbox-provider platforms, not shared-hosting tiers - the operator buys mailbox capacity and the platform handles outbound mail without operator infrastructure.
• Reseller hosting configuration - reseller-tier access to Plesk / DirectAdmin / ISPConfig varies by hosting provider. Where reseller capabilities matter (e.g. multi-account DKIM rotation), the guide notes the feature without a comprehensive walkthrough.
• Inbound spam filtering and anti-phishing at the shared- hosting server (SpamAssassin, Rspamd, Amavis) - separate from DMARC and out of scope for this guide.

2. Why DMARC matters now: Feb 2024 requirements + operator-empowerment ceiling

In February 2024 Google (jointly with Yahoo) introduced sender requirements that apply to any domain sending more than 5000 messages per day to gmail.com or yahoo.com combined - regardless of which hosting platform or control panel sends the mail. Shared-hosting senders that exceed the threshold are subject to the same enforcement as cPanel, Workspace, or M365 senders.

The five Feb 2024 requirements:

1. SPF must pass and align with the visible From: header (RFC 7208).
2. DKIM must pass and align with the visible From: header (RFC 6376).
3. DMARC TXT record published with at minimum p=none - bulk senders strongly encouraged to advance to p=quarantine or p=reject.
4. RFC 8058 one-click List-Unsubscribe on every commercial / marketing message.
5. Spam complaint rate < 0.3% as measured at the receiver.

The operator-empowerment ceiling

Shared hosting has a structural constraint that distinguishes it from cPanel / Workspace / M365: operator empowerment varies drastically by control panel. The less featureful your panel, the more DMARC work depends on hosting-provider support intervention.

Operators on the generic-no-control-panel tier are the most operator-disempowered population in the entire mailbox-provider spectrum. For this tier, the recommended path is the SaaS-relay escape hatch (section 5b): route outbound mail through a SaaS transactional relay (SendGrid, Mailgun, Amazon SES, Postmark) with CNAME-delegated DKIM so alignment works via the relay's signing infrastructure. This pattern works for ANY shared host because it bypasses the host's outbound mail entirely.

DMARC at p=quarantine or p=reject stops domain spoofing but does NOT compensate for shared-IP reputation - the same constraint that affects cPanel. Both layers must be addressed independently. Deploy DMARC for the spoofing layer regardless of volume; address deliverability separately by choosing the right outbound infrastructure for your volume.

3. Prerequisites

• Control panel access for Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP. Most hosting providers expose the panel at https://<your-domain>:8443 (Plesk default), at a vendor URL like https://<your-domain>:2222 (DirectAdmin default), or via the hosting provider's portal. You need the per- account login.
• OR support-ticket lever if you have NO control panel access. Verify the hosting provider supports DKIM at all before deploying - some bargain-tier hosts ship without DKIM signing infrastructure and will require a support escalation or a migration to a different host.
• OR a SaaS-relay account (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost) if you plan to bypass the host's outbound mail entirely. Most have free tiers up to 100-1000 messages/day (Mailgun: 1000/month free, SendGrid: 100/ day free, Amazon SES: paid but very inexpensive at scale).
• DNS edit access for the primary domain. Shared-hosting panels may manage DNS at the panel server (Plesk DNS Settings, DirectAdmin DNS Management), at the hosting provider's portal, or at an external registrar. Identify where your DNS lives BEFORE attempting to publish records - the panel UI may appear to publish a record but actually only write to the panel-server zone file, which is not consulted by public resolvers if your authoritative DNS is elsewhere.
• A monitored mailbox on the domain (or a third-party DMARC report ingestion service such as DMARC Analyzer). Reports arrive as gzip-compressed XML attachments - a typical setup uses a dedicated address like dmarc-reports@your-domain.com.
• Inventory of every legitimate sender for the domain. The host's mail (via Plesk / DirectAdmin / ISPConfig) is the obvious source, but most small businesses also have a marketing platform (Mailchimp), a transactional relay (SendGrid / Mailgun), a contact-form mailer, ecommerce platform email (WooCommerce / Shopify with custom domain), and potentially a self-hosted WordPress plugin that bypasses the host's outbound mail.

4. Step 1: Verify or publish SPF

SPF auto-generation varies by panel:

• Plesk does NOT auto-publish SPF. Add a TXT record at the domain apex manually:

  your-domain.com.   IN TXT  "v=spf1 +a +mx include:<hosting-provider-spf-host> ~all"

  via Plesk's Websites & Domains > DNS Settings (or your registrar's DNS panel if DNS is external). The include: depends on the hosting provider - check the provider's documentation.
• DirectAdmin auto-generates SPF at account creation. Default value: v=spf1 a mx ~all. Verify via Account Manager > DNS Management. Add provider-specific include: directives if your host requires them.
• ISPConfig, Webmin / Virtualmin, CWP do NOT auto-publish SPF. Add the TXT record manually via the panel's DNS-management interface or your registrar's DNS panel.
• Generic no-control-panel: publish SPF via your registrar's DNS panel. The include: depends on whether you send through the host or a SaaS relay - for a relay-only flow, use v=spf1 include:<relay-spf-host> -all with the host's outbound completely excluded.

Typical SPF record patterns:

# Plesk-style (host-only outbound)
your-domain.com.   IN TXT  "v=spf1 +a +mx ~all"

# DirectAdmin-style with SaaS relay added
your-domain.com.   IN TXT  "v=spf1 a mx include:sendgrid.net ~all"

# SaaS-relay-only flow (no host outbound at all)
your-domain.com.   IN TXT  "v=spf1 include:mailgun.org -all"

Verify with dig +short txt your-domain.com after publication, or via the Domain Security Checker. If you also send via third-party providers (SendGrid, Mailgun, Mailchimp), add each provider's include: in the same record (RFC 7208 §3.2 mandates a single SPF record per domain). Stay under the 10-DNS-lookup limit (RFC 7208 §4.6.4).

Harden the qualifier from ~all (soft-fail) to -all (hard-fail) once your DMARC reports show clean SPF passes for every legitimate sender. Hard fail is the production recommendation.

5. Step 2: Verify or publish DKIM

DKIM activation walkthroughs vary per panel. Each section below is independently usable.

5a. Plesk: Mail Settings > DKIM spam protection

1. Sign in to Plesk. Select your subscription / domain.
2. Navigate to Mail > Mail Settings (Plesk Obsidian) or Tools and Settings > Mail Server Settings (older Plesk).
3. Find the DKIM spam protection section. Two checkboxes: Use DKIM spam protection system to sign outgoing email messages and Use DKIM spam protection system to check incoming email messages. Enable the OUTGOING checkbox.
4. Click OK. Plesk generates a 1024-bit (legacy) or 2048-bit (modern) RSA key and publishes the public key at default._domainkey.<your-domain> as a TXT record in Plesk's DNS zone (if Plesk is authoritative). If DNS is external, Plesk shows the TXT record value for you to publish at your registrar.
5. Verify externally with dig +short txt default._domainkey.your-domain.com. Expected output: v=DKIM1; k=rsa; p=<long-base64-public-key>.

Typical Plesk DKIM record:

default._domainkey.your-domain.com.   IN TXT  "v=DKIM1; k=rsa; p=<long-base64-public-key>"

5a-i. DirectAdmin: Email Manager > DKIM

1. Sign in to DirectAdmin. Select your domain from the domain dropdown.
2. Open Email Manager > DKIM.
3. Click Enable. DirectAdmin generates a 1024-bit RSA key (configurable to 2048-bit in modern DirectAdmin versions) and publishes the public key at x._domainkey.<your-domain> (DirectAdmin uses the single-character x selector by historical convention).
4. Verify externally with dig +short txt x._domainkey.your-domain.com.

Typical DirectAdmin DKIM record:

x._domainkey.your-domain.com.   IN TXT  "v=DKIM1; k=rsa; p=<long-base64-public-key>"

5a-ii. ISPConfig: Email > Domain > DKIM

1. Sign in to ISPConfig as an administrator or email-admin user.
2. Open Email > Domain. Select your domain.
3. Open the DKIM tab. Check Enable DKIM. Click Generate DKIM Private-key - ISPConfig generates a 2048-bit RSA key and shows the DNS-record value (selector: default).
4. Publish the displayed TXT record at default._domainkey.<your-domain> via your DNS provider.
5. Click Save to activate signing. ISPConfig configures Amavis + Postfix to sign outbound mail with the generated key.

5a-iii. Webmin / Virtualmin: Email Settings > DKIM

1. Sign in to Virtualmin as root.
2. Open System Settings > Email Settings > DomainKeys Identified Mail (DKIM).
3. Set Signing of outgoing mail enabled? to Yes. Select the Selector for DKIM record name (Virtualmin defaults to default but allows operator customization).
4. Click Save and Apply. Virtualmin generates the key, publishes the TXT record in its DNS zone (if authoritative), and configures OpenDKIM + Postfix.

5a-iv. CWP (CentOS Web Panel)

1. Sign in to CWP at port 2031 (admin) or 2083 (user).
2. Open Email > Email Authentication (admin) or the per-domain DKIM block under Email (user).
3. Enable DKIM for the domain. CWP generates the key (default selector: default) and publishes the TXT record in its DNS zone.

5b. Generic no-control-panel: the three escape hatches

If you have no DKIM toggle in your panel (or no panel at all), pick one of three paths:

1. Support-ticket DKIM activation. File a ticket with the hosting provider: "Please enable DKIM signing for outbound mail on domain <your-domain> and publish the public key at default._domainkey.<your-domain>". Most providers will action this within a business day. Note that this only works if the provider's MTA (Exim or Postfix) is configured to sign with OpenDKIM or rspamd - a small fraction of bargain-tier hosts ship without DKIM infrastructure at all.
2. SaaS-relay CNAME-delegated DKIM (the recommended path for operators who value DMARC alignment more than the cost of a transactional relay). Sign up for SendGrid / Mailgun / Amazon SES / Postmark / SparkPost. Each provides a "domain authentication" or "sender authentication" interface that prompts you to publish a CNAME like s1._domainkey.<your-domain> CNAME s1.domainkey.u12345.relay-host.net - the CNAME delegates the DKIM key lookup to the relay's signing infrastructure. Route outbound mail through the relay via SMTP submission (port 587 with TLS) or the relay's REST API; every message is signed with d=your-domain and aligns with your visible From: header.

   # SendGrid-style CNAME-delegated DKIM
   s1._domainkey.your-domain.com.   IN CNAME  s1.domainkey.u12345.wl001.sendgrid.net.
   s2._domainkey.your-domain.com.   IN CNAME  s2.domainkey.u12345.wl001.sendgrid.net.
   
   # Mailgun-style CNAME (technically a TXT delegation in their interface)
   mailo._domainkey.your-domain.com.   IN TXT  "k=rsa; p=<mailgun-managed-key>"

3. Migrate to a host with a deliverability-focused control panel (cPanel, Plesk, DirectAdmin). The highest-friction option; warranted if your business critically depends on mail deliverability and you have outgrown the bargain-tier host's capability.

5c. Verification (universal)

Verify by sending a test message to a Gmail or Yahoo address you control. Open Show original (Gmail) or the equivalent raw-source view. The Authentication-Results header should show dkim=pass header.d=your-domain.com header.s=<your-selector>.

Key rotation: shared-hosting panels do NOT rotate selectors automatically. Plan a manual rotation every 6-12 months by generating a new key with a new selector, publishing both selectors during the transition window, switching the panel configuration to the new selector, then retiring the old.

6. Step 3: Publish DMARC at p=none

None of the shared-hosting panels auto-publish DMARC - the rua= mailbox is operator-specific. Publish manually via the panel's DNS interface (Plesk DNS Settings, DirectAdmin DNS Management, ISPConfig DNS Manager, Webmin BIND DNS Server, CWP DNS Functions) or via your registrar's DNS panel if DNS is external.

1. Open your DNS management interface.
2. Add a TXT record at _dmarc.your-domain.com with the value v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com; fo=1.
3. Save / publish the record.

Tags explained:

• v=DMARC1 - protocol version, always first.
• p=none - the reporting-only phase. Receivers will NOT change disposition based on DMARC outcomes; instead they will send daily aggregate reports describing every authentication result.
• rua=mailto:dmarc-reports@... - destination for daily aggregate (RUA) reports.
• fo=1 - request a forensic (RUF) report on any DMARC failure (most major receivers do not send forensic reports - see DMARC aggregate reports deep dive).

Confirm the record is live with dig +short txt _dmarc.your-domain.com or via DMARC Analyzer's Domain Security Checker. Reports begin arriving within 24-48 hours.

7. Step 4: Inventory legitimate senders and fix alignment

Read aggregate reports for 2-6 weeks. For each unique sending IP / sending domain combination, determine:

• Is this a legitimate sender? Your shared-hosting MTA is obvious; the WordPress plugin you installed two years ago may not be.
• Is the sender aligned? Either SPF must pass AND the envelope MAIL FROM domain match your visible From: header (organisational-domain match for relaxed alignment), OR DKIM must pass AND the d= in the signature match your visible From: header.
• If not aligned, what is the gap? Three shared-hosting- specific patterns dominate the alignment-failure surface:
  • The provider-bounce-domain pattern - some shared hosts rewrite the envelope MAIL FROM to a provider- controlled domain, so SPF passes for the provider but does not align with your visible From:. DKIM alignment (via the panel-issued DKIM signature) still works correctly because DKIM is independent of envelope rewriting - assuming DKIM is enabled on the panel.
  • The DKIM-not-enabled pattern - the most common shared-hosting failure mode on Plesk specifically. The operator deployed DMARC but skipped the Plesk DKIM activation step. Without DKIM, the only alignment path is SPF, which breaks under envelope-rewriting hosts. Fix: enable DKIM via Mail Settings > DKIM spam protection (Plesk) or the equivalent panel toggle.
  • The SaaS-sender pattern - a third-party service (SendGrid, Mailgun, Customer.io, Mailchimp) sends with the From: header set to your-domain but its own bounce domain. Fix by enabling CNAME-delegated DKIM with d=your-domain in the SaaS provider.

Continue iterating until every legitimate sender shows in reports as DMARC-pass. The DMARC Analyzer dashboard breaks down per source IP and per sending organisation so each unaligned sender is identifiable.

8. Step 5: Advance from p=quarantine to p=reject

Once every legitimate sender is aligned, advance the DMARC record to p=quarantine:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-domain.com; fo=1"

Edit the existing _dmarc TXT record in your panel's DNS interface (or your registrar's DNS panel) - change p=none to p=quarantine. Receivers begin delivering DMARC-failing mail to spam. A common pattern: a WordPress plugin that sends weekly newsletters from an unaligned SMTP configuration surfaces in the first week at p=quarantine.

After 1-3 months at p=quarantine without unexpected failures, advance to p=reject:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com; fo=1"

DMARC-failing mail is now bounced at the SMTP boundary. Spoofing of your domain at DMARC-honouring receivers is no longer possible. You have completed the rollout.

Never skip from p=none to p=reject. The p=quarantine intermediate phase exists specifically so failed mail goes to spam (recoverable) rather than bouncing (unrecoverable). The single most common self-inflicted email outage in DMARC rollouts is skipping this phase. See the DMARC policy rollout deep dive for the full rationale.

For granular ramping, use the pct= tag: p=quarantine; pct=5 applies the quarantine disposition to 5% of failing mail, leaving 95% at p=none. RFC 7489 §6.3 defines the semantics; note that the dmarcbis draft deprecates pct= so this is a transitional feature.

9. Shared-hosting gotchas

• Operator-empowerment ceiling. Covered in section 2. The defining shared-hosting constraint: the less featureful your panel, the more DMARC work depends on hosting-provider support or the SaaS-relay escape hatch.
• DNS hosted at the registrar, not the panel. The panel's DNS interface will let you publish records to its local zone file, but if your authoritative DNS lives at Cloudflare, Route 53, or your registrar, public resolvers will never see those records. Verify with dig +short ns your-domain.com - if the nameservers are NOT the panel host's nameservers, publish DNS records at the registrar / external DNS provider.
• WordPress plugins bypassing the panel. The wp_mail() function in WordPress is widely overridden by SMTP plugins (WP Mail SMTP, Easy WP SMTP, FluentSMTP) that route outbound through a third-party SMTP relay - bypassing the panel's DKIM signing entirely. Either configure the SMTP plugin to use the panel server's SMTP (so DKIM is applied) or configure the plugin's third-party SMTP to sign DKIM with d=your-domain under a CNAME-delegated selector.
• Plesk DKIM disabled by default. Unlike DirectAdmin and cPanel, Plesk does NOT enable DKIM at account creation - the operator must explicitly enable it via Mail Settings > DKIM spam protection. The most common Plesk DMARC failure mode is skipping this step.
• Postfix vs Exim signing infrastructure. Plesk and ISPConfig run Postfix; DirectAdmin and CWP run Exim. Both work the same way operationally (the panel toggle enables the appropriate signing milter or filter) but if you ever need to inspect the MTA configuration directly (e.g. via SSH), the configuration files differ: /etc/postfix/main.cf + OpenDKIM milter for Postfix, /etc/exim.conf + dkim_signing block for Exim.
• Per-tenant key vs server-wide key. Some bargain-tier shared hosts sign all outbound mail with a SERVER-WIDE DKIM key whose d= is the hosting provider's domain rather than per- tenant. In this configuration DKIM alignment is structurally impossible for tenants because d= can never match the tenant's From: header. The fix is either to demand per-tenant DKIM from the provider, route mail through a SaaS relay with per-tenant DKIM, or migrate hosts.

10. Common shared-hosting + DMARC mistakes

1. Deploying DMARC on Plesk without first enabling DKIM. The #1 Plesk failure mode. Without DKIM, the only alignment path is SPF, which breaks under envelope-rewriting hosts. Enable DKIM at Mail Settings > DKIM spam protection BEFORE advancing past p=none.
2. Assuming all shared-hosting panels use the "default" selector. DirectAdmin uses x, not default. Always verify with dig +short txt <selector>._domainkey.your-domain.com for whichever selector your panel uses.
3. Publishing DNS records at the panel when authoritative DNS lives elsewhere. Plesk DNS Settings, DirectAdmin DNS Management, etc. will accept the record but it will not be visible to public resolvers. Verify your nameservers with dig +short ns your-domain.com before deciding where to publish.
4. Forgetting to advance past p=none. The reporting-only phase does NOT stop spoofing. Advance to enforcement after 2-6 weeks of clean reports.
5. Filing a support ticket but publishing DMARC before the provider enables DKIM. The host's outbound mail will fail DMARC for the gap window. Either delay DMARC publication until the support ticket is closed AND DKIM is verified, or publish DMARC at p=none (which never quarantines / rejects) and advance to enforcement only after DKIM is confirmed working.
6. Two SPF records on the same domain. RFC 7208 §3.2 mandates a single SPF record. If you add a SaaS-sender include, MERGE it into the existing panel-generated record - do not publish a second TXT.
7. SPF over 10 DNS lookups. The panel-host include plus several third-party include: directives commonly blow the limit. Use Domain Security Checker to count lookups.
8. Skipping the WordPress plugin audit. WordPress installations typically send mail through paths that bypass the panel's signing. Configure WP Mail SMTP / equivalent to route via the panel SMTP endpoint OR to sign DKIM under your domain via the third-party SMTP's authentication settings.
9. Treating server-wide DKIM as per-tenant DKIM. If your host signs with d=<hosting- provider>.com (verify in the DKIM-Signature header on a test message), per-tenant alignment is structurally impossible. Move to a host or relay that signs with d=your-domain.
10. Publishing DMARC at p=reject without alignment fix-up. The fastest path to a self-inflicted email outage. Always ingest reports at p=none for 2-6 weeks first.

11. Troubleshooting

• "DKIM not signing despite enabling the panel toggle". Send a test message to a Gmail address; open Show Original. If dkim=none appears in the Authentication-Results header, the signing infrastructure is not active on the server - file a support ticket with the hosting provider. Common cause on Plesk: OpenDKIM is not installed at the OS level even though the toggle is exposed in the panel UI.
• "My shared-hosting mail goes to spam at Gmail despite all three records passing". Diagnose shared-IP reputation: dig +short a mail.<your-host-server> then check the IP at Blacklist Checker. If the IP is on a major blocklist (Spamhaus, SORBS, Barracuda), the deliverability problem is upstream of DMARC. Move bulk sending off shared hosting; for transactional volume, switch to a SaaS relay with a clean outbound IP.
• "DMARC reports show DKIM header.d=<hosting-provider>.com, not my custom domain". The host signs with a server-wide DKIM key whose d= is the provider's domain rather than per-tenant. Per- tenant alignment is structurally impossible in this configuration. Either demand per-tenant DKIM, route through a SaaS relay, or migrate hosts.
• "DMARC reports show DKIM pass + SPF pass but DMARC fail". An alignment failure. The SPF-passing domain or DKIM-signing domain does not match the visible From: header. See DMARC alignment explained for the deep dive.
• "My SPF record is failing with permerror". Almost always the 10-DNS-lookup limit. Run Domain Security Checker.
• "How do I inspect Plesk's outbound mail queue?" Plesk > Tools and Settings > Mail Server Settings > Mail Queue shows pending Postfix messages. From the command line:

  postqueue -p            # Postfix queue list
  mailq                   # alias for postqueue -p
  postqueue -f            # flush queue (retry deferred messages)
  postsuper -d <message-id>  # delete a stuck message

• "How do I inspect DirectAdmin's Exim queue?" DirectAdmin > Admin Tools > Mail Queue Administration. From the command line:

  exim -bp                  # list queue
  exim -bpc                 # queue size count
  exim -Mvh <message-id>    # view message headers
  exim -Mrm <message-id>    # remove a stuck message

• "I have no panel access and no SSH access". You are on the most-restrictive shared-hosting tier. Pick the SaaS-relay escape hatch from section 5b: bypass the host's outbound mail entirely and route through a transactional relay with CNAME- delegated DKIM. This is the only operator-empowering option on this tier.

12. Frequently asked questions

How do I set up DMARC on Plesk?

Five steps. Open Mail > Mail Settings > DKIM spam protection and enable DKIM signing. Verify the public key at default._domainkey.<your-domain>. Add SPF manually at the domain apex (Plesk does NOT auto-publish SPF). Publish DMARC at _dmarc via Plesk's DNS Settings. Ingest reports for 2-6 weeks, align every legitimate sender, advance through p=quarantine to p=reject.

How do I set up DMARC on DirectAdmin?

Five steps. Open Email Manager > DKIM and click Enable. Verify the public key at x._domainkey.<your-domain> (DirectAdmin uses the single-character x selector). DirectAdmin auto-generates SPF as v=spf1 a mx ~all; verify and tighten to -all after DMARC reports confirm clean alignment. Publish DMARC at _dmarc via DNS Management. Advance through p=quarantine to p=reject after 2-6 weeks.

What DKIM selector do Plesk and DirectAdmin use?

Plesk: default. DirectAdmin: x. ISPConfig: default. Webmin / Virtualmin: default by default but operator-configurable. CWP: default. cPanel: default. There is no industry-wide convention - verify with dig +short txt <selector>._domainkey.<your-domain> for whichever selector your panel uses.

How do I deploy DMARC if my shared host has no control panel?

Three escape hatches: (1) file a support ticket asking the hosting provider to enable DKIM signing for outbound mail; (2) route outbound mail through a SaaS transactional relay (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost) with CNAME-delegated DKIM so alignment works via the relay; (3) migrate to a host with a deliverability-focused control panel. Option 2 is the most operator- empowering path because it works for any host.

How is shared hosting different from cPanel, Plesk, or DirectAdmin for DMARC?

cPanel, Plesk, and DirectAdmin are specific control panels with self- service DKIM toggles - the operator can deploy DMARC end-to-end without contacting hosting support. Generic shared hosting WITHOUT a deliverability- focused control panel has no such lever - the operator depends on hosting-provider support or the SaaS- relay escape hatch. The fundamental distinction is operator empowerment.

Why does my Plesk-hosted mail fail DMARC despite SPF passing?

Almost always a DKIM-not-enabled gap. Plesk auto-configures Postfix outbound but does NOT auto-enable DKIM signing - the operator must explicitly enable DKIM via Mail Settings > DKIM spam protection. Without DKIM, your only alignment path is SPF, which breaks under envelope-rewriting hosts. See help_dmarc_alignment.php for the deep dive.

Do I need DMARC if I send all my mail through SendGrid or Mailgun instead of my hosting?

Yes. Without DMARC at enforcement, attackers can forge messages with your domain in the From: header from anywhere on the internet. SendGrid / Mailgun signing your outbound mail does not stop spoofing at receivers that ignore the relay's DKIM signature. DMARC at enforcement closes that gap. Configure DKIM via the relay's domain- authentication interface (CNAME- delegated) and ramp DMARC from p=none to p=reject over 2-6 weeks.

Where do I see DMARC reports for shared hosting mail?

Receivers (Google, Microsoft, Yahoo, Comcast, and others) send daily aggregate reports to the rua= mailbox in your DMARC record. DMARC Analyzer ingests these via includes/DmarcParser.php. Plesk, DirectAdmin, and ISPConfig do NOT parse DMARC reports - their email- stats interfaces show outbound delivery only.

13. Related guides

• Email authentication explained - the cluster-intro pillar covering the full ecosystem (SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC).
• DMARC explained - the DMARC primer for the broader ecosystem.
• SPF explained - the protocol-level deep dive on Sender Policy Framework (RFC 7208). Covers the 10-lookup limit, mechanisms, qualifiers, and flattening.
• SPF DNS-TXT-record byte syntax — the SHARED-HOSTING-TENANT-AUTHORING- OWN-SPF-RECORD-AT-CONTROL-PANEL-ZONE- EDITOR companion to this shared-hosting DMARC deployment guide. Where THIS page documents the full DMARC deployment procedure across the five canonical shared-hosting control-panels (cPanel / Plesk / DirectAdmin / ISPConfig / WHM- reseller) — the per-control-panel TXT- record-publication UI, the per-tenant DNS-zone-editor workflow, the per-host feedback-pipe ARF-redirect option, the per-tenant outbound-relay shared-MX cohabitation pattern — the SPF-DNS-syntax spoke is the BYTE-LITERAL AUTHORING REFERENCE documenting the RFC 7208 §3 SPF-record byte-grammar that the tenant TYPES INTO the control-panel zone-editor TXT-record field at the per-tenant publication boundary. The SHARED-HOSTING- TENANT-AUTHORS-OWN-SPF-RECORD cross- reference establishes FOUR structurally- distinct byte-authoring dimensions whose correctness the tenant must verify before the control-panel zone-editor accepts the record: (i) per-tenant zone-editor BYTE-LITERAL input convention — cPanel's WHM Zone Editor, Plesk's DNS Settings panel, DirectAdmin's DNS Admin page, ISPConfig's DNS records page, and WHM-reseller's per-zone editor all accept LITERAL byte input from the tenant into a single text field labelled "TXT record value" or similar; there is NO GUI abstraction layer that translates per- mechanism intent into byte-correct SPF syntax — the tenant types v=spf1 a mx include:<hosting- provider>.com -all verbatim or the record is byte-incorrect at publication time. The byte-syntax spoke documents the canonical RFC 7208 §3 byte-grammar that the tenant must encode into the zone-editor input correctly on the first attempt because most shared- hosting control-panels do NOT validate the SPF byte-grammar at submit time; (ii) shared-hosting include-cascade BYTE-ENVELOPE budget at RFC 7208 §4.6.4 10-DNS-lookup ceiling — every shared-hosting tenant inherits a include:<hosting-provider>.com sub-record cascade (cPanel's include:websitewelcome.com, Plesk's include:_spf.plesk.com) that consumes 2-5 DNS lookups before the tenant adds ANYTHING; the byte-syntax spoke documents the per-include cost accounting at byte-precise tokenization level so the tenant can measure their inherited cascade's contribution to the 10-lookup budget BEFORE supplementing with their own includes; (iii) multi-quoted-string concatenation at 255-byte fragmentation boundary — shared-hosting DNS providers handle TXT-record fragmentation differently: some require explicit double-quoted string pairs ("v=spf1 ip4:..." "ip4:..."), some abstract the fragmentation in the zone-editor UI but emit malformed records when the per-string byte budget is crossed; the byte-syntax spoke documents the canonical RFC 7208 §3.3 multi-string concatenation rules so tenants crossing the 255-byte threshold (common when supplementing the inherited cascade with explicit ip4: blocks for the tenant's own outbound-relay IPs) author the fragmentation byte-correctly at the per-string boundary; (iv) per- tenant supplemental ip4: CIDR-block byte-authoring at RFC 7208 §5.6.1 ip4-network format — tenants supplementing the inherited cascade with explicit ip4:<CIDR> blocks for outbound-relay IPs the control-panel doesn't enumerate (a per-tenant third-party-sender scenario where the tenant routes outbound mail through their own VPS or SaaS-mailer provider) MUST use the RFC 7208 §5.6.1 ip4-network format byte-precise (ip4:198.51.100.0/24 — note no embedded space, byte-contiguous CIDR notation); the byte-syntax spoke documents the canonical per-mechanism byte-grammar the tenant uses to author the supplemental ip4: blocks without introducing the byte-malformation defects that produce permerror at receiver-side evaluation. Read the SPF-DNS-syntax spoke BEFORE the tenant publishes any SPF record through the control-panel zone- editor — the byte-grammar reference is the canonical authoring prerequisite for every shared-hosting tenant's SPF-record byte-literal input session.
• include vs ip4 vs a vs mx — the SHARED-HOSTING-TENANT-AT-CPANEL- PLESK-DIRECTADMIN-ISPCONFIG-WHM-RESELLER- SPF-RECORD-AUTHORING-MECHANISM-CHOICE companion to this shared-hosting DMARC deployment guide. Where THIS page documents the full DMARC deployment procedure across the five canonical shared-hosting control-panels (cPanel / Plesk / DirectAdmin / ISPConfig / WHM- reseller) — the per-control-panel TXT- record-publication UI, the per-tenant DNS-zone-editor workflow, the per-host feedback-pipe ARF-redirect option, the per-tenant outbound-relay shared-MX cohabitation pattern — the include-vs- ip4-vs-a-vs-mx spoke documents the SHARED-HOSTING-TENANT-FACING SPF-MECHANISM- AUTHORING-DECISION-VIEW for the tenant's v=spf1 apex TXT record at the four-mechanism level: shared-hosting tenants nearly always inherit a include:<shared-relay>.< hosting-provider>.com sub-record cascade from their control-panel default (cPanel's +a +mx include:websitewelcome.com, Plesk's include:_spf.plesk.com, DirectAdmin's per-virtual-host +a mechanism, ISPConfig's +mx +a default, WHM-reseller's per-reseller include:<reseller-domain> sub-record), and the operator-side mechanism-choice decision — whether to keep the inherited include: cascade, supplement with explicit ip4: for outbound-relay IPs the control-panel doesn't enumerate, substitute a: for the tenant's own A-RR, or layer mx: for inbound-MX-doubles- as-outbound-relay topologies — IS the per-tenant SPF authoring discipline this shared-hosting DMARC deployment guide's Phase-1 SPF-prerequisite step demands every tenant complete BEFORE the DMARC publication. Without the include-vs-ip4- vs-a-vs-mx spoke a shared-hosting tenant reading THIS page knows their control-panel publishes an SPF record on their behalf, but not WHICH of the four mechanisms governs the inherited cascade nor WHICH mechanism to supplement when the inherited cascade misses their outbound-relay topology — this link closes that mechanism-choice resolution gap at the tenant-side per-mechanism authoring-decision layer.
• DKIM explained - the protocol-level deep dive on DomainKeys Identified Mail (RFC 6376). Covers selectors, canonicalization, key rotation, and CNAME delegation.
• DMARC record tags explained - every tag in the DMARC DNS record.
• DMARC alignment explained - identifier alignment (the SPF-or-DKIM-domain-matches-From: rule). Covers the provider-bounce-domain and SaaS-sender alignment failures common on shared hosting.
• DMARC policy rollout - the operational migration from p=none through p=quarantine to p=reject with a worked Week 0 -> Week 26 timeline.
• DMARC deployment checklist — the SHARED-HOSTING-TENANT-PER-CONTROL- PANEL-DEPLOYMENT-CHECKLIST-EXECUTION companion to this shared-hosting DMARC deployment reference. Where THIS page documents the per-tenant deployment workflow on shared-hosting panels (panel UI vs zone-file shell-access coordination, panel-managed nameserver vs operator- owned per-customer-domain publication, multi-tenant outbound-relay IP reputation, per-tenant SPF / DKIM / DMARC tag-list authoring), the DMARC- deployment-checklist is the CANONICAL GREEN-PATH WORKFLOW shared-hosting tenants execute PER-TENANT through the control- panel zone-editor abstraction layer with per-shared-hosting-topology-specific coordination requirements layered on top. Four per-shared-hosting-checklist- execution-coordination dimensions: (i) PHASE-0-PER-TENANT-TTL-DISCIPLINE-VIA- PANEL-MANAGED-NAMESERVER (the checklist's Phase 0 TTL-shortening step requires the shared-hosting tenant to coordinate with the panel-managed nameserver TTL precedence — the per-tenant zone-editor TTL field is structurally overridden by the panel-operator-managed parent-zone TTL at many shared-hosting providers, so the checklist's Phase 0 step requires per-tenant coordination with the host operator), (ii) PHASE-1-PER-TENANT-SPF- PREREQUISITE-AT-SHARED-OUTBOUND-RELAY (the checklist's Phase 1 SPF-prerequisite- verification step requires the shared- hosting tenant to enumerate the shared- outbound-relay IP-pool the host operator publishes, layer per-tenant ESP includes on top, and stay under the RFC 7208 §4.6.4 ten-DNS-query budget — the per-tenant SPF authoring is structurally constrained by the host-managed relay-inclusion prerequisite), (iii) PHASE-2-PER-TENANT- RUA-PUBLICATION-AT-CONTROL-PANEL-ZONE- EDITOR (the checklist's Phase 2 RUA- publication step at the per-tenant DMARC record's rua=mailto: field through the control-panel zone-editor text-field maps to per-tenant aggregation mailbox authoring with no GUI abstraction — the per-tenant RUA-receiver-mailbox- domain authorisation token requires per-receiver-mailbox setup THIS page documents), (iv) PHASE-3-THROUGH-PHASE- 5-PER-TENANT-RAMP-AT-SHARED-RELAY-IP- REPUTATION-CONSTRAINT (the checklist's Phase 3-5 ramp progression requires the per-tenant DMARC posture advancement to coordinate with the shared-outbound- relay IP-pool reputation — a single co-tenant's spam emission can degrade every co-tenant's IP-reputation-driven DMARC=pass rate even while the per-tenant DMARC authoring is correct). Critical when shared-hosting tenants executing per-tenant DMARC deployment need the canonical green-path step-by- step workflow reference layered on top of the per-tenant control-panel zone- editor abstraction — the DMARC- deployment-checklist is the operator- facing workflow driver this shared- hosting deployment page contextualises per-shared-hosting-topology-specific coordination.
• DMARC policy modes (p=none / p=quarantine / p=reject) - the PER-TENANT-PER-CONTROL-PANEL- ENFORCEMENT-TIER-SELECTION companion to this shared-hosting deployment reference. Where THIS page documents the SHARED-HOSTING DEPLOYMENT MECHANICS across the five canonical control-panels (cPanel / Plesk / DirectAdmin / ISPConfig / WHM-reseller) — the per-control-panel TXT-record-publication UI, the per-tenant DKIM selector convention, the shared-outbound-relay include: cascade, the per-tenant zone-editor byte- literal authoring boundary — the DMARC- policy-modes spoke is the PER-TENANT POLICY- TAG SELECTION REFERENCE documenting the four- phase phased-enforcement-ramp every shared- hosting tenant MUST author into their _dmarc.<tenant-domain> TXT record at the control-panel zone-editor. The SHARED-HOSTING-TENANT-DEPLOYMENT-PHASE- VS-POLICY-TAG-SELECTION cross-reference establishes FOUR structurally-distinct shared-hosting tenant cutover stages each binding a specific RFC 7489 §6.3 policy-tag choice that the tenant types VERBATIM into the control-panel zone-editor TXT-value field (NO GUI abstraction): (i) Phase 1 Discovery — tenant publishes v=DMARC1; p=none; rua=mailto:< tenant-aggregator>; at the control- panel zone-editor — the observation- only baseline phase during the FIRST 2–4 weeks of shared-hosting tenant onboarding when the tenant is inventorying which of their applications (the WordPress site, the contact form, the order-confirmation cron, the password-reset endpoint) egresses through which path (the shared-outbound-relay vs a sibling SaaS-ESP the tenant separately configured) AND any unaligned co-tenant bounce-domain rewriting the shared-outbound- relay applies that breaks SPF alignment; the DMARC-policy-modes spoke documents the p=none contract that receivers report-without-acting against the aggregate- report feed surfacing both the shared- outbound-relay egress IP pool AND the per- tenant DKIM-pass / SPF-pass / alignment-pass status; (ii) Phase 2 Triage — tenant edits zone-editor TXT-value to v=DMARC1; p=quarantine; pct=10; rua=mailto:<tenant-aggregator>; per-tenant percentage-ramp — 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 tenant progressively closes the shared-outbound-relay alignment gaps the Phase 1 aggregate-report feed surfaced; 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 the pct= value at the zone-editor); (iii) Phase 3 Soft- Enforcement — tenant edits zone-editor TXT- value to v=DMARC1; p=quarantine; pct=100; rua=mailto:<tenant-aggregator >; full-sample steady-state per tenant domain — the FINAL soft- quarantine tier where 100% of receiver evaluations apply the soft-quarantine action and the tenant's aggregate-report feed transitions from a "shared-hosting alignment- gap 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- tenant floor for 14+ consecutive days before advancing to p=reject — CRITICAL on shared hosting because co-tenants on the same shared-outbound-relay can introduce per-tenant alignment regressions if the hosting provider changes the relay-bounce- domain mid-month, surfacing as a tenant- scope DMARC-pass-rate drop the per-tenant operator must investigate at the next phase- advance gate); (iv) Phase 4 Hard- Enforcement — tenant edits zone-editor TXT- value to v=DMARC1; p=reject; pct=100; sp=reject; rua=mailto:<tenant- aggregator>; — the FINAL hard-enforcement tier where receivers reject DMARC-fail messages at SMTP 5xx response time and the per-tenant enforcement has graduated to the canonical post-deployment steady state; the DMARC-policy-modes spoke documents the p=reject + sp=reject coordination (mandatory for shared-hosting tenants whose application stack frequently uses subdomain rotation — blog.tenant.com, shop.tenant.com, support.tenant.com — and the sp=reject tag is the ONLY defence against the attacker-bypass class of cousin-subdomain spoof attacks the shared-hosting public-DNS surface inherently exposes to per-tenant brand-impersonation attempts). Pair this page (the shared-hosting per-control-panel deployment coordination reference) with the DMARC-policy-modes spoke (the per-phase policy-tag selection reference) when authoring the per-tenant four-phase cutover runbook — the spoke documents the per-phase exit-criteria gates and the pct= / sp= coordination the shared-hosting tenant MUST sequence correctly at the control-panel zone-editor TXT-value field BEFORE advancing to a stricter tier before the shared- outbound-relay authorisation coverage gates close.
• DMARC aggregate (RUA) reports - the daily XML stream receivers send back.
• DMARC monitoring discipline - the SHARED-HOSTING-MONITORING-EDGE-CASE- COMPANION documenting the daily-weekly- quarterly DMARC monitoring rhythm whose SHARED-IP-POOL and SHARED-BOUNCE-DOMAIN edge cases the shared-hosting topology THIS page documents structurally produces. Where THIS page documents the SHARED- HOSTING DEPLOYMENT MECHANICS (the cPanel / Plesk / DirectAdmin Email Deliverability UI walkthrough, the per-tenant DKIM selector convention, the include: chain for the shared-hosting provider's outbound IP pool, the bounce-domain alignment constraint), the DMARC-monitoring spoke documents the FOUR SHARED-HOSTING- SPECIFIC MONITORING EDGE CASES that SHARED-HOSTING TENANTS encounter structurally MORE OFTEN than dedicated- sender tenants do: (i) shared-IP- pool source_ip attribution dilution — the operator's monitoring view sees shared-pool source_ips emit mail for DOZENS of unrelated tenant domains, which means the per-source_ip aggregation granularity in the RUA stream cannot cleanly attribute which alignment failure originated from WHICH co-tenant's traffic, requiring the operator to read the header_from column carefully and cross-reference with local sender inventory; (ii) co- tenant DKIM-signing-key noise — the operator's monitoring view sees DKIM-pass rows for selector + d= domain combinations the operator never configured, attributable to co-tenants on the same shared-hosting infrastructure whose mail traverses the same outbound relays the operator's mail does — the per-selector observability discipline documented in the monitoring spoke catalogues which selector + d= patterns are legitimately the tenant's and which are co-tenant traffic that should be treated as noise; (iii) shared- bounce-domain alignment drift — the operator's monitoring view detects a gradual decay in SPF-aligned rows over time as the shared-hosting provider rotates the outbound IP pool without notifying tenants, which the per-week SPF-aligned-row trend the monitoring spoke documents catches BEFORE the provider's rotation produces a hard receiver-side rejection; (iv) provider-induced RUA-arrival cadence anomaly — the operator's monitoring instrumentation reports RUA-stream cadence anomalies (multi-day gaps in arriving aggregate reports) that trace to the shared-hosting provider's managed-mailbox infrastructure blocking legitimate inbound RUA mail from external receivers — the multi-mailbox-redundancy publisher-side rua= tag addressing discipline the monitoring spoke documents (mailbox at the shared- hosting provider AND a fallback mailbox at a dedicated external provider) defends against this provider-induced single- point-of-failure. Read the DMARC- monitoring spoke WITH this shared-hosting deployment page when a shared-hosting tenant's RUA stream contains data the tenant cannot cleanly attribute or when the RUA cadence reveals provider-induced gaps - the monitoring spoke documents the discipline these shared-hosting- specific edge cases require, and this page documents the deployment mechanics the monitoring spoke's edge cases operationally surface.
• DMARC troubleshooting - the cross-cutting failure-diagnosis guide synthesising the per-page troubleshooting sections into a single decision-tree reference.
• Email authentication glossary - cluster-wide definitions reference for every term-of-art used in this guide (alignment, organizational domain, selector, canonicalization, etc.).
• ARC (Authenticated Received Chain) explained - RFC 8617: preserves SPF / DKIM / DMARC results across forwarding hops.
• TLS-RPT report format (RFC 8460 §4 JSON schema deep dive) — the SHARED-HOSTING-CONTROL-PANEL-PER-TENANT-TRANSPORT-FAILURE-ATTRIBUTION-AT-MULTI-TENANT-PROVIDER-RUA-MAILBOX-CONSUMER-OF-PER-RECEIVER-AGGREGATE-JSON-REPORTS companion documenting the per-field JSON schema ("organization-name" / "contact-info" / "report-id" / "date-range" / "policies" with "policy.policy-domain" + "summary" + "failure-details" sub-records) of the aggregate JSON report receivers serialize per RFC 8460 §4 schema, whose per-customer-domain attribution is the load-bearing analytics input the shared-hosting control-panel operator (Plesk / DirectAdmin / ISPConfig) depends on when triaging transport-failure rates across the multi-tenant customer-domain pool sharing the same outbound MX, across FOUR shared-hosting TLS-RPT-JSON-attribution dimensions: (1) Per-customer-domain policy.policy-domain byte-content attribution across the multi-tenant shared-MX outbound pool — the JSON per-policy policy-domain field is the per-publisher-domain attribution anchor the shared-hosting operator pivots the JSON aggregate by; the multi-tenant operator demultiplexes the shared rua=-mailbox stream into per-customer-domain failure-streams using this byte-field as the load-bearing primary attribution key; (2) Per-customer summary.total-failure-session-count relative ratio as per-tenant deliverability triage prioritization — when one customer-domain's per-RUA-window failure-session-count materially diverges from the multi-tenant pool's baseline rate, that customer's outbound delivery posture warrants per-tenant investigation (typically a misconfigured per-customer alias on the shared MX); the JSON summary integer fields are the load-bearing triage-prioritization signals; (3) Per-customer-domain failure-details[].result-type byte-token analysis at the shared-MX boundary — when the shared-MX operator publishes a single MTA-STS policy but customers' aligned-MX configurations diverge, per-customer certificate-host-mismatch or sts-policy-fetch-error verdicts in the JSON aggregate identify which customer's per-tenant DNS/policy publication diverged from the shared-MX-published canonical posture; (4) Per-customer contact-info-mailbox routing as multi-tenant report-aggregation-vs-pass-through policy — the shared-hosting operator can elect to publish either a tenant-pool canonical rua=tls-reports@hostingprovider.tld (aggregate all customer-tenant reports into a single provider-managed inbox) or per-customer rua=tls-reports@<customer>.tld (pass through directly to the customer-tenant); the JSON per-failure-record-aggregation topology is the load-bearing multi-tenant-analytics architectural decision every shared-hosting DMARC deployment guide (THIS page) must reconcile with the customer's consent posture. The JSON-report-consumption across these four dimensions is the load-bearing per-tenant transport-failure- attribution analytics the shared-hosting control-panel operator depends on when operationalising THIS page's multi-tenant DMARC deployment guide alongside the transport-security closure.
• DMARC for cPanel & Shared Hosting - the cPanel-specific sibling deployment guide. cPanel is the largest single shared-hosting ecosystem and has its own dedicated guide because its "Email Deliverability" page differs from Plesk / DirectAdmin / ISPConfig UIs.
• DMARC for Google Workspace - the enterprise-flavoured sibling deployment guide for Google Workspace tenants.
• DKIM for Google Workspace (Gmail) - the SHARED-HOSTING-TO-WORKSPACE- MIGRATION-PER-DOMAIN-DKIM-PUBLICATION- PARITY companion reference. Where THIS page documents the per-tenant DMARC publication discipline on cPanel / Plesk / DirectAdmin / ISPConfig / WHM-reseller panels and the shared- outbound-relay coordination primitives operators must align with the panel's per-tenant control surface, the Workspace-DKIM spoke is the DEDICATED per-Workspace-tenant DKIM-publication reference operators consult when evaluating a shared-hosting → Workspace migration or operating a per-domain mail-flow inventory split between shared-hosting outbound-relay egress AND Workspace egress. Three concrete shared-hosting-vs-Workspace-DKIM coupling points: (i) per- domain DKIM-publication-parity audit between shared-hosting outbound-relay and Workspace egress — when the per-domain mail-flow inventory includes BOTH shared-hosting outbound- relay egress AND Workspace egress (a common transitional topology during a shared-hosting → Workspace migration), the operator must publish DKIM keys for BOTH egress paths at DISTINCT selectors (the shared-hosting panel's default selector + the Workspace google._domainkey selector); the Workspace-DKIM spoke documents the per-tenant Workspace- side selector-publication discipline that complements the shared-hosting panel-side DKIM publication this page documents; (ii) per-domain gappssmtp.com signing- identity gotcha during the migration window — during the shared- hosting → Workspace migration window BEFORE the Workspace tenant has activated the operator-controlled google._domainkey publication, Workspace egress signs with the per-tenant <tenant>.gappssmtp.com identity (DKIM-aligned to the Workspace-internal domain, NOT to the operator's org-domain); the per-tenant DMARC-record's aspf= + adkim= alignment-mode commitments THIS page documents will surface a sustained DMARC-fail rate on the Workspace-egress portion of the mail-flow until the Workspace-DKIM spoke's per-tenant activation workflow is completed; (iii) per- domain manual rotation cadence parity between shared-hosting panel-managed rotation and Workspace manual rotation — shared-hosting panels typically automate per-tenant DKIM key rotation via the panel's per- tenant scheduled task; Workspace DKIM rotation is MANUAL (the Admin Console operator must execute "Generate new record" + dual-publish + flip + retire) per RFC 8301 cadence; the Workspace-DKIM spoke documents the Workspace-side manual rotation discipline operators must reconcile with the shared-hosting panel's automated-rotation discipline at the per-domain audit boundary. Read the Workspace-DKIM spoke ALONGSIDE this shared-hosting DMARC reference whenever the per-domain mail-flow inventory includes Workspace egress OR when scoping a shared-hosting → Workspace migration.
• DKIM for Microsoft 365 - the SHARED-HOSTING-TO-M365-PER-DOMAIN- DKIM-PUBLICATION-PARITY companion to this shared-hosting DMARC deployment reference for operators running a shared-hosting → M365 migration window. Where THIS page documents the per-tenant shared-hosting deployment topology where cPanel / Plesk / DirectAdmin / ISPConfig / generic-no-panel egress flows through the panel's per-mail-flow MTA stack and the per-tenant DKIM key is managed by the panel (Outgoing Spam Filter → configure DKIM / Email Deliverability → Repair), the M365-DKIM spoke documents the post-migration per-tenant Defender- managed DKIM topology where the operator publishes two CNAMEs once and Microsoft handles all subsequent key rotations behind those CNAMEs. The cross-tenancy comparison reference matters at four shared-hosting → M365 migration coordination dimensions: (i) per-domain DKIM publication parity audit — during the migration window the per-domain DNS zone may simultaneously hold the panel- managed TXT-published DKIM record AND the M365-managed CNAME-published records; the operator must audit both per the panel's selector convention AND M365's selector1 / selector2 CNAMEs are present before flipping MX; (ii) operator-vs-platform rotation cadence parity — the panel side typically does NOT rotate keys automatically (manual operator responsibility per the panel's runbook) while M365 rotates the key behind the CNAME on a platform-managed schedule without operator action — closing this cadence gap is a load-bearing migration success criterion; (iii) per- selector naming-convention coordination — panel-managed DKIM typically publishes at a default._ domainkey or panel-specific selector while M365 always uses selector1 / selector2; the per-domain DNS zone audit must distinguish the two and avoid overwriting either; (iv) onmicrosoft.com signing-identity gotcha during cutover — until the Defender "Enable DKIM" toggle is flipped post-cutover, M365 egress signs with the per-tenant <tenant>.onmicrosoft.com identity instead of the operator's domain, breaking DKIM-alignment against the RFC 5322 From: domain and producing a DMARC-fail spike that mimics a publication regression. Read the M365- DKIM spoke ALONGSIDE this shared- hosting DMARC reference whenever the per-domain mail-flow inventory includes Microsoft 365 egress OR when scoping a shared-hosting → M365 migration.
• MTA-STS for Microsoft 365 - the SHARED-HOSTING-TO-M365-TRANSPORT-LAYER- POLICY-PUBLICATION-PARITY companion to this shared-hosting DMARC deployment reference for operators running a shared-hosting → M365 migration window at the transport- layer (MTA-STS / TLS-RPT / RFC 8461 / RFC 8460) dimension. Where THIS page documents the per-tenant shared-hosting deployment topology where cPanel / Plesk / DirectAdmin / ISPConfig / generic-no-panel operators publish a single shared-MX canonical MTA-STS policy enumerating the shared-hosting provider's MX hostnames and operate a single shared TLS-RPT aggregation mailbox, the M365-MTA-STS spoke documents the post-migration per- tenant Exchange Online MTA-STS topology where each tenant publishes a per-domain MTA-STS policy enumerating ONLY the Exchange Online canonical MX hostnames (*.mail.protection.outlook.com) with the per-tenant HTTPS-policy-host certificate served on the tenant-controlled web infrastructure. The cross-tenancy comparison reference matters at four shared-hosting → M365 transport-layer migration coordination dimensions: (i) per-domain MX-allowlist parity audit — during the migration window the per-domain DNS zone may simultaneously hold the shared-hosting- provider's MX records AND the Exchange Online MX records; the per-tenant MTA-STS policy file's mx: hostname- glob list MUST be updated to enumerate the Exchange Online canonical MX hostnames BEFORE the per-domain MX cutover — failure to update the policy file before MX cutover converts every receiver-side MTA-STS enforce-mode TLS handshake into a per-publisher delivery failure; (ii) shared-pool vs per- tenant HTTPS-policy-host certificate responsibility transition — the shared-hosting operator's mta-sts.<hostingprovider>.tld HTTPS-policy-host is multi-tenant certificate infrastructure; the post- migration per-tenant mta-sts.<customer>.tld HTTPS-policy-host becomes the customer's per-domain certificate-management responsibility — closing this responsibility-transition gap is a load- bearing migration success criterion; (iii) testing → enforce mode- progression coordination — the shared-hosting operator may operate per-shared-pool mode: enforce while the migrating tenant's per-domain M365 MTA-STS policy MUST start at mode: testing and only advance to mode: enforce after per-tenant TLS-RPT JSON-aggregate ingestion confirms a per-tenant steady-state zero-failure baseline against the Exchange Online MX infrastructure; (iv) per-tenant TLS-RPT JSON-aggregate mailbox routing as multi-tenant report-aggregation-vs- pass-through policy — the shared-hosting operator publishes a single pool-canonical rua=mailto:tls-reports@hostingprovider.tld while the post-migration per-tenant M365 deployment must publish a per-domain rua=mailto:tls-reports@<customer>.tld — the per-tenant TLS-RPT JSON-aggregate report-flow then becomes the customer- side per-domain analytics responsibility instead of being aggregated into the provider's shared pool. Read the M365- MTA-STS spoke ALONGSIDE this shared- hosting DMARC reference whenever the per-domain transport-layer inventory includes Microsoft 365 egress OR when scoping a shared-hosting → M365 transport-layer migration.
• MTA-STS for Google Workspace (Gmail) - the SHARED-HOSTING-TO-WORKSPACE- TRANSPORT-LAYER-POLICY-PUBLICATION-PARITY companion to this shared-hosting DMARC deployment reference for operators running a shared-hosting → Workspace migration window at the transport-layer (MTA-STS / TLS-RPT / RFC 8461 / RFC 8460) dimension. Where THIS page documents the per-tenant shared-hosting deployment topology where cPanel / Plesk / DirectAdmin / ISPConfig / generic-no-panel operators publish a single shared-MX canonical MTA-STS policy enumerating the shared-hosting provider's MX hostnames and operate a single shared TLS-RPT aggregation mailbox, the Workspace-MTA-STS spoke documents the post-migration per- tenant Gmail MTA-STS topology where each tenant publishes a per-domain MTA-STS policy enumerating ONLY the Gmail canonical MX hostnames (the five *.ASPMX.L.GOOGLE.COM entries) with the per-tenant HTTPS- policy-host certificate served on the tenant-controlled web infrastructure. The cross-tenancy comparison reference matters at four shared-hosting → Workspace transport-layer migration coordination dimensions: (i) per-domain MX-allowlist parity audit — during the migration window the per-domain DNS zone may simultaneously hold the shared- hosting-provider's MX records AND the Gmail MX records; the per-tenant MTA-STS policy file's mx: hostname-glob list MUST be updated to enumerate the five *.ASPMX.L.GOOGLE.COM hostnames BEFORE the per-domain MX cutover — failure to update the policy file before MX cutover converts every receiver-side MTA-STS enforce-mode TLS handshake into a per-publisher delivery failure; (ii) shared-pool vs per-tenant HTTPS-policy-host certificate responsibility transition — the shared-hosting operator's mta-sts.<hostingprovider>.tld HTTPS-policy-host is multi-tenant certificate infrastructure; the post- migration per-tenant mta-sts.<customer>.tld HTTPS-policy-host becomes the customer's per-domain certificate- management responsibility — closing this responsibility-transition gap is a load-bearing migration success criterion; (iii) testing → enforce mode-progression coordination — the shared- hosting operator may operate per- shared-pool mode: enforce while the migrating tenant's per-domain Workspace MTA-STS policy MUST start at mode: testing and only advance to mode: enforce after per-tenant TLS-RPT JSON- aggregate ingestion confirms a per- tenant steady-state zero-failure baseline against the Gmail MX infrastructure; (iv) per- tenant TLS-RPT JSON-aggregate mailbox routing as multi-tenant report- aggregation-vs-pass-through policy — the shared-hosting operator publishes a single pool- canonical rua=mailto:tls-reports@hostingprovider.tld while the post-migration per-tenant Workspace deployment must publish a per-domain rua=mailto:tls-reports@<customer>.tld — the per-tenant TLS-RPT JSON- aggregate report-flow then becomes the customer-side per-domain analytics responsibility instead of being aggregated into the provider's shared pool. Read the Workspace-MTA- STS spoke ALONGSIDE this shared- hosting DMARC reference whenever the per-domain transport-layer inventory includes Google Workspace egress OR when scoping a shared-hosting → Workspace transport-layer migration.
• MTA-STS policy syntax — the PER-SHARED-HOSTING-TENANT-PER- DOMAIN-MTA-STS-POLICY-FILE-BODY-LINE- GRAMMAR-AUTHORING-DISCIPLINE companion reference. Where THIS page documents the per-shared-hosting-tenant per-domain DMARC publication discipline (per-tenant _dmarc.<org-domain> TXT-record authoring, per-tenant sp= subdomain-policy scoping, per-tenant pct= sampling-RNG percentage ramp from p=none through p=quarantine to p=reject, the per-tenant shared-IP-cohort SPF authorisation constraint that compounds with the per-tenant DKIM-aligned-pass-rate floor determining per-tenant DMARC-aligned- pass-rate floor), the MTA-STS-policy- syntax spoke is the BYTE-SHAPE-OF-THE- POLICY-FILE-BODY reference documenting the RFC 8461 §3.2 line-grammar each per-tenant publisher instantiates at https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt. Four per-shared-hosting-tenant authoring dimensions the spoke addresses: (1) per-tenant inbound-MX hostname enumeration in the policy file's mx: allow-list — the shared- hosting era's per-tenant policy lists the shared-hosting-provider's canonical inbound MX hostnames (e.g. mx: mail.hostingprovider.tld plus mx: mail2.hostingprovider.tld), with each tenant's policy enumerating the SAME provider-canonical MX hostname set; the per-tenant policy MUST be re-authored to enumerate the post-migration Exchange Online MX hostname-glob (mx: *.mail.protection.outlook.com) or the Workspace MX hostnames (mx: aspmx.l.google.com plus four alt[1-4].aspmx.l.google.com lines) BEFORE the per-tenant MX cutover — failure to update converts every receiver-side MTA-STS enforce-mode TLS handshake into a per-tenant delivery failure; (2) mode progression discipline per tenant — the shared-hosting tenant's deployment cadence requires the per- tenant policy to start at mode: testing for the first 2-4 weeks so per-tenant TLS-RPT _smtp._tls.<tenant-domain> JSON-aggregate ingestion surfaces per- tenant per-day failures WITHOUT blocking delivery, followed by mode: enforce after the per-tenant TLS-RPT failure rate falls below the tenant's risk threshold — the spoke documents the per-mode behaviour difference at sender-MTA enforcement time; (3) max_age cache-TTL choice per tenant — the per-tenant MX-inventory- rollover cadence (provider-MX rollover, per-tenant migration to M365/Workspace, per-tenant DR-failover MX-substitution) determines the per-tenant max_age: seconds value published — too-long means sending-MTA caches retain stale per-tenant allow- lists during rollovers; too-short means sending-MTAs re-fetch the policy daily, increasing the per-tenant HTTPS-policy-host bandwidth consumption — the spoke documents the cache-TTL bounds-check RFC 8461 §3.2 imposes; (4) per-tenant _mta-sts.<tenant-domain> TXT-record id= versioning — the per-tenant policy file body changes (a new shared-hosting-provider MX rolled out, a mode flip from testing to enforce, a max_age tightening) must be paired with an id= bump in the per-tenant TXT-record so sending-MTAs respecting the policy detect the change and invalidate their cached copy — the spoke documents the id=-keyed cache- invalidation contract sending-MTAs implement against the per-tenant policy file body. Read the MTA-STS-policy- syntax spoke alongside this page when authoring the per-tenant mta-sts.txt policy file body — the per-tenant per-MX-hostname- pattern enumeration + per-tenant mode progression + per-tenant max_age cache- TTL + per-tenant id=-keyed versioning decisions are the load- bearing byte-shape choices the per- tenant transport-layer publication discipline imposes on the per-tenant policy file body grammar.
• MTA-STS vs DANE — the SHARED-HOSTING-PROVIDER-PARENT- ZONE-DNSSEC-COVERAGE-AS-LOAD-BEARING- INPUT-TO-PER-TENANT-TRANSPORT-LAYER- PROTOCOL-CHOICE companion reference. Where THIS page documents the per-shared- hosting-tenant per-domain DMARC publication discipline (per-tenant _dmarc.<org-domain> TXT-record authoring, per-tenant sp= subdomain-policy scoping, per-tenant pct= sampling-RNG percentage ramp from p=none through p=quarantine to p=reject, per-tenant shared-IP-cohort SPF authorisation constraint compounding with per-tenant DKIM-aligned-pass-rate floor), the MTA-STS-vs-DANE spoke is the BINARY- TRANSPORT-LAYER-PROTOCOL-CHOICE companion each per-tenant transport-security publication discipline MUST resolve across four shared-hosting protocol-choice dimensions: (1) shared-hosting-provider parent zone DNSSEC coverage constraint — DANE STRUCTURALLY requires DNSSEC on the shared-hosting-provider's canonical MX hostnames' parent zones (e.g. the provider's mail.hostingprovider.tld + mail2.hostingprovider.tld parent zones must be DNSSEC-signed AND each MX hostname must publish a TLSA record at _25._tcp.mail.hostingprovider.tld); most shared-hosting providers (cPanel operators, Plesk providers, ISPConfig operators) do NOT DNSSEC-sign their canonical MX hostname parent zones, which STRUCTURALLY rules out DANE for per-tenant inbound paths sharing the provider's MX infrastructure and forces MTA-STS as the only viable transport- security protocol for the shared-pool receive-side; (2) per-tenant receiver- population enforcement coverage — the per-tenant outbound-traffic receiver mix (consumer Gmail / Yahoo / Microsoft 365 / Apple iCloud where MTA-STS is dominant vs European B2B t-online.de / GMX / web.de / posteo.de / mail.de where DANE is dominant) determines whether the per-tenant transport-security discipline favours MTA-STS-only, DANE-only, or the RFC 7672 §1.3 dual-protocol coexistence — the spoke documents the per-receiver enforcement-coverage matrix the per- tenant protocol-choice decision-tree consumes; (3) RFC 7672 §1.3 coexistence rule for per-tenant dual-protocol publication — when a per-tenant publisher operates BOTH MTA-STS AND DANE simultaneously (typical for B2B tenants with mixed receiver populations when the shared-hosting provider has DNSSEC-signed the MX-hostname parent zones), the RFC 7672 §1.3 coexistence- and-precedence rule applies: DANE- validating receivers prefer DANE; receivers that fail to DNSSEC-validate fall back to MTA-STS — the spoke documents the receiver-side fallback- precedence ordering the dual-protocol coexistence imposes on per-tenant transport-failure-signal interpretation; (4) per-tenant MX-publication-discipline divergence — DANE TLSA records key on the _25._tcp.<shared-mx-hostname> record AT THE SHARED-MX-HOSTNAME parent zone (which means the shared-hosting provider authors the TLSA records ONCE for all per-tenant inbound traffic); MTA-STS policy files key on the mta-sts.<tenant-domain> HTTPS-policy-host AT EACH PER-TENANT apex (which means each per-tenant publisher must operate per-tenant HTTPS-policy-host certificate infrastructure) — the per-MX-keyed-DANE- vs-per-tenant-MTA-STS publication- discipline divergence is the load-bearing per-tenant authoring discipline shared- hosting tenants must coordinate with the shared-hosting provider's MX-layer DNSSEC-publication discipline. Read the MTA-STS-vs-DANE spoke alongside this page when scoping the per-tenant transport-security publication discipline — the binary protocol choice and the per-tenant receiver-population enforcement coverage are the load- bearing transport-layer publication decisions each shared-hosting tenant MUST resolve before the per-tenant TLS- enforcement coverage guarantee can be declared operational.
• DMARC for Microsoft 365 - the enterprise-flavoured sibling deployment guide for Exchange Online tenants.
• DMARC for transactional email - the SHARED-HOSTING-TENANT-DELEGATES-PER- MESSAGE-TRANSACTIONAL-CLASS-TO-THIRD-PARTY- ESP-WITH-PER-CUSTOMER-DKIM-CNAME-DELEGATION companion to this shared-hosting DMARC deployment guide. Where THIS page documents the per-tenant shared-hosting deployment mechanics across the five canonical non-cPanel control-panels (Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP) — the per-control-panel TXT-record-publication UI, the per-tenant DKIM selector convention, the shared- outbound-relay include: cascade, the shared-IP-pool reputation cross-contamination compounding effects — the transactional-email spoke documents the STRUCTURALLY-COMPLEMENTARY per-tenant third-party-ESP-as-transactional-egress topology where the shared-hosting tenant delegates the per-message transactional class (OTP / MFA / password-reset / order- confirmation / shipping-notification messages) to a dedicated transactional ESP (SendGrid / Mailgun / Amazon SES / Postmark / SparkPost / Twilio / Resend) across FOUR shared-hosting-vs-transactional- ESP coordination dimensions: (i) per-customer-domain DKIM-CNAME- delegation at the per-control-panel zone- editor TXT-record-publication boundary as load-bearing per-publisher distinguisher — the per-tenant shared-hosting topology renders SPF STRUCTURALLY UNABLE to distinguish the per-tenant publisher (the shared-IP-pool authorises ANY co-tenant's mail indiscriminately); the transactional ESP's per-customer-domain DKIM-CNAME-delegated publication (s1._domainkey.<tenant> CNAME s1.domainkey.u123.wl.sendgrid.net, krs._domainkey.<tenant> CNAME krs.<tenant>.mailgun.org, scph0825._domainkey.<tenant> CNAME scph0825.dkim.amazonses.com) supplies the per-customer d=<tenant-domain>-aligned DKIM signature the shared-hosting topology cannot supply at the shared-IP-cohort granularity — making the per-customer CNAME-delegation publication at the per- control-panel zone-editor (Plesk's DNS Settings, DirectAdmin's DNS Admin, ISPConfig's DNS records page) the load- bearing per-publisher distinguisher every shared-hosting tenant's transactional outbound stream depends on; (ii) per-customer return-path bounce- domain delegation as transactional-class SPF-alignment recovery from shared-outbound- relay envelope-MAIL-FROM rewriting — the per-tenant shared-hosting control- panel's outbound relay rewrites the envelope-MAIL-FROM to bounces+<tenant-id>@<shared- relay-hostname>, structurally breaking SPF alignment for shared-relay- egressed mail; transactional ESPs publish per-customer return-path bounce domains (bounce.<tenant>.com delegated to ESP-managed MX/A records) so the per-message envelope-MAIL-FROM aligns with the per-tenant customer's SPF record — the transactional-ESP delegation thus recovers SPF alignment the shared-hosting topology structurally cannot supply at the shared-relay envelope-rewriting boundary; (iii) per-tenant include:<transactional-esp-pool> cooperative-extension at the per-control- panel zone-editor TXT-record-publication boundary within the 10-DNS-lookup budget envelope — the per-tenant shared-hosting SPF record inherits a vendor-managed include:<hosting-vendor-pool> sub-record cascade consuming 2-5 DNS lookups baseline; cooperatively-extending with a transactional ESP include:<sendgrid|mailgun|amazonses| postmarkapp|sparkpostmail|twilio|resend> token consumes 2-4 additional lookups through the ESP's per-platform recursive sub-cascade — placing the per-tenant cumulative lookup-budget at 4-9 lookups of the RFC 7208 §4.6.4 10-DNS-lookup ceiling with NO additional headroom for a SECOND transactional ESP or a marketing- ESP cooperative-extension; the per-tenant operator's transactional-ESP cooperative- extension decision at the per-control- panel zone-editor IS the canonical operational decision the shared-hosting SPF-authoring discipline must accommodate within the tight per-tenant lookup-budget envelope; and (iv) per-tenant transactional-ESP per-message t= timestamp + x= expiry tag replay-protection as time-sensitive- delivery-outcome contract for shared- hosting product-issued transactional messages — the per-tenant shared-hosting product issues time- sensitive transactional messages (OTPs with 30-second-to-5-minute time-bounds, password-resets with 1-hour time-bounds, order-confirmations with 24-hour time- bounds) that the transactional ESP's per- message t=/x= signature-tag publication enforces at the per-message DKIM signature level — the per-tenant transactional ESP delegation thus supplies the per-message time-bounded replay-protection discipline the per- tenant shared-hosting Postfix/Exim/ OpenDKIM outbound MTA structurally cannot publish at the per-tenant signing boundary. Pair this shared-hosting deployment reference (covering the multi- tenant control-panel-egress topology) with the transactional-email spoke (covering the per-customer-domain CNAME-delegated transactional-ESP-egress topology) when scoping the per-tenant transactional outbound-stream architecture — the per-tenant shared-hosting tenant's transactional-class delegation to a dedicated transactional ESP is the operationally-binding architectural pattern every shared-hosting tenant issuing time-sensitive product-bound transactional messages MUST coordinate at the per- control-panel zone-editor + the per- transactional-ESP signing-and-bounce- handling publication boundary.
• SPF for Microsoft 365 - the SINGLE-INCLUDE-DEDICATED-CLOUD- CONTRAST-TO-SHARED-HOSTING-INCLUDE- CASCADE companion to this shared- hosting DMARC deployment guide. Where THIS page documents the Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP control- panel-managed shared-IP-pool SPF authoring workflow with its characteristic vendor-managed include:<hosting-vendor-pool> token AND the SHARED-IP-COHORT REPUTATION CROSS-CONTAMINATION compounding effects, the SPF-for- Microsoft-365 spoke documents the STRUCTURALLY-OPPOSITE single-cloud- provider M365-tenant SPF authoring discipline across FOUR contrast dimensions: (i) the single- include canonical record vs the shared-hosting include-cascade — M365 tenants publish the canonical v=spf1 include:spf.protection.outlook.com -all single-include record covering the entire EOP outbound netblock, contrasting sharply with the shared-hosting tenant record's multi-include cascade (typical pattern: include:<hosting-vendor-pool> + include:<email-relay-vendor> + include:<mailing-list-vendor>) whose lookup-cost accumulates rapidly toward the 10-lookup ceiling; (ii) the dedicated-cloud-provider reputation pool vs the shared-IP-cohort reputation pool — M365 tenants egress through Microsoft-managed EOP netblocks whose receiver-side reputation is dedicated to the Microsoft sender cohort (not contaminated by unrelated third-party customers), structurally the opposite of the shared-hosting tenant whose egress IP is shared with dozens or hundreds of unrelated control- panel-customer domains and inherits whatever cross-contamination the co-tenant cohort produces at every major receiver simultaneously; (iii) the hybrid dual-egress topology vs the shared-hosting single- control-panel-egress topology — M365 tenants may run a hybrid topology (on-prem Edge Transport + Exchange Online dual-egress) requiring explicit on-prem IP enumeration in the SPF record, an authoring complexity ABSENT from the shared-hosting case where every customer-domain egress flows through the control-panel- managed shared-IP pool with no per-domain hybrid alternative path, and (iv) the receiver-side spf=pass attribution clarity vs the shared-IP-cohort attribution ambiguity — at major receivers the M365 SPF=pass verdict is unambiguously attributable to the specific M365 tenant (via the DKIM-d= tag and DMARC alignment), while the shared-hosting SPF=pass verdict alone only authorises the shared-IP cohort as a group — DKIM-signing per the per-customer-isolated key documented on this page is structurally load-bearing for the shared-hosting case (the M365 case has it via the EOP-managed selector). Pair this shared-hosting deployment guide (covering the MULTI-TENANT-CONTROL- PANEL-EGRESS topology) with the SPF-for-Microsoft-365 spoke (covering the SINGLE-CLOUD-PROVIDER-DEDICATED- EGRESS topology) for the contrast operators considering migration from shared hosting to a dedicated cloud mailbox-provider tenancy need when evaluating the SPF-authoring- complexity-and-reputation-pool- characteristic tradeoffs of the two deployment models.
• Multi-domain DMARC strategy - the SHARED-HOSTING-PORTFOLIO-ESCALATION companion to this shared-hosting DMARC deployment guide. Where THIS page documents the SINGLE-shared-hosting-DOMAIN authoring workflow for the SMB-tier Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP operator, the multi-domain-strategy spoke documents the PORTFOLIO-COORDINATION decision framework the shared-hosting operator transitions to once the tenancy hosts multiple sender domains on the SAME shared-IP-pool. The shared-hosting portfolio case is STRUCTURALLY-DIFFERENT from the dedicated-IP-pool portfolio case the universal multi-domain framework anticipates because the SHARED-IP-POOL REPUTATION CROSS-CONTAMINATION COMPOUNDS ACROSS the portfolio: one bad-reputation co-tenant on the shared /24 affects EVERY portfolio domain at every major receiver simultaneously, not just the primary-tenant domain. The multi-domain spoke documents the shared-hosting-tenancy patterns where portfolio coordination is load- bearing: (i) single-org many- brands on shared-IP — the Plesk / DirectAdmin / ISPConfig tenant running 3-15 product / brand / regional sub-brand domains all outbound through the same shared-IP- pool (per-brand reputation drag from co-tenant authentication-failure rate compounds linearly with portfolio domain count at major receivers), (ii) parked-domain defensive-registrations on shared- IP — typosquat defensive domains (company.org / company.net / company.co) which the operator publishes p=reject + v=spf1 -all + null-MX on, but which still benefit from portfolio-wide _dmarc.<domain> publishing because the shared-IP-pool reputation surface attackers spoof from is the SAME pool the operator sends from, (iii) acquired- domain wind-down on shared-IP — defunct campaign domains the operator wants to LOCK against spoofers (the apex-only- p=reject + null-SPF pattern); the shared-IP-pool constraint means the operator CANNOT keep an acquired domain "lightly protected at p=quarantine" because the shared-IP-pool's reputation drag will surface false-positives at major receivers for the acquired domain just as it does for the primary-tenant domain, (iv) subdomain segmentation on shared-IP — the sp= (subdomain policy) and np= (RFC 9091 non-existent subdomain policy) tag family the shared-hosting operator uses to apply per-product / per- region subdomain risk-profile segmentation WITHOUT publishing per-subdomain TXT records for every leaf node. The multi-domain spoke also documents the Public Suffix List (PSL) organisational-domain boundary that governs which subdomains sp= covers (every subdomain under the apex registered organisational-domain is covered; domains under SEPARATE organisational domains need their own _dmarc.<domain> records). Read the multi-domain- strategy spoke when the shared-hosting tenancy publishes its second sender domain — the portfolio-coordination decision framework is the load-bearing reference for the moment the shared- hosting operator transitions from single-domain DMARC authoring to multi-domain DMARC coordination on the SAME shared-IP-pool infrastructure.
• Email Header Analyzer - paste any email's headers and see SPF, DKIM, DMARC, and ARC results.
• Domain Security Checker - live DNS lookups for every email- authentication record on a domain. Surfaces the live SPF lookup count, the published DKIM selectors (including the panel-specific default and x selectors), and the DMARC policy state.
• Blacklist Checker - check a sending IP against the major blocklists. Essential when diagnosing shared-IP reputation issues on shared hosting.
• Why SPF alone is insufficient - the SHARED-HOSTING-MULTI-TENANT-IP- COHORT-AS-LOAD-BEARING-CASE-STUDY-OF- SPF-AS-POOR-PUBLISHER-DISTINGUISHER companion to this shared-hosting DMARC deployment reference. Where THIS page documents the shared-hosting tenancy topology (cPanel / Plesk / DirectAdmin / ISPConfig multi-customer mailbox provisioning, Exim / Postfix per-customer domain configuration via per-vhost sender-restriction maps, the shared- IP-pool reputation pooling where one customer's spam events contaminate the deliverability of all customer domains sharing the IP, the per-customer DKIM OpenDKIM signing-key isolation under /etc/opendkim/keys/<customer>/, the Postfix milter chain wiring DKIM signing into the outbound submission path), the why-SPF-alone-is-insufficient pillar is the BROADER STRUCTURAL ARGUMENT companion documenting the SHARED-HOSTING case study as one of SEVEN distinct STRUCTURAL CLASSES of SPF-protocol limitation — specifically the SHARED- HOSTING-MULTI-TENANT-IP-COHORT-AS- PUBLISHER-IDENTITY class which the broader pillar enumerates alongside forwarding-rewrites-MAIL-FROM, MAIL-FROM- vs-From-header-asymmetry, cloud- provider-IP-rotation, the 10-DNS- lookup-budget cap, absence-of-content- integrity, and absence-of-publisher- private-key. The shared-hosting case is the OPERATIONALLY-VISIBLE proof point because: (i) SPF on a shared- hosting IP authorizes the entire shared- IP pool indiscriminately — any customer on the shared IP can send mail that SPF-aligned-passes for that customer's domain, but if customer A's mailbox is compromised and the attacker uses customer A's outbound credentials to send forged-From: messages claiming to be customer B (a co-tenant on the same shared IP), SPF cannot distinguish the cases because both customer A's legitimate mail and the attacker's forgery egress from the same shared IP and both pass SPF check_host() evaluation; (ii) only DKIM provides the per-customer publisher- distinguisher the shared-hosting topology requires because the per- customer DKIM private-key is per- customer-isolated and the d=<customer-domain> tag in the signature identifies the specific customer's organizational domain INDEPENDENTLY of the shared-IP- cohort membership; (iii) the operational implication is that a shared-hosting customer's p=reject DMARC posture is ONLY meaningful if their DKIM-aligned signing is operationally working — relying on SPF alone leaves the customer's p=reject cosmetic, because any co-tenant on the shared IP can pass SPF for the customer's domain regardless of whether the co-tenant has any legitimate authority to send for that domain. Read the why-SPF-alone-is-insufficient pillar when authoring the shared- hosting customer-education content — the broader structural argument that SPF cannot serve as the SOLE publisher- authentication mechanism is what gates the shared-hosting tenant's p=reject rollout from cosmetic to load-bearing, and the per-customer DKIM-aligned signing setup this page documents is the LOAD- BEARING control closing the shared- hosting-specific SPF-insufficiency case study.
• CAA records explained - the SHARED-HOSTING-MULTI-TENANT-CAA- RECORD-AUTHORITY-DELEGATION companion to this shared-hosting DMARC deployment reference. Where THIS page documents the shared-hosting tenancy topology (cPanel / Plesk / DirectAdmin / ISPConfig multi- customer provisioning, the shared-IP-pool reputation pooling, the per-customer DKIM signing-key isolation, the per-customer SPF-include + DKIM-CNAME-delegation publication discipline), the dedicated CAA-records spoke documents the STRUCTURALLY-DISTINCT shared-hosting CAA-record-publication discipline at FOUR shared-hosting-specific CAA coordination dimensions that NO other shared-hosting- deployment-guide covers: (i) shared- hosting provider often publishes a default wildcard CAA record at the customer-domain zone (e.g. 0 issue "letsencrypt.org" + 0 issue "sectigo.com") without consulting the tenant - the tenant's per-domain cert issuance preference is structurally CONSTRAINED by the panel- provider's default CAA policy that the tenant may or may not have authority to override via the control-panel Zone Editor depending on the panel-provider's empowerment-ceiling boundary; the CAA-records spoke documents the per-panel- provider default-CAA inheritance and the per-tenant override discipline; (ii) per-customer cert issuance authority preference diverges structurally between shared-hosting tenants - one tenant on the same shared-hosting cohort wants Let's Encrypt for cost-free automated cert renewal, another wants Sectigo or DigiCert for B2B-counterparty-recognised cert chain, a third wants Google Trust Services for Workspace-tenant cohabitation - but the shared-hosting provider's default CAA cannot satisfy all three tenants simultaneously, producing a per-tenant CAA- publication discipline coordination problem the dedicated CAA reference documents; the CAA-records spoke documents the per- tenant CAA-preference-vs-shared-default- CAA reconciliation discipline; (iii) shared-hosting tenants publishing BIMI VMC certs or MTA-STS HTTPS-policy-host certs face CAA-issuance-authority gating because the BIMI VMC-issuing CA (DigiCert, Entrust) and the MTA-STS-policy-host-cert- issuing CA (typically Let's Encrypt via ACME-DNS-01 or HTTP-01) BOTH require CAA permission at the mta-sts.<customer-domain> or bimi._domainkey.<customer-domain> sub-owner-name - the tenant must publish appropriately-scoped CAA records that permit BOTH cert-issuance authorities without inadvertently blocking the shared-hosting provider's primary HTTPS cert renewal; the CAA-records spoke documents the per-subdomain-CAA scope-management discipline shared-hosting BIMI / MTA-STS tenants must layer on top of the provider's default CAA; and (iv) RFC 8659 §3 CAA-property iodef violation-reporting-URI publication produces a per-customer-domain cert-mis-issuance evidence-stream that flows to the tenant's operator-chosen iodef-URI rather than to the shared-hosting provider's centralised mailbox - the tenant's iodef= mailto:secops@customer-domain publication enables per-tenant cert- violation observability that mirrors the per-tenant RUA-mailbox publication this page's rua=mailto: shared- hosting publication-side discipline documents; the CAA-records spoke documents the per-tenant iodef= publication discipline as the cert-layer parallel to the DMARC RUA-mailbox publication discipline this page covers at the email-authentication-layer. Read the dedicated CAA-records spoke when scoping the per-tenant cert-issuance- authority discipline for a shared-hosting domain whose tenant intends to publish BIMI VMC or MTA-STS policy-host cert independently of the shared-hosting provider's primary HTTPS cert renewal - the spoke is the authoritative RFC 8659 CAA-record reference whose four shared- hosting-specific CAA-coordination boundaries this shared-hosting deployment page is the per-tenant operator-empowerment- ceiling companion for.
• Business Email Compromise (BEC) defence — shared-hosting tenants are disproportionately targeted by BEC operators because (a) the provider's shared outbound-relay IPs accumulate a per-CIDR reputation that one tenant's spoof-friendly SPF policy degrades for every co-tenant, AND (b) a tenant publishing p=none at the per-tenant DMARC record gives the BEC operator an exact-domain spoofing window the receiver's policy filter cannot close. This page's p=quarantine/p=reject rollout sequence is the per-tenant BEC-defence application-layer contract; the BEC spoke documents the FBI-IC3-tracked attack-class whose stage-1 exact-domain spoof THIS page's per-tenant DMARC enforcement structurally defeats.
• SPF 10-DNS-lookup limit and SPF flattening — the SHARED-HOSTING-TENANT-STACKED-ESP- INCLUDE-CASCADE-AS-CANONICAL-SPF-PERMERROR- ROOT-CAUSE-CLASS companion to this shared- hosting DMARC deployment guide. Where THIS page documents the per-tenant DMARC deployment workflow on shared-hosting panels (panel UI vs zone-file shell-access coordination, panel-managed nameserver vs operator-owned per-customer-domain publication, multi-tenant outbound-relay IP reputation, per-tenant p=quarantine / p=reject rollout sequence), the SPF-lookup-limit spoke is the per- tenant per-domain RFC 7208 §4.6.4 ten- DNS-query-budget operational reference whose four SHARED-HOSTING-LOOKUP-BUDGET- COORDINATION dimensions catalogue the canonical shared-hosting-specific SPF- publication root-cause classes the per-tenant DMARC rollout structurally depends on: (i) per-tenant stacked-ESP-include cascade lookup overflow root-cause — the shared-hosting tenant's per-domain SPF record routinely accumulates four-to- six include: mechanisms (panel's default outbound smarthost include + the tenant's primary transactional-ESP include + the tenant's marketing-automation include + an abandoned-but-not-removed legacy ESP include + a per-region SES include + a per-currency Klaviyo include) and the per-ESP recursive include cascade documented by the lookup-limit spoke's per-ESP reference table consumes 9 to 14 lookups against the §4.6.4 cap; the shared-hosting tenant is the canonical SPF-lookup-overflow operator- class because the panel's default outbound-smarthost include is OPAQUE to the tenant (the tenant cannot edit it through the panel UI), producing a structural floor on the per-tenant lookup budget; (ii) per-tenant flattening operational discipline on panel- managed DNS — when the shared-hosting tenant's per-domain SPF record is over the §4.6.4 cap, the tenant must either (a) flatten the include cascade down to ip4/ip6 ranges + maintain a recurring cron refresh (operationally infeasible without zone-file shell access the panel does not offer), or (b) request the hosting provider's operator to flatten on the tenant's behalf (which couples the tenant's SPF-publication discipline to the provider's panel-automation roadmap); the SPF-lookup-limit spoke documents the flattening operational-trade-off catalogue the shared-hosting tenant consults before electing this remediation path; (iii) per-tenant subdomain delegation as budget- split workaround — when the shared-hosting tenant's per- apex-domain SPF record is budget- constrained, the tenant splits the SPF publication across per- subdomain records (transactional ESP at mail.<tenant>, marketing ESP at newsletter.<tenant>, bulk ESP at bulk.<tenant>) so each per-subdomain SPF record gets its own independent 10- lookup budget; the SPF-lookup- limit spoke documents the per- subdomain delegation operational discipline and the per-subdomain DMARC sp=-tag coordination this shared-hosting page's per-tenant p=quarantine / p=reject rollout contract consumes — the per- subdomain SPF publication is the load-bearing precondition for per-subdomain dmarc=pass on the tenant's marketing-newsletter stream; and (iv) per- tenant sender consolidation as architectural remediation — when the shared-hosting tenant's stacked-ESP cascade cannot be remediated through flattening or subdomain delegation, the architectural remediation is to retire redundant ESPs to a single primary transactional relay + a single primary marketing relay (eliminating the abandoned legacy ESP include: + the rarely-used per-region SES include); the SPF-lookup-limit spoke documents the sender- consolidation operational playbook the shared-hosting tenant follows when the per-tenant per-domain SPF record cannot fit under the §4.6.4 cap through any other path, AND the per-tenant outbound mail-flow inventory the consolidation requires is the same per-tenant ESP inventory THIS page's pre- rollout audit catalogues at §6 of the per-tenant DMARC deployment workflow. Read the SPF-lookup-limit spoke alongside this shared-hosting DMARC deployment guide whenever the per-tenant per- domain SPF record is showing spf=permerror in the aggregate RUA stream (the per-tenant SPF-permerror rate is the canonical precursor symptom that blocks any p=quarantine / p=reject advancement on the per- tenant DMARC policy THIS page documents — the lookup-limit spoke is the structural remediation reference the shared-hosting tenant consults to clear the precursor symptom).
• SPF PermError vs TempError — the SHARED-HOSTING-TENANT-PER-VHOST-SPF- PERMERROR-VS-TEMPERROR-DIAGNOSTIC-LADDER companion to this shared-hosting DMARC deployment guide. Where THIS page documents the per-tenant DMARC deployment workflow on shared-hosting panels (panel UI vs zone-file shell-access coordination, panel-managed nameserver vs operator-owned per-customer- domain publication, multi-tenant outbound- relay IP reputation, per-tenant SPF / DKIM / DMARC tag-list authoring), the permerror- vs-temperror spoke is the focused per-code diagnostic reference shared-hosting tenants consult when the aggregate RUA evidence stream surfaces SPF-failure rows that the per-tenant DMARC deployment ramp must triage. Four per-shared-hosting-per-code- root-cause dimensions: (i) PER-TENANT- PERMERROR-VIA-PANEL-INCLUDE-CASCADE attribution (the panel's default outbound- relay include: token + the tenant's per-ESP marketing-automation include: + transactional-ESP include: + per-region transactional include: stack exceeds the RFC 7208 §4.6.4 ten-DNS-query budget and produces PermError on EVERY message from the tenant's domain — the spoke's lookup-audit workflow + flattening / subdomain-delegation / sender-consolidation remediation catalogue is the canonical shared-hosting-tenant remediation reference), (ii) PER-TENANT-PERMERROR-VIA-RECORD- GRAMMAR-VIOLATION attribution (RFC 7208 §4.5 version-prefix omission, malformed ip4: / ip6: CIDR, invalid qualifier-prefix combinations, the one-SPF-record-per-domain constraint per RFC 7208 §3.2 violated by accidental per-tenant duplicate-record publication — all PERMANENT operator-side record-edit remediation), (iii) PER-TENANT-TEMPERROR- VIA-SHARED-NAMESERVER-INFRASTRUCTURE- OUTAGE attribution (shared-hosting tenants whose nameserver is panel-managed observe TempError rows correlated with shared- nameserver-infrastructure outages — per-receiver per-source-IP correlation distinguishes self-resolving outages from persistent shared-nameserver regressions REQUIRING shared-host-operator escalation), (iv) PER-TENANT-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 — shared- hosting tenants whose receiver mix spans both must factor per-receiver-interpretation variance into the per-tenant ramp risk- assessment). Critical when this shared- hosting DMARC deployment guide's per-tenant rollout reaches an SPF permerror or temperror symptom in the aggregate RUA stream — the spoke's per-code diagnostic ladder is the canonical next step in the shared-hosting-tenant SPF-failure triage workflow.
• DMARC for Office 365 Hybrid — the contrasting-deployment-topology- peer companion to this shared-hosting DMARC deployment reference. Where THIS page documents the SHARED-HOSTING- TENANT-AS-PROVIDER-MANAGED-MULTI-TENANT deployment topology (the shared-host- operator-managed SMTP relay shared across hundreds of co-resident tenant domains, the per-tenant SPF record constrained by the shared-host-operator's published mechanism inventory, the per- tenant DKIM signing key whose publication is governed by the shared- host operator's WHM/Plesk/DirectAdmin/ ISPConfig control panel, the per-tenant DMARC TXT record published into the per-tenant zone via the shared-host operator's DNS management interface), the Office-365-hybrid spoke documents the structurally-OPPOSITE HYBRID- EXCHANGE-AS-TENANT-MANAGED-DUAL-CLOUD- AND-ON-PREM deployment topology in which the per-tenant outbound stream is split across Exchange Online + on- prem Exchange via tenant-managed mail- flow connectors, the per-tenant SPF must authorize TWO independent source- IP topologies (the cloud-leg include:spf.protection.outlook.com + the on-prem-leg per-tenant IP literals or mx mechanism), the per-tenant DKIM-signing surface is dual-rooted (Exchange-Online-managed selector1._domainkey + on- prem-Exchange-managed selector), AND the per-tenant operator owns BOTH the Exchange Online tenant configuration AND the on-prem Exchange server configuration. Read the Office-365- hybrid spoke alongside this shared- hosting deployment reference when evaluating the per-tenant DMARC- deployment-control spectrum: the shared-hosting tenant baseline THIS page documents is the per-tenant deployment topology with the LEAST operator control (the shared-host operator dictates the mechanism inventory), the Office-365-hybrid spoke documents the per-tenant deployment topology with the MOST operator control (the tenant owns cloud + on-prem + connector configuration), and the contrast exposes the per-tenant SPF / DKIM / DMARC publication-discipline dimensions that scale with the per- tenant operator-control surface.
• DMARC for SaaS senders — the shared-hosting-tenant-as-SaaS- customer-of-external-marketing-and- transactional-ESP-platforms-downstream- consumer companion to this shared- hosting DMARC deployment reference. Where THIS page documents the SHARED- HOSTING-TENANT-AS-PROVIDER-MANAGED- MULTI-TENANT deployment topology (the shared-host-operator-managed SMTP relay + per-tenant cPanel/Plesk/DirectAdmin/ ISPConfig control panel + per-tenant zone-managed DNS), the SaaS-senders spoke documents the structurally- complementary PER-SAAS-PROVIDER-AS- MULTI-TENANT-ESP-PLATFORM deployment shape in which the per-shared-hosting- tenant is the per-customer consumer of external marketing-ESP / transactional- ESP / notification-platform SaaS providers (Mailchimp / SendGrid / Mailgun / Klaviyo / Brevo) whose per- customer SPF-include cascade + per- customer-CNAME-delegated DKIM signing + per-customer subdomain delegation must be coordinated through the per- tenant control-panel-managed DNS interface. Read the SaaS-senders spoke alongside this shared-hosting deployment reference when the per- tenant outbound mail-flow stacks the shared-host-managed SMTP relay WITH external SaaS-platform-relayed mail (the canonical stacked-ESP- include-cascade root-cause class for SPF-permerror under the 10-DNS-lookup cap THIS page's pre-rollout audit catalogues) — the per-tenant SPF publication on the shared-host- managed zone must enumerate the shared-host-operator's include: token AND every per-SaaS-platform per-customer include: token, the per- tenant DMARC publication on the same zone is the load-bearing per-tenant alignment-verdict surface every per- SaaS-sender per-customer-CNAME- delegated DKIM signature must produce dkim=pass + dkim-aligned=true against, and the per-tenant subdomain-delegation discipline is the budget-split workaround the SPF- lookup-limit spoke documents when the per-tenant per-domain SPF cannot fit under the 10-DNS-lookup cap with both shared-host-include and per-SaaS- customer-include cascades stacked on a single per-domain record.
• DKIM selectors explained — the PER-CONTROL-PANEL-AUTO-GENERATED- PER-TENANT-SELECTOR-NAMESPACE-PRIMITIVE- REFERENCE companion to this shared- hosting DMARC deployment reference. Where THIS page documents the SHARED- HOSTING-TENANT-AS-PROVIDER-MANAGED- MULTI-TENANT DMARC-deployment topology and its per-tenant per-control-panel SPF / DKIM / DMARC publication discipline, the dkim_selectors_ explained spoke documents the DKIM-SELECTOR-NAMESPACE PRIMITIVE the shared-host control panel auto- publishes per-tenant at the <selector>._domainkey.<tenant-domain> TXT-record level: the per-control- panel canonical selector catalogue (cPanel's default._domainkey, Plesk's default._domainkey, DirectAdmin's per-tenant selector, ISPConfig's per-tenant configured selector), the dual-selector rotation publishing-window mechanics, and the seven selector-publication failure modes the per-shared-host operator and per-tenant customer must coordinate. FOUR structurally- distinct PER-CONTROL-PANEL-AUTO- GENERATED-PER-TENANT-SELECTOR- NAMESPACE dimensions the per-shared- hosting-tenant DMARC deployment THIS page documents operationally consumes: (i) per-control- panel auto-published per-tenant canonical selector identity AS LOAD- BEARING-PER-TENANT DKIM-PUBLICATION- SCHEMA INPUT — the per- shared-host control panel (cPanel / Plesk / DirectAdmin / ISPConfig) auto-generates a per-tenant DKIM selector at a control-panel-specific canonical name (default is the cPanel + Plesk convention, DirectAdmin uses a per-tenant configured selector, ISPConfig uses a per-tenant configured selector); the per-tenant DMARC alignment surface THIS page audits depends on the per-control-panel canonical selector being correctly published at <sel>._domainkey.<tenant-domain> the selectors-explained spoke catalogues; (ii) per-tenant zone-managed DKIM TXT-record byte- level publication AS LOAD-BEARING- PER-TENANT PUBLISHER-SIDE-SELECTOR- DEFECT-PREVENTION DISCIPLINE — the per-tenant zone the control panel manages is the per-tenant publication surface for the per-selector v=DKIM1; k=rsa; p=<base64> TXT-record the selectors-explained spoke documents; the seven publisher-side selector-publication failure modes the spoke enumerates (NXDOMAIN, stale t=y, empty p=, truncated p=, mid-cutover gap, selector-reuse, SERVFAIL) are the canonical per-tenant dkim=permerror root- cause catalogue this shared-hosting DMARC-deployment audit must prevent at the per-tenant zone- publication level; (iii) per- tenant DKIM-key-rotation cutover AS LOAD-BEARING-DUAL-SELECTOR- PUBLISHING-WINDOW-COORDINATION- WITH-PER-CONTROL-PANEL-AUTO- GENERATION DISCIPLINE — the per-shared-host control panel's per-tenant DKIM-rotation operation produces a NEW per-tenant selector (typically default2 or a control-panel-versioned name) while the OLD per-tenant selector remains zone-published in a per- tenant publishing-window the selectors-explained spoke documents as the canonical dual- selector overlap discipline; the per-tenant operator coordinating the rotation through the shared- host control-panel UI inherits the publishing-window / cutover- window / retirement-window mechanics the spoke catalogues; (iv) per-tenant stacked- SaaS-include selector-attribution AS LOAD-BEARING-PER-TENANT MULTI- SIGNER-CUSTODY-ISOLATION INVARIANT — the per-tenant outbound mail-flow stacks the shared-host control-panel auto- signed mail (per-control-panel canonical selector) WITH external SaaS-platform-signed mail (per- SaaS-provider CNAME-delegated selector — SendGrid's s1, Mailchimp's k1, Mailgun's mta); the per-tenant 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-tenant attribution- discipline that lets the per-row aggregate-report auth_results.dkim.selector field disambiguate which signer produced which per-row verdict across the stacked-ESP-include cascade THIS page's pre-rollout audit catalogues. Read the dkim_selectors_explained spoke ALONGSIDE this shared-hosting deployment reference when authoring the per-tenant DKIM-publication audit-checklist row in the pre- rollout audit THIS page documents — the spoke is the canonical PER- CONTROL-PANEL-AUTO-GENERATED- PER-TENANT-SELECTOR-NAMESPACE- PRIMITIVE REFERENCE the shared- host-tenant DMARC deployment depends on at the per-tenant zone-publication level.
• DNS Record Generator - SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• DMARC Analyzer Dashboard - ingests aggregate reports and surfaces the per-sender / per-IP / per-day breakdown via includes/DmarcParser.php.
• Plesk Documentation: DKIM and SPF - the canonical primary-source vendor documentation for Plesk DKIM configuration.
• DirectAdmin Documentation: Email - the canonical primary-source vendor documentation for DirectAdmin email management.
• ISPConfig Documentation - the canonical primary-source vendor documentation for ISPConfig.
• Google: Email sender guidelines - the canonical Feb 2024 bulk-sender requirements that apply to every sender regardless of hosting platform.
• BIMI - the PER-SHARED-HOSTING-TENANT-PER-DOMAIN- BIMI-PUBLICATION-INTRO upstream-companion spoke that PAIRS with the BIMI-SVG- requirements byte-level profile reference (the next entry directly downstream in THIS Related Guides UL) AND the BIMI-certificates VMC/CMC procurement reference (further downstream in THIS UL). Where THIS page documents the per-tenant DMARC publication discipline on cPanel / Plesk / DirectAdmin / ISPConfig / WHM-reseller panels and the shared-outbound-relay reputation-coordination constraint, the bimi_explained spoke is the UPSTREAM PROTOCOL INTRODUCTION REFERENCE documenting what BIMI is (RFC 9078), how the default._bimi.<tenant-domain> TXT record encodes the l=-URL + a=-URL tag pair, and why mailbox-provider receivers (Gmail, Apple Mail, Yahoo, AOL, Fastmail) require BOTH a per-tenant DMARC-aligned-and-enforcing publication-floor AND the per-tenant SVG-Tiny-PS + VMC PKI chain BEFORE rendering the per-tenant per-domain brand logo at the inbox-list rendering boundary. Four per-shared-hosting-tenant per-domain BIMI-publication-vs-DMARC-enforcement-and- control-panel-Zone-Editor coupling dimensions the cross-reference makes explicit: (i) shared-hosting-tenant BIMI eligibility floor is the per-tenant DMARC enforcement gate THIS page documents — the bimi_explained spoke names the p=quarantine OR p=reject per-tenant enforcement publication floor mailbox-provider BIMI evaluators MUST observe before they will render the per-tenant SVG logo; the shared-hosting-tenant operator following THIS page's Phase-1-through-Phase-5 DMARC rollout timeline reaches the BIMI-eligibility threshold AS the Phase-5 enforcement transition completes, making bimi_explained the natural next-step intro the shared- hosting-tenant consults BEFORE diving into the bimi_svg_requirements byte-grammar deep-dive or the bimi_certificates VMC procurement workflow; (ii) shared- hosting-tenant BIMI TXT-record publication via control-panel Zone Editor distinct from managed-provider tenant publication — the shared-hosting-tenant operator publishes the default._bimi.<d> TXT record via the cPanel / Plesk / DirectAdmin / ISPConfig Zone Editor UI (the SAME publication topology this page documents for the per-tenant _dmarc.<d> TXT record), NOT via a managed-provider cloud-tenancy admin console; the per-tenant Zone-Editor-publication discipline bimi_explained intro documents thus reuses the SAME shared-hosting-tenant operator- empowerment surface as the DMARC publication on THIS page, distinct from per-Workspace- tenant or per-M365-tenant BIMI publication topologies; (iii) shared-hosting- tenant BIMI publication distinction from managed-provider Workspace / M365 BIMI publication topologies — bimi_explained documents that managed-provider BIMI publication for Workspace and M365 tenants flows through cloud-tenancy admin consoles (Google Admin / Microsoft 365 Admin) WHILE the shared-hosting tenant publishes via the panel's Zone Editor; this publication- topology distinction is the load-bearing operator-empowerment-ceiling input the shared-hosting tenant must internalise BEFORE following the bimi_svg_requirements and bimi_certificates downstream-deep-dives, because the per-tenant operator MUST coordinate SVG asset hosting (cPanel-tenant document-root / Plesk-tenant subdomain / external CDN) and VMC PEM URL hosting SEPARATELY from the BIMI TXT-record publication — a coordination burden the managed-provider Workspace / M365 admin-console-driven BIMI flow centralises; (iv) shared-hosting-tenant BIMI- eligibility-to-VMC-procurement timeline coordination — bimi_explained documents that the per-tenant BIMI publication AT A MINIMUM requires the per-tenant SVG logo published at the l=-URL; receiver-side logo rendering AT MAJOR receivers (Gmail, Apple Mail, Yahoo) additionally requires the per-tenant VMC (or, for Gmail blue-verified-mark only, the CMC) PEM chain published at the a=-URL. The shared-hosting-tenant operator who plans BIMI logo deployment SHOULD initiate VMC procurement 6 weeks BEFORE the planned Phase-5 p=reject publication date (the 3-6-week VMC issuance timeline documented in bimi_certificates) so that the per-tenant BIMI l=+a= tag pair can publish AS the Phase-5 enforcement transition completes — unlocking the SVG-display rendering AT THE receiver-side inbox-list rendering boundary at the SAME moment as the shared-hosting- tenant per-domain DMARC-enforcement-floor reaches its terminal disposition. Read bimi_explained as the per-shared-hosting- tenant BIMI PROTOCOL INTRODUCTION reference that PAVES THE WAY for the byte-level bimi_svg_requirements deep-dive AND the X.509 PKI bimi_certificates VMC/CMC procurement workflow further downstream in THIS Related Guides UL.
• BIMI SVG Tiny PS logo requirements - the SHARED-HOSTING-TENANT-PER-DOMAIN- BIMI-LOGO-PUBLICATION-AT-HTTPS-IMAGE- SVG-XML-ENDPOINT companion to this shared-hosting DMARC operator-reference. Where THIS page documents the per- tenant DMARC publication discipline on cPanel / Plesk / DirectAdmin / ISPConfig / WHM-reseller panels and the shared-outbound-relay coordination primitives operators must align with the panel's per-tenant control surface, the BIMI-SVG-requirements spoke is the DEDICATED byte-level reference operators consult when the per-tenant per-domain BIMI logo file must be published at a panel-controlled HTTPS endpoint serving the image/svg+xml Content-Type. Three concrete shared-hosting-vs-Tiny- PS-publication coupling points: (i) HTTPS + image/svg+xml Content- Type serving contract on the panel's webserver - the BIMI l=-URL MUST resolve over HTTPS (not HTTP) with the image/svg+xml Content-Type header; on shared hosting the per- tenant Apache / Nginx config-block is managed by the panel and may default to application/octet-stream for SVG without a per-tenant .htaccess override or a panel-side MIME-type-mapping change; the BIMI-SVG-requirements spoke documents the byte-level serving contract operators verify against the panel's per-tenant webserver configuration; (ii) 32KB file-size cap vs panel-side upload and quota constraints - the Tiny PS profile imposes a 32KB upper bound on the SVG file; on shared hosting the per-tenant upload-tooling (panel file manager, SFTP-quota enforcement, per-tenant disk-space cap) and the per-tenant php.ini upload_max_filesize / post_max_size directives rarely block 32KB uploads but the per-tenant control surface MAY rewrite or strip <!DOCTYPE> / <?xml> headers during upload sanitisation; the BIMI- SVG-requirements spoke documents the byte-level file-structure profile that survives the panel's per-tenant upload pipeline; (iii) per- tenant subdomain serving vs apex serving - the BIMI l=-URL is per-publisher per-domain and routinely resolves at a per-tenant subdomain (logo.example.com or cdn.example.com/bimi.svg); on shared hosting the per-tenant subdomain DNS + virtual-host configuration is panel-managed, and the per-tenant control over the Content-Type response header at the subdomain endpoint is a load-bearing coordination primitive THIS page's shared-hosting tenant must align with the panel's per-tenant subdomain virtual-host configuration. Read the BIMI-SVG-requirements spoke ALONGSIDE this shared-hosting DMARC operator-reference whenever the per- tenant per-domain BIMI deployment is scoped onto a shared-hosting topology where the per-tenant control over the webserver-side MIME-type, the panel's per-tenant file-upload sanitisation pipeline, and the per-tenant subdomain virtual-host configuration are the load-bearing publication-side coordination constraints.
• MX records — the PER-SHARED-HOSTING-TENANT-INBOUND- MX-AS-RECEIVER-SIDE-STRUCTURALLY-PAIRED- IDENTITY-RECORD-CLASS-TO-PER-TENANT- OUTBOUND-DMARC-PUBLICATION-DISCIPLINE companion reference. Where THIS page documents the per-shared-hosting-tenant per-domain DMARC deployment discipline across Phase 0 through Phase 5 ramp (panel-managed-nameserver TTL discipline + per-tenant SPF prerequisite at shared outbound relay + per-tenant DKIM publication at panel-managed selector + per-tenant DMARC TXT record publication at panel zone editor + per-tenant RUA ingestion + per-tenant Phase 3–5 ramp at shared-relay IP reputation baseline), the MX-records spoke documents the structurally-paired RECEIVER-SIDE per- shared-hosting-tenant per-domain inbound MX publication discipline (the panel zone-editor-published MX RDATA — typically the shared-hosting provider's per-tenant inbound MTA target like mail.<tenant-domain> or the provider-supplied mx<N>.<provider-domain> target — whose per-tenant per- domain publication at the panel-managed nameserver steers inbound mail traffic to the per-tenant inbound MTA), across four per-shared-hosting-tenant-inbound- MX-to-per-tenant-DMARC-publication- coupling dimensions: (i) per- shared-hosting-tenant-inbound-MX-and- outbound-DMARC-publication-as- structurally-paired-record-class-pair — every per-tenant per-domain shared- hosting deployment requires BOTH the per- tenant outbound SPF / DKIM / DMARC TXT records THIS page documents AND the per- tenant inbound MX record the MX-records spoke documents at the panel-managed nameserver zone to fully wire the per- tenant per-domain to the shared-hosting boundary; the two record classes are structurally paired at the per-tenant panel zone-editor publication event; (ii) per-shared-hosting-tenant- inbound-MX-publication-as-load-bearing- input-to-inbound-DMARC-evaluation-at- shared-inbound-MTA — the per- tenant inbound MX RDATA the MX-records spoke documents resolves the receiver- side endpoint where the per-message inbound DMARC evaluation occurs at the shared-hosting provider's per-tenant inbound MTA frontend (typically Exim / Dovecot LMTP / Postfix per-shared-host deployment); per-tenant inbound DMARC evaluation outcomes feed the per-tenant spamassassin / per-tenant inbox-routing policy and the per-tenant Authentication- Results header emitted downstream into the per-tenant Webmail / IMAP / POP3 delivery surface; (iii) per- shared-hosting-tenant-inbound-MX-as- structurally-symmetric-load-bearing- input-to-per-tenant-RUA-feed-evidence- source-IP-attribution — the per-tenant inbound MX endpoint the MX- records spoke documents IS the per- tenant per-receiver-side MTA that emits per-day aggregate RUA reports BACK to the per-tenant's rua=mailto: tag-value mailbox (when the per-tenant is also the receiver via the shared- hosting inbound MTA for inbound mail from EXTERNAL publishers whose DMARC TXT records authorize the shared- hosting inbound MTA as an RUA emitter); per-tenant inbound MX publication at the panel-managed nameserver GATES whether the receiver-side per-tenant RUA-emission infrastructure operates against the per-tenant per-domain; (iv) per-shared-hosting-tenant- inbound-MX-publication-via-panel-zone- editor-as-coordinated-lockstep-with- outbound-DMARC-TXT-publication — the per-tenant per-domain shared- hosting onboarding sequence at the panel zone editor requires publishing BOTH the per-tenant outbound SPF / DKIM / DMARC TXT records THIS page documents AND the per-tenant inbound MX record the MX-records spoke documents at the panel-managed nameserver IN COORDINATED LOCKSTEP (operators MUST NOT flip the inbound MX to point at the per-tenant shared-inbound MTA before BOTH record classes have fully DNS-propagated, lest in-flight inbound mail be black-holed at the per-tenant prior to the shared- hosting inbound MTA's acceptance threshold). Read this WITH the per- shared-hosting-tenant DMARC operator reference when the per-tenant per- domain wiring sequence to the shared- hosting boundary reaches the operator's queue: THIS page documents the per- tenant outbound SPF / DKIM / DMARC publication discipline across Phase 0 through Phase 5 ramp, the MX-records spoke documents the structurally-paired receiver-side per-tenant per-domain inbound MX publication discipline whose panel-managed nameserver-published MX RDATA gates inbound mail traffic to the per-tenant inbound MTA the per-tenant outbound DMARC publication symmetric receiver-side identity endpoint THIS page documents presupposes is operational.
• DKIM troubleshooting - the PER-SHARED-HOSTING-TENANT PER-CONTROL-PANEL-MANAGED PER-SELECTOR DKIM-VERIFICATION-FAILURE-DIAGNOSTIC- PLAYBOOK companion to this shared- hosting DMARC deployment reference. Where THIS page documents the per- shared-hosting-tenant DKIM-publication discipline at the control-panel- managed zone-editor (cPanel / Plesk / DirectAdmin / panel-mediated default._domainkey / per-panel-issued selector TXT-record provisioning with the SHARED-OUTBOUND- RELAY signer co-tenant constraint every per-tenant per-domain on the shared-hosting topology inherits), the DKIM-troubleshooting spoke is the per-control-panel-tenant per-selector failure-mode investigation playbook documenting the FIVE per-receiver DKIM-verifier verdict states a per- shared-hosting-tenant 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-tenant outbound message carried NO DKIM-Signature header at all - per-shared-hosting failure mode where the per-tenant control-panel DKIM- signer toggle is disabled at the per-account level, the SHARED- OUTBOUND-RELAY did not signer-tag the per-tenant per-domain outbound flow, or the per-tenant zone-editor UI never published the per-selector TXT-record; (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-shared-hosting failure mode where the per-tenant per- selector TXT-record publication is suffering per-RR-TTL propagation lag at the panel-managed authoritative nameserver or the panel-managed nameserver SERVFAILs under per- receiver query load; (iii) dkim=permerror indicating the per-receiver verifier successfully retrieved the per- selector public-key TXT-record but could not parse it - per-shared- hosting failure mode where the panel-published per-selector TXT record is truncated past the 255- byte single-string boundary without proper multi-string quoting (cPanel zone-editor known historical bug), contains an unsupported k= algorithm-tag value from a panel-defaulted legacy configuration, or carries the p=-revocation marker from an old panel-managed key- rotation pass that left the empty- value record behind; (iv) dkim=fail indicating the per-receiver verifier retrieved a parseable per-selector public-key TXT but the per-message body-hash or signature-hash did NOT verify - per-shared-hosting failure mode where the per-tenant outbound mail- flow post-signature modification (panel-injected SHARED-MTA Received- header, per-tenant SpamAssassin header-injection on the SHARED- OUTBOUND-RELAY, panel-mandated per-co-tenant unsubscribe-link rewrite at the SHARED-OUTBOUND- RELAY egress point) 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-tenant From: header organizational domain under the per-publisher adkim= alignment- strictness setting - per-shared- hosting failure mode where the SHARED-OUTBOUND-RELAY signs every co-tenant per-domain outbound message with the SHARED-HOSTING- PROVIDER's own d=- domain rather than the per-tenant customer domain. Read THIS page when PUBLISHING the per-shared- hosting-tenant DKIM selector TXT via the control-panel zone editor; read the DKIM-troubleshooting spoke when INVESTIGATING per-tenant per- selector DKIM-verification failures surfaced in per-receiver Authentication-Results headers or per-publisher RUA aggregate-report rows.
• Reverse DNS / PTR records for mail servers — the SHARED-OUTBOUND-RELAY-IP-PTR- RECORD-OWNED-BY-HOSTING-PROVIDER-NOT- BY-PER-TENANT-CUSTOMER companion documenting the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR-record publication discipline whose per-IP reverse-zone delegation in the shared-hosting topology is STRUCTURALLY DIFFERENT from the per- tenant per-customer-domain FORWARD- zone publication discipline THIS page documents. Where THIS page documents the per-shared-hosting- tenant per-customer-domain FORWARD-zone publication discipline at the control-panel-managed nameservers (cPanel WHM / Plesk / DirectAdmin / ISPConfig zone editors publishing per-tenant SPF / DKIM-selector / DMARC TXT records), the reverse-DNS-PTR spoke is the REVERSE-zone publication discipline companion documenting the STRUCTURALLY-DISTINCT shared-hosting IP-IDENTITY-LAYER pattern at four per-shared-hosting-tenant-PTR- record-coordination-with-control- panel-provider dimensions: (i) per-shared-hosting-shared- outbound-relay-IP-PTR-record- ownership-boundary — the SHARED-OUTBOUND-RELAY IP that EVERY per-tenant per-customer-domain on the shared-hosting deployment outbound- mail flows through has ONE PTR record in the IN-ADDR.ARPA reverse zone delegated to the SHARED-HOSTING PROVIDER's reverse-zone-managing nameservers — NOT to any per-tenant customer; the per-tenant customer CANNOT independently publish a PTR record for the SHARED-OUTBOUND-RELAY IP and MUST coordinate with the hosting provider for any per-IP PTR- record change; (ii) shared- hosting per-tenant HELO-name-vs-PTR- name FCrDNS verification — the SHARED-OUTBOUND-RELAY's HELO/ EHLO name in SMTP transactions TYPICALLY presents the HOSTING- PROVIDER's own hostname pattern (mail.providername.com / relay-N.providername.net); the FCrDNS (Forward-Confirmed reverse DNS) verification at receiver-side connecting-IP-identity check requires the per-IP PTR record + the HELO-name forward-A lookup to round-trip-match; per-tenant customer cannot influence this layer — only the hosting provider can; (iii) per- tenant DMARC alignment is ORTHOGONAL to per-IP PTR alignment — DMARC alignment (FROM:-org-domain ↔ d= or return-path-domain identity) is EVALUATED INDEPENDENTLY of the per-IP FCrDNS verification at the per-publisher per-message authentication-results header; per- tenant DMARC publication discipline THIS page documents can achieve per-message dmarc=pass even when the SHARED-OUTBOUND-RELAY's per-IP FCrDNS verification fails — BUT the per-receiver-mailbox-provider per-day IP-reputation aggregate floor for the SHARED-OUTBOUND-RELAY IP STILL degrades per-receiver inbox placement for EVERY co-tenant on the shared-hosting deployment; (iv) shared-hosting per-tenant per-domain rDNS-as-co-tenant- reputation-coupling-axis — because the SHARED-OUTBOUND-RELAY IP is SHARED across every per-tenant customer on the shared-hosting deployment, FCrDNS-misalignment OR per-IP IP-reputation degradation triggered by ANY single co-tenant's outbound-mail abuse (spam / phishing / BEC outbound from a compromised per-tenant account) IS A LOAD- BEARING per-IP IP-reputation-floor degradation event that AFFECTS EVERY co-tenant's per-receiver- mailbox-provider per-day inbox- placement baseline — irrespective of each individual co-tenant's per- domain DMARC publication discipline correctness. Read THIS page when PUBLISHING per-shared-hosting-tenant per-customer-domain DMARC FORWARD- zone records via the control-panel zone editor; read the reverse-DNS- PTR spoke when COORDINATING with the hosting provider on the SHARED- OUTBOUND-RELAY's per-IP PTR-record publication discipline OR when investigating per-tenant per-domain inbox-placement degradation that originates at the per-IP FCrDNS verification layer rather than the per-domain DMARC publication layer.
• SPF mechanisms explained (RFC 7208 §5) — the SHARED-HOSTING-TENANT-PER-MECHANISM- LOOKUP-COST-ACCOUNTING companion to this shared-hosting DMARC deployment guide. Where THIS page documents the per-shared- hosting-tenant per-customer-domain DMARC deployment procedure across the five canonical control-panels (cPanel / Plesk / DirectAdmin / ISPConfig / WHM-reseller) — the per-control-panel TXT-record- publication UI, the per-tenant DNS-zone- editor workflow, the per-host inherited include: cascade the tenant must compose against, the per-tenant outbound-relay shared-MX cohabitation pattern — the SPF-mechanisms-explained spoke is the per-mechanism lookup-cost- and-evaluation-order REFERENCE documenting the RFC 7208 §5 grammar the tenant must apply when budgeting their own include: / ip4: / a: / mx: mechanisms on top of the inherited host-wide cascade. The SHARED- HOSTING-TENANT-VS-SPF-MECHANISM cross- reference establishes FOUR structurally- distinct lookup-budget accounting dimensions whose correctness the tenant must verify before publication: (i) per-tenant inherited include: cascade base cost — cPanel's include:websitewelcome.com, Plesk's include:_spf.plesk.com, and DirectAdmin's host-provider include: all consume 2-5 lookups from the 10-lookup budget BEFORE the tenant adds anything; (ii) per-tenant supplemental include: nested cost — every transactional-ESP include:spf.<esp>.tld the tenant appends to support their own outbound flow adds 1 lookup for the include: itself PLUS the cost of every nested mechanism in the ESP's published SPF record (commonly 3-5 more); (iii) per-tenant a: / mx: mechanism A/AAAA-record fan-out cost — every a:mail.< tenant>.tld costs 1 lookup PLUS one per A/AAAA record returned, every mx:<tenant>.tld costs 1 lookup PLUS one per MX record returned PLUS one per A/AAAA per MX host; (iv) per-tenant permerror cascade at receiver-side — when the cumulative shared-host + tenant cascade crosses the 10-lookup ceiling, every DMARC-honouring receiver returns spf=permerror on EVERY tenant message, which under p=reject the receiver propagates to dmarc=fail + 550 SMTP-time rejection at the receiving MX. Read THIS page when PUBLISHING per- shared-hosting-tenant per-customer-domain DMARC records via the control-panel zone editor; read the SPF-mechanisms-explained spoke when AUDITING the per-tenant cumulative SPF lookup-budget arithmetic that determines whether the tenant's supplemental mechanisms fit underneath the inherited host-cascade's residual budget headroom BEFORE the control-panel zone editor accepts the record.
• SPF for Google Workspace — the PER-PUBLISHER-PER-TENANT-PER- OPERATOR-SPF-PUBLICATION-DISCIPLINE-AS-LOAD- BEARING-PEER-PROTOCOL-LAYER-PER-OPERATOR- PER-TENANT-AUTHENTICATION-PUBLICATION- DISCIPLINE companion to this DMARC-for- shared-hosting publication reference. Where THIS page documents the per-shared-hosting- tenant per-domain DMARC publication discipline at the per-tenant per-operator shared-hosting-control-panel zone-editor layer (the per-tenant per-domain _dmarc.<domain> TXT-RR publication, the per-shared-hosting-server per-tenant per-domain three-mode policy- progression cadence, the per-shared- hosting-tenant per-domain rua=-mailbox routing discipline, the per-shared-hosting- host-cascade-inherited-SPF cumulative- budget-headroom arithmetic), the SPF-for- Google-Workspace spoke is the peer per- publisher per-tenant per-operator SPF publication discipline whose per-Google- Workspace-tenant SPF publication discipline (canonical v=spf1 include:_spf.google.com ~all SPF-record template, per-tenant supplemental third-party-ESP include-statement composition (include:sendgrid.net, include:_spf.mailgun.org), per-tenant cumulative 10-lookup-limit budget arithmetic, per-tenant zone-editor commit cadence) pairs operationally with the per-shared-hosting-tenant per-domain DMARC publication discipline THIS page documents at FOUR per-operator-per-tenant coupling dimensions: (i) peer per- publisher per-tenant per-operator cross- protocol-pillar authentication-publication- discipline parallelism — the per-shared-hosting-tenant per-domain DMARC publication discipline THIS page documents at the per-tenant per-operator shared-hosting-control-panel zone-editor layer pairs operationally with the per- publisher per-Google-Workspace-tenant SPF publication discipline the SPF-for-Google- Workspace spoke documents at the per- tenant per-operator Admin-Console DNS- publication layer — both are per-publisher per-tenant per-operator authentication- publication-discipline references whose per-tenant per-operator deployment workflow is the load-bearing per-publisher per- tenant per-operator cross-protocol-pillar publication-discipline composition rhythm every per-publisher per-tenant per-operator DMARC-deployment programme requires; (ii) per-publisher per-tenant per- operator cross-protocol-pillar SPF-and- DMARC publication-coordination parallelism — the per- shared-hosting-tenant per-domain DMARC publication discipline THIS page documents at the per-tenant per-operator zone-editor layer presupposes a per-publisher per- tenant per-operator SPF publication discipline (per-shared-hosting-host- cascade-inherited include:shared-hosting-host-template SPF-template OR per-tenant per-Google- Workspace tenant include:_spf.google.com ~all publication) whose per-tenant per-operator SPF publication discipline the SPF-for- Google-Workspace spoke documents the per- tenant per-operator publication-rationale of — together the per-tenant per-operator SPF-and-DMARC publication coordination is the load-bearing per-publisher per-tenant per-operator cross-protocol-pillar publication-discipline composition rhythm every per-publisher per-tenant per-operator DMARC-deployment programme requires; (iii) per-publisher per-tenant per- operator cumulative-10-lookup-limit-budget arithmetic parallelism — the per-shared-hosting-tenant per-domain DMARC publication discipline THIS page documents operationally depends on the per-publisher per-tenant per-operator SPF-record cumulative-10-lookup-limit-budget arithmetic the SPF-for-Google-Workspace spoke documents the per-Google-Workspace-tenant publication rationale of (per-Google- Workspace-tenant canonical include:_spf.google.com consumes 4 DNS lookups, per-tenant supplemental third-party-ESP include- statements consume additional 1-3 DNS lookups each, per-tenant cumulative budget cap at 10 hard-ceiling) — per-tenant per- operator cumulative-10-lookup-limit-budget breach emits per-message spf=permerror that propagates to per-message policy_evaluated.spf=fail feeding the per-shared-hosting-tenant per- domain DMARC disposition rule THIS page documents the operator-side publication rationale of; (iv) per-publisher per-tenant per-operator zone-editor commit- cadence coordination — the per-shared-hosting-tenant per-domain DMARC publication discipline THIS page documents at the shared-hosting-control-panel zone- editor layer pairs operationally with the per-publisher per-Google-Workspace-tenant SPF publication discipline the SPF-for- Google-Workspace spoke documents at the per-tenant Admin-Console DNS-publication layer, and the per-publisher per-tenant per-operator cross-operator zone-editor commit-cadence coordination (shared- hosting-control-panel commits DMARC TXT-RR cadence synchronized with Google-Workspace- tenant Admin-Console SPF TXT-RR commit cadence) is the load-bearing per-publisher per-tenant per-operator publication-cadence coordination rhythm every per-publisher per- tenant per-operator DMARC-deployment programme requires for sustainable cross- protocol-pillar publication-discipline coordination. Read THIS page when PUBLISHING per-shared-hosting-tenant per- domain DMARC infrastructure via the shared-hosting control panel; read the SPF-for-Google-Workspace spoke when PUBLISHING per-Google-Workspace-tenant per- domain SPF infrastructure via the Admin Console whose per-tenant per-operator SPF publication discipline pairs operationally with the per-shared-hosting-tenant per- domain DMARC publication discipline THIS page documents at the per-publisher per- tenant per-operator cross-protocol-pillar publication-discipline-composition boundary.
• DMARC forensic reports - the per-shared-hosting-tenant per- domain per-message authentication-failure forensic-investigation discipline companion to this shared-hosting DMARC deployment reference. Where THIS page documents the per-shared-hosting-tenant per-domain DMARC publication workflow (the per-shared-hosting-vendor control- panel zone-editor commit cadence, the per-tenant shared-outbound-MTA IP block attribution, the per-tenant third-party- ESP include-cascade composition, the per-tenant ruf=-tag forensic-failure-report subscription publication), the DMARC-forensic-reports spoke is the PER-MESSAGE-FORENSIC- EVIDENCE REFERENCE documenting the RFC 6591 AFRF MIME per-message failure- report envelope whose per-message authentication-failure attribution payload (the per-message envelope-MAIL- FROM-IP attributable to the per-shared- hosting-server outbound-MTA-IP-block, the per-message From:- domain-vs-envelope-MAIL-FROM alignment evidence, the per-message Authentication- Results: header dump, the per-receiver verifier-side per-leg SPF/DKIM/DMARC failure-reason-code attribution) the per-shared-hosting-tenant per-domain operator MUST examine to root-cause per-message DMARC-failure attribution between: (i) genuine per-shared-hosting- tenant per-message envelope-MAIL-FROM- IP-vs-published-SPF mechanism-mismatch, (ii) per-shared-hosting-server shared- outbound-MTA-IP-block reputation-shift, (iii) per-shared-hosting-tenant per- message third-party-ESP include-cascade publication-discipline regression, and (iv) genuine per-tenant per-message DMARC-spoofing attribution at a per- shared-hosting-vendor-vs-attacker-IP attribution boundary. Pair this page (the per-shared-hosting-tenant per- domain DMARC deployment reference) with the DMARC-forensic-reports spoke (the per-message RFC 6591 AFRF MIME failure- report payload reference) when designing the per-shared-hosting-tenant per-domain per-message DMARC-failure forensic-investigation discipline.
• SPF qualifiers explained — the LOAD-BEARING per-shared-hosting- tenant per-domain SHARED-HOSTING-~ALL- VS--ALL-TERMINAL-QUALIFIER-CHOICE- DISCIPLINE companion documenting the four RFC 7208 §4.6.2 qualifiers (+ Pass / - Fail / ~ SoftFail / ? Neutral) whose per- tenant per-domain terminal-mechanism choice is the SINGLE DOMINANT DEPLOYMENT-RISK VARIABLE for shared- hosting tenants: pick -all too early and every tenant-authored message from a not-yet-authorized outbound path (a tenant's marketing ESP, a tenant's transactional SaaS, a tenant's vacation auto-reply through a forwarder) gets receiver-side rejected with no DMARC-aggregate-report diagnostic warning window; pick +all and the shared- hosting IP space becomes a phishing- broadcast accelerant; pick ?all and the tenant gets zero DMARC SPF-authentication signal from receivers. The canonical shared- hosting deployment ramp follows the qualifiers-spoke playbook precisely: publish ~all with DMARC p=none + RUA, accumulate ≥30 days of aggregate-report evidence cataloguing every legitimate tenant- authored outbound path, only then flip to -all + DMARC p=quarantine / p=reject. Where THIS page documents the per-tenant per-domain DMARC + SPF + DKIM SHARED-HOSTING DEPLOYMENT TUTORIAL (the mechanics of publishing tenant DNS records on a shared-hosting control panel), the qualifiers spoke documents the TERMINAL-QUALIFIER-CHOICE DECISION DISCIPLINE that determines whether the published SPF record actually delivers the receiver-side enforcement-vs- deployment-monitoring posture the shared-hosting tenant needs at each ramp phase. Read THIS page when PUBLISHING the per-tenant per-domain DNS records; read the qualifiers spoke when CHOOSING the per-tenant per- domain terminal qualifier (~all during monitoring, -all after ramp completion) that determines the receiver-side enforcement-disposition the published record actually produces.
• DKIM alignment with DMARC — the per-message DKIM identifier- alignment discipline (the RFC 6376 d=-tag signing-domain match against the RFC 5322 From: header organisational domain per RFC 7489 §3.1.1, the per-tenant relaxed vs strict adkim= mode toggle) whose per-shared-hosting-tenant per-domain alignment outcome is the LOAD-BEARING precondition for the per-tenant DMARC pass verdict THIS shared-hosting deployment reference catalogues. The composition operates through FOUR per- control-panel per-selector DKIM-alignment coupling dimensions every shared-hosting- tenant operator must reason about: (i) per-control-panel-default-signer-domain DKIM d=-tag alignment with the tenant's per-domain From: header — cPanel WHM's outbound DKIM signs with d=<tenant-domain> directly (aligned by default under relaxed mode), while Plesk's panel-shared outbound relay may sign with d=<panel-host-name> (UNALIGNED by default, requiring per- tenant per-domain DKIM-signer reconfiguration); the per-tenant operator MUST audit which signer-domain the panel publishes BEFORE expecting DMARC composite-pass on the DKIM leg; (ii) per-tenant per-third-party-ESP DKIM-alignment via CNAME-delegated publication — when the per-tenant per-domain outbound flow includes external ESPs (Mailgun, SendGrid, Mailchimp) for marketing or transactional traffic, the tenant MUST publish per-ESP CNAME-delegated DKIM-selector TXT-RRs at <ESP-selector>._domainkey. <tenant-domain> so the per- message DKIM signature emits d=<tenant-domain> (aligned) rather than d=<ESP-default-domain> (unaligned); the DKIM-alignment-with- DMARC spoke documents the per-third- party-ESP CNAME-delegation pattern that achieves per-message DKIM-aligned-pass; (iii) per-control-panel-managed per- selector key-rotation cadence vs per- tenant DMARC-aligned-pass-rate continuity — when the panel rotates the shared outbound-relay DKIM selector without per-tenant operator coordination, the per-tenant per-day DKIM-aligned- pass-rate may briefly collapse during the rotation overlap window, producing per-tenant DMARC composite-fail spikes in the RUA stream; the spoke documents the per-control-panel-managed DKIM rotation coordination discipline; (iv) per-tenant relaxed vs strict adkim= mode choice as shared-hosting deployment-stability gate — shared-hosting tenants whose outbound flow traverses both the panel- default-relay AND per-third-party-ESP cascades SHOULD default to relaxed alignment (adkim=r, the DMARC default) because the per-tenant sub-domain DKIM signing (e.g., d=mail.<tenant-domain>) is aligned under organisational-domain match per RFC 7489 §3.1.1 but FAILS strict alignment that requires exact domain match; the spoke documents the per-tenant per-domain alignment-mode- toggle decision matrix. Read THIS page when AUTHORING the per-shared-hosting- tenant per-domain DMARC deployment plan; read the DKIM-alignment-with- DMARC spoke when the per-tenant per- message DKIM signature emits dkim=pass at the receiver but the per-message DMARC composite verdict still reports dmarc=fail — the spoke explains why per-message DKIM-VALID- BUT-DKIM-MISALIGNED is the canonical per-shared-hosting-tenant DMARC-fail root-cause class at the per-control- panel per-selector publication boundary.
• DKIM DNS-record byte syntax - the SHARED-HOSTING-DKIM-DNS- PUBLICATION-DISCIPLINE companion to this shared-hosting DMARC deployment reference. Where THIS page documents the per-tenant per-control-panel-emitted DKIM-selector publication workflow (the cPanel / Plesk / DirectAdmin / Vesta control-panel UI emitting a per-tenant per-domain DKIM key-pair plus the per-tenant default._domainkey TXT record the control panel asks the tenant to publish at the DNS-provider boundary — the per-tenant per-control- panel DKIM-signer-to-DNS-publisher round-trip the per-shared-hosting-tenant operator must complete BEFORE the per-message DKIM signature can produce dkim=pass at the receiver), the DKIM DNS-syntax spoke documents the RFC 6376 §3.6.1 per-tag byte-grammar reference every receiver-side DKIM verifier consumes — 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 shared-hosting deployment guide with the DKIM-DNS-syntax spoke when verifying that the per-tenant per-control-panel-emitted TXT record at default._domainkey.<tenant-domain> matches the RFC 6376 §3.6.1 byte- grammar contract — the per-tenant per- selector terminal TXT-record byte- grammar compliance is the STRUCTURAL receiver-side verification PREREQUISITE every shared-hosting-signed outbound message depends on for the dkim=pass verdict that gates the per-message per-receiver DMARC-aligned-pass-rate floor this shared-hosting deployment guide's per-tenant per-domain DMARC enforcement ramp STRUCTURALLY DEPENDS on.
• DMARC myths and misconceptions — the SHARED-HOSTING-INDUCED-MYTH- DEBUNK-COMPANION to this per-shared- hosting-tenant per-domain DMARC deployment reference. Where THIS page documents the per-shared-hosting-tenant per-domain DMARC publication-discipline mechanics (the per-shared-hosting-tenant per-domain SPF authoriser publication across the per-shared-hosting-provider- managed shared egress IP pool, the per- shared-hosting-tenant per-domain DKIM selector publication through the per- shared-hosting-provider managed key- rotation chain, the per-shared-hosting- tenant per-domain DMARC record publication at _dmarc.<tenant- domain>), the myths-and- misconceptions spoke is the MISCONCEPTION-CATALOGUE companion documenting FOUR shared-hosting-induced myth classes whose per-shared-hosting- tenant per-domain DMARC-deployment mental-model REBUTTAL is the PREREQUISITE the per-shared-hosting- tenant per-domain operator MUST INTERNALISE before configuring the per- tenant per-domain DMARC publication through the per-shared-hosting-provider cPanel / Plesk / DirectAdmin / WHM Email Deliverability UI: (i) myth 6 — "Subdomains do not get protected because the DMARC record is at the apex" — the per-shared- hosting-tenant per-domain operator-side misconception that per-publisher per- apex-domain DMARC record-publication does NOT cover per-tenant per-subdomain mailflow originating from per-shared- hosting-tenant per-subdomain (transactional-mail subdomain, marketing subdomain, ticketing subdomain) — when the per-publisher per-apex sp= subdomain-policy-inheritance tag per RFC 7489 §6.3 EXPLICITLY documents the per-publisher per-apex DMARC record- publication covering per-tenant per- subdomain mailflow under the per- publisher per-apex sp=quarantine / sp=reject inheritance- discipline, with the per-tenant per- subdomain DMARC override-discipline requiring a per-tenant per-subdomain _dmarc.<subdomain> record only when per-tenant per-subdomain policy-tier diverges from per-publisher per-apex sp=-inherited policy-tier; (ii) myth 12 — "I only need DMARC on domains I send mail from" — the per-shared- hosting-tenant per-domain operator-side misconception that per-tenant non-sending shared-hosting per-tenant per-domain DMARC publication is unnecessary — when the per-shared-hosting-tenant per-domain attacker-spoofing surface inventory THIS page documents demonstrates that EVERY per-tenant per-domain — sending or non- sending — MUST publish a per-publisher per-domain DMARC record at p=reject with empty rua= to prevent per-tenant per-domain attacker-spoofing on the non-sending tenant-domain (RFC 7489 §11.4 parking-domain-DMARC-publication- discipline contract); (iii) myth 3 — "I have SPF and DKIM so I do not need DMARC" — the per-shared- hosting-tenant per-domain operator-side misconception that per-shared-hosting- tenant per-domain SPF + DKIM publication- discipline ALONE produces the per- receiver per-message envelope-MAIL-FROM- vs-header-From-domain ALIGNMENT verdict the per-receiver per-message DMARC evaluation per RFC 7489 §3.1 identifier-alignment materially depends on — when the per-shared-hosting-tenant per-domain DMARC publication is the per-publisher per-domain ALIGNMENT- VERDICT-EMITTING per-message DMARC- verdict-coordination primitive whose per-shared-hosting-tenant per-domain publication-discipline-completeness is the load-bearing per-tenant per-domain anti-spoofing-mitigation-pillar publication-discipline-completeness primitive; and (iv) myth 7 — "Going straight to p=reject is fine if my records look right" — the per-shared-hosting-tenant per-domain operator-side misconception that per- publisher per-domain SPF + DKIM + DMARC record-publication SYNTACTIC-CORRECTNESS ALONE is sufficient to declare per- tenant per-domain DMARC-enforcement readiness — when the per-shared-hosting- tenant per-domain shared-egress-IP-pool- operator-shared mailflow traffic-pattern inventory THIS page documents demonstrates that per-shared-hosting- tenant per-domain operator MUST first publish at p=none to observe the per-shared-hosting-tenant per-domain per-receiver per-message SPF-aligned-pass / DKIM-aligned-pass rate-floor completeness across the per- shared-hosting-provider shared egress IP pool BEFORE ramping policy to p=quarantine / p=reject enforcement. Pair this shared-hosting deployment guide with the myths-and-misconceptions spoke when explaining the per-shared- hosting-tenant per-domain DMARC- publication-discipline scope to a stakeholder who has internalised one or more of the four myth classes above — the myths-page documents the PER- MISCONCEPTION-CLASS REBUTTAL-DISCIPLINE the per-shared-hosting-tenant per- domain operator MUST DEPLOY at the stakeholder-conversation boundary, and THIS page documents the PER-SHARED- HOSTING-PROVIDER per-tenant per-domain PROTOCOL-LEVEL ROOT-CAUSE the per- misconception-class rebuttal-discipline materially attributes against.
• BIMI Verified Mark Certificates (VMC and CMC) - the PER-SHARED-HOSTING-TENANT-PER- DOMAIN-BIMI-VMC-CMC-LOGO-AUTHENTICATION companion to this shared-hosting DMARC deployment reference. Where THIS page documents the per-shared-hosting-tenant per-domain DMARC publication workflow and the protocol-level per-shared- hosting-provider per-tenant per-domain root-cause attribution the per- misconception-class rebuttal-discipline addresses, the BIMI VMC certificates spoke documents the BIMI-PROTOCOL-LAYER LOGO-AUTHENTICATION extension whose per- shared-hosting-tenant per-domain VMC or CMC procurement workflow STRUCTURALLY DEPENDS on the per-tenant DMARC enforcement floor THIS page deploys, at FOUR per-shared-hosting-tenant per- domain BIMI-coupling dimensions: (i) per-shared-hosting-tenant per- domain p=quarantine or p=reject DMARC-enforcement- floor as MANDATORY BIMI-evaluator-gating precondition for receiver-side logo display - Gmail / Apple Mail / Yahoo / Fastmail BIMI evaluators refuse to render the per-tenant per-domain VMC-asserted logo until the per-domain DMARC TXT declares p=quarantine or p=reject AND sp=quarantine / sp=reject AND the per- receiver per-publisher per-day DMARC- aligned-pass-rate threshold sustains a sustained-high baseline; (ii) per-shared-hosting-tenant per- domain VMC-procurement-workflow trademark-registry-pre-validation as load-bearing per-tenant per-domain prerequisite the shared-hosting-tenant publishes INDEPENDENTLY of the shared-hosting-provider's DNS-zone- management UI - the per-shared- hosting-tenant operator must coordinate per-domain per-jurisdiction trademark- registry registered logo presence BEFORE engaging DigiCert or Entrust for VMC issuance (CMC accepts in-use marks without registered trademark, accepted by Gmail since 2024 but still gated by Apple Mail on VMC only); (iii) per-shared-hosting-tenant per- domain SVG-Tiny-PS asset canonicalisation + per-VMC X.509 cert SHA-256 hash binding + per-asset HTTPS serving discipline as per-tenant per-domain cryptographic-evidence-of-logo- authenticity primitive the shared- hosting-tenant operator publishes on its own tenant-domain HTTPS infrastructure - the per- tenant-domain default._bimi.<tenant-domain> TXT-record's l= SVG asset URL and a= PEM cert URL must both serve over HTTPS with the published certificate-chain validating against the public-CA root AND the SVG bytes' SHA-256 must match the SubjectAltName-embedded hash in the VMC cert (a hash-binding contract Gmail and Apple Mail enforce per-message at the per-receiver evaluation moment); and (iv) per-shared-hosting- tenant per-domain VMC 1-year renewal calendar coordination as per-tenant per-domain logo-display-availability- continuity primitive parallel to per- domain DKIM key-rotation cadence the shared-hosting-tenant manages INDEPENDENTLY of the shared-hosting- provider's managed-DNS UI - VMCs issue with a 1-year validity, and the per-shared-hosting-tenant operator must coordinate per-domain VMC renewal at least 30 days before expiry to avoid receiver-side BIMI-display fallback to the generic-monogram default. Pair THIS shared-hosting DMARC deployment reference with the BIMI VMC certificates spoke when the per-shared-hosting-tenant operator advances the per-domain DMARC ramp to p=quarantine or p=reject and engages the BIMI logo-display-publication phase as the per-tenant per-domain cryptographic- anti-spoofing posture's end-user-visible reinforcement layer.
• DKIM failures explained — the SHARED-HOSTING-TENANT-PER-DOMAIN-DKIM- FAILURE-ROOT-CAUSE companion to this shared- hosting DMARC deployment reference. Where THIS page documents the per-shared-hosting- tenant per-domain DMARC publication discipline at the five canonical control- panels' zone-editor + Email Deliverability commit cadence (per-tenant SPF / DKIM / DMARC TXT-record publication primitives, the shared-outbound-relay egress IP-pool baseline, per-tenant Forwarders alias-loop surface, per-tenant p=none → p=quarantine → p=reject ramp coordination), the DKIM-failures-explained spoke is the RECEIVER-SIDE-DOWNSTREAM- CONSUMER whose per-message DKIM-verification verdict class is the load-bearing per-message authentication outcome the per-tenant per- domain DMARC ramp gates on. FOUR per-shared- hosting-tenant per-domain DKIM-failure root- cause dimensions: (i) per-shared-hosting-tenant per- domain control-panel-default selector-name publication (cPanel default._domainkey / Plesk default._domainkey / DirectAdmin x._domainkey / ISPConfig default._domainkey) producing cluster-wide single-selector posture and per-receiver dkim=permerror verdicts during per-tenant rotation — every shared- hosting tenant defaults to the per-control- panel canonical selector name via the control-panel Email Deliverability UI, producing a cluster-wide single-selector posture across the shared-hosting-provider's entire tenant base; per-tenant rotation past the default selector requires per-tenant operator intervention through the per- control-panel Manage Keys interface (often skipped by the per-tenant operator), and the per-tenant per-domain post-rotation propagation window routinely surfaces as per-receiver dkim=permerror verdicts the DKIM-failures spoke catalogues; (ii) per-shared-hosting-tenant per- domain shared-private-key-custody risk from co-tenant filesystem read of /var/cpanel/domain_keys/private/<d> (cPanel) or /etc/opendkim/keys/<d>/ (Plesk/ISPConfig) producing per-publisher revocation-via-empty-p= publication and per-receiver dkim=fail "revoked key" verdicts — the shared-physical-host kernel-level access boundary between co- tenants on the same physical host structurally elevates the per-tenant per-domain DKIM private-key compromise risk profile; per- tenant per-domain key-compromise incident response requires revocation via v=DKIM1; p=; empty-public-key publication producing per-receiver dkim=fail "revoked key" verdicts across the per-tenant per-domain message stream the DKIM-failures spoke catalogues at the per-shared-hosting-tenant per-domain operator-discipline boundary; (iii) per-shared-hosting-tenant per- domain RSA-1024-bit-default vs RSA-2048-bit- RFC-8301-recommended key-strength regression producing per-receiver dkim=neutral verdicts at receivers enforcing RFC 8301 key-strength minimum — older shared-hosting control-panel installations default-generate RSA-1024-bit DKIM keys, producing per- receiver dkim=neutral verdicts (RFC 6376 §6.3 unsupported-key-strength result-code) at Gmail / Outlook.com / Yahoo Mail receivers enforcing the per-publisher per-selector key-strength minimum, a defect class the DKIM-failures spoke catalogues whose per-tenant per-domain remediation requires regeneration via the per-control- panel Manage Keys interface to the 2048-bit floor; (iv) per-shared-hosting-tenant per- domain Forwarders feature alias-loop triggering downstream relay body modification producing per-receiver dkim=fail body-hash-mismatch verdicts at the second-hop receiver — per-shared-hosting-tenant Forwarders / email-forwarders feature configuration at the control-panel UI routinely produces alias- loop topologies where the per-tenant per- domain DKIM-signed message traverses a downstream forwarder that normalizes whitespace / appends Received headers / converts line endings, producing per-receiver dkim=fail body-hash-mismatch verdicts at the second-hop receiver the DKIM-failures spoke catalogues; per-tenant per-domain remediation requires the per- control-panel Exim/OpenDKIM signing config canonicalization-mode override to c=relaxed/relaxed. Read the DKIM-failures-explained spoke alongside this shared-hosting DMARC deployment reference when DIAGNOSING per- receiver per-day per-tenant per-domain dkim=permerror / dkim=fail / dkim=neutral RUA-attributed evidence rows correlating with a per-tenant per-domain control-panel Manage Keys commit or shared-pool co-tenant incident response, when PLANNING the per-tenant per-domain DKIM-selector rotation cadence with explicit per-receiver propagation-window-floor coordination, or when AUDITING the per- shared-hosting-tenant per-domain signing- MTA canonicalization-mode configuration whose body-hash-mismatch root cause the DKIM-failures spoke catalogues at the per- tenant per-domain signing-MTA-configuration- discipline boundary.
• DKIM key rotation — the SHARED-HOSTING-TENANT-PER-DOMAIN- DKIM-KEY-ROTATION-OPERATOR-DISCIPLINE companion to this shared-hosting DMARC deployment reference. Where THIS page documents the per-shared-hosting-tenant per-domain DMARC publication discipline at the five canonical control-panels' Email Deliverability + zone-editor commit cadence (per-tenant SPF / DKIM / DMARC TXT-record publication primitives, shared-outbound- relay egress IP-pool baseline, per-tenant Forwarders alias-loop surface, per-tenant `p=none → p=quarantine → p=reject` ramp coordination), the DKIM-key-rotation spoke is the per-publisher per-selector key- lifetime operator-discipline floor the per-tenant per-domain DKIM-signing leg STRUCTURALLY PRESUPPOSES is being operated on a bounded rotation cadence. FOUR per- shared-hosting-tenant per-domain DKIM-key- rotation coupling dimensions: (i) per-shared-hosting-tenant per- control-panel-default rotation-not-engaged single-selector posture as cluster-wide per-publisher per-selector indefinite-key- lifetime regression class — every shared-hosting tenant defaults to the per- control-panel single canonical selector (cPanel `default._domainkey` / Plesk `default._domainkey` / DirectAdmin `x._domainkey`) generated AT-account- provisioning time and never rotated by the control-panel without per-tenant operator intervention; the per-publisher per-selector indefinite-key-lifetime posture this default produces structurally violates the RFC 8301 90-180-day rotation cadence the DKIM-key- rotation spoke catalogues, elevating the per-tenant per-domain key-compromise window from the recommended floor to indefinite; (ii) per-shared-hosting-tenant per- domain dual-selector overlap-window rotation coordination at the per-control-panel Manage Keys + zone-editor commit boundary as per-receiver per-resolver-cache TTL- bounded propagation-window-floor consumer — the per-tenant operator performing a per-selector rotation through the per-control-panel Manage Keys UI MUST publish `selector2._domainkey.<d>` AND keep `selector1._domainkey.<d>` live across the per-receiver per-resolver cache-eviction window; the DKIM-key-rotation spoke documents the per-receiver propagation- window-floor coordination discipline whose regression produces per-receiver dkim=permerror verdicts on in- flight mail signed by the just-deactivated selector; (iii) per-shared-hosting-tenant per- domain RSA-1024-bit-default key-strength regression remediation through rotation as per-receiver RFC 8301 key-strength minimum enforcement consumer — older shared-hosting control-panel installations default-generate RSA-1024-bit DKIM keys (smaller-than-RFC-8301-recommended 2048-bit floor); per-tenant per-domain remediation from the RSA-1024 to RSA-2048 floor REQUIRES a per-selector key-rotation event the per- control-panel Manage Keys interface mediates, which the DKIM-key-rotation spoke catalogues as the per-publisher per-selector key-strength remediation discipline whose Gmail / Outlook.com / Yahoo Mail receiver- side enforcement is the load-bearing empirical-observability primitive; (iv) per-shared-hosting-tenant shared-physical-host kernel-level access boundary co-tenant key-compromise incident response REQUIRING per-tenant per-selector revocation-via-empty-`p=` publication + emergency rotation as canonical rotation- cadence-acceleration discipline — when a co-tenant on the shared-physical- host suffers per-tenant DKIM private-key compromise (filesystem read of `/var/cpanel/domain_keys/private/<d>` from a colocated tenant), per-publisher per- domain incident response REQUIRES per- selector revocation via `v=DKIM1; p=;` empty-public-key publication PLUS emergency rotation to a new per-selector key the per- control-panel Manage Keys UI mediates; the DKIM-key-rotation spoke documents the emergency rotation-cadence-acceleration discipline whose per-shared-hosting-tenant per-domain incident-response runbook the per-tenant operator MUST author at the per-control-panel operator-boundary. Read the DKIM-key-rotation spoke alongside this shared-hosting DMARC deployment reference when PLANNING the per-tenant per- domain DKIM-selector rotation cadence with explicit per-receiver propagation-window- floor coordination, when AUDITING the per- shared-hosting-tenant per-domain `default._domainkey` indefinite-key-lifetime posture for RFC 8301 90-180-day rotation cadence compliance, or when AUTHORING the per-tenant per-domain DKIM-private-key compromise incident-response runbook the per-shared-hosting-tenant operator- discipline-floor the per-control-panel Manage Keys interface mediates.
• How attackers bypass weak DMARC — the WEAK-DMARC-ATTACK-SURFACE-CATALOGUE companion to this shared-hosting per- tenant DMARC deployment reference. Where THIS page documents the per-tenant per- domain DMARC publication discipline on cPanel / Plesk / DirectAdmin / WHM panels, the host-default DKIM key multi-tenant exposure landscape, the per-tenant SPF include: chain hygiene against the per-host shared ESP-cascade, and the per-tenant per-domain control-panel Manage Keys interface mediated DKIM-key-rotation workflow, the DMARC-attacker-bypass spoke catalogues the eleven attack-class taxonomy of how attackers bypass weak DMARC postures that structurally apply to shared-hosting tenants with elevated risk — the sp= subdomain-policy-gap attack-class lands hardest on multi-tenant shared-hosting deployments where untracked subdomain inventory accumulates across the per-tenant lifecycle (per-tenant per-domain auto- generated subdomains, expired-but-still- DNS-resolving subdomains); the host-default DKIM-key cryptanalysis attack-variant exposes shared-hosting tenants whose per- host shared DKIM private key is multi- tenant-shared and never rotated; the SPF +all / ~all permissive-qualifier attack-class lands hardest on shared-hosting tenants whose per-tenant SPF record includes the per- host shared ESP cascade with attacker-IP- inclusive ranges. The shared-hosting deployment THIS page documents has an elevated attacker-bypass attack-surface at four shared-hosting-DMARC-deployment-vs- DMARC-attacker-bypass-surface coupling dimensions: (i) per-tenant sp=reject explicit publication as multi-tenant subdomain-inventory-attack- surface closure — the per-tenant sp=reject publication closes the subdomain-policy- gap attack-class that lands hardest on multi-tenant shared-hosting deployments where untracked subdomain inventory accumulates; (ii) per-tenant per-domain DKIM-key isolation discipline as host- default-key-cryptanalysis attack-variant closure — the per-tenant per-domain control-panel Manage Keys interface mediated DKIM-key generation discipline closes the host-default DKIM-key cryptanalysis attack-variant where the per- host shared DKIM private key is multi- tenant-shared and never rotated; (iii) per- tenant per-domain SPF include: chain audit as +all/~all permissive- qualifier-abuse attack-variant closure — the per-tenant per-domain SPF record-audit discipline closes the SPF permissive- qualifier attack-class that lands hardest on shared-hosting tenants whose per-tenant SPF record includes the per-host shared ESP cascade with attacker-IP-inclusive ranges; and (iv) per-tenant per-domain DMARC policy-mode ramp cadence as shared- hosting-tenant operator-side discipline- floor — the per-tenant per-domain p=none → p=quarantine pct=N → p=reject ramp cadence is the operator-side bypass-catalogue closure discipline-floor every shared-hosting tenant MUST execute to defend against the eleven attack-class catalogue the attacker- bypass spoke documents. Read THIS page when AUTHORING the per-tenant per-domain shared-hosting DMARC publication workflow on cPanel / Plesk / DirectAdmin / WHM; read the DMARC-attacker-bypass catalogue spoke when AUDITING the per-tenant per- domain shared-hosting DMARC posture against the eleven attack-class catalogue the per-tenant per-domain shared-hosting deployment THIS page documents structurally defends against at the per-receiver per- message DMARC evaluation boundary.
• Phishing protection — the PER-SHARED-HOSTING-TENANT-PER-CUSTOM- DOMAIN-DMARC-DEPLOYMENT-AS-PER-TENANT-PHISHING- ATTACK-SURFACE-COMPRESSION-DISCIPLINE companion to THIS per-shared-hosting-tenant per-custom-domain DMARC deployment workflow reference. Where THIS page documents the per-shared-hosting-tenant per-custom-domain DMARC deployment workflow (the per-tenant shared-IP-pool egress reputation isolation discipline, the per-tenant per-custom-domain SPF include:-mechanism alignment to the per-hosting-provider central SPF record, the per-tenant per-custom-domain DKIM default._domainkey selector publication via cPanel / Plesk / DirectAdmin / WHM tooling, the per-tenant per-custom- domain DMARC _dmarc.<custom- domain> record-publication discipline, and the per-tenant per-custom- domain RUA-mailbox observability-pipeline cadence), the phishing-protection spoke documents the per-receiver per-message anti-phishing defence-stack at FOUR per- tenant per-custom-domain DMARC-deployment-vs- phishing-attack-surface coupling dimensions: (i) per-tenant per-custom-domain DMARC p=-policy publication AS load-bearing per-receiver per-message anti- spoofing receiver-side enforcement primitive — the per-receiver per- message anti-phishing evaluator consumes the per-tenant per-custom-domain DMARC p=quarantine / p=reject verdict as the per- publisher per-domain anti-spoofing enforcement primitive that quarantines or rejects per-attacker spoofed mail claiming the per-tenant per-custom-domain From-domain identity at the per-receiver per-message disposition-decision boundary; the per-tenant per-custom-domain DMARC-policy publication discipline THIS page documents directly compresses the per-tenant per-custom-domain spoofing-attack-surface the phishing- protection spoke catalogues; (ii) per-shared-hosting-tenant per-shared- IP-pool egress-reputation isolation AS per- tenant per-custom-domain phishing-attack- surface-elevation-vector compression — per-shared-hosting-tenant deployments share per-shared-IP-pool egress infrastructure across multiple per-hosting-provider tenants, and a single per-tenant per-shared-IP-pool compromised or spam-sending tenant elevates the per-receiver per-message anti-phishing evaluator's per-shared-IP-pool sender- reputation-degradation signal that decays every per-tenant per-custom-domain mail-flow sharing the same per-shared-IP-pool egress infrastructure; the per-tenant per-shared- IP-pool egress-reputation isolation discipline THIS page documents (per-tenant per-shared-IP-pool dedicated-IP migration path, per-tenant per-shared-IP-pool sender- reputation segregation via per-tenant DKIM-d=-tag identity attribution) directly compresses the per-tenant per-custom-domain phishing-attack-surface-elevation vector the phishing-protection spoke catalogues at the per-shared-IP-pool reputation-poisoning attack-class boundary; (iii) per- tenant per-custom-domain DMARC RUA-mailbox observability-pipeline AS per-tenant per- custom-domain phishing-attack-discovery evidence-stream — the per-tenant per-custom-domain DMARC RUA aggregate-XML per-source-IP per-disposition row stream THIS page documents the publication discipline for is the per-tenant per-custom- domain primary evidence stream the per- tenant operator consults to DISCOVER per- attacker phishing campaigns targeting the per-tenant per-custom-domain From-domain identity (per-attacker per-source-IP per- disposition row attribution surfaces sustained per-attacker spoofing campaigns within the per-tenant per-receiver per-day RUA report cadence); the phishing-protection spoke documents the per-attacker per- campaign threat-model the per-tenant per- custom-domain operator decodes the per- receiver per-day per-source-IP RUA evidence stream against; (iv) per-tenant per-custom-domain SPF + DKIM + DMARC composite-authentication publication AS per-tenant per-custom-domain anti-spoofing- and-anti-phishing baseline floor — the per-receiver per-message anti-phishing evaluator's per-publisher per-domain sender- authenticity composite-verdict consumes the per-tenant per-custom-domain SPF + DKIM + DMARC composite-publication discipline THIS page documents (per-tenant per-custom-domain SPF include:-mechanism alignment + per-tenant per-custom-domain DKIM default._domainkey selector publication + per-tenant per-custom-domain DMARC _dmarc.<custom-domain> record-publication) as the per-tenant per- custom-domain anti-phishing-baseline floor; the phishing-protection spoke documents the per-receiver per-message anti-phishing defence-stack the per-tenant per-custom- domain composite-publication discipline THIS page documents feeds at the per-receiver per-message sender-authenticity-evaluation boundary. Read THIS page when DEPLOYING per- tenant per-custom-domain DMARC on shared- hosting (cPanel / Plesk / DirectAdmin / WHM); read the phishing-protection spoke when UNDERSTANDING how the per-tenant per-custom- domain DMARC deployment THIS page documents IS the load-bearing per-tenant per-custom- domain anti-phishing-attack-surface compression discipline the per-receiver per- message anti-phishing defence-stack consumes at the per-tenant per-custom-domain sender- authenticity-evaluation boundary.
• SPF forwarding issues
• DKIM-Signature header explained
• TLS-RPT record syntax
• DMARC reporting pipeline — the PER-CPANEL-PER-SHARED-HOSTING- PER-CUSTOM-DOMAIN-MULTI-TENANT-DMARC-RUA- AGGREGATE-REPORT-URI-PUBLICATION-CASCADE- AS-LOAD-BEARING-PER-TENANT-PER-CUSTOM- DOMAIN-RECEIVER-EMITTED-EVIDENCE-STREAM- COORDINATION-AT-SHARED-IP-POOL-EGRESS companion at four shared-hosting-DMARC- deployment-vs-DMARC-RUA-aggregate-report- pipeline coupling dimensions: (1) per- cPanel-tenant per-custom-domain DMARC TXT-RR publication at _dmarc.<custom-domain> carries the per-tenant per-custom-domain rua=mailto: aggregate-report- URI per RFC 7489 §6.2 — across an N-tenant shared-hosting deployment the per-cPanel-tenant per- custom-domain RUA URI choice determines whether per-tenant evidence-streams aggregate at the tenant’s own mailbox, at the hosting-provider’s operator mailbox, or split via per-tenant dual-URI publication; (2) per-cPanel-tenant per- custom-domain shared-IP-pool egress surfaces per-source-IP attribution per RFC 7489 §7.2.1.1 in per-receiver per-day DMARC RUA per-row <row><source_ip> attribution — distinguishing per- tenant verdict cleanly from per-shared-IP- pool cross-tenant verdict-noise requires per-tenant per-custom-domain DKIM-aligned- pass attribution as the per-tenant identity-attribution leg the per-cPanel- per-shared-hosting page documents per- tenant per-custom-domain DKIM publication discipline for; (3) per-cPanel-tenant per- custom-domain DMARC enforcement-mode ramp p=none → p=quarantine → p=reject progression decision per-tenant depends on per-tenant per-custom-domain DMARC RUA aggregate-report-pipeline visibility into per-tenant per-custom-domain composite- aligned-pass-rate floor — without per-tenant rua=mailto: publication the per-tenant per-custom- domain operator has no per-day per- receiver per-source-IP per-row evidence stream against which to ramp; (4) per- cPanel-tenant per-custom-domain DMARC RUA aggregate-report-pipeline per-receiver per-day per-source-IP per-row attribution stream IS the per-tenant per-custom- domain operator-actionable evidence- channel surfacing per-tenant per-custom- domain shared-MX-cluster egress-pollution verdicts (cross-tenant SPF-fail from another tenant’s misconfigured SPF, third-party-mailer per-tenant impersonation attempt) underpinning per- tenant per-custom-domain enforcement-mode- ramp-readiness decision THIS DMARC-for- shared-hosting page documents the per- tenant per-custom-domain SPF + DKIM + DMARC publication discipline of.
• DKIM best practices
• Email deliverability — the inbox-placement companion to this DMARC-for-shared-hosting guide. The defining deliverability challenge of shared hosting is the shared-IP-pool reputation problem: a per-tenant per-custom-domain sender inherits the aggregate sending reputation of every other tenant on the same shared-Exim-MTA egress IP, so one tenant's spam run can depress inbox placement for the whole pool. The five-step DMARC ramp this page documents (clean SPF/DKIM alignment, then p=quarantine → p=reject) is precisely what lets a mailbox provider attribute reputation to the per-tenant domain rather than the shared IP. Read the deliverability spoke to see how domain-level authentication rescues inbox placement from shared-IP-pool reputation drag.
• Email security glossary — the plain-language reference for the authentication vocabulary this shared-hosting deployment guide uses: SPF, DKIM, DMARC alignment, p=quarantine/p=reject, RUA aggregate reports, and shared-IP reputation terms. Read the glossary when a term in the five-step enforcement ramp is unfamiliar before you act on it.
• TLS-RPT explained — shared-hosting MX endpoints frequently run older or misconfigured STARTTLS, and on a control panel you rarely see those transport failures directly. SMTP TLS Reporting (RFC 8460) publishes a _smtp._tls.<domain> TXT record that asks receivers to email you a daily JSON report of every TLS-handshake failure to your domain — the visibility that lets a shared-hosting tenant catch a downgraded or broken transport hop the same way DMARC RUA reports surface authentication failures. Read the TLS-RPT primer to extend your reporting beyond the message layer.
• DKIM replay attacks — on shared hosting many tenants are often signed with the same control-panel DKIM selector and key, which widens the blast radius of a replay: an attacker who captures one validly-signed message can re-mail it in bulk and it still passes DKIM under your domain. The five-step enforcement ramp this guide walks gets you to p=quarantine/p=reject, but a replay rides a genuine DKIM pass straight through that policy. Hardening a shared-hosting deployment past the ramp means rotating the signing selector, setting a DKIM x= expiry, and leaning on the SPF leg to fail the replayed copy's foreign IP. Read the replay-attacks spoke for the post-enforcement hardening step a shared-host tenant should not skip.
• DANE explained (the transport-layer companion to message-layer DMARC) — the five-step ramp this guide walks gets a shared-hosting tenant to an enforced message-layer DMARC policy; DANE (RFC 7672 + RFC 6698) secures the transport layer that carries those authenticated messages, publishing a DNSSEC-signed TLSA record that pins the receiving MX's TLS certificate so STARTTLS cannot be stripped or spoofed. Many shared hosts cannot offer DANE without a DNSSEC-signed zone, which makes it the natural pairing topic when a tenant weighs MTA-STS instead. Read it to see where transport-layer authentication fits alongside the enforcement posture this page builds.
• RFC 7489 - DMARC
• RFC 7208 - SPF
• RFC 6376 - DKIM
• RFC 8058 - One-Click List-Unsubscribe - required by the Feb 2024 bulk-sender rules.
• Microsoft SNDS + JMRP monitoring — on shared or panel-managed infrastructure you inherit your neighbours' IP reputation: SNDS shows the GREEN/YELLOW/RED verdict Outlook.com assigned to the shared outbound IP and JMRP shows the complaints driving it.

Deploy DMARC for your shared-hosting domain now

DMARC Analyzer parses the daily aggregate reports receivers send to your rua= mailbox, deduplicates by report_id + org_name, and surfaces the per-sender / per-IP / per-day breakdown needed to drive the alignment fix-up phase. Live DNS verification for every SPF / DKIM / DMARC record on your domain runs through includes/DnsChecker.php; the Email Header Analyzer at header_analyzer.php diagnoses individual message failures by parsing the full Authentication-Results stack via includes/EmailHeaderParser.php; the Blacklist Checker diagnoses shared-IP reputation issues common on shared-hosting infrastructure.

Sign up — Free plan Check my shared-hosting domain