How to set up DMARC/DKIM/SPF for Pecorari Cloud
Published 17 Aug 2026
Updated 23 Oct 2026
13 min read
Summarize with
Updated on 23 Oct 2026: We updated the Pecorari Cloud setup steps for current DMARC enforcement and added external report authorization checks.
For Pecorari Cloud shared hosting, add the domain in cPanel, open Email Deliverability, install or copy the account-specific SPF and DKIM records, then publish one DMARC TXT record at _dmarc. Pecorari Cloud does not have one safe universal SPF include or DKIM value for every server, so the values shown in your own cPanel account are authoritative.
On a self-managed Pecorari Cloud VPS or dedicated server, generate DKIM in the mail transfer agent, authorize the actual outbound IPv4 or IPv6 address in SPF, and ask Pecorari Cloud to set the PTR for a dedicated IP. DMARC passes when SPF or DKIM passes with a domain that has DMARC alignment with the visible From domain.
Keep existing working records
Do not replace an existing SPF record without merging every legitimate sender. Do not lower an existing DMARC policy of p=quarantine or p=reject to p=none.
Check your domain and DNS
Pecorari Cloud web-hosting accounts expose cPanel through the customer area. The primary domain is normally attached when the hosting account is provisioned. Add another sending domain only when it is absent from cPanel.
- Open the account. Sign in to the Pecorari Cloud customer area, open the active hosting service, and choose the cPanel login action.
- Check Domains. Open Domains in cPanel and confirm that the exact domain used after the @ sign exists. Use Create A New Domain only when it is missing.
- Find authoritative DNS. Check the domain's authoritative nameservers. Edit cPanel Zone Editor only when it manages the active DNS zone. Otherwise, copy the required cPanel-generated records to the authoritative DNS provider.
- Confirm mail routing. Open Email Routing. Choose Local Mail Exchanger only when Pecorari Cloud hosts the inboxes. Choose Remote Mail Exchanger when another system receives mail.
- Use authenticated SMTP. Configure the hosted site or application to authenticate with its Pecorari Cloud mailbox. Use the SSL/TLS host and port shown under Email Accounts > Connect Devices, with the full email address as the username. Set the visible From address and envelope sender to the same organizational domain.
Pecorari Cloud hosting account with cPanel access highlighted
VPS and dedicated servers
A self-managed server does not gain mail authentication merely because the domain points at Pecorari Cloud. Configure the mail transfer agent first, then publish the records it generates. For a dedicated sending IP, use a hostname whose A or AAAA record points to that IP and request a matching PTR.
Set up SPF
SPF (Sender Policy Framework) authorizes sending IP addresses for the envelope-sender domain, also shown as smtp.mailfrom or Return-Path. In cPanel, open Email Deliverability, find the domain, and choose Manage. Use the Suggested SPF Record for your account's sending server.
If cPanel controls DNS, review the suggested changes before using Repair or Install the Suggested Record. If DNS is external, copy the TXT host and value exactly. Keep one SPF record per envelope-sender domain and merge all authorized senders before the final all mechanism. ~all returns softfail for unmatched senders; -all returns fail. Neither setting guarantees delivery or rejection.
- Copy the suggestion. Use the SPF value shown for the domain in Email Deliverability. Do not guess a Pecorari Cloud include domain.
- Publish at the envelope-sender domain. For an envelope sender at example.com, publish at the root, commonly entered as @. A return path at bounce.example.com needs SPF at bounce.example.com; SPF is not inherited from the parent domain.
- Keep one record. Combine mechanisms into one v=spf1 value. Two SPF TXT records cause PermError and make SPF unusable.
- Check the lookup budget. Keep SPF within ten DNS-querying terms per evaluation, counting nested includes and redirect. ip4, ip6, and all do not use this budget. Remove stale authorizations and check the complete lookup chain. RFC 7208 defines the limit.
- Set the return path. When the site or application supports an envelope-sender setting, use a mailbox or bounce subdomain within the same organizational domain as the visible From address. Confirm smtp.mailfrom in a delivered message; do not add a Return-Path header manually.
Pecorari Cloud cPanel Email Deliverability SPF controls
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the check after DNS updates. The result must show one syntactically valid SPF record and no lookup-limit error. A pass alone is not enough for DMARC: the smtp.mailfrom domain in the message headers must share the organizational domain used in the visible From address.
Some applications do not expose a return-path setting. In that case, expect SPF alignment errors when the envelope sender uses a Pecorari Cloud server hostname. This is acceptable only when DKIM passes and its d= domain has DMARC alignment with the visible From domain.
Set up DKIM
DKIM (DomainKeys Identified Mail) can preserve a DMARC pass through forwarding when SPF breaks, provided the signed content remains intact. cPanel generates a private key on the server; publish only its public key in DNS. Never use a key copied from another account. The cPanel documentation explains key generation and record publishing.
- Open the domain. In cPanel, open Email Deliverability, locate the sending domain, and choose Manage.
- Install the key. If no key exists, choose Generate Local DKIM Key first. Use Repair when cPanel controls authoritative DNS. For external DNS, copy the Suggested DKIM Record name and TXT value to the active DNS zone.
- Preserve the selector. Use the selector shown by cPanel, often default. In a sent message, s= identifies the selector and d= identifies the signing domain. During rotation, retain the old public key while previously signed messages remain in transit.
- Avoid broken quoting. Use cPanel's Full or Split value as required by the DNS editor. Split strings must remain in one TXT record and concatenate without spaces inside the p= public key.
- Confirm signing. Send through the actual mailbox, website, or application. Confirm dkim=pass and a d= domain that shares the visible From address's organizational domain under relaxed DMARC alignment. Strict alignment requires an exact domain match.
DKIM record shape onlydns
default._domainkey.example.com. IN TXT ("v=DKIM1; k=rsa; " "p=PUBLIC_KEY_FROM_CPANEL")
Pecorari Cloud cPanel DKIM record and repair action
Self-managed mail servers
Generate a separate 2048-bit DKIM key in the mail transfer agent, publish its public key under selector._domainkey, and keep the private key readable only by the signing service. cPanel's key does not configure a separate mail server.
Set up DMARC
Publish DMARC (Domain-based Message Authentication, Reporting, and Conformance) after SPF or DKIM is active. Start new deployments at p=none to request reports without requesting quarantine or rejection for DMARC failures. Receivers still apply their own filtering. If the domain already has p=quarantine or p=reject, keep that stronger policy and correct authentication beneath it.
Create a TXT record at _dmarc. Replace the example reporting mailbox with an address that accepts aggregate XML reports, or use the DMARC record generator to build the value. Keep exactly one DMARC record at that hostname.
Starting DMARC recorddns
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
- Open Zone Editor. Use cPanel Zone Editor when Pecorari Cloud is authoritative for DNS. Otherwise, open the authoritative DNS provider.
- Add the host. Create a TXT record named _dmarc. Some DNS panels append the domain automatically, so do not enter the domain twice.
- Use monitoring policy. For a new deployment without an existing stronger policy, publish v=DMARC1; p=none; rua=mailto:dmarc@example.com after replacing the reporting address.
- Leave alignment relaxed. The defaults for adkim and aspf are relaxed: the authenticated domain and visible From domain must share an organizational domain. Existing adkim=s or aspf=s settings require exact domain matches; test those settings before changing them.
- Check for duplicates. Delete or merge an older _dmarc TXT value. Multiple DMARC records make the policy invalid.
Pecorari Cloud cPanel Zone Editor adding a DMARC TXT record
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The checker should return one valid policy at _dmarc.yourdomain and show the rua destination. A valid record confirms DNS syntax, not message-level authentication. Send a real message next and inspect its results.
Participating receivers typically send aggregate XML reports daily after observing mail; not every receiver sends reports. For a new deployment, keep p=none until reports and direct message tests cover all legitimate sources. An empty report view does not prove that no mail was sent.
Authorize external DMARC reporting
If rua points outside your organizational domain, the reporting destination must authorize your domain before receivers send aggregate reports. RFC 9990 specifies this DNS check. Missing authorization explains a valid DMARC record with no external reports.
For a policy at _dmarc.example.com with rua=mailto:dmarc@reports.example.net, the administrator for reports.example.net publishes this TXT record:
Example authorization in the reporting destination's DNSdns
example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1"
Publish this in the reporting destination's DNS, not your Pecorari Cloud sending domain's zone. A reporting provider can use wildcard authorization instead. For Suped, use the reporting address and authorization instructions supplied during setup; do not invent either value.
Verify and troubleshoot
Test each real sending path separately. A message sent from webmail does not prove that a website contact form, billing system, or application uses the same server or signing domain. Send one message through each path to a mailbox where the raw headers are available. For contact forms, use your domain in From and put the visitor's address in Reply-To.
Use our Suped email tester below to test a real message. It provides a temporary recipient and reports authentication results alongside other delivery checks.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
In raw headers, use Authentication-Results added by the receiving mailbox service. Look for spf=pass and dkim=pass, then confirm dmarc=pass. DMARC still passes when SPF fails if DKIM passes with a domain that has DMARC alignment. PTR is a separate delivery check, and authentication does not guarantee inbox placement.
Also run the DMARC checker after every policy edit. DNS checks and message tests answer different questions, so a clean result requires both.
|
|
|
|---|---|---|
SPF | pass | Authorize the actual outbound IP in the envelope-sender domain's SPF record. |
DKIM | pass | Check the s= selector, d= domain, published public key, and active signer. |
DMARC | pass | Ensure SPF or DKIM passes with DMARC alignment. |
PTR | Forward-confirmed | Request the PTR and ensure its hostname resolves to the sending IP through A or AAAA. |
Authentication results and the separate reverse DNS check
Shared cPanel hosting
- Repair SPF and DKIM. Use Email Deliverability for the affected domain.
- Check SMTP use. If PHP mail is unsigned, use authenticated SMTP or ask Pecorari Cloud to check the application's DKIM signing.
- Escalate PTR faults. Pecorari Cloud controls reverse DNS for shared outbound IPs.
Self-managed server
- Inspect the MTA. Confirm the public sending IP and active DKIM signer.
- Set forward DNS. Point the mail hostname A or AAAA record at the sending IP.
- Request the PTR. Have Pecorari Cloud map the dedicated IP back to that hostname.
Common failure signatures
- SPF PermError. Remove duplicate SPF records or reduce DNS lookups.
- DKIM fail or permerror. Check the selector and public key. If DNS is correct, check for message changes after signing.
- DMARC fail. Ensure SPF or DKIM passes with DMARC alignment; matching domains alone are insufficient.
- PTR mismatch. Make forward and reverse DNS resolve to each other on a dedicated IP.
Monitor Pecorari Cloud authentication failures
A DNS check is a snapshot. SPF can exceed its lookup limit after an included record changes, a DKIM selector can disappear during migration, and a website can begin sending through a new IP without notice. Report processing reveals authentication changes after receivers observe mail and deliver reports, so report-based alerts inherit that delay.
Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring connects observed sending sources to authentication failures and supports threshold-based alerts as reports are processed.
Alerting workflow
- Collect reports. Send aggregate DMARC data to Suped and allow enough traffic to identify normal sources.
- Verify sources. Mark Pecorari Cloud servers and each legitimate application as authorized.
- Enable alerts. Set a failure threshold and route alerts to the responsible owner. Review newly observed sources before authorizing them.
- Use issue steps. Follow source-specific guidance, change DNS or SMTP settings, then send a fresh test and review subsequent reports.
If authenticated mail is still rejected, inspect the SMTP response and the sending IP's blocklist (blacklist) status. Authentication does not override recipient filtering.
Assign each alert to the person who controls the affected layer. Pecorari Cloud support owns faults on shared infrastructure, the DNS administrator owns published records, and the application owner controls the visible From address and envelope sender.
Secure your domain with p=reject
Move to p=reject only after every legitimate Pecorari Cloud sending path and every external sender passes DMARC. A high total pass rate is not enough if a low-volume password reset, invoice, or contact-form path still fails.
- Inventory all sources. Account for cPanel mailboxes, hosted sites, forms, billing mail, monitoring jobs, and any external sender using the domain.
- Require DMARC pass. Make each legitimate source pass through SPF alignment, DKIM alignment, or both. Prefer DKIM for mail that is commonly forwarded.
- Watch a full cycle. Observe at least one complete business sending cycle, including low-frequency transactional messages and scheduled campaigns.
- Stage enforcement. After legitimate senders are verified, move to p=quarantine without pct, review failures, then change to p=reject. Treat each policy change as applying to all DMARC-failing mail covered by that policy.
- Keep reporting active. Retain rua after enforcement so new sources and regressions remain visible.
Quarantine and reject values, publish one at a timedns
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Ready for enforcement
- Known sources pass. Every approved sender has a stable DMARC pass.
- Unknown traffic is classified. Unexpected sources are confirmed as unauthorized or obsolete.
- Owners can respond. Alerts reach someone who can reverse a harmful change.
Stop before enforcement
- A sender is unknown. Investigate its IP, hostname, message type, and owner first.
- DKIM changes often. Stabilize selector rotation and DNS publishing before enforcement.
- Reports are incomplete. Confirm rua delivery and test low-volume paths that reports do not cover.
Use Suped to review each source's authentication results before changing policy. Our Hosted DMARC workflow manages policy changes after DNS delegation is configured. Follow the account-specific instructions when replacing the TXT record with a CNAME; a CNAME and TXT record cannot share the _dmarc hostname.
Do not rely on pct for policy rollout
The pct tag is historic under RFC 9989. Receivers using that specification ignore it, so pct=25 does not reliably limit enforcement to 25% of failures. p=reject requests rejection of DMARC-failing mail, but receivers retain local handling decisions. Check subdomain DMARC records and the parent policy's sp setting before tightening enforcement.
Frequently asked questions
Use the Suggested SPF Record in cPanel Email Deliverability for your domain and assigned server. Merge it with existing authorized senders so each envelope-sender domain has one SPF TXT record. A bounce subdomain needs its own SPF record.
cPanel often uses the selector default, but the selector shown in Email Deliverability or in a real DKIM-Signature header is authoritative. Copy the full selector hostname and public key generated for your own account.
No. DMARC passes when SPF or DKIM passes and the passing protocol's authenticated domain has DMARC alignment with the visible From domain. Configuring both gives legitimate mail a second authentication path.
The envelope sender can use a Pecorari Cloud server domain instead of your visible From domain, or forwarding can change the route. DMARC still passes when DKIM passes with an aligned d= domain. Set a custom return path where the sending application supports it.
An rDNS hostname ending in pecoraricloud.com.br indicates a Pecorari Cloud naming association, but does not prove that your account authorized the message. Match the actual sending IP and authentication results to your account, and confirm unclear sources with Pecorari Cloud support before authorizing them. Shared infrastructure carries mail for multiple customers.
A saved record appears after authoritative DNS publishes it and cached copies expire according to TTL. Check the authoritative nameservers first. If the record is absent there, the problem is the zone or host name, not propagation.
