DMARC Analyzer

TL;DR

• cPanel auto-generates SPF and DKIM during account creation. Open the Email Deliverability page in cPanel (under the Email section), verify both records, and click Install Suggested Record if either shows a warning status.
• cPanel does NOT auto-generate DMARC. You must publish it manually as a TXT record at _dmarc.<your-domain> via the cPanel Zone Editor (or your registrar's DNS panel if DNS is hosted elsewhere). Start at p=none.
• Default DKIM selector: cPanel uses default._domainkey by convention - distinct from Google Workspace (google._domainkey) and Microsoft 365 (selector1 + selector2 CNAMEs). Key rotation is MANUAL on cPanel; plan one every 6-12 months.
• SPF include is provider-specific. Bluehost, HostGator, SiteGround, A2 Hosting, GoDaddy cPanel, Namecheap each publish their own outbound mail infrastructure under a different include directive. Use cPanel's Install Suggested Record button to apply the correct one for your host.
• Shared-IP reputation is the deliverability ceiling. cPanel shared hosting puts your outbound mail on an IP shared with potentially hundreds of other tenants. A sibling tenant's spam can poison the shared IP's reputation and send YOUR legitimate mail to spam at Gmail / Outlook - DMARC does not compensate. For commercial-scale or bulk-sending workloads, move to a dedicated outbound IP or a transactional relay.
• Google's Feb 2024 bulk-sender requirements apply to cPanel 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: 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.
• WHM administrators have additional levers: server-wide DKIM key regeneration via Exim Configuration Manager, outbound mail queue management, per-account email quotas, and outbound spam protection. End-user cPanel operators are limited to the Email Deliverability page; ask the hosting provider for WHM-level intervention when needed.

1. What this guide covers

This is the operator-implementation walkthrough for deploying SPF, DKIM, and DMARC on a domain whose mail is sent by cPanel - the dominant control panel for SMB and shared-hosting environments (Bluehost, HostGator, SiteGround, A2 Hosting, GoDaddy cPanel, Namecheap Stellar, Hostinger cPanel, InMotion, DreamHost cPanel, and many others).

The guide is structured around two operator personas because cPanel's UI is intentionally split:

• End-user cPanel operator - accesses the per-account cPanel UI at cpanel.<your-domain> or via the hosting provider's portal. Limited to the Email Deliverability page for SPF/DKIM validation; can publish DMARC via the Zone Editor (if DNS is hosted at the cPanel server) or the registrar's DNS panel (if DNS is external). Cannot rotate DKIM selectors or change Exim configuration.
• WHM administrator (Web Host Manager) - accesses the server-wide control panel at whm.<hosting-server>. Full access to Exim Configuration Manager, per-account DKIM regeneration, outbound mail queue diagnostics, and server-wide outbound IP configuration. Most shared-hosting customers do NOT have WHM access - it is reserved for VPS / dedicated-server customers and the hosting provider's own staff.

Sections 4-8 (the five deployment steps) apply to both personas. Section 9 (gotchas) and section 11 (troubleshooting) tag persona-specific items explicitly with "[end-user cPanel]" or "[WHM administrator]" so each operator can find their relevant guidance.

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 cPanel-specific UI paths, syntax, and gotchas.

What this guide does not cover:

• Plesk, DirectAdmin, and Webmin - other shared-hosting control panels. Each has its own DKIM signing implementation (Plesk integrates with Postfix and uses a "DomainKeys" UI; DirectAdmin uses Exim like cPanel but with a different management UI). The general DMARC rollout is the same; UI paths differ.
• Reseller hosting configuration - reseller-tier cPanel access (a subset of WHM) 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 cPanel server (SpamAssassin / Apache SpamAssassin, Boxtrapper) - separate from DMARC and out of scope for this guide.

2. Why DMARC matters now: Feb 2024 requirements + shared-IP reputation

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 mailbox provider or hosting control panel sends the mail. cPanel-hosted senders that exceed the threshold are subject to the same enforcement as 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 shared-IP reputation problem

cPanel shared hosting has a structural deliverability ceiling that DMARC does NOT address: outbound mail leaves the server from an IP shared with potentially hundreds of other tenants. The shared IP's reputation at Gmail, Outlook, Yahoo, and the major blocklists is determined by the worst- behaving tenant on the shared server. If a sibling account at the same host sends spam, the IP gets flagged, and YOUR legitimate mail goes to spam regardless of whether your SPF, DKIM, and DMARC all pass.

Operational implications:

• Low-volume transactional and personal mail (under ~1000 messages/day) tolerates shared-IP reputation well. Most cPanel-hosted small business sites fall here. Deploy DMARC for spoofing protection; shared-IP reputation rarely matters at this volume.
• Marketing or commercial-scale sending (above ~1000 messages/day, definitely above 5000) should NOT run through shared cPanel hosting. Move to:
  • A dedicated outbound IP (most hosts offer this as a paid upgrade - check with your provider).
  • A transactional relay (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost) with a dedicated IP or pool.
  • A marketing platform (Mailchimp, Klaviyo, Customer.io) for marketing campaigns.
  Each of these provides per-tenant reputation isolation that shared cPanel does not.

DMARC at p=quarantine or p=reject stops domain spoofing but does NOT improve a poor outbound IP reputation. 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

• cPanel access for the account you are deploying. Most hosting providers expose cPanel at cpanel.<your-domain> or via the hosting portal's "Manage cPanel" button. You need the per-account login.
• WHM access if your DKIM keys need server-side regeneration (e.g. switching from 1024-bit to 2048-bit, or rotating selectors). Reseller / VPS / dedicated-server customers usually have WHM; pure shared-hosting customers usually do not. If you do not have WHM and need a change at that layer, file a support ticket with your hosting provider.
• DNS edit access for the primary domain. cPanel hosts may manage DNS at the cPanel server (Zone Editor), at the hosting provider's portal, or at an external registrar. Identify where your DNS lives BEFORE attempting to publish records - the cPanel UI may appear to publish a DMARC record but actually only write to the cPanel-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. cPanel itself 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 cPanel mail.

4. Step 1: Verify SPF on the Email Deliverability page

cPanel auto-generates an SPF record during account creation. Your job is to verify the record exists and matches what cPanel suggests.

1. Sign in to cPanel. Navigate to Email > Email Deliverability.
2. The page lists every domain on the account with three columns: SPF, DKIM, and Reverse DNS. Each shows a status indicator (Valid, Problem, or Not Configured).
3. If SPF shows Problem or Not Configured, click Manage for the affected domain. The detail page shows the suggested SPF record and a button: Install Suggested Record.
4. Click Install Suggested Record. cPanel publishes the record - either to the cPanel-managed zone file (if DNS lives here) or to a downloadable text snippet you must publish manually at your external DNS provider.

Typical cPanel-generated SPF record:

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

Where <provider-spf-host> is the hosting provider's outbound mail server identity. Common values:

• Bluehost: include:bluehost.com
• HostGator: include:websitewelcome.com
• SiteGround: include:_spf.siteground.net
• A2 Hosting: include:a2hosting.com
• GoDaddy cPanel: include:secureserver.net
• Namecheap Stellar: include:spf.web-hosting.com
• Hostinger cPanel: include:_spf.hostinger.com
• InMotion: include:inmotionhosting.com

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, etc.), 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, cPanel's default) 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 DKIM at the default._domainkey selector

cPanel auto-generates a DKIM key during account creation and publishes the public key at default._domainkey.<your-domain> as a TXT record (NOT a CNAME - distinct from Microsoft 365). The Exim mail server on the cPanel host signs outbound mail with the corresponding private key.

Verify on the Email Deliverability page:

1. From cPanel, open Email > Email Deliverability.
2. Confirm the DKIM column shows Valid for the domain. If Problem or Not Configured, click Manage > Install Suggested Record - cPanel will fetch the public key from Exim's local DKIM configuration and publish it.
3. Verify externally with dig +short txt default._domainkey.your-domain.com. Expected output: a v=DKIM1; k=rsa; p=<long-base64-public-key> TXT record.

Typical cPanel DKIM record:

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

Key length: cPanel historically generated 1024-bit keys; modern cPanel installations (since cPanel & WHM version 90+) generate 2048-bit keys by default. RFC 8301 deprecates 1024-bit RSA DKIM keys - if your account was created years ago, regenerate the key:

• [end-user cPanel]: open Email > Email Deliverability > Manage, look for Regenerate DKIM Key or Update DKIM. If the option is not exposed at your hosting provider, contact support.
• [WHM administrator]: WHM > Email > Email Authentication exposes per-account key regeneration; or via the command line:

  # Run as root on the cPanel server
  /usr/local/cpanel/bin/dkim_keys_install <cpanel-user>
  # Or regenerate via the cPanel API:
  uapi --user=<cpanel-user> EmailAuth install_dkim_records domain=your-domain.com

Key rotation: cPanel does NOT rotate selectors automatically. Plan a manual rotation every 6-12 months by generating a new key with a new selector (e.g. default20260519._domainkey), publishing both selectors during the transition window, switching the Exim signing configuration to the new selector, then retiring the old.

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=default.

6. Step 3: Publish DMARC at p=none (cPanel does NOT auto-generate)

DMARC is the one record cPanel does NOT auto-generate - the rua= mailbox is operator-specific and cPanel cannot guess where reports should go. Publish the record manually via the cPanel Zone Editor:

1. From cPanel, open Domains > Zone Editor.
2. Find the row for your domain and click Manage.
3. Click + Add Record and select Add "TXT" Record.
4. Fill in:
   • Name: _dmarc.your-domain.com (cPanel may append your domain automatically - check the final FQDN).
   • TTL: 14400 (default; lower if you plan to iterate rapidly).
   • Type: TXT.
   • Record: v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com; fo=1
5. Click Add Record.

