SPF, DKIM and DMARC Setup for cPanel and VPS

If your domain sends any kind of email – newsletters, order confirmations, password resets or plain corporate mail – SPF, DKIM and DMARC are an important foundation. Requirements vary by receiver and sending volume: Gmail requires SPF or DKIM for all senders, and all three for bulk senders. Missing or incorrect authentication can contribute to spam placement or rejection and make domain spoofing harder to detect.

This updated guide explains SPF, DKIM and DMARC for cPanel and VPS mail systems. The current cPanel workflow uses Email Deliverability → Manage; available actions depend on the version, account permissions and DNS authority. The VPS sections describe how signing fits an existing secured mail service, rather than a complete mailbox deployment. Save existing records and configuration before changing either path.

Why Email Authentication Matters for Your Domain

From “Sent” to Inbox: What’s Actually Happening

When you click “Send”, your email doesn’t go straight to the recipient’s inbox. It passes through several layers of anti‑spam checks, filters, content analysis, and reputation systems. Providers (Gmail, Outlook, Yahoo, corporate gateways, etc.) use different filtering systems, which may consider:

• IP and domain reputation
• Technical setup (SPF, DKIM, DMARC, rDNS, TLS)
• Content and links in the message
• User feedback, such as spam complaints

SPF, DKIM and DMARC help receivers check sending authorization, the integrity of signed message content, and alignment with the visible From: domain. They do not prove that a message is safe or guarantee inbox delivery. Without them, even perfectly legitimate content can look suspicious.

How SPF, DKIM and DMARC Work Together

Think of the three as layers:

• SPF – declares which sending IPs are authorized for an envelope sender or HELO domain.
• DKIM – cryptographically signs selected headers and body content so receivers can verify their integrity and the signing domain’s responsibility.
• DMARC – requests receiver handling when neither SPF nor DKIM passes with From: domain alignment, and lets you request reports about mail using your domain.

We have a broader deliverability overview in our guide “Inbox or Spam? A Friendly, Step‑by‑Step Guide to SPF, DKIM, DMARC and rDNS”. Here, we will focus on hands‑on setup specifically for cPanel and VPS environments.

Key Concepts: DNS, MX and Who Is Actually Sending Your Mail

DNS Records You’ll Touch

All three mechanisms rely on DNS – the “phone book” of the internet. For email authentication, you will mainly work with:

• MX – which servers receive your domain’s mail
• A / AAAA – the IP addresses of your web and mail servers
• TXT – where SPF and DMARC records live, and where DKIM public keys are published

If you edit these records in cPanel’s DNS Zone Editor, make sure that zone is authoritative for your domain. On a VPS, you might manage DNS on the same server, at your registrar, or on external DNS – the principle is the same: publish the right TXT records for SPF, DKIM and DMARC.

Mapping Your Real Senders

Before editing anything, list every system that sends email using your domain:

• Your main hosting/cPanel server (contact forms, transactional mails, system alerts)
• Any VPS or dedicated server you use for mail
• Marketing / newsletter platforms
• CRM or support tools that send as @yourdomain.com
• Applications that send via SMTP with your domain in the From: address

This mapping is critical. Configure each legitimate sender’s SPF authorization and DKIM signing as appropriate, and verify that its messages pass at least one aligned check. DMARC evaluates those results, not your inventory; investigate unknown senders before tightening policy.

SPF Explained: Telling the World Who Can Send for Your Domain

What SPF Does (and What It Doesn’t)

SPF (Sender Policy Framework) is a DNS record (type TXT) that lists the servers allowed to send email using your domain in the envelope sender (the technical return‑path). When a mail server receives an email with envelope sender user@yourdomain.com, it checks:

1. Which IP is sending the email?
2. Is that IP allowed in the SPF record of yourdomain.com?

Important limitations:

• SPF authenticates the envelope sender (Return‑Path) or HELO identity, not the visible From: header.
• When email is forwarded, the original SPF often fails, because the forwarder’s IP is not in your SPF.
• SPF alone does not stop spoofing of the From: address – that’s where DMARC comes in.

