SPF, DKIM and DMARC Explained for cPanel and VPS Email

If your domain sends any kind of email – newsletters, order confirmations, password resets or plain corporate mail – SPF, DKIM and DMARC are no longer optional. They are the minimum you need so that big providers can trust your messages. Without them, you will see a mix of problems: messages going to spam, random bounces, or in the worst case, attackers spoofing your brand and sending phishing emails that look like they came from you.

In this article, we will walk through what SPF, DKIM and DMARC actually do, how they fit together, and then go step‑by‑step through configuration on both cPanel and VPS servers. The goal is simple: by the end, you should be able to look at any domain you manage and confidently say “this is authenticated correctly” – and know exactly where to fix things when deliverability is not where it should be.

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. Each major provider (Gmail, Outlook, Yahoo, corporate gateways, etc.) uses its own scoring model based on:

• IP and domain reputation
• Technical setup (SPF, DKIM, DMARC, rDNS, TLS)
• Content and links in the message
• User behaviour (opens, clicks, spam complaints)

SPF, DKIM and DMARC are the technical foundation that tells receivers “this email really belongs to this domain, and hasn’t been tampered with”. 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 servers are allowed to send mail for your domain (IP and hostname‑based).
• DKIM – cryptographically signs messages so receivers can verify they weren’t modified and really came from your domain.
• DMARC – tells receivers how to treat emails that fail SPF and/or DKIM, and gives you reports so you can see who is sending on your behalf.

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

In cPanel, these are managed under DNS Zone Editor (or Email Deliverability in newer versions). 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. Your SPF and DKIM records must include all legitimate senders. Anything not on this list should be treated as unauthorized by DMARC.

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 claiming to be from [email protected], it checks:

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

Important limitations:

• SPF only authenticates the envelope sender (Return‑Path), not necessarily 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 records are always TXT records on the root of your domain, with content like:

• v=spf1 a mx -all – allow the IPs of A and MX records, block everything else.
• v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.mailprovider.com -all – allow two specific IPs and one external sender; block others.

Breaking it down:

• v=spf1 – SPF version
• a – allow IPs listed in your domain’s A record
• mx – allow IPs of 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)

Some frequent mistakes we see in real audits:

• Multiple SPF TXT records – you must have exactly one SPF record per domain. Merge entries instead of adding a second one.
• Exceeding the 10 lookup limit – mechanisms like include:, a, mx, exists trigger DNS lookups. More than 10 makes SPF invalid. If your setup is complex, we cover SPF flattening strategies in detail in our article “Beat the 10 Lookup Wall: Automated SPF Flattening”.
• Using ~all forever – softfail (~all) is fine while testing, but long term you want -all once DMARC is in place.
• Forgetting third‑party senders – if a tool sends as your domain but is not in SPF, those messages will fail SPF and possibly DMARC.

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. If the contents are changed in transit, the signature fails.

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:

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

On cPanel, keys and records are usually generated automatically; you only need to make sure the TXT record is present and correct.

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) must match (or be a subdomain of) the From: domain.
• For DKIM alignment, the domain in the DKIM d= tag must match (or be a subdomain of) the From: domain.

With a good setup, your messages should pass DKIM and DKIM alignment, which is usually more stable than SPF in the presence of forwarding and mailing lists.

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?

The DMARC record is a TXT record at _dmarc.yourdomain.com. A basic one looks like:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Key tags:

• p= – policy: none, quarantine or reject
• rua= – where to send aggregate XML reports
• ruf= – where to send optional forensic (per‑message) reports
• pct= – percentage of messages to which the policy applies

Designing a Safe DMARC Rollout

A sensible rollout path looks like this:

1. Publish p=none with rua= so you can see what is happening without affecting delivery.
2. Fix SPF and DKIM for all legitimate senders until most of your traffic passes DMARC.
3. Move to p=quarantine with pct=25, then 50, then 100.
4. When comfortable, switch to p=reject (optionally with pct=100) to actively block spoofed mail.

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

• Monitoring only (good first step):
  v=DMARC1; p=none; rua=mailto:[email protected]; fo=1
• Quarantine, full enforcement:
  v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; fo=1
• Reject spoofed mail:
  v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1

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:

• If your nameservers point to your hosting (for example ns1/ns2 of your provider), cPanel’s DNS Zone Editor controls your DNS.
• If you use external DNS (such as a third‑party DNS provider), you’ll read values from cPanel but create TXT records at that external DNS.

In cPanel:

• Open Zone Editor and note any existing TXT records for SPF or DMARC.
• Open Email Routing to verify where mail for the domain is actually delivered (Local, Backup, or Remote).

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: Enable SPF and DKIM in cPanel

Recent cPanel versions consolidate this under Email Deliverability:

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

Here you will see:

• Current status of SPF and DKIM (valid/invalid)
• Suggested records and values

If SPF or DKIM show as missing or invalid:

• Click Repair or Install the Suggested Record.
• cPanel will create or update the corresponding TXT records in DNS.

After a few minutes, re‑check the page; it should show green/valid. If you manage DNS externally, copy the suggested TXT records from here and paste them into your external DNS dashboard instead.

Step 3: Customise SPF for Third‑Party Senders

cPanel’s default SPF usually looks something like:

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

To support third‑party services:

1. Get the SPF include or IP range from your provider’s documentation (e.g. include:_spf.mailprovider.com).
2. In cPanel, open Zone Editor → Manage → edit the SPF TXT record.
3. Add the new mechanism before ~all, for example:
   v=spf1 +a +mx +ip4:YOUR.SERVER.IP include:_spf.mailprovider.com ~all
4. Save the record.

Once you are sure everything is sending correctly, consider changing ~all to -all for stricter enforcement, especially after DMARC is in place.