If DNS is hosted at your registrar instead of at the cPanel server, publish the same record at the registrar's DNS panel (the Zone Editor in cPanel will appear to publish but the record will not be reachable from public resolvers).

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? cPanel itself (via the host's shared outbound IP range) 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 cPanel-specific patterns dominate the alignment-failure surface:
  • The shared-bounce-domain pattern - some shared hosts rewrite the envelope MAIL FROM to a provider- controlled domain (e.g. bounces.bluehost.com), so SPF passes for the provider but does not align with your visible From:. DKIM alignment (via the cPanel-issued default._domainkey signature) still works correctly because DKIM is independent of envelope rewriting.
  • The WordPress / plugin pattern - many WordPress contact-form, ecommerce, and transactional-email plugins send mail via PHP's mail() function or an SMTP plugin without involving cPanel's Email Authentication settings. The mail leaves cPanel's outbound pipe but may bypass the DKIM signing path depending on plugin configuration.
  • 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 the cPanel Zone Editor (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. cPanel and shared-hosting gotchas

• [shared hosting] Shared outbound IP reputation. Covered in section 2. The single biggest commercial-reality issue with cPanel hosting that DMARC does NOT solve. Move bulk and marketing-scale sending to a dedicated IP or a transactional relay.
• [end-user cPanel] DNS hosted at the registrar, not cPanel. The cPanel Zone Editor 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 cPanel host's nameservers, publish DNS records at the registrar / external DNS provider.
• [end-user cPanel] WordPress plugins bypassing Email Deliverability. 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 cPanel's Exim DKIM signing entirely. Either configure the SMTP plugin to use the cPanel 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.
• [WHM administrator] Exim global configuration vs per-account DKIM. WHM > Exim Configuration Manager controls global signing behaviour - per-account DKIM keys are managed separately via Email Authentication. Both layers must cooperate: a per-account DKIM key with signing disabled at the global level produces no signatures.
• [WHM administrator] Outbound IP rotation and feedback loops. High-volume shared servers sometimes rotate outbound IPs to distribute spam complaint load. Per-tenant DMARC reports will show MULTIPLE source IPs across the host's outbound pool. Register the outbound pool with major-receiver feedback loops (Microsoft SNDS, Google Postmaster Tools - which works for any sender not just Workspace, Yahoo Complaint Feedback Loop) for inbound spam-complaint telemetry.
• [end-user cPanel] cPanel Webmail vs external IMAP/SMTP. End users sending via cPanel Webmail (Roundcube / Horde) or via the cPanel SMTP endpoint get the full Exim DKIM treatment automatically. Users sending from a phone or desktop client configured against a NON-cPanel SMTP relay (rare but possible) will bypass the DKIM signing path.

10. Common cPanel + DMARC mistakes

1. Assuming cPanel auto-generated DMARC. cPanel auto-generates SPF and DKIM but NOT DMARC. The Email Deliverability page does not surface DMARC at all - operators must publish the _dmarc TXT record manually.
2. Publishing DMARC at the cPanel Zone Editor when DNS is hosted elsewhere. The Zone Editor 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.
3. Forgetting to advance past p=none. The reporting-only phase does NOT stop spoofing. Advance to enforcement after 2-6 weeks of clean reports.
4. Running a 1024-bit DKIM key on a legacy cPanel install. RFC 8301 deprecated 1024-bit RSA DKIM. Modern cPanel installs use 2048-bit by default; legacy installs need regeneration via Email Deliverability > Manage or via WHM.
5. 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 cPanel-generated record - do not publish a second TXT.
6. SPF over 10 DNS lookups. The cPanel-host include plus several third-party include: directives commonly blow the limit. Use Domain Security Checker to count lookups.
7. Skipping the WordPress plugin audit. WordPress installations typically send mail through paths that bypass cPanel's Exim signing. Configure WP Mail SMTP / equivalent to route via the cPanel SMTP endpoint OR to sign DKIM under your domain via the third-party SMTP's authentication settings.
8. Treating shared-IP reputation as a DMARC problem. DMARC does not improve poor outbound IP reputation. If your mail is consistently going to spam at Gmail despite SPF/DKIM/DMARC all passing, the diagnosis is reputation, not authentication. Migrate the workload off shared hosting.
9. 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.
10. Treating DMARC as one-time work. New WordPress plugins, SaaS integrations, and acquired domains constantly surface new senders. Indefinite monitoring is the ongoing cost of DMARC enforcement.

11. Troubleshooting

• "Email Deliverability page shows SPF/DKIM as Problem despite Install Suggested Record being clicked". Two causes: (1) DNS is hosted at your registrar, not at the cPanel server - the suggested record was published to the local zone file but the public DNS sees nothing. Republish at the registrar. (2) The DNS change has not propagated yet - wait 24 hours and retry. Verify externally with dig +short txt your-domain.com and dig +short txt default._domainkey.your-domain.com.
• "My cPanel mail goes to spam at Gmail despite all three records passing". Diagnose shared-IP reputation: dig +short a mail.<your-cpanel-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, file a ticket with the hosting provider and request a clean outbound IP.
• "DMARC reports show DKIM header.d=<hosting-provider>.com, not my custom domain". The mail is being signed under the hosting provider's domain (typical when envelope rewriting is enabled server-wide), not under default._domainkey.your-domain.com. Either confirm Exim is configured to sign with the per-account DKIM key ([WHM administrator] - check Exim Configuration Manager) or accept that DMARC alignment will rely on provider-domain SPF rather than per-domain DKIM.
• "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 Exim's outbound mail queue?" [WHM administrator] WHM > Email > Mail Queue Manager shows the live Exim queue with delivery status per message. 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 don't have WHM access and need a DKIM key rotation". File a support ticket with the hosting provider. Most providers will rotate the key on request; many will not proactively rotate without operator intervention. A workaround: publish a new DKIM key with a new selector at the SaaS-relay layer (CNAME-delegated) and route outbound mail through the relay until cPanel-side rotation is scheduled.

12. Frequently asked questions

How do I set up DMARC on cPanel?

Five steps. Open Email > Email Deliverability, click Install Suggested Record if SPF or DKIM is missing or invalid. Verify SPF at the apex and DKIM at default._domainkey. Manually publish DMARC at _dmarc via Zone Editor (cPanel does NOT auto-generate DMARC). Ingest reports for 2-6 weeks, align every legitimate sender, advance through p=quarantine to p=reject.

What SPF include does cPanel use?

Provider-specific. Bluehost: bluehost.com, HostGator: websitewelcome.com, SiteGround: _spf.siteground.net, A2 Hosting: a2hosting.com, GoDaddy: secureserver.net, Namecheap: spf.web-hosting.com, Hostinger: _spf.hostinger.com. The cPanel Install Suggested Record button fetches the correct include from the WHM server's mail configuration.

What DKIM selector does cPanel use?

default. The TXT record lives at default._domainkey.<your-domain>. Distinct from Workspace (google._domainkey) and M365 (selector1/selector2 CNAMEs). Key rotation is manual on cPanel; plan one every 6-12 months.

Why does cPanel not auto-generate DMARC like it auto-generates SPF and DKIM?

The rua= mailbox destination is operator-specific. cPanel cannot pick a sensible default without risking that reports go to a non- existent or third-party address. Publish manually via Zone Editor with v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com; fo=1.

How do shared IPs affect DMARC and deliverability on cPanel hosting?

Shared cPanel hosting puts your outbound mail on an IP shared with other tenants. The shared IP's reputation is set by the worst-behaving sibling. DMARC at enforcement stops spoofing but does NOT compensate for poor IP reputation. For bulk or commercial-scale sending, move to a dedicated outbound IP or a transactional relay (SendGrid, Mailgun, Amazon SES, Postmark).

Why is my DMARC failing despite cPanel showing SPF and DKIM as passing?

Alignment failure. Either the provider-bounce-domain pattern (SPF passes on the host but does not align), the WordPress-plugin pattern (mail bypasses cPanel's Exim signing path), or the SaaS-sender pattern (third-party platform uses its own bounce domain). See help_dmarc_alignment.php for the deep dive.

Do I need DMARC if I only send transactional email through cPanel?

Yes. cPanel's SPF / DKIM on your legitimate outbound mail does NOT stop attackers from spoofing your domain at other receivers. DMARC at enforcement is what closes that gap. Deployment cost is one DNS record; benefit is unbounded.

Where do I see DMARC reports for cPanel 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. cPanel's Email Deliverability page does not parse DMARC reports - it only validates the current DNS records exist.

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 10-DNS-lookup limit (RFC 7208 §4.6.4) - the CPANEL-TENANT-INHERITED-INCLUDE- CASCADE-BUDGET-MANAGEMENT companion to this cPanel DMARC deployment reference. Where THIS page documents the cPanel-specific deployment workflow (WHM Email Deliverability auto-generation, the cPanel-server shared- outbound MTA IP block, the per-tenant zone- editor manual-edit path), the SPF-lookup- limit spoke is the BUDGET-ACCOUNTING REFERENCE documenting the per-mechanism cost cPanel tenants MUST track to avoid the RFC 7208 §4.6.4 `permerror` receiver-side rejection. The CPANEL-TENANT-INHERITED- CASCADE-BUDGET cross-reference establishes FOUR structurally-distinct cPanel-budget- consumption dimensions: (i) cPanel server's include:<cpanel- server>.com inherited cascade cost — the WHM-auto-generated SPF record's include:websitewelcome.com (HostGator) or include:hostmonster.com (Hostmonster) or per-CPanel-server-vendor sub-include consumes 2–5 DNS lookups before the tenant adds ANYTHING; the SPF-lookup- limit spoke documents the per-include recursive-expansion accounting algorithm receivers apply at evaluation time and the per-vendor inherited-cascade cost matrix cPanel tenants must measure BEFORE adding third-party ESP includes; (ii) cPanel tenant third-party ESP include accumulation cost — every additional include:<esp>.com the tenant adds via the WHM DNS Zone Editor consumes its own sub-include cascade cost (SendGrid include:sendgrid.net ~2-3 lookups, Mailgun include:mailgun.org ~2 lookups, Amazon SES include:amazonses.com ~3 lookups, Mailchimp include:servers.mcsv.net ~2 lookups, Constant Contact include:spf.constantcontact.com ~2 lookups); the SPF-lookup-limit spoke documents the per-ESP-vendor measured-cost table cPanel tenants use to budget the remaining capacity in the 10-lookup ceiling BEFORE saturation drops the entire record into `permerror` and breaks receiver-side SPF evaluation for ALL outbound traffic; (iii) cPanel-tenant a and mx mechanism cost when cPanel server's apex domain hosts non-trivial A/MX RRset — the WHM-auto-generated record's +a +mx tokens trigger per-evaluation A-record + MX-record sub- resolution that on multi-MX-host or multi- IP-A-record cPanel server topologies can consume up to 10 sub-lookups per mechanism AGAINST the 10-budget; the SPF-lookup-limit spoke documents the per-mechanism sub- resolution cost matrix AND the canonical ip4: literal-block migration pattern cPanel tenants apply when the a / mx sub-lookup cost is excessive; (iv) cPanel- tenant void-lookup risk on stale-include operator-tracking — RFC 7208 §4.6.4 also imposes a void-lookup cap of 2 (TXT lookups that return NXDOMAIN or no records); cPanel tenants that retain include: tokens for legacy ESPs whose authorization- SPF sub-record has been retired silently accumulate void-lookups on every receiver- side evaluation; the SPF-lookup-limit spoke documents the void-lookup cap enforcement contract AND the canonical operator-side monitoring discipline cPanel tenants apply (DMARC-aggregate-report spf=permerror row inspection) to detect void-lookup accumulation BEFORE the 2-cap saturates and breaks SPF evaluation across the entire cPanel-tenant domain. Pair this page (the cPanel-specific deployment reference) with the SPF-lookup- limit spoke (the per-mechanism budget- accounting reference) when authoring the cPanel-tenant outbound-egress include- cascade — the spoke documents the per- vendor measured-cost matrix and the void- lookup cap that cPanel tenants must budget BEFORE publishing the SPF record at the WHM zone-editor.
• SPF DNS TXT-record byte syntax - the CPANEL-TENANT-SPF-RECORD- PUBLICATION-AT-CPANEL-ZONE-EDITOR- CONSUMER-OF-SPF-TXT-RECORD-BYTE-LAYOUT companion to THIS cPanel DMARC deployment guide. Where THIS page documents the cPanel-specific deployment workflow (cPanel tenant provisioning, the per-cPanel-server shared-outbound MTA IP block, the WHM > Email Deliverability panel auto-generation flow, the WHM > DNS Functions > Edit DNS Zone UI for manual record edits), the SPF-DNS-syntax spoke is the BYTE-LAYOUT REFERENCE the cPanel tenant operator consults when editing the SPF TXT-record in either UI flow. The four-axis CPANEL-DEPLOYMENT-VS- SPF-BYTE-SYNTAX comparison exposes the structurally-distinct CPANEL-TENANT- EDITING-CONTEXTS: (i) WHM > Email Deliverability auto-generation flow — cPanel's WHM-tier auto- generation produces a default SPF record of the form v=spf1 +a +mx include:<cpanel-server>.com ~all; the SPF-DNS-syntax spoke documents the byte-level grammar (RFC 7208 §4) that auto-generated record conforms to + the per-token expansion cost against the 10-DNS-lookup budget; (ii) WHM > DNS Functions > Edit DNS Zone manual-edit flow — when the cPanel tenant adds third-party ESP includes (SendGrid / Mailgun / Amazon SES / Constant Contact / Mailchimp) via manual zone-editor edit, the SPF-DNS- syntax spoke is the byte-syntax reference the tenant operator consults to confirm the multi-mechanism record stays within the RFC 7208 §3 single-TXT-record constraint AND the §3.3 multi-string concatenation form when the byte-length approaches the 255-byte single-string DNS TXT limit; (iii) cPanel operator-empowerment-ceiling ~all vs -all qualifier choice — cPanel's auto-generated record uses ~all (SoftFail) rather than the stricter -all (HardFail); the SPF-DNS-syntax spoke documents the byte-level qualifier semantics + the per-qualifier receiver-side evaluation behaviour the cPanel tenant must understand before ramping from ~all to -all; (iv) cPanel + external DNS delegation (Cloudflare / Route 53 fronting the cPanel server) — when the tenant publishes SPF via the external DNS provider's UI rather than cPanel's Zone Editor, the SPF-DNS-syntax spoke is the byte-layout reference the tenant operator uses to confirm the externally-published record conforms to the RFC 7208 byte-grammar regardless of which DNS-publishing UI surfaces it. Read the SPF-DNS-syntax spoke ALONGSIDE this cPanel deployment guide when manually authoring or editing the SPF TXT-record at the WHM > DNS Functions UI — the byte-layout spoke is the authoritative byte-grammar reference every cPanel-tenant operator consults when the SPF record syntax matters more than the cPanel UI semantics.
• include: vs ip4: vs a: vs mx - the SHARED-HOSTING-SPF-MECHANISM-DECISION companion to this cPanel DMARC deployment guide. Where THIS page documents the cPanel-specific DMARC publication workflow (the WHM > Email Authentication UI, the per-shared-tenant SPF authoring within the cPanel UI's "Email Authentication" panel, and the per-cPanel- server outbound IP block the provider instantiates), the include-vs-ip4-vs-a-vs-mx spoke documents the FOUR STRUCTURALLY- DIFFERENT mechanism tokens (RFC 7208 §5) a cPanel operator chooses between when authoring the SPF record manually — the cPanel context is DISTINCT from managed-provider Workspace / M365 deployments because cPanel SHARED-HOSTING SPF records typically use a MIX of ip4:<CIDR> tokens (the cPanel server's per-tenant outbound IP), a:<hostname> tokens (the cPanel A-record-identified hostname), mx:<domain> tokens (the common cPanel legacy-MX-is-also-outbound topology where the inbound MX hostname is also the cPanel-server SMTP-AUTH-relay outbound), and selective include: tokens (for the rare SaaS-sender add-on a cPanel customer layers on top). Where Workspace operators almost-always pick include:_spf.google.com and leave it there, cPanel operators face a MUCH richer per-token-class decision matrix because the shared-hosting provider DOES NOT publish a canonical include:<cpanel-provider>.com token for customer adoption — instead the cPanel customer authors the SPF record using the cPanel server's RAW IPv4 block (the ip4:<CIDR> token), the cPanel server's hostname (the a: or mx: token), or both. The include-vs-ip4-vs-a-vs-mx spoke documents the per-mechanism TRADE-OFF MATRIX (lookup-cost: ip4:=0, a:=1, mx:=1+N, include:=1+chain; freshness: ip4:=frozen, a:=follows-A-record, mx:=follows-MX-record, include:=follows-sender-record; operator-burden: ip4:=highest, include:=lowest) plus the canonical cPanel-server mechanism-choice DECISION-TREE (use ip4: for the cPanel-server's hard-coded SMTP-AUTH-relay block; use a: when the cPanel-server hostname resolves to a single A record that follows hosting- provider IP rotation; use mx: when the inbound MX hostname is also the cPanel-server SMTP-AUTH relay). Read the include-vs-ip4-vs-a-vs-mx spoke EVERY time you author or audit the SPF record in WHM > Email Authentication — the mechanism-choice is the load-bearing decision for cPanel shared-hosting SPF authoring.
• DKIM explained - the protocol-level deep dive on DomainKeys Identified Mail (RFC 6376). Covers selectors, canonicalization, key rotation, and CNAME delegation.
• DKIM DNS TXT-record byte syntax (RFC 6376 §3.6.1 tag-list grammar) - the CPANEL-TENANT-DKIM-RECORD-PUBLICATION-AT-CPANEL-ZONE-EDITOR-CONSUMER-OF-DKIM-TXT-RECORD-BYTE-LAYOUT companion documenting the per-tag byte-level grammar (v=DKIM1 / k=rsa / p=<base64> / s=email / h=sha256 / t=y|s) of the DKIM TXT-record the cPanel tenant publishes via the WHM > DNS Functions > Edit DNS Zone UI or the cPanel > Email Deliverability > DKIM auto-generation panel, whose paste-and-publish correctness across FOUR cPanel-tenant-specific byte-syntax dimensions determines whether the cPanel-generated DKIM record produces dkim=pass at the receiver vs permerror on v=-tag absence / p=-tag malformation / 255-byte TXT-chunk truncation: (1) cPanel auto-generation v=DKIM1; k=rsa; p=<base64> baseline byte layout at the WHM > Email Deliverability > DKIM panel — the cPanel auto-generation flow emits the three mandatory tags in the RFC 6376 §3.6.1 canonical order, but the tenant operator MUST verify the emitted byte-sequence preserves the single-string <=255-byte form OR the multi-string concatenation contract (RFC 6376 §3.6.2.2) before pasting into the Zone Editor; (2) 255-byte TXT-chunk split discipline at 2048-bit RSA p=-tag publication — 2048-bit RSA public keys produce ~395-byte base64 strings that exceed the per-TXT-string 255-byte limit and MUST be split across multiple double-quoted strings per RFC 1035 §3.3.14 — the cPanel Zone Editor's textarea accepts the literal "chunk1" "chunk2" syntax but the tenant operator MUST verify the split occurs at byte boundaries that do NOT bisect the base64 padding (== / =) at the trailing byte boundary; (3) cPanel default k=rsa / h=sha256 / s=email tag-emission discipline — the cPanel DKIM auto-generation panel emits these three defaults implicitly (omitted from the TXT record per RFC 6376 §3.6.1 default-value clauses), and the tenant operator MUST verify the receiver-side DKIM verifier-implementation applies the RFC 6376 default-values rather than treating the absent tag as a publication-error; (4) cPanel test-mode t=y vs production t=s tag-emission discipline — the cPanel DKIM auto-generation panel defaults to NO t=-tag (RFC 6376 §3.6.1 "no flags" production behaviour), but operators staging DKIM rotation on a side-channel selector via the WHM > DNS Functions Edit DNS Zone manual-edit flow SHOULD publish t=y during the rotation overlap window AND remove it before committing to production-traffic enforcement. Byte-syntax correctness across these four cPanel-tenant DKIM publication dimensions is the load-bearing prerequisite for the DKIM ramp-to-aligned-pass-rate workflow whose per-percentage-tier closure is the gate the cPanel-tenant DMARC deployment workflow on THIS page depends on at the p=quarantine-to-p=reject ramp boundary.
• DKIM-Signature header anatomy — the CPANEL-EXIM-OUTBOUND-MTA-PER-MESSAGE- DKIM-SIGNATURE-HEADER-EMISSION-CONSUMER-OF- DKIM-SIGNATURE-HEADER-TAG-BYTE-ANATOMY companion to this cPanel DMARC deployment reference. Where THIS page documents the cPanel-tenant DMARC deployment workflow (per-cPanel-account WHM > Email Deliverability DKIM auto-generation + Zone Editor DMARC TXT publication + Exim outbound-MTA DKIM signing configuration at the per-tenant /etc/exim.conf macros), the DKIM-signatures-explained spoke is the per-tag BYTE-LEVEL HEADER ANATOMY canonical reference documenting the FOUR per-cPanel-Exim-tenant DKIM-Signature publication dimensions every outbound mail the cPanel-Exim MTA emits encodes per- message: (i) v=1; a=rsa- sha256; cPanel-Exim DKIM-Signature default tag-emission baseline — the cPanel-Exim default DKIM signing configuration emits the canonical v=1; a=rsa-sha256; tag-pair at the per-message DKIM-Signature header emission boundary (the v=1 version sentinel + a=rsa-sha256 signing algorithm pair per RFC 6376 §3.5 + RFC 8301 §3 modern algorithm-discipline deprecation of rsa-sha1) — the cPanel-tenant operator MUST verify the per-message emission matches via local exim -bV / opendkim- testkey diagnostics; (ii) c=relaxed/relaxed cPanel-Exim canonicalization default vs the per-tenant c=simple/simple legacy-override discipline — the cPanel-Exim DKIM-signing default emits c=relaxed/relaxed (the modern forwarder-survivable canonicalization pair per RFC 6376 §3.4), but legacy cPanel-tenant operators occasionally override to c=simple/simple via custom Exim macros — the cPanel- tenant operator MUST verify which canonicalization mode the per-tenant Exim emits because the c=- tag value materialises per-message in the emitted DKIM-Signature header byte- layout this spoke documents; (iii) d=<cpanel-account- domain>; s=default; cPanel- Exim per-tenant identity emission discipline — the cPanel-Exim DKIM-signing flow defaults to the per-cPanel-account primary domain as the d=-tag value with s=default as the per- cPanel-host shared selector convention; the cPanel-tenant operator MUST verify the d=-tag value matches the RFC 5322 From-author-domain for DMARC-aligned-pass evaluation, and that the s=default selector's per-tenant cPanel-published TXT-record at default._domainkey.< cpanel-domain> resolves to a cryptographically-valid public-key the receiver-side DKIM-verifier consumes; (iv) h=From:To:Subject: Date:Message-Id; bh=<sha-256>; b=<rsa-pkcs1-v1_5>; cPanel- Exim per-message signed-header-list + body-hash + signature emission discipline — the cPanel-Exim DKIM-signing flow emits the standard h=From:To:Subject:Date:Message- Id signed-header-list per cPanel- default Exim DKIM macros + the per- message SHA-256 body-hash + the per- message RSA-PKCS#1-v1_5 signature value; the cPanel-tenant operator MUST verify per-message header-injection attack surface (X-Original-From, From-Display-Name override headers below the h= coverage floor) and per-message body-hash coverage scope (cPanel-Exim does NOT emit an l=-tag by default, forcing whole-body coverage — the cPanel-tenant operator MUST verify no custom Exim configuration introduces an l=-tag truncation surface). Read DKIM-signatures- explained as the per-tag byte-anatomy reference when verifying the cPanel- Exim outbound-MTA DKIM-signing configuration emits canonical RFC- 6376-§3.5-compliant DKIM-Signature headers at the per-tenant SMTP egress boundary.
• 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 that cPanel operators routinely hit.
• DMARC policy rollout - the operational migration from p=none through p=quarantine to p=reject with a worked Week 0 -> Week 26 timeline.
• DMARC aggregate (RUA) reports - the daily XML stream receivers send back.
• BIMI (Brand Indicators for Message Identification) explained - the post-DMARC-enforcement brand-logo publication layer for cPanel tenants whose Zone-Editor-published p=quarantine or p=reject policy meets the BIMI enforcement floor (RFC 9078). The cPanel-tenant context is distinct from managed-provider Workspace / M365 because the default._bimi.<d> TXT-record and the selector._bimi.<d> SVG Tiny PS asset URL are BOTH published via the WHM > DNS Functions > Edit DNS Zone UI rather than a managed-tenancy control panel, and the SVG / VMC asset hosting decisions (cPanel-tenant document- root vs CDN) interact with the cPanel-server TLS-certificate-renewal cadence.
• BIMI Verified Mark Certificates (VMC and CMC) - the CPANEL-TENANT-VMC-PROCUREMENT-AND-DNS- PUBLICATION companion that PAIRS with the BIMI-explained intro spoke directly upstream in THIS Related Guides UL. Where the BIMI-explained entry above answers "what is BIMI and what is the DMARC-enforcement prerequisite floor THIS page's cPanel-tenant operator must reach for BIMI eligibility", the bimi_certificates spoke is the DOWNSTREAM PROCUREMENT REFERENCE answering "now that the Zone-Editor-published p=quarantine or p=reject policy this guide documents satisfies the BIMI enforcement floor, HOW does the cPanel-tenant operator acquire and publish the X.509 PKI Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) that mailbox-provider receivers require before they will render the SVG Tiny PS logo at the inbox-list rendering boundary". Four cPanel-tenant- VMC-procurement-vs-DMARC-enforcement coupling dimensions the cross-reference makes explicit: (i) cPanel-tenant VMC issuance timeline interacts with DMARC-enforcement-ramp schedule — VMC issuance is a 3-6 week procurement task (1-2 weeks of trademark-registry coordination delay + 1-2 days domain-control validation + same-day SVG-hash validation + same-day PEM chain emission); a cPanel-tenant operator following THIS page's Phase-1-through-Phase-5 DMARC rollout timeline who wishes to claim the BIMI logo display benefit AS the p=reject Phase-5 transition completes must initiate VMC procurement 6 weeks BEFORE the planned p=reject publication date — a procurement-pacing discipline distinct from the managed-provider Workspace / M365 timeline where the cloud-tenant DMARC enforcement publication has different operator-action latency characteristics; (ii) cPanel-tenant VMC-vs-CMC procurement-cost discipline for SME-tier tenants — VMCs require a registered trademark in one of the six accepted registries (USPTO, EUIPO, UKIPO, JPO, IP Australia, CIPO) where trademark- registration cost is the dominant component (~$500-$2,000 per jurisdiction + multi-year renewal cycle); CMCs accept unregistered common-law marks proven in commerce for at least 12 months at lower procurement cost but cover only the Gmail blue-verified-mark badge feature, NOT the SVG-display path at most major receivers. The cPanel-tenant small-business operator typically lacks the registered-trademark substrate large- managed-tenancy operators routinely hold, making the VMC-vs-CMC choice an operator-empowerment-ceiling input the cPanel-tenant DMARC deployment workflow on THIS page must surface for SME-tier tenants BEFORE the cPanel-tenant operator begins Phase-5 p=reject commitment; (iii) cPanel-tenant SVG / VMC asset hosting decisions interact with cPanel- AutoSSL TLS certificate renewal cadence — the bimi_explained entry directly upstream documents that the cPanel-tenant operator publishes the l=-tag-referenced SVG Tiny PS asset URL either at the cPanel-tenant document-root (HTTPS-served via cPanel's standard Apache + Let's Encrypt + AutoSSL workflow) OR at an external CDN; the a=-tag-referenced VMC PEM chain hosted at the SAME or a DIFFERENT URL is subject to the SAME HTTPS-availability + certificate-validity discipline — the VMC PEM URL MUST resolve under a TLS connection chain-validating to the public- CA trust store at every BIMI receiver verification, so the cPanel-tenant AutoSSL renewal cadence (60-day cycle Let's Encrypt + per-domain renewal triggers) is the LOAD-BEARING availability substrate the bimi_certificates spoke names as a cPanel-tenant-specific operational dimension; (iv) cPanel- tenant CA-trust-boundary discipline (DigiCert and Entrust ONLY) — the bimi_certificates spoke documents that as of 2026 the only two production-issuing CAs whose root certificates major mailbox providers trust for VMC chain validation are DigiCert and Entrust; certificates from other PKI CAs are rejected even if structurally identical. The cPanel-tenant operator following THIS page's deployment workflow whose existing TLS PKI procurement relationship is with a non-BIMI-trusted CA (e.g., GlobalSign for a corporate compliance reason) MUST establish a new procurement relationship with DigiCert or Entrust SPECIFICALLY for the VMC and CMC; this is distinct from the standard cPanel-tenant Let's Encrypt AutoSSL TLS cert workflow used for the document-root and the _bimi.<d> SVG / VMC asset hosting endpoints. Read bimi_certificates as the per-cPanel- tenant-deployment VMC-and-CMC procurement reference that EXTENDS the BIMI-explained intro upstream from "BIMI is the post- DMARC-enforcement publication layer" to "here is the X.509 PKI certificate procurement and publication discipline the cPanel-tenant operator MUST execute to UNLOCK the SVG-display rendering at major- receiver inbox boundaries".
• ARC (Authenticated Received Chain) explained - RFC 8617: preserves SPF / DKIM / DMARC results across forwarding hops.
• MTA-STS vs DANE - the CPANEL-TENANT-OPERATOR-EMPOWERMENT-DECISION-INPUT companion documenting the transport-security choice cPanel tenants face when extending the DMARC deployment workflow on THIS page with the transport-encryption layer that MTA-STS OR DANE adds. Where THIS page is the cPanel-tenant DMARC deployment guide (Zone Editor publication path, OpenDKIM key management, shared-MTA SPF compounding, operator-empowerment ceiling on per-tenant DKIM, shared-IP-block reputation observability gap), the mta_sts_vs_dane spoke is the TRANSPORT-SECURITY-LAYER DECISION REFERENCE documenting how the cPanel-tenant operator-empowerment ceiling SHAPES the MTA-STS-vs-DANE choice in FIVE structurally- distinct ways the cross-reference makes explicit: (i) DANE requires DNSSEC-signed-zone support that MOST cPanel platforms LACK — DANE TLSA records require DNSSEC-chain validation; cPanel platforms generally do NOT offer per-tenant DNSSEC signing in the Zone Editor UI, so DANE is OPERATIONALLY UNAVAILABLE to most cPanel-tenants out of the box; (ii) MTA-STS HTTPS-policy-file hosting is NATURAL fit for cPanel — cPanel's primary value proposition is HTTPS-served-content with Let's Encrypt cert automation, so the mta-sts.<domain> subdomain + .well-known/mta-sts.txt policy file maps cleanly to cPanel's standard Apache + Let's Encrypt + AutoSSL workflow; (iii) cPanel-tenant CAA records may BLOCK MTA-STS cert issuance — when a cPanel-tenant's CAA record is locked to a specific CA (e.g., GlobalSign for a corporate compliance reason) and that CA's Let's Encrypt-tier automated-issuance is unavailable, the MTA-STS HTTPS cert cannot be auto-renewed — DANE would sidestep this, but DANE requires the DNSSEC support cPanel platforms lack (chicken-and-egg); (iv) cPanel operator deploying transport-security AFTER DMARC publication — the cPanel-tenant following THIS page's Phase 5 steady-state monitoring may observe TLS-RPT failures suggesting STARTTLS-downgrade attacks; the natural next-step is transport-security deployment, and the MTA-STS-vs-DANE choice determines the cPanel-tenant's defense-layer; (v) cPanel-tenant migrating away from shared hosting to managed-DNS-provider gains DANE access — when a cPanel-tenant migrates from cPanel-hosted DNS to Cloudflare / Route 53 / NS1 with DNSSEC support, DANE becomes operationally viable AND the MTA-STS-vs-DANE choice opens up. Read the MTA-STS-vs-DANE head-to-head AFTER completing the cPanel-tenant DMARC deployment on THIS page when the operator is choosing the transport-security layer to add on top.
• DMARC for Google Workspace - the enterprise-flavoured sibling deployment guide for Google Workspace tenants.
• DMARC for Microsoft 365 - the enterprise-flavoured sibling deployment guide for Exchange Online tenants. Compare the dual-selector CNAME-delegated DKIM model (M365) with the single-selector TXT-publication model (cPanel) and the explicit DKIM provisioning model (Workspace).
• DMARC for Shared Hosting: Plesk, DirectAdmin, ISPConfig - the sibling deployment guide for shared-hosting platforms OTHER than cPanel. Covers Plesk (the second-largest shared-hosting control panel, Postfix backend, DKIM toggle at Mail Settings > DKIM spam protection), DirectAdmin (Exim like cPanel but with a completely different management UI, single- character x selector), ISPConfig (Postfix + Dovecot, MSP- popular), Webmin / Virtualmin, CentOS Web Panel (CWP), and the generic-no- control-panel population with a SaaS- relay CNAME-delegated DKIM escape hatch.
• Multi-domain DMARC strategy - the CPANEL-ADDON-DOMAIN-PORTFOLIO-LIFECYCLE companion to this cPanel DMARC deployment guide. Where THIS page documents the SINGLE-cPanel-DOMAIN authoring workflow (WHM > Email Authentication for the primary tenant domain, single _dmarc.<domain> TXT record, single SPF / DKIM stack), the multi-domain-strategy spoke documents the PORTFOLIO-COORDINATION decision framework a cPanel operator transitions to as the tenancy accumulates additional sender domains via cPanel's Addon Domains, Parked Domains (cPanel-terminology for alias-domains pointing at the same document root), Subdomains (per-product / per-region / per-brand subdomain spin-up), and Aliased Domains (a per-cPanel-account feature that lets one DocumentRoot serve multiple distinct sender domains). The portfolio decision-framework documents FOUR STRUCTURALLY-DISTINCT cPanel-tenancy patterns: (i) single-org many- brands — the cPanel reseller / SMB tenant who runs the primary corporate domain plus 3-15 product / brand / regional sub-brand domains via Addon Domains (each with its own _dmarc.<brand-domain> TXT record + per-brand selectorN DKIM selectors), (ii) acquired- domain wind-down — the cPanel operator who inherits a defunct marketing-campaign domain or an acquired-startup's mail-history domain the operator no longer sends from but wants to LOCK against spoofers (the p=reject + v=spf1 -all + null-MX RFC 7505 lockdown pattern), (iii) parked-domain enforcement — the cPanel operator who registers typosquat defensive-registrations (the company.org / company.net / company.co defensive registrations the legitimate operator never sends from but must guard against attacker-spoofing) and publishes p=reject + null- SPF on each, (iv) subdomain segmentation — the cPanel operator using sp= (subdomain policy) and np= (non-existent subdomain policy, RFC 9091) tags to segment per-product subdomain risk profiles without publishing per-subdomain TXT records for every leaf node. The multi-domain spoke also documents the load-bearing Public Suffix List (PSL) organisational- domain boundary that governs which cPanel-tenant subdomains the apex-domain sp= tag actually covers (every subdomain under the apex registered organisational-domain is covered by the apex's sp=; addon-domains under SEPARATE organisational domains need their own _dmarc.<addon-domain> records). Read the multi-domain- strategy spoke EVERY time a cPanel tenancy publishes its second sender domain via Addon Domains / Parked Domains / Aliased Domains — the portfolio-coordination decision framework is the load-bearing reference for the moment the cPanel operator transitions from single-domain DMARC authoring to multi-domain DMARC coordination.
• DMARC forensic (RUF) reports — the SHARED-HOSTING-CONTROL-PANEL-RUF- PUBLICATION-AND-PRIVACY-IMPLICATIONS companion to this cPanel-shared-hosting DMARC deployment reference. Where THIS page documents the cPanel-WHM Email Deliverability wizard's _dmarc TXT-record authoring discipline + the cPanel-Exim outbound signer + the cPanel-DKIM selector publication, the DMARC-forensic-reports (RUF) spoke is the PER-MESSAGE-FAILURE- SAMPLE channel whose ruf= tag publication discipline at the cPanel-shared- hosting customer-domain boundary interacts with FOUR shared-hosting-control-panel- specific RUF authoring boundaries: (i) cPanel customer's ruf= publication shares the shared-IP attribution surface — RUF rows can reveal cross-tenant message-header details from a neighbouring customer's authentication failures — when the cPanel-shared-hosting provider publishes a tenant-shared bounce-domain (e.g. _dmarc.<provider>.com addressed RUF) at the provider's apex, every customer's RUF capture-stream may surface message headers attributable to a different tenant if the receiver's evaluation logic cross-attributes the bounce-domain to the provider rather than the customer, creating a cross-tenant message-content privacy leakage surface absent in single-tenant topologies; (ii) cPanel WHM does NOT typically expose a per-customer ruf= management UI — unlike the auto-generated SPF and DKIM records the WHM Email Deliverability wizard publishes, the _dmarc TXT record's ruf= tag must be manually edited via WHM DNS-zone-editor or per-customer DNS-management panel, creating an authoring-surface asymmetry the operator must close manually; (iii) shared-hosting-provider receiving RUF reports for the customer's domain raises a GDPR / privacy-policy-disclosure question the cPanel-shared-hosting provider's terms-of-service must resolve — when the customer's ruf= delegates to a provider-managed mailbox (so the provider's abuse-team can act on forensic-failure samples on behalf of all tenants), the per-message AFRF (RFC 5965) payload carries the original message's sensitive headers (To:, Subject:, Date:, Message-ID, etc.) which the customer-tenant may not have consented to the provider accessing; (iv) provider-managed bounce-domain confounds RUF attribution at the receiver — when the cPanel- shared-hosting provider's outbound-Exim envelope-MAIL-FROM rewrites to a provider- managed bounce-domain (e.g. bounce.<provider>.com), receivers may attribute RUF generation to the provider's bounce-domain rather than the customer's organizational domain, causing the customer's ruf= address to receive zero forensic samples even when receivers DO emit RUF for the customer's p=reject / p=quarantine failures. Read the DMARC-forensic-reports spoke alongside this cPanel-deployment reference when authoring the cPanel-shared-hosting customer's per-message-failure-sample forensic-evidence-collection posture — the spoke is the canonical RFC 7489 §7.3 / RFC 6591 / RFC 5965 RUF-format and RUF-publication reference whose four shared-hosting-control-panel-specific authoring boundaries this cPanel- deployment page is the operational execution-layer companion for.
• DKIM selectors explained - the PER-SELECTOR-NAMESPACE-AS-LOAD- BEARING-PER-CPANEL-ACCOUNT-DKIM-KEY- PARTITIONING-PRIMITIVE-FOR-SHARED-HOSTING- MULTI-TENANT-DEPLOYMENT companion to this cPanel-deployment reference. Where THIS page documents the cPanel-shared-hosting DMARC + SPF + DKIM deployment workflow (the WHM-level per-account DKIM provisioning, the cPanel Email Deliverability interface, the per-account default._domainkey selector publication via the cPanel API), the DKIM-selectors-explained spoke is the per-selector-namespace publication-discipline reference documenting the per-tenant DKIM selector partitioning model EVERY shared- hosting cPanel account must operate against at FOUR per-cPanel-account-DKIM-selector- partitioning dimensions: (i) per- account default._domainkey.<d> selector publication-naming-convention as the per-tenant DKIM-key-publication-namespace primitive — the spoke documents why cPanel's default default._domainkey selector choice is the per-account publication- namespace anchor, and how the per-account TXT-RR publication-discipline at default._domainkey.<tenant-domain> produces per-tenant key-isolation despite the shared underlying cPanel infrastructure; (ii) per-account selector-rotation cadence as the per-tenant key-compromise- window discipline — the spoke documents the canonical selector-rotation cadence (rotate within 6-12 months) the cPanel host-operator's per-tenant DKIM key-rotation tooling must execute (rotate from default._domainkey to cpanel2025q1._domainkey, propagate the per-account TXT publication through the cPanel DNS Zone Editor, and retire the old selector via empty- p= publication); (iii) per-cPanel-host shared-selector- pool topology vs per-account-isolated- selector topology as the multi-tenant- deployment-discipline dimension — the spoke documents the two canonical cPanel deployment patterns (per-tenant isolated selector at default._domainkey.<tenant-d> on each tenant's own zone vs per-host shared selector at default._domainkey.<cpanel-host> CNAME-delegated from each tenant) and the per-tenant abuse-isolation tradeoff the cPanel host-operator must decide between; (iv) per-account selector- retirement workflow as the per-tenant DKIM-deprovisioning publication discipline primitive — the spoke documents the per-tenant selector-retirement workflow (empty-p= publication at the retired selector FQDN to signal receiver- side validators "fail any signature claiming this selector") the cPanel host- operator must execute when a tenant account is suspended / terminated / migrated to avoid leaving dangling DKIM signatures signed by retired tenants. Read the DKIM- selectors-explained spoke alongside this cPanel DMARC reference when designing the per-tenant cPanel DKIM provisioning, rotation, and deprovisioning runbook — the spoke documents the per-selector publication discipline whose namespace + rotation cadence + topology + retirement workflow the cPanel host-operator's per-tenant DKIM operations depend on.
• DNS propagation explained — the CPANEL-ZONE-EDITOR-PUBLISH-CACHE- VS-RECURSIVE-RESOLVER-CACHE-AGING- PROPAGATION-WINDOW-AS-LOAD-BEARING- UPSTREAM-GATE-OF-PER-TENANT-DMARC-AND- DKIM-AND-SPF-PUBLICATION-OBSERVABILITY- AT-RECEIVER-AT-FOUR-CPANEL-OPERATOR- PROPAGATION-DISCIPLINE-COUPLING- DIMENSIONS companion to this DMARC-for- cPanel reference. Where THIS page documents the per-tenant DMARC publication workflow at the cPanel host- operator boundary (cPanel Zone Editor + Email Deliverability dashboard + per- domain SPF / DKIM / DMARC record provisioning + WHM-side admin defaults + per-tenant rua mailbox configuration), the DNS-propagation spoke is the canonical propagation-window discipline reference whose per-resolver per-zone- version cache-aging behaviour determines WHEN each per-tenant per-domain DMARC + DKIM + SPF publication via the cPanel Zone Editor becomes globally observable at the receiver's recursive-resolver cache tier — at four cPanel-operator propagation discipline coupling dimensions: (i) cPanel Zone Editor edit-publish-cache vs recursive- resolver propagation-window coordination — cPanel Zone Editor commits per-tenant DNS edits to the local zone-file backing store (BIND / NSD / PowerDNS depending on the host- operator's name-server stack) at the cPanel host-operator's edit-publish cadence; the per-tenant DMARC TXT-RR + per-tenant DKIM <selector>._domainkey. <tenant-domain> TXT-RR + per-tenant SPF apex-domain TXT-RR edited through the cPanel Zone Editor is then subject to the per-receiver- cohort recursive-resolver cache-aging propagation window THIS spoke documents before becoming observable at the receiver-side per-message DMARC / DKIM / SPF evaluation boundary; (ii) cPanel AutoSSL renewal-cycle DNS-prerequisite propagation-window coordination — cPanel AutoSSL per-vhost certificate renewal (issued through Sectigo / Let's Encrypt) depends on per-tenant CAA-record DNS-publication propagation completing BEFORE the AutoSSL renewal cron job attempts the per-CA pre-issuance CAA fetch — the per- resolver per-zone cache-aging propagation-window THIS spoke documents is the upstream timing gate the AutoSSL cron-schedule depends on; (iii) per-tenant DKIM-key-rotation dual-selector overlap-window vs cPanel Exim signing-key cutover coordination — the per-tenant per-selector DKIM rotation workflow on cPanel (publish new selector1 TXT-RR via Zone Editor; flip cPanel Exim's per-domain DKIM signing-key path to the new selector's private key; wait for recursive-resolver-cache propagation; retire the prior selector's public-key TXT-RR) is gated by the per-resolver per-zone cache-aging propagation-window THIS spoke quantifies — the per-tenant per-rotation cutover-discipline ladder bottoms out on the DNS-propagation- window-discipline reference; (iv) cPanel WHM-side per-tenant TTL default vs operator-tuned-per-record- TTL coordination — cPanel WHM defaults to a per-zone TTL value (typically 14400 seconds = 4 hours) that propagates uniformly to ALL per- tenant per-domain TXT-RRs unless the host-operator tunes per-record TTLs downward for email-authentication records (DMARC / DKIM / SPF — the ~5-minute TTL recommendation THIS DNS- propagation spoke documents for emergency-rollback discipline) — the cPanel host-operator's per-tenant per- record-TTL tuning discipline is the publisher-side per-tenant emergency- rollback-readiness floor the DNS- propagation spoke documents the operator-side discipline rationale for. Read the DNS-propagation spoke ALONGSIDE this DMARC-for-cPanel reference whenever a per-tenant per- domain DMARC / DKIM / SPF publication timing question emerges at the cPanel host-operator boundary — THIS page gives the cPanel-host-operator-side per-tenant DMARC publication workflow, the DNS-propagation spoke gives the upstream propagation-window discipline reference the cPanel-host-operator- side per-tenant publication timing ladder bottoms out on at the per- receiver-cohort recursive-resolver cache-aging boundary.
• Reverse DNS (PTR) and FCrDNS explained — the CPANEL-SHARED-OUTBOUND-MTA- SHARED-IP-POOL-RDNS-AS-PER-HOST-OPERATOR- CONTROLLED-PER-TENANT-IDENTITY-ATTRIBUTION- LAYER companion to this DMARC-for-cPanel deployment reference. Where THIS page documents the per-tenant DMARC + DKIM + SPF publication workflow at the cPanel host-operator boundary (cPanel Zone Editor + Email Deliverability dashboard + per-tenant OpenDKIM key management + shared-MTA Exim outbound egress + WHM-side admin defaults + per-tenant rua mailbox configuration), the reverse-DNS / PTR / FCrDNS spoke documents the per-source-IP rDNS publication discipline whose in-addr.arpa / ip6.arpa PTR record AND forward-confirmed forward-A back-lookup is STRUCTURALLY DISTINCT from the per-tenant forward-zone authoring THIS page documents at FOUR cPanel-shared-hosting-rDNS-coordination coupling dimensions: (i) cPanel shared-IP-pool PTR publication at the host- operator layer NOT the per-tenant layer — the cPanel host-operator's shared-IP egress pool emits all per-tenant outbound mail from a SHARED set of source-IPs; the per-source-IP PTR record for each shared-pool IP is owned by the host-operator (typically published in the in-addr.arpa zone delegated by the upstream hosting-vendor / data-centre operator) NOT by the per-tenant cPanel customer — the rDNS spoke documents the host-operator-side PTR publication discipline that no per-tenant Zone Editor can author and that the cPanel Zone Editor workflow THIS page documents does NOT cover; (ii) shared-IP-pool rDNS hostname as PER-CPANEL-HOST-OPERATOR (not per-tenant) identity attestation — when a receiver runs FCrDNS on a cPanel shared-IP-pool egress IP, the PTR resolves to a host-operator-canonical hostname (typically mail-out-NNN.<host-operator- domain> or <data-centre-hostname>) rather than the per-tenant publisher domain — the per-tenant publisher's brand identity is therefore NOT attested by the per-IP rDNS lookup AND the per-message DMARC verdict alignment-evaluation (per-tenant publisher domain vs the host-operator canonical hostname in the PTR) is the only per-tenant attribution surface the receiver consults; (iii) cPanel per-tenant DKIM-d= and SPF-aligned envelope- MAIL-FROM as PER-TENANT identity substrate COMPLEMENTING the host-operator-owned per- IP PTR — because the per-IP PTR cannot identify the per-tenant publisher, the per-message DKIM-d= tag and the per-tenant SPF-aligned envelope- MAIL-FROM are the LOAD-BEARING per-tenant identity attestation the cPanel-shared-IP- pool deployment relies on — the rDNS spoke documents the per-IP-side identity boundary that compounds with the per-tenant DKIM / SPF publication discipline THIS page documents at the per-tenant identifier layer; (iv) shared-IP-pool reputation contamination as cross-tenant per-IP-rDNS- attributed event class — when a co-tenant on the shared-IP pool ships spam / phishing / malware traffic from the same host-operator-PTR-attested egress IP, the per-receiver per-IP reputation evaluation attributes the negative reputation to the SHARED PTR hostname rather than the per-tenant cPanel customer — the rDNS spoke documents the per-IP-side reputation- attribution boundary whose cross-tenant contamination class the cPanel host-operator Email Deliverability dashboard surfaces via per-IP RBL / blacklist queries the per- tenant Zone Editor workflow THIS page documents cannot self-remediate. Read the reverse-DNS / PTR / FCrDNS spoke when designing the cPanel host-operator's shared-IP-pool rDNS coordination discipline whose per-IP host-operator-owned PTR publication compounds with the per-tenant DKIM / SPF / DMARC publication discipline THIS page documents at the per-tenant identifier layer.
• 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 cPanel's default selector), and the DMARC policy state.
• Blacklist Checker - check a sending IP against the major blocklists. Essential when diagnosing shared-IP reputation issues on shared cPanel hosting.
• 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.
• cPanel Documentation: Email Deliverability - the canonical primary-source vendor documentation for the Email Deliverability page.
• Google: Email sender guidelines - the canonical Feb 2024 bulk-sender requirements that apply to every sender regardless of mailbox provider.
• DMARC deployment checklist - the CPANEL-AGNOSTIC PHASED-DEPLOYMENT-PIPELINE companion to this cPanel-specific DMARC deployment reference. Where THIS page documents the cPanel-CONCRETE step-by-step deployment workflow (WHM Email Deliverability auto- generation flow, the WHM > DNS Functions > Edit DNS Zone manual-edit flow, the cPanel-shared-outbound MTA IP block, the per-tenant SPF + DKIM + DMARC TXT publication across the cPanel zone), the deployment checklist documents the CPANEL-AGNOSTIC canonical phased-deployment sequence that applies regardless of the underlying operator's host control panel (cPanel / Plesk / DirectAdmin / ISPConfig / managed-DNS-only). Four DEPLOYMENT-CHECKLIST-VS-CPANEL-DEPLOYMENT axes the checklist documents that THIS page is the cPanel-CONCRETE walkthrough for: (1) SPF publication phase — the checklist's "publish an SPF TXT record covering every legitimate sending source" step that this page concretises with the cPanel-shared- outbound MTA +ip4:<cPanel-host-IP> mechanism plus the per-tenant include:<ESP>.com chain (covering the 10-DNS-lookup limit budget per RFC 7208 §4.6.4 across the typical cPanel tenant's ESP inventory); (2) DKIM publication phase — the checklist's "publish DKIM TXT at <selector>._domainkey" step that this page concretises with WHM Email Deliverability's auto-generation flow producing the default._domainkey RSA-2048 keypair plus the per-tenant zone-editor publication path; (3) monitoring phase — the checklist's "deploy p=none with rua= reporting" step that this page concretises with the cPanel-tenant rua=mailto: publication and the rua-destination domain's own DKIM + SPF prerequisites at the cPanel-host level; (4) enforcement-commitment phase — the checklist's p=none → p=quarantine → p=reject ramp this page concretises with the cPanel- tenant's per-tenant Feb 2024 Gmail/Yahoo bulk- sender enforcement deadline, the cPanel shared- IP reputation segmentation rules, and the per-tenant zone-editor flip from p=none to p=quarantine once the monitoring phase converges. Read the deployment checklist FIRST to understand the canonical phased sequence; read THIS page SECOND to execute that sequence in cPanel.
• TLS-RPT explained — the TLS-RPT-PUBLICATION-DISCIPLINE- AS-CPANEL-TENANT-TRANSPORT-LAYER- TELEMETRY-COMPLEMENT-TO-DMARC-MESSAGE- LAYER-TELEMETRY companion to this cPanel-specific DMARC deployment reference. Where THIS page documents the per-cPanel-tenant DMARC deployment workflow (cPanel zone editor / WHM Email Deliverability UI / Local Mail Exchanger routing / shared-IP reputation cohort / per-account default._domainkey publication / per-tenant p=none → p=quarantine → p=reject ramp), the TLS-RPT-explained spoke is the per-cPanel-tenant per-domain RFC 8460 transport-layer telemetry- publication reference whose four PER-CPANEL-TENANT-TRANSPORT-LAYER- TELEMETRY-PUBLICATION-COUPLING dimensions catalogue the per-tenant transport-layer telemetry discipline that complements the per-tenant DMARC message-layer telemetry publication: (i) per- cPanel-tenant _smtp._tls.<tenant> TXT-record publication via the cPanel zone editor — the per-cPanel-tenant publishes the per-domain _smtp._tls.<tenant> IN TXT "v=TLSRPTv1; rua=mailto: tlsrpt@<tenant>" record through the SAME cPanel Zone Editor UI the per-tenant DMARC TXT publication THIS page documents uses; the cPanel-tenant operates a UNIFORM per-domain TXT-publication workflow across the DMARC message-layer telemetry- publication (THIS page's _dmarc.<tenant> publication) AND the TLS-RPT transport-layer telemetry- publication the spoke documents, both gated behind the same per- tenant zone-editor write-access boundary the shared-hosting provider provisions; (ii) per-cPanel-shared-MTA TLS-failure attribution — the per-cPanel-tenant per-day TLS-RPT JSON report decomposes into per-failure-class rows attributed against the per-cPanel- shared-outbound-MTA topology documented on THIS page (one per-account Local Mail Exchanger MTA + one per-cPanel-host shared- outbound-relay MTA + per-WHM- cohort smarthost-MTA target); the TLS-RPT-explained spoke documents the per-failing-MX-host attribution that lets the cPanel- tenant decompose per-recipient- MX TLS-failure events (starttls- not-supported on per-recipient-MX Gmail / Yahoo / Microsoft 365 endpoints + certificate-host- mismatch on per-recipient-MX regional providers) into the cPanel-shared-MTA pre-SMTP connection topology that produced them; (iii) per- cPanel-tenant TLS-RPT collector endpoint provisioning — the per-cPanel-tenant TLS-RPT publication elects a per-tenant mailto: ingestion endpoint that the per-tenant SPF + DKIM + DMARC publication discipline THIS page documents must self-align to receive the per-receiver-day TLS-failure JSON report stream (the receiver-side TLS-RPT collector validates sender-side DMARC alignment on the per-tenant TLS-RPT-rua endpoint before accepting the JSON report); the TLS-RPT-explained spoke documents the per-tenant TLS-RPT collector provisioning workflow that consumes the per- tenant DKIM default._domainkey publication + per-tenant v=spf1 publication + per-tenant v=DMARC1 publication THIS page catalogues as the load-bearing receive-side ingestion prerequisite; and (iv) per-cPanel-tenant cross- layer publication-discipline stack — the per-cPanel- tenant per-domain publication stack (SPF message-layer authentication + DKIM message- layer cryptographic + DMARC message-layer policy + DMARC message-layer telemetry + TLS- RPT transport-layer telemetry + MTA-STS transport-layer enforcement when adopted) is coordinated through the SAME cPanel Zone Editor / WHM Email Deliverability surface this page documents; the TLS-RPT- explained spoke documents the per-tenant transport-layer telemetry-publication discipline whose cross-layer coordination with the per-tenant DMARC message-layer telemetry- publication discipline THIS page documents is the load- bearing per-cPanel-tenant cross-layer publication- discipline contract every adjacent transport-layer surface (MTA-STS publication for receiving MX of the cPanel- tenant, DANE TLSA-RR if the provider operates DNSSEC zones) structurally consumes. Read the TLS-RPT-explained spoke alongside this cPanel-specific DMARC deployment reference when adopting the per-cPanel- tenant cross-layer publication- discipline stack — the per- tenant DMARC message-layer telemetry-publication THIS page documents is the load-bearing message-layer telemetry- publication whose receiver-side evidence the per-tenant TLS-RPT transport-layer telemetry- publication complement structurally completes.
• DMARC for Office 365 Hybrid — the contrasting-deployment-complexity- peer companion to this cPanel-tenant deployment reference. Where THIS page documents the cPanel-TENANT-AS-SINGLE- HOST-SINGLE-MX deployment topology (the per-tenant cPanel-managed Exim outbound relay + per-tenant cPanel-WHM-managed DKIM signing-key at the default._domainkey selector + per-tenant cPanel-resolved per-domain MX record + single per-domain SPF record authorizing the cPanel-host IP), the Office-365-hybrid spoke documents the structurally-OPPOSITE HYBRID- EXCHANGE-AS-DUAL-MAIL-FLOW-DUAL-MX deployment topology in which the per- tenant outbound stream is split across Exchange Online + on-prem Exchange via per-tenant 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), and the per-tenant DKIM-signing surface is dual-rooted (Exchange-Online-managed selector1._domainkey + on-prem-Exchange-managed selector for legacy on-prem signed mail). Read the Office-365-hybrid spoke alongside this cPanel deployment reference when evaluating the per-tenant DMARC- deployment-complexity spectrum: the cPanel-tenant single-host single-MX baseline THIS page documents is the simplest per-tenant deployment topology in the cluster, the Office-365-hybrid spoke documents the most-complex per- tenant deployment topology, and the contrast exposes the per-tenant SPF / DKIM / DMARC publication-discipline dimensions that scale with the per- tenant mail-flow-leg count.
• SPF mechanisms explained — the RFC-7208-§5-MECHANISM-CATALOGUE-REFERENCE companion to this cPanel-tenant DMARC deployment reference — the RFC-7208-§5-MECHANISM- CATALOGUE-REFERENCE companion to this cPanel-tenant DMARC deployment reference. Where THIS page documents the per-cPanel-tenant single-host single-MX deployment topology and its per-tenant cPanel-WHM-auto-generated SPF / DKIM / DMARC publication discipline, the spf_mechanisms_ explained spoke documents the canonical RFC 7208 §5 SPF MECHANISM CATALOGUE the per-cPanel-tenant SPF record is constructed from at the token-by-token authoring level: the eight per-mechanism tokens (a, mx, ip4, ip6, include, exists, ptr, all), their per-mechanism RFC 7208 §4.6.4 DNS-lookup-count contribution, the per-mechanism RFC 7208 §5.5 deprecation status (ptr SHOULD NOT be used by RFC 7208 §5.5), and the per-mechanism RFC 7208 §4.6.2 prefix qualifier interaction (+, -, ~, ?). FOUR structurally-distinct PER- MECHANISM-VS-PER-cPanel-TENANT- DEPLOYMENT-COUPLING dimensions the per-cPanel-tenant SPF-publication discipline THIS page documents operationally consumes: (i) per-cPanel-tenant +a / +mx mechanism pair AS LOAD-BEARING-PER-TENANT-SINGLE- HOST-SINGLE-MX SPF-AUTHORIZATION- PRIMITIVE — the per- cPanel-tenant single-host deployment topology THIS page documents canonically uses the +a (authorize the A- record-resolved IPs) and +mx (authorize the MX-target-A-record-resolved IPs) mechanism pair as the per-tenant SPF-authorization primitive — the spf_mechanisms_explained spoke catalogues the per-mechanism semantic these per-cPanel-tenant SPF records depend on at the per- mechanism RFC 7208 §5.1 (a- mechanism) and §5.2 (mx-mechanism) evaluation level; (ii) per- cPanel-tenant include:<ESP-domain> mechanism stack AS LOAD-BEARING- PER-TENANT-STACKED-ESP-AUTHORIZATION- PRIMITIVE — the per-cPanel- tenant per-domain SPF record stacks the include: token per- external-ESP (SendGrid, Mailgun, Mailchimp, etc.); the spf_mechanisms_ explained spoke catalogues the per- include: RFC 7208 §5.2 recursive-resolution semantic and its per-mechanism RFC 7208 §4.6.4 DNS-lookup-count contribution the per-cPanel-tenant pre-rollout SPF audit must enforce; (iii) per-cPanel-tenant -all / ~all qualifier choice AS LOAD-BEARING-PER-TENANT-TERMINAL- SPF-MODE-DISCIPLINE — the per-cPanel-tenant SPF record terminal-mode qualifier (the choice between -all for per-receiver-side hard-fail and ~all for per-receiver- side soft-fail) is the canonical per-tenant SPF-enforcement-policy primitive the per-mechanism RFC 7208 §4.7 qualifier-evaluation semantic the spf_mechanisms_ explained spoke documents operationalizes per-tenant; (iv) per-cPanel-tenant ptr mechanism absence AS LOAD-BEARING-PER-TENANT- RFC-7208-§5.5-DEPRECATION-COMPLIANCE- INVARIANT — the per-cPanel- tenant SPF record MUST NOT publish the ptr mechanism per RFC 7208 §5.5 (SHOULD NOT be used); the spf_mechanisms_explained spoke documents the ptr- mechanism deprecation rationale (slow reverse-DNS-lookup latency + per-receiver-side opt-out permission to skip it under per-receiver evaluation-budget pressure) the per-cPanel-tenant SPF-publication discipline THIS page documents structurally observes by EXCLUDING the ptr-mechanism from the per-tenant SPF record. Read the spf_mechanisms_explained spoke ALONGSIDE this cPanel-tenant DMARC deployment reference whenever the per-tenant operator authors the per-cPanel-tenant SPF record at the per-mechanism token level — the spoke is the canonical RFC 7208 §5 PER-MECHANISM CATALOGUE REFERENCE the cPanel-tenant SPF- publication discipline THIS page documents depends on at the per- mechanism token-by-token authoring level.
• DKIM key rotation — the PER-CPANEL-WHM-TENANT PER-SELECTOR KEY-ROTATION-CADENCE companion to this cPanel-hosted DMARC deployment reference. Where THIS page documents the per-cPanel- WHM-account DKIM-publication discipline at default._domainkey.<tenant> via the WHM Email Deliverability interface, the DKIM-key-rotation spoke documents the per-selector quarterly-or-faster rotation cadence (old-selector grace-period retention, per-tenant per-selector revocation discipline, per-tenant WHM-managed key regeneration) every per-cPanel-tenant DKIM signer MUST execute against EACH per-account selector boundary. Read THIS page when DEPLOYING per-cPanel-tenant DKIM/SPF/DMARC; read the DKIM-key-rotation spoke when AUTHORING the per-tenant rotation cadence that keeps per-account cryptographic material fresh across the WHM-managed DKIM-publication infrastructure.
• DKIM troubleshooting - the PER-CPANEL-WHM-TENANT PER-ACCOUNT-PER-SELECTOR DKIM-VERIFICATION-FAILURE-DIAGNOSTIC- PLAYBOOK companion to this cPanel- hosted DMARC deployment reference. Where THIS page documents the per- cPanel-WHM-account DKIM-publication discipline at default._domainkey.<tenant> via the WHM Email Deliverability interface (key-pair generation, public- key TXT-record publication, selector choice, per-account RSA-2048 provisioning), the DKIM-troubleshooting spoke is the per-cPanel-WHM-account per-selector failure-mode investigation playbook documenting the FIVE per- receiver DKIM-verifier verdict states a per-cPanel-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-account outbound message carried NO DKIM-Signature header at all - per-cPanel-tenant failure mode where the WHM Email Deliverability interface DKIM-signer is disabled at the per- account level or the cPanel outbound- relay pipeline strips the DKIM-Signature header in-flight; (ii) dkim=temperror indicating the per-receiver verifier could not complete the per-selector public-key TXT-record DNS-lookup within the per- receiver evaluation-budget window - per-cPanel-tenant failure mode where the per-account selector TXT-record publication is suffering per-RR-TTL propagation lag or the per-tenant authoritative-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-cPanel-tenant failure mode where the WHM-zone-editor-published per- selector TXT record is truncated past the 255-byte single-string boundary without proper multi-string quoting, contains an unsupported k= algorithm-tag value, or carries the p=-revocation marker without the corresponding key material; (iv) dkim=fail indicating the per-receiver verifier retrieved a parseable per-selector public-key TXT record but the per-message body-hash or signature- hash did NOT verify - per-cPanel- tenant failure mode where the per- account outbound-mail-flow post- signature modification (cPanel-side content-rewriting, Exim mail-filter body-modification, per-account SpamAssassin header-injection) 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-account From: header organizational domain under the per- publisher adkim= alignment-strictness setting - per-cPanel-tenant failure mode where the per-account outbound mail is routed via a third-party SMTP relay (mailgun.org, sendgrid.net, amazonses.com) signing with the relay's d=-domain rather than the per-cPanel-tenant customer domain. Read THIS page when PUBLISHING the per-cPanel-tenant per-account DKIM key-pair via the WHM Email Deliverability interface; read the DKIM-troubleshooting spoke when INVESTIGATING per-account per- selector DKIM-verification failures surfaced in per-receiver Authentication-Results headers or per-publisher RUA aggregate-report rows.
• DMARC policy modes (p=none / p=quarantine / p=reject) - the PER-CPANEL-TENANT-PER-ACCOUNT-DMARC- DISPOSITION-DECISION companion to this cPanel deployment guide. Where THIS page documents the cPanel-specific DMARC publication workflow (the WHM > Email Deliverability auto-generation flow that sets the _dmarc.<account-domain> TXT-record with a default p=none, the cPanel-server shared-outbound MTA IP block and its per-server include:<cpanel-server> SPF cascade interaction with per-account DMARC enforcement, and the per-account WHM > DNS Functions Edit DNS Zone manual-edit path for p=-tag promotion), the policy-modes spoke is the per-receiver DMARC-disposition-action reference documenting what each p=-tag value actually instructs the per-receiver to DO with per-message DMARC-failed mail. cPanel tenants typically launch at p=none for at least 30 days to capture the per-account per- source-IP authentication-row inventory in RUA aggregate reports - the WHM-auto- generated SPF record's cPanel-server shared-outbound MTA IP block produces a baseline aligned-pass population BEFORE the tenant promotes to p=quarantine for Junk-folder routing of misaligned traffic, then to p=reject for receiver-side SMTP-time 550 enforcement. Read THIS page when PUBLISHING the per- cPanel-account _dmarc TXT record via WHM > Email Deliverability or WHM > DNS Functions; read the policy-modes spoke when CHOOSING which p=-tag value to publish at each ramp step of the per-cPanel-account DMARC-enforcement-mode progression.
• DMARC reporting pipeline (RUA aggregate-report end-to-end flow) - the PER-CPANEL-ACCOUNT RUA-AGGREGATE- EVIDENCE-STREAM-INGESTION-PIPELINE companion to this cPanel DMARC deployment guide. Where THIS page documents the per-cPanel-account per-domain DMARC publication workflow (WHM > Email Deliverability auto-generation of the _dmarc.<account-domain> TXT record with cPanel-server shared- outbound MTA IP block context, per-account WHM > DNS Functions zone-editor manual- edit path), the reporting-pipeline spoke is the per-cPanel-account per-domain end-to-end RUA-aggregate-XML evidence- stream ingestion-pipeline reference documenting the six pipeline stages each per-cPanel-account per-domain DMARC deployment's per-day RUA aggregate-XML evidence stream traverses: (1) receiver- side per-message authentication-result-row capture, (2) receiver-side per-RUA-mailbox daily aggregate-XML batching, (3) SMTP delivery from receiver-side outbound MTA to the per-cPanel-account rua= mailbox destination, (4) per-publisher RUA-aggregate-XML- parser ingestion, (5) per-cPanel-account per-source-IP per-disposition row analysis with particular attention to the cPanel-server shared-outbound MTA IP block baseline aligned-pass population and per-account third-party-ESP per- source-IP aligned-pass populations, and (6) per-cPanel-account per-domain DMARC- ramp-step tightening commit decision discipline. Read THIS page when PUBLISHING per-cPanel-account per-domain DMARC infrastructure via WHM; read the reporting-pipeline spoke when INGESTING per-cPanel-account per-domain RUA aggregate-XML evidence streams from receivers.
• 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- cPanel publication reference. Where THIS page documents the per-cPanel-account per- domain DMARC publication discipline at the per-tenant per-operator WHM Email Deliverability auto-generation workflow layer (the per-cPanel-account per-domain _dmarc.<domain> TXT-RR publication, the per-cPanel-server per- account per-domain three-mode policy- progression cadence, the per-cPanel-account per-domain rua=-mailbox routing discipline), 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- cPanel-account 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-cPanel-account per-domain DMARC publication discipline THIS page documents at the per-tenant per-operator WHM Email Deliverability 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- cPanel-account per-domain DMARC publication discipline THIS page documents at the per- tenant per-operator WHM Email Deliverability layer presupposes a per-publisher per- tenant per-operator SPF publication discipline (per-cPanel-server canonical +a +mx ~all shared-outbound-MTA 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-cPanel-account 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-cPanel-account 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- cPanel-account per-domain DMARC publication discipline THIS page documents at the WHM Email Deliverability auto-generation workflow 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 (cPanel-WHM commits DMARC TXT-RR auto-generation 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-cPanel-account per-domain DMARC infrastructure via WHM; 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-cPanel-account per-domain DMARC publication discipline THIS page documents at the per-publisher per-tenant per-operator cross-protocol-pillar publication-discipline- composition boundary.
• DKIM canonicalization — the per-cPanel-account default Exim DKIM signing-MTA canonicalization-mode publication discipline as load-bearing per-cPanel- account per-domain DKIM-signing-MTA canonicalization-mode reference companion to this DMARC-for-cPanel deployment guide. Where THIS page documents the per-cPanel- account per-domain DMARC publication flow (per-account WHM-zone-editor DNS-record publication, per-account default selector default._domainkey publication, per-account Exim-MTA signing-discipline), the DKIM canonicalization spoke documents the per-message RFC 6376 §3.4 simple-vs- relaxed body-and-header canonicalization- mode byte-normalization grammar whose per-cPanel-account default Exim c=relaxed/relaxed publication discipline is the LOAD-BEARING per-account per-domain DKIM-signing-MTA fixed canonicalization-mode reference every per- account per-domain DMARC publication deployment STRUCTURALLY DEPENDS on. Four DKIM-CANONICALIZATION-VS-CPANEL-ACCOUNT- PUBLICATION cross-correlation axes the canonicalization spoke documents: (i) per-cPanel-account default Exim DKIM signing-MTA c=relaxed/relaxed publication STRUCTURALLY DETERMINES per- account per-message body-hash recomputation consistency — every per-cPanel- account per-domain default selector default._domainkey signs per- message DKIM-Signature headers with c=relaxed/relaxed by Exim-MTA default; the per-receiver per-message bh= body-hash recomputation normalizes per-line whitespace and strips trailing empty lines BEFORE the SHA-256 body-hash recomputation, preserving the per-message body-hash through per- intermediary whitespace mutation but NOT through per-intermediary footer-injection content-mutation; (ii) per-cPanel- account default selector default._domainkey canonicalization-mode publication STRUCTURALLY GATES per-account per-domain DKIM-aligned-pass coverage-rate baseline — the per-account WHM-zone-editor DNS-publication discipline carries the per-account per-selector public-key TXT-RR whose per-message signature MUST be verifiable against the per-account Exim-MTA-fixed c=relaxed/relaxed canonicalization-mode floor; per-account operators MUST NOT attempt to override the per-Exim-MTA fixed canonicalization-mode publication discipline at the per-account WHM-MTA-configuration boundary; (iii) per-cPanel-account autoresponder forwarder intermediary mutation footprint operationally interacts with the per-Exim- MTA fixed canonicalization-mode publication discipline — per-cPanel-account per-domain autoresponder forwarder rules (vacation rules, mailbox-level forwarder rules at /etc/valiases/<domain>) re-emit per-message bodies through the per-account Exim-MTA forwarder pipeline that under c=relaxed/relaxed preserves per-message body-hash through per-line whitespace mutation but NOT through per-forwarder footer-injection content-mutation; (iv) per-cPanel- account WHM-zone-editor publication- discipline canonicalization-mode tag publication MUST match per-Exim-MTA signing-engine canonicalization-mode baseline — per-account WHM-zone- editor publication of per-selector public- key TXT-RR MUST NOT carry per-publisher per-selector h= permitted- hash-algorithm tag values that contradict the per-Exim-MTA fixed c=relaxed/relaxed canonicalization-mode publication discipline (Exim-MTA fixed a=rsa-sha256 + c=relaxed/relaxed publication baseline); per-cPanel-account per-domain operators MUST audit per-account WHM-zone- editor per-selector TXT-RR publication against the per-Exim-MTA fixed signing- engine canonicalization-mode publication discipline. Read THIS page when DEPLOYING per-cPanel-account per-domain DMARC publication infrastructure via the per- account WHM-zone-editor; read the DKIM canonicalization spoke when AUDITING the per-cPanel-account per-domain Exim-MTA- fixed canonicalization-mode publication- discipline floor whose per-account per- message body-hash recomputation reference is the LOAD-BEARING per-account per- message DKIM-signing-MTA canonicalization- mode prerequisite every per-cPanel-account per-domain DMARC deployment STRUCTURALLY DEPENDS on.
• DMARC monitoring - the per-cPanel-account per-domain DMARC-monitoring KPI dashboard as operator-console for per-account per- domain authentication-and-enforcement- discipline companion to this cPanel DMARC deployment reference. Where THIS page documents the cPanel-specific deployment workflow (WHM Email Deliverability auto-generation, the cPanel-server shared-outbound-MTA IP block, the per-tenant zone-editor manual-edit path, the per-account third-party-ESP include-cascade), the DMARC-monitoring spoke is the OPERATOR- CONSOLE REFERENCE documenting the per- cPanel-account per-domain KPI dashboard whose per-day per-receiver per-source-IP DMARC-disposition pass-rate telemetry the per-cPanel-account operator MUST track to detect per-account authentication-and-enforcement- discipline regression BEFORE it propagates into per-receiver per-day per-source-IP DMARC-disposition cliffs. Four CPANEL-TENANT-DMARC-MONITORING- KPI-DASHBOARD cross-correlation dimensions the monitoring spoke documents: (i) per-cPanel-account shared-outbound-MTA-IP attribution as upstream input to monitoring-KPI per- source-IP DMARC-disposition pass-rate baseline — the cPanel-server shared-outbound-MTA IP block (HostGator websitewelcome.com, Hostmonster hostmonster.com, per-cPanel-vendor sub- include) is the LOAD-BEARING upstream input to the per-cPanel-account per- domain DMARC-monitoring KPI per-source- IP pass-rate baseline; the DMARC- monitoring spoke documents the per-day per-receiver per-source-IP DMARC- disposition pass-rate KPI panel whose per-source-IP-attribution baseline lets the per-cPanel-account operator distinguish a per-account discipline- regression from a per-cPanel-server-IP reputation-shift the cPanel hosting operator must escalate; (ii) per-cPanel-account third- party-ESP include-cascade SPF-aligned- pass coverage-rate as upstream determinant of monitoring-KPI sustained SPF-aligned-pass baseline — the per-account third-party-ESP include- cascade (SendGrid include:sendgrid.net, Mailgun include:mailgun.org, Amazon SES include:amazonses.com, Mailchimp include:servers.mcsv.net) publication-discipline-correctness is the LOAD-BEARING upstream determinant of the monitoring-KPI sustained SPF-aligned- pass coverage-rate baseline; the DMARC- monitoring spoke documents the per-day per-receiver per-ESP-include-cascade- attribution rule the per-cPanel-account operator applies to distinguish per-ESP- include-cascade publication-discipline regression from per-day per-receiver per-source-IP legitimate-traffic-pattern shift; (iii) per-cPanel-account DKIM-signing-discipline regression as upstream cause of monitoring-KPI DKIM- aligned-pass coverage-rate cliff — a per-cPanel-account DKIM-signing- discipline regression (the per-account Exim default c=relaxed/relaxed canonicalization-mode publication- discipline-drift after a cPanel-vendor software upgrade, the per-account selector-rotation-without-overlap-window misstep, the per-account weak-key regression below the Bulk-Sender- Requirements-2024 floor) emits per-day per-receiver per-source-IP DKIM- aligned-pass coverage-rate cliffs the monitoring-KPI dashboard surfaces as the per-cPanel-account operator-side discipline-regression alarm; (iv) per-cPanel-account p=quarantine-to- p=reject ramp-advancement readiness as function of monitoring-KPI sustained pass-rate baseline stability — the per-cPanel-account per-domain ramp-advancement from p=quarantine to p=reject structurally depends on per-day per-receiver per- source-IP DMARC-pass-rate baseline stability the monitoring-KPI dashboard publishes; the DMARC-monitoring spoke documents the per-account per-domain pass-rate-baseline-vs-ramp-advancement readiness gate the per-cPanel-account operator applies BEFORE advancing the per-domain DMARC policy-mode against the per-account authentication-and- enforcement-discipline regression budget. Pair this page (the per- cPanel-account per-domain DMARC deployment reference) with the DMARC- monitoring spoke (the operator-side per-account per-domain KPI dashboard reference) when designing the per- cPanel-account per-domain DMARC- deployment-to-monitoring-KPI feedback loop — the spoke documents the per-day per-receiver per-source-IP DMARC- disposition pass-rate KPI panel whose telemetry is the operationally-grounded discipline-regression-detection stream every per-cPanel-account per-domain DMARC deployment STRUCTURALLY DEPENDS on as the operator-side per-account- per-domain authentication-and- enforcement-discipline regression- detection feedback channel.
• MTA-STS for Google Workspace — the CROSS-MAILBOX-PROVIDER-TENANT TRANSPORT-LAYER publication-tutorial peer to this cPanel APPLICATION-LAYER DMARC deployment reference. Where THIS page documents the per-cPanel- tenant per-domain DMARC + SPF + DKIM application-layer publication discipline via the WHM Email Deliverability auto- generation flow and the WHM DNS-Zone- Editor manual-edit path, the GW MTA-STS spoke documents the per-Google-Workspace- tenant per-custom-domain transport-layer MTA-STS policy-publication discipline: the _mta-sts.<d> TXT-RR version + policy ID publication, the https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file publication listing mx: *.aspmx.l.google.com (and the four Workspace backup MX hosts) as the enforced-mode MX cone, and the per-tenant mode: enforce policy-mode choice. Read the GW MTA-STS spoke as the CROSS-MAILBOX-PROVIDER- TENANT-TRANSPORT-LAYER analog of this page's per-cPanel-tenant APPLICATION- LAYER publication discipline — the two together cover the per-tenant AUTHENTICATION-LAYER and TRANSPORT- LAYER publication-disciplines a multi- mailbox-provider operator manages across a heterogeneous tenant portfolio.
• SPF forwarding issues (the second-hop break) — the SPF-FORWARDER-INDUCED-AUTHENTICATION- BREAK companion to this cPanel-tenant DMARC deployment reference. Where THIS page documents the per-cPanel-tenant DMARC publication discipline (the WHM Email Deliverability DKIM key-generation interface, the per-tenant v=spf1 include:<cpanel-shared-pool> +mx -all SPF cascade, the shared- outbound-relay envelope-MAIL-FROM rewriting behaviour, the Exim configuration discipline, the per-tenant DKIM default._domainkey RSA-2048 auto-generation cadence, the per- Reseller IP-delegation surface, and the per- tenant _dmarc.<domain> record-publication discipline), the SPF- forwarding-issues spoke is the FORWARDER-HOP- DOWNSTREAM-CONSUMER companion documenting how the per-cPanel-tenant SPF publication discipline is structurally consumed at every receiver- side forwarder hop where envelope-rewriting causes the second-hop SPF evaluation to authenticate against the forwarder's source- IP rather than the per-cPanel-tenant's shared-outbound-relay source-IP. The cPanel- deployment-vs-SPF-forwarding-issues relationship is per-cPanel-tenant-publication-discipline-as- upstream-of-per-forwarder-hop-survival: the per-cPanel-tenant SPF cascade THIS page architectures determines the original first- hop SPF verdict; the SPF-forwarding-issues spoke documents how that first-hop verdict is preserved (via DKIM-aligned-pass) or destroyed (via SPF-only-aligned-publisher + forwarder-second-hop break) when the message traverses per-recipient mailbox-rule auto- forwarders, .forward / Sieve forwarders, MLM list-expanders, or per-receiver-domain envelope- MAIL-FROM-rewriting forwarders. Four per-cPanel- tenant-vs-SPF-forwarding-break coupling dimensions matter at the per-tenant-deployment- boundary: (i) per-cPanel-tenant shared-outbound- relay envelope-MAIL-FROM rewriting at first- hop — the WHM-managed shared-relay rewrites the per-tenant envelope-MAIL-FROM to the cPanel- managed bounce-domain, so the first-hop SPF evaluation passes against the WHM-managed shared-pool include; (ii) per-cPanel-tenant DKIM-aligned-pass as load-bearing forwarder- survival primitive — when the forwarder hop destroys the per-tenant SPF-aligned-pass via envelope rewriting, the per-tenant WHM-managed default._domainkey RSA-2048 DKIM signature becomes the SOLE DMARC-aligned-pass leg surviving the forwarder hop, requiring Rule 5 (relaxed canonicalization) / Rule 6 (oversigning) / Rule 7 (dual-selector rotation overlap) discipline; (iii) per-cPanel-tenant ARC sealer trust-list participation — when a per-cPanel-tenant message traverses a forwarder that has adopted RFC 8617 ARC sealing, the per-tenant original-publisher SPF verdict can be cryptographically committed into the AAR and recovered at the second-hop receiver via chain-validation, but only if the receiver treats the forwarder as a trusted ARC sealer; (iv) per-cPanel-tenant SPF flattening coordination with forwarder-second-hop-break diagnosis — when the per-tenant SPF cascade is flattened to per-WHM-shared-pool ip4: / ip6: literals for budget compliance, the per-tenant first- hop SPF verdict stabilizes but the forwarder- second-hop break behaviour is unchanged since forwarder-hop SPF re-evaluation authenticates against the forwarder's source- IP regardless of how the per-tenant SPF cascade is composed. Read THIS page when AUTHORING the per-cPanel-tenant DMARC publication discipline at the WHM Email Deliverability interface boundary; read the SPF-forwarding-issues spoke when DIAGNOSING per-receiver per-message DMARC-fail outcomes whose root cause is the canonical forwarder- induced second-hop SPF-fail scenario the per- cPanel-tenant SPF cascade is structurally vulnerable to.
• DKIM replay attacks explained (RFC 6376 §8.6 + RFC 8617 ARC) — the DKIM-replay-attacks spoke documents the RFC 6376 §8.6 DKIM- replay threat-class whose attacker- captures-legitimately-signed-message-and- re-sends-to-arbitrary-recipients mechanic STRUCTURALLY EVADES every per-publisher per-domain DMARC p= tag value the WHM/cPanel Email Deliverability UI publishes for tenants because the replayed message carries a cryptographically valid DKIM signature aligned with the publisher's domain. Four PER-CPANEL-TENANT-PER-DOMAIN- DKIM-REPLAY-DEFENSE coupling axes the replay-attacks spoke documents: (i) per-cPanel-tenant per-domain per- selector DKIM private-key custody discipline is the LOAD-BEARING upstream operator- discipline whose regression converts a per-tenant per-domain DKIM-signing key into an attacker-replayable forgery primitive — the WHM/cPanel Email Deliverability UI generates the per-tenant DKIM key pair AT-THE-WHM-LEVEL with the private key stored in /var/cpanel/domain_keys/private/<domain> and DKIM signing performed at the Exim MTA layer; shared-hosting-pool kernel-level access boundary between co-tenants on the same physical host structurally elevates the per-tenant DKIM key compromise risk profile compared to dedicated-tenant deployments; (ii) per-cPanel-tenant per-domain per-selector key-lifetime discipline (90– 180-day rotation cadence with 7-day overlap window via WHM's Manage Keys interface) is the LOAD-BEARING operator-discipline floor whose regression extends the per-key replay window from 90 days to indefinite — tenants who default to the WHM- generated key without scheduled rotation operate per-domain DKIM keys at indefinite lifetime, structurally violating the per- key bounded-replay-window operator-discipline primitive the replay-attacks spoke catalogues; (iii) per-cPanel-tenant per-domain Exim signing-MTA configuration for the per-message x= expiration-tag publication (per RFC 6376 §3.5) is the LOAD-BEARING per-message- granularity anti-replay control whose Exim-default-OFF deployment posture leaves per-tenant per-domain DKIM signatures replayable indefinitely after origination — the WHM/cPanel Email Deliverability UI does NOT enable per-message x= expiration-tag publication by default, structurally leaving the per- tenant per-domain DKIM-signed message stream without per-message-granularity anti-replay bounding; the replay-attacks spoke documents the Exim configuration override required to engage per-message expiration-tag-based anti-replay defense at the per-tenant per- domain signing-MTA boundary; (iv) per- cPanel-tenant per-domain ARC-sealing (RFC 8617) of forwarded mail at the per-tenant per-domain inbound-relay leg is STRUCTURALLY ORTHOGONAL to but COMPLEMENTARY with the per-tenant per-domain DKIM-signing leg's anti-replay discipline — per- tenant per-domain ARC-sealing populates the receiver-side arc= verdict chain that the per-publisher per-domain DMARC evaluator consults under p=reject for ARC-trusted intermediary rescue; per-tenant per-domain ARC-sealing configuration through the WHM/ cPanel Exim configuration boundary is the per-tenant operator-discipline-floor for per-tenant per-domain trusted-forwarder- rescue and anti-replay-cascade defense. Read THIS page when AUTHORING the per- cPanel-tenant per-domain DMARC + SPF + DKIM publication workflow through the WHM/cPanel Email Deliverability UI; read the replay- attacks spoke when AUDITING the per-tenant per-domain per-selector DKIM private-key custody, key-lifetime, per-message x= expiration-tag, and ARC- sealing operator-discipline at the per- tenant per-domain anti-replay control- surface boundary.
• CAA records explained — the per-cPanel-tenant per-domain apex- zone CAA RR publication discipline is the per-publisher per-domain TLS-chain authorization-record-publication primitive that coexists with the per-cPanel-tenant per-domain apex-zone SPF / DKIM / DMARC TXT-RR publication primitive at the same authoritative DNS apex-zone publication boundary the WHM > DNS Functions > Edit DNS Zone UI mediates. Joint apex-zone SPF + DKIM-policy + DMARC-policy + CAA RR publication discipline forms the per-cPanel- tenant per-domain unified authorization-RR-class publication cadence covering the per-message envelope-MAIL-FROM authorization surface (SPF), the per-message DKIM-signature verification surface (DKIM TXT key publication), the per-publisher per-message DMARC enforcement surface (DMARC TXT policy publication), and the per-tenant X.509-certificate issuance- authority surface (CAA). Publishing all four RR classes at the same per-tenant WHM-zone-editor commit cycle is the canonical operator-side per-cPanel-tenant per-domain apex-zone authorization-RR-class deployment discipline.
• DMARC for SaaS senders — the SaaS-multi-tenant-relay companion to this cPanel-shared-hosting per-tenant per-domain DMARC publication discipline. Where THIS page documents the per-cPanel- tenant per-domain apex-zone-editor deployment workflow (WHM zone-editor + per-tenant _dmarc.<d> TXT-record + per-tenant SPF include: + per-tenant DKIM opendkim/exim integration), the SaaS-senders spoke documents the STRUCTURAL-PEER per-SaaS-vendor per- customer-domain CNAME-delegated-DMARC + SPF-include-cascade + DKIM-CNAME- delegated-selector publication discipline operators of multi-tenant relay platforms apply. The CPANEL-SHARED- HOSTING-VS-SAAS-MULTI-TENANT-RELAY cross-reference establishes FOUR coupling dimensions: (i) multi-tenant publication-substrate parallel — cPanel per-tenant WHM-zone-editor TXT-RR publication vs SaaS per-customer-domain CNAME-delegation TXT-RR publication at _dmarc.<customer-domain> → SaaS-vendor-controlled CNAME target; both topologies share the per-tenant-per-domain DNS-publication- cycle that this cPanel deployment discipline anchors at the apex-zone- editor commit boundary; (ii) per- tenant per-customer-domain DMARC-ramp- progression discipline transfer — cPanel per-tenant p=none → p=quarantine → p=reject ramp coordination at the apex-zone-editor commit cycle parallels the SaaS per- customer-domain CNAME-delegated DMARC ramp via the SaaS-vendor's policy publication interface; the SaaS spoke documents the per-customer per- SaaS-vendor ramp coordination discipline; (iii) per-tenant DKIM-key-rotation cadence transfer — cPanel per-tenant opendkim/exim per-tenant per-selector key rotation cadence parallels the SaaS per-customer-domain DKIM-CNAME-delegated- selector rotation cadence the SaaS-vendor manages; the SaaS spoke documents the per-customer per-vendor rotation discipline that transfers directly from this cPanel per-tenant rotation workflow; (iv) per- tenant aggregate-report consumption discipline transfer — cPanel per-tenant rua= mailbox aggregation parallels the SaaS per-customer-domain aggregate- report consumption pattern the SaaS-vendor's DMARC-as-a-service offering provides; the SaaS spoke documents the per-customer per-vendor aggregate-consumption discipline whose per-tenant operational visibility this cPanel deployment workflow anchors at the apex-zone-editor commit boundary. Read the SaaS-senders spoke alongside this cPanel shared-hosting reference when operating a multi-tenant relay platform with cross-topology per- customer-domain DMARC publication discipline.
• SPF PermError vs TempError Four per-cPanel-tenant SPF-error-mode root-cause dimensions: (i) cPanel-shared-outbound-relay include:<hosting-vendor-pool> at the per-tenant SPF apex publication baseline as RFC 7208 §4.6.4 ten-DNS-query budget consumer — every cPanel-tenant operator publishes include:<cpanel-vendor-shared-relay-pool> as the foundational shared-outbound authorisation token, which consumes 2-5 DNS queries depending on the per-cPanel-vendor include cascade depth (typical: 3 DNS queries for the vendor-managed apex include + 1-2 queries per supplementary nested include), leaving only 5-8 DNS queries remaining for per-customer-tenant supplementary include:<esp-pool> tokens (SendGrid / Mailgun / Amazon SES / Postmark / Mailjet) before per-receiver evaluation produces spf=permerror; (ii) per-cPanel-tenant zone-editor authoring multi-record SPF publication producing permerror from RFC 7208 §3.2 one-SPF-record-per-domain constraint violation — the cPanel zone-editor UI does NOT prevent the per-tenant operator from publishing TWO v=spf1 ... TXT records at the per-customer-domain apex (one published by the cPanel vendor's auto-config, one published by the operator after acquiring an ESP), which the per-receiver evaluator interprets as RFC 7208 §3.2 violation producing permerror regardless of the individual records' grammatical correctness; (iii) cPanel-shared-IP-pool reputation-cohort interaction with per-receiver spf=temperror retry behaviour — when a co-tenant on the cPanel shared-outbound-IP-pool produces per-receiver-side DNS-resolver rate-limiting or anti-abuse query-throttling against the per-tenant SPF-record DNS endpoint, OTHER co-tenants on the same shared-IP cohort experience correlated spf=temperror retry spikes — a cross-tenant SPF-error-mode amplification class the per-tenant operator must coordinate diagnosis for; (iv) per-cPanel-tenant DMARC ramp gating on spf=permerror/temperror RUA-row attribution — the cPanel-tenant DMARC ramp (p=none → p=quarantine pct=10 → p=reject) gating on per-tenant per-receiver per-source-IP RUA evidence requires per-row attribution of spf=permerror rows (operator-side investigation required) vs spf=temperror rows (transient receiver-side outage, likely self-resolving) to avoid stalling the per-tenant ramp on per-row evidence that does not require operator-side remediation. Read the SPF-permerror-vs-temperror spoke alongside this cPanel DMARC deployment reference when the per-cPanel-tenant operator is investigating per-customer-domain RUA-attributed spf=permerror rows, when planning the per-tenant cPanel include-chain expansion against the RFC 7208 §4.6.4 ten-DNS-query budget, or when authoring the per-cPanel-tenant DMARC-ramp playbook with concurrent SPF-error-mode RUA-row attribution discipline.
• TLS-RPT record syntax explained — the RFC 8460 §3 _smtp._tls.<domain> TXT-record byte-grammar reference covering the v=TLSRPTv1 version-token prefix, the rua=mailto: / rua=https:// per-publisher per-domain reporting-endpoint-token publication, and the per-publisher per-domain transport-layer observability reporting-channel registration discipline. THIS page documents the per-cPanel-tenant per-customer-domain DMARC publication workflow at the WHM Email Deliverability auto-generation + cPanel DNS Zone Editor commit cadence (per-tenant SPF / DKIM / DMARC TXT-record publication primitives, per-cPanel-server shared-outbound-MTA IP-block baseline, per-account Exim default._domainkey TXT publication contract, per-Forwarders-feature alias-loop SPF-leg-failure surface); the TLS-RPT-record-syntax spoke is the per-cPanel-tenant per-customer-domain TRANSPORT-LAYER OBSERVABILITY TXT-record publication peer documenting the per-publisher per-domain RFC 8460 §3 _smtp._tls.<d> TXT-record byte-grammar token catalogue (v=TLSRPTv1; rua=mailto: terminal-mailbox-endpoint token, rua=https:// JSON-POST-endpoint token, the ; per-token delimiter discipline at the RFC 8460 §3 record-grammar level) authored at the per-cPanel-tenant zone-editor commit boundary alongside the per-tenant SPF + DKIM + DMARC TXT-record publication. Both the per-cPanel-tenant DMARC-publication workflow and the per-cPanel-tenant TLS-RPT-record publication share the per-publisher per-customer-domain WHM Email Deliverability + cPanel Zone Editor commit substrate, the per-tenant operator-side authoring discipline, and the per-tenant rotation-aware DNS-propagation overlap-window operational cadence — the per-cPanel-tenant DMARC publication AUTHORS the per-tenant message-authentication composite-policy + RUA-endpoint registration at the per-customer-domain apex and the per-cPanel-tenant TLS-RPT publication AUTHORS the per-tenant transport-layer STARTTLS-chain-validation observability reporting-channel-endpoint at the per-customer-domain _smtp._tls.<d> underscore-prefixed subdomain. Read the TLS-RPT-record-syntax spoke alongside this cPanel DMARC deployment reference when authoring the per-cPanel-tenant per-customer-domain DNS-zone-file commit batch that publishes BOTH the per-tenant SPF / DKIM / DMARC TXT records AND the per-tenant TLS-RPT record as the unified per-cPanel-tenant per-customer-domain message-authentication + transport-layer-observability dual-TXT-RR publication discipline at the WHM Zone Editor commit boundary.
• DKIM failures explained — the PER-CPANEL-TENANT-PER-DOMAIN- DKIM-FAILURE-ROOT-CAUSE companion to this cPanel DMARC deployment reference. Where THIS page documents the per-cPanel-tenant per-domain DMARC publication discipline at the WHM Email Deliverability auto-generation + cPanel DNS Zone Editor commit cadence (per- tenant SPF / DKIM / DMARC TXT-record publication primitives, per-cPanel-server shared-outbound-MTA IP-block baseline, per- account Exim default._domainkey TXT publication contract), 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- cPanel-tenant per-domain DMARC ramp gates on. FOUR per-cPanel-tenant per-domain DKIM-failure root-cause dimensions: (i) per-cPanel-tenant per-domain WHM/cPanel-default default._domainkey selector-name publication discipline as load-bearing root cause of cross-tenant DKIM-selector-collision and per-receiver dkim=permerror verdicts — every cPanel tenant defaults to the single canonical selector name default._domainkey via WHM's Email Deliverability UI, producing a cluster-wide single-selector posture across the cPanel-vendor's entire tenant base; per- domain rotation past the default selector requires per-tenant operator intervention through the WHM 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-cPanel-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 WHM/cPanel installations default-generate RSA-1024-bit DKIM keys (smaller-than-RFC-8301-recommended 2048-bit floor), 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 WHM Manage Keys interface to the 2048-bit floor; (iii) per-cPanel-tenant per-domain Exim canonicalization-mode default (c=simple/simple) vs RFC 6376 §3.4-recommended c=relaxed/relaxed producing per-receiver dkim=fail body-hash-mismatch verdicts on legitimately-modified mail — per-tenant Exim DKIM signing configurations defaulting to c=simple/simple canonicalization produce per-receiver dkim=fail body-hash-mismatch verdicts when downstream relays normalize whitespace, append RFC 5322 Received headers, or convert line endings; the DKIM-failures spoke catalogues the body- hash-mismatch failure class whose per-tenant per-domain remediation requires the Exim signing config canonicalization-mode override to c=relaxed/relaxed; (iv) per-cPanel-tenant shared-IP-pool co-tenant DKIM-key compromise as cross-tenant per-domain dkim=fail revoked-key verdict amplification surface — when a co-tenant on the cPanel shared-physical- host suffers per-tenant DKIM private-key compromise (filesystem read of /var/cpanel/domain_keys/private/<domain> from a colocated tenant), the per-publisher per-domain revocation-via-empty-p= publication produces per-receiver dkim=fail "revoked key" verdicts across the per-tenant per-domain message stream the DKIM-failures spoke catalogues at the per-tenant per-domain operator-discipline boundary the WHM/cPanel Email Deliverability UI mediates. Read the DKIM-failures-explained spoke alongside this cPanel DMARC deployment reference when DIAGNOSING per-receiver per-day per-cPanel-tenant per-domain dkim=permerror / dkim=fail / dkim=neutral RUA-attributed evidence rows correlating with a per-tenant per-domain WHM Manage Keys interface commit, when PLANNING the per-tenant per-domain DKIM- selector rotation cadence with explicit per- receiver propagation-window-floor coordination, or when AUDITING the per-cPanel-tenant per- domain Exim 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.
• MX records explained — the CPANEL-MX-RR-AS-INBOUND-MAIL- AND-RUA-RUF-DELIVERY-PREREQUISITE companion to this cPanel DMARC deployment reference. Where THIS page documents the cPanel-tenant DMARC TXT-record publication workflow (WHM Email Deliverability auto-generation, the cPanel shared-outbound MTA IP block, the WHM Edit DNS Zone manual MX/SPF/DKIM/DMARC coordination), the MX-records spoke is the APEX-MX-RR-PUBLICATION reference cPanel tenants consult when verifying the apex MX RRset on the publisher domain remains continuously resolvable so receiver-generated aggregate (RUA) and forensic (RUF) reports the cPanel tenant's DMARC record requests can actually be delivered back to the tenant mailbox. The MX-RR-byte-syntax-and-preference- ordering cross-reference is structurally load-bearing: every cPanel WHM Edit DNS Zone MX-record edit that drops the apex MX RRset, mis-orders the preference values, or points the highest-preference MX at a non-resolvable host silently breaks BOTH inbound mail delivery (the receiver's MX query fails before SMTP is attempted) AND the publisher's per-domain DMARC reporting loopback (the receiver-side report-generation cron cannot deliver to a publisher mailbox whose MX is unresolvable), turning the publisher's rua= / ruf= tags into silently-discarded configurations and dropping the DMARC observability the publisher relies on to gate the p=none → p=quarantine → p=reject policy ramp this cPanel deployment workflow documents.
• DMARC myths and misconceptions — the PER-CPANEL-TENANT-PER-DOMAIN- OPERATOR-SIDE-DMARC-MISTAKE-PATTERN-AS- PER-PUBLISHER-PER-DOMAIN-MYTH-CATALOGUE- LOOKUP-REFERENCE companion to THIS per-cPanel-tenant per-custom-domain DMARC deployment workflow reference. Where THIS page documents the per-cPanel-tenant per- custom-domain operator-side DMARC deployment workflow (the per-tenant cPanel Zone-Editor TXT-RR publication discipline coordinating per-tenant SPF v=spf1 +a +mx include:_spf.<cpanel- host> ~all record, per-tenant DKIM default._domainkey selector publication via WHM Email- Deliverability tooling, per-tenant DMARC _dmarc.<custom-domain> record with operator-selected p= tier + rua=/ ruf= mailbox publication, and the per-tenant per-custom-domain cron- delivered RUA-mailbox observability pipeline), the DMARC-myths-and- misconceptions spoke documents the per- publisher per-domain operator-side misconception-and-mistake-pattern catalogue the per-cPanel-tenant operator MUST consult at FOUR per-cPanel-tenant-vs-DMARC- myth-catalogue coupling dimensions: (i) per-cPanel-tenant per-custom- domain SPF mechanism-choice mistake- pattern lookup as per-publisher per-domain SPF-mythbusting catalogue consultation — per-cPanel-tenant operators commonly adopt the "+all is a valid permissive qualifier" or "~all is equivalent to -all" or "include:-cascade depth has no bound" SPF misconceptions during per- tenant per-custom-domain SPF record- authoring, and the DMARC-myths-and- misconceptions spoke's SPF-specific mythbusting entries (per-mechanism per- qualifier semantics, the RFC 7208 §4.6.4 ten-DNS-lookup permerror cap, the per- publisher per-domain SPF-aligned-pass- rate vs DMARC-aligned-pass-rate distinction) IS the per-publisher per- domain canonical pre-flight per-tenant per-custom-domain SPF record-authoring audit reference the per-cPanel-tenant operator MUST consult BEFORE per-tenant SPF record commit; (ii) per- cPanel-tenant per-custom-domain DKIM- selector publication mistake-pattern lookup as per-publisher per-domain DKIM- mythbusting catalogue consultation — per-cPanel-tenant operators commonly adopt the "DKIM signs message body alone" / "DKIM p= tag in DNS is same as DMARC p= tag" / "DKIM selectors are per-domain not per-key" DKIM misconceptions during per-tenant per-custom-domain DKIM record-authoring, and the DMARC-myths-and-misconceptions spoke's DKIM-specific mythbusting entries provide the per-publisher per-domain canonical pre-flight per-tenant per- custom-domain DKIM-selector-publication audit reference; (iii) per- cPanel-tenant per-custom-domain DMARC p= policy-tier mistake- pattern lookup as per-publisher per- domain DMARC-mythbusting catalogue consultation — per-cPanel-tenant operators commonly adopt the "p=reject is the default starting point" / "subdomain inherits parent p= automatically" / "p=none is wasted time" / "pct= partial enforcement does not affect aggregate-report attribution" DMARC misconceptions during per-tenant per-custom-domain DMARC-record authoring, and the DMARC-myths-and-misconceptions spoke's DMARC-specific mythbusting entries provide the per-publisher per-domain canonical pre-flight per-tenant per- custom-domain DMARC-record audit reference the per-cPanel-tenant operator MUST consult BEFORE per-tenant DMARC record commit; (iv) per-cPanel-tenant per-custom-domain RUA/RUF observability- pipeline mistake-pattern lookup as per- publisher per-domain reporting-mythbusting catalogue consultation — per- cPanel-tenant operators commonly adopt the "DMARC reports are real-time" / "RUA reports include message bodies" / "RUF forensic reports are sent for every failure" / "rua= mailbox can be on the same domain without DNS-coordination" DMARC reporting misconceptions during per- tenant per-custom-domain RUA/RUF observability-pipeline setup, and the DMARC-myths-and-misconceptions spoke's reporting-pipeline mythbusting entries provide the per-publisher per-domain canonical pre-flight per-tenant per- custom-domain observability-pipeline- coordination audit reference. Read THIS per-cPanel-tenant per-custom-domain DMARC deployment workflow when EXECUTING the per-tenant SPF + DKIM + DMARC record- authoring workflow AND when COORDINATING the per-tenant per-custom-domain operator- discipline floor against the per-publisher per-domain operator-side mistake-pattern catalogue; read the DMARC-myths-and- misconceptions spoke when AUDITING the per-tenant per-custom-domain operator- side mistake-pattern catalogue lookup BEFORE per-tenant per-custom-domain record- publication commit THIS page documents.
• TLS-RPT report format (RFC 8460 §4 JSON-aggregate schema) — the per-receiver per-publisher per-day RFC 8460 §4 TLS-RPT JSON-aggregate-report byte-grammar reference companion to this cPanel per-tenant per-custom-domain DMARC deployment playbook. Where THIS page documents the per-cPanel-tenant per- custom-domain SPF + DKIM + DMARC composite- publication discipline (the per-tenant provider-specific SPF include: mechanisms — Bluehost / HostGator / SiteGround / A2 Hosting / GoDaddy / Namecheap / Hostinger / InMotion — the per-tenant Exim/OpenDKIM signer DKIM TXT-RR or CNAME publication, the per- tenant per-custom-domain DMARC TXT-RR publication, the per-tenant per-shared-IP- pool egress isolation discipline, the per- tenant per-custom-domain forwarder-induced envelope-rewriting recovery via DKIM- aligned-pass + ARC chain preservation), the TLS-RPT report-format spoke documents the structurally parallel per-publisher per-domain transport-layer JSON-aggregate- report byte-grammar whose result-type enum (starttls-not-supported, certificate-host- mismatch, certificate-expired, certificate- not-trusted, validation-failure, sts- policy-fetch-error) IS the per-cPanel- tenant per-custom-domain transport-layer STARTTLS-handshake-observability primitive. Four per-shared-hosting per-tenant per- custom-domain TLS-egress-vs-TLS-RPT- failure-class coupling dimensions matter at the per-cPanel-tenant per-custom-domain composite authentication-and-transport- layer deployment boundary: (i) per-cPanel- tenant per-shared-IP-pool TLS-handshake success-rate — the per-cPanel-tenant per- shared-IP-pool Exim outbound transport executes per-message STARTTLS negotiation against per-recipient mailbox-provider MX endpoints; per-shared-IP-pool TLS- handshake failures (legacy TLS versions, expired or self-signed certificates on the shared MX, broken cipher suites) contaminate per-tenant per-custom-domain TLS-encryption-rate KPI surfaced by Gmail Postmaster Tools / Outlook SNDS at the per-cPanel-tenant per-custom-domain deliverability boundary; the per-publisher per-domain TLS-RPT publication the report- format spoke documents IS the load-bearing per-cPanel-tenant per-custom-domain transport-layer observability feed-back- channel that surfaces these per-shared-IP- pool TLS-handshake failures; (ii) per- cPanel-tenant per-custom-domain HTTPS-vs- SMTP TLS-RPT publication coexistence — the per-cPanel-tenant per-custom-domain operator publishes the per-domain _smtp._tls.<domain> TXT- RR at the per-tenant per-custom-domain zone-file via the cPanel Zone Editor or WHM DNS Zone Editor alongside the per- custom-domain SPF + DKIM + DMARC publications THIS page documents; (iii) per-cPanel-tenant per-custom-domain forwarder-egress observability — per- cPanel-tenant forwarders (Email Forwarders feature, .forward file delegation, Mail Routing rules) re-emit per-tenant per-custom-domain inbound mail as per-tenant per-shared-IP-pool egress traffic to per-receiver MX endpoints; per-receiver-side STARTTLS-handshake failures on the per-cPanel-tenant forwarder-egress hop surface as TLS-RPT JSON-aggregate-report failure-events the report-format spoke documents byte-grammar for; (iv) per-cPanel-tenant per-custom- domain composite authentication-and- transport-layer publication portfolio — the per-cPanel-tenant per-custom-domain composite SPF + DKIM + DMARC + ARC + MTA- STS + TLS-RPT publication portfolio THIS page's authentication-protocol-publication component IS the load-bearing per-tenant per-custom-domain envelope-and-application- layer publication primitive, while the TLS-RPT report-format spoke's transport- layer per-day per-receiver observability feed IS the load-bearing per-tenant per- custom-domain transport-layer egress- stack-health evidence stream every per- cPanel-tenant per-custom-domain composite publication-and-observability discipline consumes at the per-publisher per-domain publication-portfolio coordination floor. Read THIS page when AUTHORING the per- cPanel-tenant per-custom-domain SPF + DKIM + DMARC composite publication; read the TLS-RPT report-format spoke when EVALUATING the per-publisher per-day per- receiver transport-layer STARTTLS- handshake-failure JSON-aggregate-report evidence stream every per-cPanel-tenant per-custom-domain composite publication- and-transport-layer observability discipline depends on for per-publisher per-domain composite shared-hosting- tenant-and-transport-layer publication- portfolio-coordination floor.
• Email security & privacy glossary — the cross-protocol security-and- privacy threat-and-defense vocabulary registry consumed at four per-shared- hosting per-tenant deployment-context vs threat-catalogue coupling dimensions.
• DKIM alignment with DMARC
• SPF qualifiers explained — the per-publisher per-domain SPF qualifier-prefix envelope-MAIL-FROM-layer authorization-discipline companion at four per-cPanel-tenant per-custom-domain SPF-qualifier-prefix-vs-shared-hosting-DMARC-deployment coupling dimensions: (i) per-cPanel-tenant per-custom-domain SPF terminal-qualifier publication-decision -all strict-fail vs ~all softfail per RFC 7208 §4.6.2 IS the load-bearing per-tenant per-custom-domain envelope-MAIL-FROM-layer enforcement-floor publication-decision whose per-receiver per-message SPF-aligned-pass discipline feeds the per-tenant per-custom-domain DMARC composite-aligned-pass-rate floor preservation against shared-IP-pool cross-tenant verdict-noise the shared-hosting DMARC-deployment THIS page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of; (ii) per-cPanel-tenant per-custom-domain SPF qualifier-prefix publication-decision matrix discipline (typically published as v=spf1 include:<hosting-provider-spf-macro> ~all at per-tenant DNS-publication time) IS the load-bearing per-tenant per-custom-domain envelope-MAIL-FROM-layer authorization-discipline whose per-receiver per-message SPF-aligned-pass verdict feeds per-tenant per-custom-domain DMARC composite-aligned-pass-rate floor the per-cPanel hosting page documents per-tenant per-custom-domain authentication-discipline of; (iii) per-cPanel-tenant per-custom-domain SPF ~all softfail terminal-qualifier publication-decision IS the per-tenant per-custom-domain ramp-readiness envelope-MAIL-FROM-layer enforcement-floor publication-discipline whose per-receiver per-day DMARC RUA policy_evaluated/spf attribution-row evidence stream the per-cPanel hosting page documents the per-tenant per-custom-domain operator-actionable ramp-progression decision-discipline of consumes for the per-tenant per-custom-domain DMARC p=none → p=quarantine → p=reject enforcement-mode-publication-decision ramp-discipline gating; (iv) per-cPanel-tenant per-custom-domain SPF qualifier-prefix mechanism-class publication-discipline drift (per-tenant SPF include:-cascade-target drift / per-tenant SPF ~all-stuck publication-discipline drift / per-tenant SPF -all-premature-cutover under shared-IP-pool egress-IP overlap with cross-tenant publishers) directly opens per-tenant per-custom-domain DMARC composite-aligned-pass-rate floor regression that the per-cPanel hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM dual-leg authentication-leg-OR-conjunction publication-discipline of structurally depends on for per-tenant per-custom-domain DMARC ramp-readiness preservation.
• MTA-STS policy file syntax — the PER-PUBLISHER-PER-POLICY-DOMAIN-MTA-STS-POLICY-FILE-MX-LINE-MX-PATTERN-PUBLICATION-DECISION-AS-LOAD-BEARING-TRANSPORT-LAYER-PER-MX-HOST-AUTHORIZATION-DISCIPLINE-FOR-PER-CPANEL-TENANT-SHARED-EXIM-MTA-CLUSTER-EGRESS-COORDINATION companion at four per-cPanel-tenant per-custom-domain MTA-STS-policy-file-vs-shared-hosting-DMARC-deployment coupling dimensions: (i) per-cPanel-tenant per-custom-domain MTA-STS policy-file mx: MX-pattern publication-discipline per RFC 8461 §3.2 MUST encompass all per-tenant per-cPanel-cluster shared-MX hosts (typically mx: *.<hosting-provider>.com single-label-wildcard covering all per-tenant shared-cPanel-WHM-server-hostnames) IS the load-bearing per-tenant per-custom-domain transport-layer per-MX-host authorization-discipline whose per-receiver per-MX-host STARTTLS-required-or-fail enforcement-verdict preserves per-tenant per-custom-domain envelope-byte-stream-integrity baseline against MITM downgrade-attack-class at shared-Exim-MTA cluster egress; (ii) per-cPanel-tenant per-custom-domain MTA-STS policy-file mode: testing → mode: enforce two-stage transport-layer policy-mode publication-discipline ramp per RFC 8461 §5 IS structurally parallel to per-tenant per-custom-domain DMARC p=none → p=quarantine → p=reject three-stage application-layer policy-mode publication-discipline ramp per RFC 7489 §6.3 — both per-tenant per-custom-domain progressively-stricter policy-mode-publication ramps gate on per-receiver per-day per-source-IP / per-MX-host evidence-driven readiness metrics the per-cPanel hosting DMARC-deployment THIS page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of; (iii) per-cPanel-tenant per-custom-domain MTA-STS policy-file max_age: cache-lifetime publication-decision per RFC 8461 §3.2 (max 31557600 seconds = 1 year) drives per-receiver-side per-tenant per-MX-host policy-cache-coherence cadence whose per-tenant per-custom-domain transport-layer policy-cache-stability publication-discipline cascades into per-tenant per-custom-domain composite cross-protocol cross-layer publication-discipline-stability floor the per-cPanel hosting DMARC-deployment THIS page documents the per-tenant per-custom-domain operational-discipline of; (iv) per-cPanel-tenant per-custom-domain MTA-STS policy-file byte-grammar publication-discipline drift (BOM-prefix mis-publication / inline-comment mis-publication / wildcard-label crossing single-label-budget / max_age: exceeding 31557600-second ceiling / per-tenant per-cPanel-cluster shared-MX-host omission from mx:-line-list) surfacing in per-tenant per-policy-domain TLS-RPT JSON-aggregate-report failure-type: sts-policy-invalid attribution per RFC 8460 §4.3 directly opens per-tenant per-custom-domain transport-layer per-MX-host authorization-discipline-floor regression cascading into per-tenant per-custom-domain composite cross-protocol DMARC-aligned-pass-rate floor preservation regression the per-cPanel hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of structurally depends on at the per-cPanel-tenant per-custom-domain composite cross-protocol cross-layer per-MX-host publication-discipline-and-shared-hosting-deployment coordination boundary.
• DKIM for Google Workspace — the PER-WORKSPACE-TENANT-PER-ACCEPTED-DOMAIN-DKIM-SINGLE-SELECTOR-TXT-PUBLICATION-AS-STRUCTURALLY-PARALLEL-APPLICATION-LAYER-DKIM-PUBLICATION-DISCIPLINE-REFERENCE-TO-PER-CPANEL-TENANT-PER-CUSTOM-DOMAIN-DEFAULT-DOMAINKEY-TXT-PUBLICATION companion at four per-Workspace-tenant-vs-per-cPanel-tenant per-accepted-domain DKIM-TXT-publication-discipline coupling dimensions: (i) per-Workspace-tenant per-accepted-domain DKIM google._domainkey.<accepted-domain> TXT-RR publication-discipline IS structurally parallel hosted-mailbox-provider per-tenant per-accepted-domain application-layer DKIM publication-discipline reference to per-cPanel-tenant per-custom-domain default._domainkey.<custom-domain> TXT-RR publication-discipline THIS page documents at canonical Step 2 (verify DKIM at the default._domainkey selector) — both per-hosted-tenant per-accepted-domain hosting-provider-managed-publication-vs-operator-controlled-publication-discipline references coordinate at the per-hosted-tenant per-accepted-domain application-layer DKIM publication-discipline coordination boundary; (ii) per-Workspace-tenant per-accepted-domain DKIM operator-controlled manual rotation cadence (Admin Console operator-driven 2048-bit RSA key-regeneration + manual cut-over discipline) IS structurally parallel hosted-mailbox-provider per-tenant per-accepted-domain DKIM-rotation cadence reference to per-cPanel-tenant per-custom-domain DKIM-rotation cadence whose per-cPanel-tenant operator-controlled WHM/cPanel DKIM-regeneration workflow THIS page documents the per-tenant per-custom-domain DKIM publication-discipline operator-control of — both per-hosted-tenant per-accepted-domain operator-controlled-rotation cadence references jointly contribute to per-tenant per-accepted-domain DKIM-aligned-pass-rate floor preservation across rotation events; (iii) per-Workspace-tenant per-accepted-domain DKIM c=relaxed/relaxed canonicalization-mode default per RFC 6376 §3.4.2 IS structurally parallel canonicalization-mode-publication discipline reference to per-cPanel-tenant per-custom-domain DKIM c=relaxed/relaxed canonicalization-mode publication discipline THIS page documents implicitly via the per-cPanel-tenant per-custom-domain DKIM-verdict-stability-under-shared-Exim-MTA-rewrite-cascade discipline at Step 2 — both per-hosted-tenant per-accepted-domain canonicalization-mode-publication discipline references jointly tolerate per-forwarder-class header-folding mutation preserving per-tenant per-accepted-domain DKIM-verdict stability; (iv) per-Workspace-tenant per-accepted-domain DKIM single-selector model contrasts with per-cPanel-tenant per-custom-domain DKIM single-selector default._domainkey publication model documented HERE, with structural parallel at the per-hosted-tenant per-accepted-domain mailbox-provider-managed-vs-shared-hosting-managed application-layer DKIM-publication-discipline coordination boundary — the per-hosted-tenant per-accepted-domain DKIM-for-Workspace operator reference documents the per-Workspace-tenant deployment companion to the per-cPanel-tenant per-custom-domain shared-hosting DMARC-deployment THIS page documents, jointly covering the per-hosted-tenant per-accepted-domain mailbox-provider-managed-vs-shared-hosting-managed application-layer authentication-discipline publication-discipline spectrum.
• BIMI logo SVG requirements — BIMI is the reward for finishing the cPanel deployment this page walks through. A cPanel tenant only earns inbox logo display after its custom domain reaches DMARC enforcement (p=quarantine/p=reject) with a sustained aligned-pass over the shared-Exim egress; once you are there, publish the BIMI record and fit the SVG asset to the Tiny PS rules documented on this spoke before browsers will render it.
• MTA-STS explained — the transport-layer hardening a cPanel tenant should publish once the DMARC ramp on this page reaches enforcement. DMARC closes the message-layer spoofing surface; MTA-STS closes the transport-layer STARTTLS-stripping downgrade surface by committing your shared-Exim MX to authenticated TLS — read the MTA-STS primer to add the transport leg to the per-custom-domain posture this cPanel deployment establishes.
• 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 cPanel 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 cPanel hosting.

Sign up — Free plan Check my cPanel domain