Example SPF Records

SPF policies are TXT records at the domain used for the envelope sender or HELO identity, which may be a subdomain. The examples below are illustrative: replace the IP addresses and include domain with your actual sending IPs and your provider’s documented SPF include domain.

• v=spf1 a mx -all – allow the domain’s A/AAAA addresses and the addresses of its MX hosts; return SPF fail for other IPs.
• v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.mailprovider.com -all – allow two specific IPs and IPs that pass the included SPF policy; return SPF fail for other IPs. Receivers decide whether to reject mail.

Breaking it down:

• v=spf1 – SPF version
• a – allow IPs listed in your domain’s A/AAAA records
• mx – allow IP addresses of the hosts named in your MX records
• ip4:203.0.113.10 – allow a specific IPv4 address
• include:_spf.mailprovider.com – reuse another domain’s SPF (for a trusted relay)
• -all – hard fail for all others (recommended once you are confident)

Common SPF Pitfalls (and How to Avoid Them)

Common configuration mistakes include:

• Multiple SPF TXT records – publish only one SPF policy TXT record at each evaluated domain name. Multiple SPF policies there cause a permanent error; merge authorizations into one policy.
• Exceeding the 10-term DNS lookup limit – DNS-causing terms such as include:, a, mx, exists and redirect= count toward a limit of 10 during evaluation, including nested policies. Exceeding it produces SPF permerror, not an ordinary fail. If your setup is complex, we cover SPF flattening strategies in detail in our article “Beat the 10 Lookup Wall: Automated SPF Flattening”.
• Misunderstanding ~all – softfail (~all) is not a pass or a reporting mode. Choose -all when the policy can confidently exclude other senders; DMARC does not require this change and still needs an aligned SPF or DKIM pass.
• Forgetting third‑party senders – if a tool uses your domain as its envelope sender, its sending IPs need SPF authorization. A tool using its own envelope domain may pass SPF without aligning; aligned DKIM can still let DMARC pass.

DKIM Explained: Cryptographic Signatures for Your Email

Selectors, Keys and DNS Records

DKIM (DomainKeys Identified Mail) adds a digital signature to each email. That signature is generated with a private key on your mail server and verified with a public key published in DNS. Changes to the signed headers or body that are not normalized away by DKIM’s canonicalization rules cause verification to fail; unsigned headers are not protected.

A DKIM setup has three pieces:

• Selector – a short label (e.g. default or mail) that appears in the DKIM-Signature header, like s=default.
• Public key in DNS – a TXT record at selector._domainkey.yourdomain.com containing the public key.
• Private key on the mail server – used to sign outgoing emails.

A simplified DKIM DNS record looks like this. The public key is abbreviated, so this is not a publishable record; use the complete key generated for your signer:

Host:  default._domainkey.yourdomain.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh... (long public key)

Use cPanel’s Email Deliverability → Manage to inspect the suggested DKIM record. Generate Local DKIM Key is available when a key is missing; do not replace an active selector unnecessarily. The public TXT value belongs in authoritative DNS, while the private key stays protected on the signer. A matching public key and an enabled, correctly routed signing service are both needed; test actual outgoing messages.

How DKIM Alignment Affects DMARC

DMARC checks whether SPF and/or DKIM “align” with the visible From: domain:

• For SPF alignment, the envelope sender domain (Return‑Path) and the From: domain must share the same organizational domain in relaxed mode, or match exactly in strict mode.
• For DKIM alignment, the domain in the DKIM d= tag and the From: domain must share the same organizational domain in relaxed mode, or match exactly in strict mode.

With a good setup, your messages should pass DKIM and DKIM alignment, which can survive forwarding when signed content is preserved. Mailing lists that change signed headers or body content can break DKIM, so aligned DKIM does not solve every forwarding case.

DMARC Explained: Policy, Reporting and Protection

DMARC Alignment in Plain Language