Step 4: Add a DMARC Record

cPanel does not always create DMARC for you, but adding it is simple:

1. Go to Zone Editor → Manage.
2. Click + Add Record and choose TXT.
3. Set the name/host to _dmarc (cPanel will append your domain).
4. Use a monitoring‑only value such as:
   v=DMARC1; p=none; rua=mailto:[email protected]; fo=1
5. Save the record.

After 1–24 hours, DMARC aggregate reports will start arriving at [email protected]. Review these to understand:

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

As your configuration stabilises, you can update p= to quarantine and eventually reject.

Step 5: Test and Monitor Deliverability

Once SPF, DKIM and DMARC are in place:

• Send test mails to several major providers (Gmail, Outlook, a corporate address, etc.).
• Inspect the email headers to confirm SPF: pass, DKIM: pass, DMARC: pass.
• Watch spam folders for a few days to be sure nothing legitimate is being quarantined.

If you use cPanel’s spam filtering, it’s a good moment to review those settings as well. Our guide “Email Spam Filtering on cPanel: SpamAssassin, RBLs and Quarantine Step‑By‑Step” walks through tuning filters so that authenticated mail is treated more kindly while still blocking obvious junk.

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):

• Point your domain’s MX record to the VPS hostname (e.g. mail.yourdomain.com).
• Ensure A and AAAA records for that hostname point to the VPS IPs.
• Publish SPF including your VPS IP (or a / mx if the A/MX records match).
• Set up DKIM signing on the mail server and publish the public key in DNS.
• Add a DMARC record at _dmarc.yourdomain.com.

Scenario 2: Web on VPS, Mail on External Provider

In this more common pattern, web traffic lives on your VPS while mail is handled elsewhere (e.g. hosted email service). In that case:

• MX records usually point to the external mail provider.
• SPF and DKIM should mostly reflect that provider’s requirements.
• Any applications on the VPS sending mail as your domain should relay through the provider’s authenticated SMTP or be explicitly included in SPF and DKIM.
• DMARC still sits at the domain level and evaluates both the provider’s and your VPS’s traffic.

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. Install the DKIM signer (e.g. OpenDKIM packages for your distro).
2. Generate DKIM keys per domain (2048‑bit RSA is a good default).
3. Configure the signer with key paths, selectors and domains.
4. Integrate it with Postfix via a milter (in main.cf and master.cf).
5. Publish the generated public key in DNS at selector._domainkey.yourdomain.com.
6. Reload/restart Postfix and the DKIM service.

We discuss a full stack (Postfix, Dovecot, rspamd) in detail in our article “I Built a 3‑Part Mail Server: Postfix, Dovecot, rspamd, and the Calm Path to Deliverability”, including IP warm‑up strategies.

High‑Level Steps for DKIM on Exim

On Exim, DKIM is often built‑in or enabled through configuration:

1. Generate a DKIM key pair per domain.
2. Place the private key in a secure path on the server.
3. Configure Exim to sign outgoing messages with that key for the specific domain.
4. Publish the public key as a TXT record at selector._domainkey.yourdomain.com.
5. Restart Exim and send test messages to confirm DKIM: pass.

In both Postfix and Exim setups, the DNS side remains exactly the same as on cPanel – SPF, DKIM, and DMARC are always just TXT records in DNS.

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)

The only hard rule: the DNS provider that is authoritative for your domain must hold the SPF, DKIM and DMARC TXT records. If nameservers at the registry point to one provider and you add TXT records elsewhere, they will simply never be seen.

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

Email forwarding can break SPF because the forwarding server’s IP is not in your original SPF. DMARC may still pass if DKIM survives, but in some cases both can fail. To handle complex forwarding scenarios safely, technologies like SRS (Sender Rewriting Scheme) and ARC (Authenticated Received Chain) help preserve trust chains.

We explain the forwarding problem and the SRS/ARC solutions in more detail in “Forwarding Broke Your SPF/DMARC? Here’s How SRS and ARC Save the Day”. If you rely heavily on forwards (info@ → personal mailbox, catch‑all addresses, etc.), it is worth understanding how your providers implement these.

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

For many small sites and businesses, cPanel hosting with properly configured SPF, DKIM and DMARC is more than enough. But there are situations where moving part of your stack to a VPS or dedicated server makes sense:

• 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.

At dchost.com, we see customers evolve from basic shared hosting mail to separate VPS‑based mail gateways as their requirements grow, sometimes combined with external email services for redundancy. Whatever the size of your project, our shared hosting, VPS, dedicated and colocation options give you room to design the email architecture that fits your risk and control requirements.

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:

• List all systems that send email as your domain (hosting, VPS, tools, platforms).
• Confirm who hosts your DNS and that you have access to add TXT records.
• On cPanel: enable/repair SPF and DKIM via Email Deliverability, or configure DKIM on your VPS mail server.
• Create a single, consolidated SPF record that includes all legitimate senders; avoid exceeding 10 DNS lookups.
• Generate DKIM keys per domain and publish the public key at selector._domainkey.yourdomain.com.
• Add a DMARC record at _dmarc.yourdomain.com starting with p=none and rua= for monitoring.
• Send test emails to multiple providers and verify SPF/DKIM/DMARC pass and align.
• Review DMARC reports, fix any failing legitimate sources, then gradually move to quarantine and reject.
• Monitor rDNS, blocklists, complaint rates and forwarding behaviour over time.

If you want help choosing the right infrastructure for your email stack – from cPanel hosting with solid defaults to VPS or dedicated servers where you control every detail – our team at dchost.com works with these standards every day. When your DNS, mail servers and authentication are all designed together, your messages stop fighting to reach the inbox and simply arrive where they belong.