Knowledgebase

"My email goes to spam" is the single most common email-related support ticket in hosting. The fix is almost always the same: you're missing one of three DNS records that mail providers expect to see in 2026. This article explains SPF, DKIM, and DMARC in plain English, shows you how to set up all three on your ipxcore cPanel account, and walks through how to verify they're working.

What each record does

SPF (Sender Policy Framework)

An SPF record is a TXT record on your domain that says "these IP addresses are allowed to send mail as my domain." When a receiving mail server gets a message claiming to be from you@yourdomain.com, it checks the SPF record. If the sending IP isn't in the allowed list, the message is treated as suspicious.

Without SPF, anyone can send email pretending to be you. With SPF, only servers you've explicitly authorized can.

An SPF record looks like this:

yourdomain.com.   TXT   "v=spf1 +a +mx +ip4:192.0.2.10 include:_spf.google.com ~all"

DKIM (DomainKeys Identified Mail)

DKIM cryptographically signs every outbound message with a private key. The corresponding public key lives in your DNS as a TXT record. When the receiving server gets the message, it pulls the public key, verifies the signature, and confirms the message wasn't tampered with in transit and was actually sent from a server with access to your private key.

SPF says "this IP is authorized." DKIM says "this exact message was authentically signed." Together they give receivers high confidence the mail is legitimate.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC tells receiving servers what to do with messages that fail SPF or DKIM — ignore, quarantine (send to spam), or reject outright. It also enables reporting: receiving providers send you periodic reports showing exactly which sources are sending mail as your domain, including spoofers.

SPF and DKIM verify authenticity. DMARC sets policy and gives you visibility.

Set up all three in cPanel

cPanel makes this nearly one-click via the Email Deliverability tool:

1. Open cPanel.
2. Under Email, click Email Deliverability.
3. For each domain, you'll see status indicators for SPF and DKIM.
4. Click Manage next to a domain.
5. If SPF or DKIM is missing or invalid, click Repair. cPanel adds the correct DNS records automatically.

For DMARC, you have to add the record manually (cPanel doesn't auto-create DMARC):

1. cPanel → Zone Editor.
2. Click Manage next to the domain.
3. Click Add Record.
4. Fill in:
   • Name: _dmarc.yourdomain.com
   • TTL: 14400
   • Type: TXT
   • Record: v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com; ruf=mailto:postmaster@yourdomain.com; fo=1
5. Save.

The p=none tells receiving servers "don't take action on failures yet, just report." That's the safe starting policy — let it run for 30 days and review the reports before tightening.

DMARC policies, in increasing strictness

• p=none — receive reports but take no action. Use for the first 30 days.
• p=quarantine — receiving servers send failing mail to spam. Use after 30 days of clean reports.
• p=reject — receiving servers refuse failing mail outright. Use after 60-90 days of clean reports under quarantine.

Each tightening reduces spoofing potential but increases the risk that legitimate mail is blocked if a sending source isn't covered by SPF/DKIM. Move slowly and check reports.

Reading DMARC reports

Once rua=mailto:postmaster@yourdomain.com is set, you'll start receiving daily XML reports from Gmail, Microsoft, Yahoo, and other providers. They're ugly to read raw. Use one of:

• Dmarcian — free tier good for small volume; converts XML to a readable dashboard.
• Postmark DMARC — free, simple weekly summaries by email.
• EasyDMARC — free for small volume, paid features for enterprise.

Look for: legitimate sources that fail (your CRM, marketing tool, payment processor) — each needs to be added to your SPF or signed via DKIM. Then look for spoofers using your domain — you'll see their IPs and where their mail is being delivered. Tighten your policy once your legitimate sources all pass.

If you send mail from third-party services

Many sites send transactional or marketing mail from services like Mailchimp, SendGrid, Postmark, Amazon SES, or Google Workspace. Each one needs to be authorized. Two patterns:

Pattern A: SPF include

Add an include: directive to your SPF record:

v=spf1 +a +mx include:sendgrid.net include:_spf.google.com ~all

Each provider gives you their include: string in their setup docs.

Pattern B: Their own DKIM

Many providers ask you to add CNAME records pointing at their DKIM keys. Follow their setup wizard verbatim — the records are generated specifically for your account.

Test your setup

Send a test email from your domain to check-auth@verifier.port25.com. You'll get an automated reply showing exactly how your message looked at the receiving end — SPF result, DKIM result, DMARC result, content scoring. Free, instant, and tells you exactly what's wrong if anything is.

Other tools:

• MXToolbox — check SPF/DKIM/DMARC records for any domain.
• Mail-Tester — send a message to their test address, get a 0-10 score with deliverability recommendations.
• Gmail postmaster tools at postmaster.google.com — if you send significant mail to Gmail users, this is the official Gmail-side dashboard for your domain reputation.

Common pitfalls

• Multiple SPF records. Only one SPF record per domain is allowed. Multiple records cause SPF to fail entirely. cPanel's Email Deliverability tool catches this.
• Forgetting to update SPF when adding a new sending source. A new tool that sends mail from a new IP will fail SPF until you update the record.
• DMARC alignment failures. SPF and DKIM both have to align with the visible "From" domain. Some services (Mailchimp, etc.) need extra setup to use your domain as the visible From rather than their own.
• Reverse DNS (PTR) mismatches. Less common but real: your sending IP needs reverse DNS that matches your sending hostname. Already handled for ipxcore-sent mail; matters if you're sending from your own server.

If after all of this your mail still goes to spam consistently, it may be your domain or IP reputation rather than authentication. Open a ticket with the bounced mail headers and we'll diagnose.