DMARC (Domain‑based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM and answers three key questions for receivers:

1. Did this email pass SPF and/or DKIM in alignment with the From: domain?
2. If not, what should we do with it? (none, quarantine, reject)
3. Where should we send reports about what we’re seeing for this domain?

Publish one DMARC policy at _dmarc.yourdomain.com, editing an existing policy rather than adding a second one. Replace the example domain and reporting mailbox with values you control. This monitoring example requests no DMARC-based quarantine or rejection; it does not turn off the receiver’s other filters:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Key tags:

• p= requests how to handle messages that fail DMARC: none, quarantine or reject. Final disposition remains with the receiver.
• rua= requests aggregate reports. A reporting destination outside the policy domain’s organisational domain needs DNS authorisation from that destination.
• ruf= requests optional failure reports, which can expose message and personal data; it is omitted from the starter examples.
• pct= is historic: current DMARC RFC 9989 removed percentage sampling. Do not rely on a 25/50/100 percentage rollout.

Designing a Safe DMARC Rollout

Choose policy from evidence about legitimate senders and indirect mail flows, not from a fixed countdown. Current RFC 9989 advises against p=reject for domains hosting users who may post to mailing lists. For such domains still considering reject, it recommends comparing at least a month of none with an equally long quarantine period. Reject domains must apply valid DKIM and must not rely solely on SPF.

1. Use p=none and rua= to investigate authentication and alignment; receivers can still filter messages for other reasons.
2. Check every legitimate sending path, including applications, external providers, forwarding and mailing lists. A high overall pass rate can hide a small critical sender.
3. Consider p=quarantine only after understanding the effects on legitimate mail; monitor results and retain a recovery plan.
4. Use p=reject only when it fits the domain’s use. It is not a mandatory final stage, and it cannot block look-alike domains or malicious mail that authenticates successfully.

If you want to go beyond basics (RUA/RUF analysis, subdomain policies, BIMI), we have a deep‑dive in “Beyond p=none: The Friendly Playbook for Advanced DMARC and BIMI”.

Sample DMARC Records

• Initial monitoring request:
  v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
• Quarantine request for DMARC failures:
  v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
• Reject request where appropriate for the domain:
  v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Setting Up SPF, DKIM and DMARC on cPanel

Step 1: Check Your Current DNS and Email Routing

Log in to your cPanel account for the domain you want to configure. First, confirm where DNS is being managed:

• Determine which nameservers actually serve the domain’s authoritative zone. A hosting-branded nameserver name alone does not prove this cPanel server controls its records.
• If DNS is external, inspect suggested cPanel values but publish changes at the authoritative provider. A local zone update does not update external DNS.

In cPanel:

• Inspect existing SPF and DMARC records at the authoritative provider; use Zone Editor only when it controls the relevant zone.
• Check Email Routing against the intended incoming-mail path. Local, Backup and Remote routing are receiving decisions, separate from SPF and outgoing signing.

Make a quick inventory of what you find – if older, conflicting SPF/DMARC records exist, plan to clean them up instead of stacking new ones on top.

Step 2: Review SPF and DKIM Records and Verify Signing

In current cPanel documentation, the relevant interface is Email Deliverability. Your provider must enable it for the account. Do not assume an older Authentication screen’s Enable button exists in every version, or interpret a valid DNS status as proof that all application mail is signed.

1. In cPanel, go to Email Deliverability.
2. Find your domain in the list.
3. Click Manage.

Here you will see:

• Status and suggested Name/Value for SPF and DKIM.
• Customize for the proposed SPF policy and Generate Local DKIM Key when a key is missing.
• The option to inspect a private DKIM key is separate; never publish that private material in DNS.

If SPF or DKIM show as missing or invalid:

• If the system controls authoritative DNS, Repair opens recommendations for review and confirmation before updating invalid records; it is not merely a preview button.
• If it does not control DNS, Repair is unavailable. Copy the suggested public record to the authoritative provider; installing a local record is not external publication.
• Keep required third-party SPF authorisations and existing valid selectors. Confirm the final record instead of accepting a replacement blindly.

cPanel rechecks repaired records, but there is no universal DNS propagation time. Cached earlier answers can persist according to their TTLs. A public DKIM key mismatch can cause cPanel to omit outgoing signatures to avoid failure. If signatures are still absent after correcting DNS, have the provider check the domain’s DKIM enablement and actual Exim/PHP/SMTP route. Incoming DKIM verification is a different control.

Step 3: Customise SPF for Third‑Party Senders

A cPanel SPF suggestion may resemble this example. YOUR.SERVER.IP is a placeholder, not a publishable address. Keep a and mx only when the addresses they authorise really send mail, and compare the proposed policy with existing senders:

v=spf1 +a +mx +ip4:YOUR.SERVER.IP ~all

To support third‑party services:

1. Follow the sending provider’s instructions for the actual envelope domain. Not every service needs an include at your root domain.
2. Edit the existing SPF TXT policy at the authoritative provider; Zone Editor → Manage is appropriate only if that zone is authoritative.
3. Place any needed mechanism before the final all, for example:
   v=spf1 +a +mx +ip4:YOUR.SERVER.IP include:_spf.mailprovider.com ~all
4. Replace every placeholder and verify lookup limits and actual messages. Do not publish a second SPF policy.

~all produces softfail, not pass or a monitoring mode. Consider -all when the sender inventory supports excluding other IPs. This SPF decision is separate from DMARC policy: an aligned DKIM pass can satisfy DMARC when SPF fails, and receivers still apply their own handling rules.

Step 4: Add a DMARC Record

Current Email Deliverability includes a Suggested DMARC (TXT) Record section. When this server is authoritative, Install the Suggested Record can publish the recommendation. Read its value first; use Zone Editor or the external authoritative panel to configure your intended reporting address and policy. The interface’s SPF/DKIM checks should not be confused with DMARC’s protocol rule of at least one successful aligned mechanism.

1. Open the authoritative DNS panel; for a cPanel-controlled zone use Zone Editor → Manage.
2. Find an existing DMARC TXT policy and edit it, or choose Add Record → TXT if none exists.
3. Ensure the final owner name is _dmarc.yourdomain.com; account for the panel’s automatic domain suffixing.
4. Use your chosen mailbox, for example:
   v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
5. Save and verify the authoritative answer. If the reporting destination is outside the same organisational domain, arrange its external reporting authorisation.

Aggregate reports arrive only from receivers that send them and on those receivers’ schedules. There is no guaranteed 1–24 hour start time. Confirm that dmarc@yourdomain.com or your chosen service can accept and process reports, then review:

• Which IPs and hosts are sending for your domain
• Which of them pass/fail SPF and DKIM

Compare authentication, alignment and disposition across all legitimate paths before changing p=. Reporting is not complete traffic coverage, and an unknown source is not automatically an attacker. Keep the mailing-list and forwarding constraints in the rollout section in view; reject is not suitable for every general-purpose domain.

Step 5: Test and Monitor Deliverability

Once SPF, DKIM and DMARC are in place:

• Send permissioned test messages from each actual application, webmail and external sending service.
• Inspect the receiving provider’s trusted Authentication-Results, the DKIM d=/s= identities and visible From: alignment. A DKIM-Signature header alone does not prove DKIM passed.
• Monitor bounces, forwarding and spam placement as well as authentication. One successful test or a few quiet days do not cover every legitimate path.

Inbound spam filtering is a separate control from outbound authentication. Authenticated mail can still be malicious, and passing DMARC should not be treated as a blanket allowlist rule. The linked “Email Spam Filtering on cPanel: SpamAssassin, RBLs and Quarantine Step‑By‑Step” is a Turkish guide to cPanel filtering; use it as separate background when reviewing receiving-side policy.

Configuring SPF, DKIM and DMARC on a VPS (Postfix/Exim)

On a VPS without a control panel, you have more flexibility but also more responsibility. The concepts stay the same; the main change is that you edit configuration and keys directly instead of using a GUI.

Scenario 1: Your VPS Hosts Both Website and Mail

If your VPS runs both web and mail (e.g. Postfix + Dovecot or Exim + Dovecot):

• If this server really receives the domain’s mail, configure the intended MX target, such as mail.yourdomain.com.
• Publish A/AAAA only for address families that actually reach the configured service; test IPv4 and IPv6 separately.
• Authorise actual outgoing addresses with SPF. Web A or incoming MX addresses should not be allowed to send by assumption.
• Configure DKIM signing for authorised submission paths and publish the complete matching public key.
• Publish one DMARC policy at _dmarc.yourdomain.com and inspect real recipient results.

Scenario 2: Web on VPS, Mail on External Provider

When web applications run on a VPS and incoming mail is hosted elsewhere, receiving and sending paths must be documented separately. Incoming MX records alone do not tell an application which SMTP service to use. In this arrangement:

• MX records identify the intended receiving provider.
• Use the sender provider’s SPF envelope-domain and DKIM instructions; some DKIM setups use provider-supplied CNAMEs rather than a directly managed key TXT record.
• Configure applications to use the chosen authenticated relay. Direct VPS sending is a separate path that needs its own authorisation, signing and reputation management.
• DMARC evaluates the visible From: domain and aligned authentication, regardless of where the website is hosted.

This is where having a clear sender inventory really pays off.

High‑Level Steps for DKIM on Postfix

On a typical Postfix VPS, you use a DKIM signing service such as OpenDKIM or rspamd. At a high level:

1. Select packages and instructions for the actual distribution and existing mail stack; protect and back up current configuration.
2. Generate a new selector and a suitable key, commonly RSA 2048. Do not overwrite an active selector during rotation.
3. Configure key paths and domain/selector mappings, restrict private-key access and limit which clients may obtain signatures.
4. Integrate with Postfix using the intended main.cf Milter settings, checking any master.cf service overrides and existing filters. Decide how signer failures affect delivery.
5. Publish the complete generated key at selector._domainkey.yourdomain.com in authoritative DNS before using it.
6. Validate configuration, apply the service change and test both actual SMTP submission and local application paths. A successful syntax check does not prove authentication.

The linked Turkish guide to setting up a VPS mail server with Postfix, Dovecot and rspamd covers a broader mail stack. A DKIM Milter fragment does not configure secure public submission, relay restrictions or mailbox access. Keep trusted local processes limited: a process allowed to submit under a signing policy may be able to produce mail signed for that domain.

High‑Level Steps for DKIM on Exim

Exim’s DKIM signing is configured in the outgoing SMTP transport. Incoming DKIM verification is separate. On cPanel-managed Exim, use supported cPanel/WHM configuration rather than overwriting generated transport files with a generic recipe.

1. Choose a selector and generate a new key without replacing an active key unexpectedly.
2. Store the private key so the Exim process can read it and unrelated users cannot.
3. Configure the intended outgoing SMTP transport’s signing domain, selector and private-key settings for authorised mail.
4. Publish the complete public key at selector._domainkey.yourdomain.com before using the new selector.
5. Check effective configuration and restart/reload as required by that deployment; test received messages for a valid, aligned signature. Retain old public keys while previously signed mail may still need verification.

SPF and DMARC policies are DNS TXT records; DKIM verification normally retrieves a public key through DNS, sometimes using a provider-supplied CNAME indirection. Those records do not themselves sign messages. The MTA or sending service must apply the corresponding private key on the real sending route.

Where to Put the DNS Records

On a VPS, you are free to use:

• Your registrar’s DNS
• A separate DNS hosting service
• DNS servers you manage yourself (for example, on other VPS or dedicated servers)

Publish at the DNS authority for each record name. This is usually the domain’s DNS host, but delegated subdomains or provider-supplied DKIM CNAMEs can lead elsewhere. Updating an unused local zone does not change what public receivers see. Verify the resolved name and complete value rather than judging correctness from the dashboard where you typed it.

If you want to build more advanced and resilient DNS architectures for agencies or multi‑domain setups, we cover that in “DNS and Domain Access Management for Agencies” and our guide to setting up private nameservers and glue records.

Operational Tips: Keeping Email Deliverability Healthy

Forwarding, Mailing Lists and Aliases

Forwarding can fail SPF when it preserves the original envelope domain but sends from a different IP. Aligned DKIM may still pass if signed content survives. SRS rewrites the envelope sender; it does not by itself restore alignment with the original visible From:. ARC carries intermediary authentication assessments, but receivers must evaluate trust in that chain and may still reject the message.

The linked “Forwarding Broke Your SPF/DMARC? Here’s How SRS and ARC Save the Day” is a Turkish explanation of forwarding and SRS/ARC. Despite the shorthand in its title, neither mechanism guarantees a DMARC pass or delivery. Test aliases, catch-all forwarding and mailing lists through the actual providers before choosing a stricter policy.

IPv6, rDNS and Blocklist Hygiene

If you send mail over IPv6, all the same rules apply: SPF, DKIM and DMARC still operate on domains, but IP reputation and reverse DNS matter for v6 as well. Make sure:

• Your mail IP (both IPv4 and IPv6) has a proper PTR record (rDNS) pointing to a sensible hostname.
• That hostname has matching A/AAAA records.
• SPF includes both IPv4 and IPv6 where relevant.

Our article “Email Deliverability over IPv6: PTR, HELO, SPF and Blocklists” dives into v6‑specific gotchas and how to keep them under control.

On the reputation side, always monitor:

• Major blocklists for your sending IPs
• Spam complaint rates
• DMARC aggregate reports for unknown sources

If you end up on a blocklist or see serious reputation damage, follow a structured recovery plan. We share a practical roadmap in “Stuck on a Blocklist? The Friendly Playbook for Email Sender Reputation Recovery”.

When to Scale Beyond Shared Hosting

Compare managed mail, an external SMTP relay and self-managed servers against sending volume, support, data requirements and operational capacity. A hosting plan’s mail limits and authentication features must be verified for that plan. Moving to a larger server does not automatically improve reputation or delivery. Reasons for a separate architecture might include:

• You send a large volume of transactional or marketing email.
• You need custom mail routing, filtering or archiving logic.
• You want stricter isolation between applications and mail.

A relay can reduce some queue and reputation work while leaving you responsible for sender authorisation and domain configuration. A self-managed VPS offers control but also requires patching, access restrictions, backups and incident handling. Compare those duties with the actual service scope offered by DCHost or any chosen provider; do not infer managed mail or redundancy from the server product name.

Wrapping Up: A Practical Checklist You Can Reuse

Getting SPF, DKIM and DMARC right is mostly about being methodical. Here is a checklist you can run through for every domain you manage:

• Inventory senders, envelope domains, DKIM signers and visible From: domains.
• Identify the authoritative DNS path and preserve current records before editing.
• In cPanel, review Email Deliverability suggestions and DNS authority; on a VPS, configure the actual authorised signing path.
• Publish one SPF policy per evaluated identity and check nested DNS-causing terms against the limit of ten.
• Publish the complete public DKIM key and protect the private key; test the signer rather than merely checking record presence.
• Create or update one DMARC policy at _dmarc.yourdomain.com, with a deliberate p=none monitoring start where appropriate and a working rua= destination.
• Inspect trusted recipient results and alignment for each real path, including forwarding.
• Choose policy from evidence and domain use; do not assume every domain should progress to reject or rely on pct sampling.
• Monitor actual sending IPs, forward/reverse DNS, TLS, complaints, bounces and reports over time.

Start with one sending path and a test message, then cover the remaining applications and providers. Confirm service features and operational responsibility before choosing hosting, a relay or a dedicated mail server. Correct authentication helps receivers assess your messages; it does not remove content filtering, reputation problems or the need to monitor delivery.