SPF, DKIM, and DMARC Setup — Complete Email Authentication Guide

Three DNS records — SPF, DKIM, and DMARC — separate professional email senders from spammers in the eyes of Gmail, Outlook, and every other major provider. Without them, your legitimate emails frequently end up in spam, even when content is fine. With them set up correctly, deliverability problems mostly disappear. This guide goes deeper than the standard “just enable it” — what each one does, the syntax, and how to diagnose failures.

The three records, in plain terms

• SPF (Sender Policy Framework) — declares which servers are allowed to send mail for your domain. Receivers check “did this email come from a server SPF authorized?”
• DKIM (DomainKeys Identified Mail) — cryptographically signs outgoing mail. Receivers verify the signature against a public key in your DNS, proving the mail wasn’t tampered with.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — tells receivers what to do when SPF or DKIM fails, and optionally has them send you reports.

All three are TXT records in your DNS zone. All three are recommended. Together they’re the modern minimum for serious email delivery.

The fast path — cPanel’s Email Deliverability tool

cPanel → Email → Email Deliverability. For each domain, you’ll see Status (problems if any) and a Manage button. Click Manage:

• Reverse DNS — should be green if your server’s PTR is set correctly.
• SPF — should be green if a valid SPF record is in DNS.
• DKIM — should be green if DKIM record is present and the keys match.

For any item showing red or “Repair”, click the Install the Suggested Record button. cPanel adds the correct DNS record automatically (if your DNS is managed by iWebVault).

Note: this tool sets up SPF and DKIM. DMARC is separate and almost always needs to be added manually. See the DMARC section below.

SPF — what your record should look like

A standard iWebVault SPF record:

v=spf1 +a +mx +ip4:185.123.45.67 ~all

Breaking it down:

• v=spf1 — SPF version 1 (the only version).
• +a — allow servers in the domain’s A record to send.
• +mx — allow servers in the MX records to send.
• +ip4:185.123.45.67 — explicitly allow your server’s IP (use your actual IP).
• ~all — soft-fail anything else (-all = hard fail, ?all = neutral).

If you send from external services too (Mailchimp, SendGrid, Google Workspace), add their include: mechanism. Common ones:

• Google Workspace: include:_spf.google.com
• Mailchimp: include:servers.mcsv.net
• SendGrid: include:sendgrid.net
• Brevo (Sendinblue): include:spf.brevo.com
• Microsoft 365: include:spf.protection.outlook.com

So a record sending via iWebVault + Google Workspace would be:

v=spf1 +a +mx +ip4:185.123.45.67 include:_spf.google.com ~all

Critical rule: only ONE SPF record per domain. Multiple SPF records cause receivers to reject all of them. If you have a second SPF for a new sender, merge it into the existing one.

DKIM — how it works in practice

cPanel generates a public/private key pair for your domain. The private key signs every outgoing email’s headers. The public key sits in your DNS as a TXT record at default._domainkey.yourdomain.com:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...<long base64 key>

Receivers fetch your public key from DNS, verify the signature on the email’s headers, and decide whether the mail is authentic. If the signature doesn’t match (because the mail was tampered with, or forged), DKIM fails.

Setup via Email Deliverability is one click. If DNS is hosted elsewhere (Cloudflare, registrar), you’ll have to copy the DKIM record value cPanel generates and paste it manually at your DNS provider.

DMARC — the policy and reporting layer

SPF and DKIM are about authentication. DMARC is about what to do when authentication fails — and getting reports about it.

Create a TXT record at _dmarc.yourdomain.com:

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

Components:

• v=DMARC1 — version.
• p=none — policy. none = monitor only, quarantine = send failing mail to spam, reject = bounce it.
• rua=mailto:... — where aggregate reports go (daily summaries of authentication results).

Always start with p=none. Monitor reports for several weeks to confirm legitimate mail is passing. Then move to p=quarantine, watch some more. Finally p=reject when you’re sure.

Jumping straight to p=reject is the #1 way to start dropping your own legitimate mail. Patience is part of the protocol.

Reading DMARC reports

DMARC reports arrive as XML attachments in your rua= mailbox. They’re not readable by humans directly — feed them to a free DMARC analyzer:

• DMARC Digests — free tier sufficient for small senders.
• parsedmarc — self-hosted tool if you want full control.
• Postmark’s free analyzer — forward reports to a special address, get human-readable weekly emails.

What to look for in reports:

• “Legitimate sources passing” — your own SMTP server, Google Workspace, Mailchimp etc. Should all be passing both SPF and DKIM. If not, fix configurations.
• “Unknown sources sending” — could be a service you forgot you set up, OR could be a spoofer impersonating your domain. Investigate.
• “Failing legitimate mail” — services authorized but mail is failing. Usually SPF doesn’t include them (add an include) or DKIM isn’t signed (configure DKIM at the service).

Testing your setup

Two tools to verify everything works:

• mail-tester.com — send an email to the address they give you, get a 0–10 score and a breakdown of every authentication check. Anything below 9/10 has fixable issues.
• mxtoolbox.com SuperTool — lookups for SPF, DKIM, DMARC records. Verify your records resolve correctly.

After every change to authentication records, allow 1-2 hours for DNS propagation, then retest.

Common authentication problems

SPF passing but mail still spam-foldered. DKIM probably not set up. Both are needed for solid deliverability in 2026.

Mail from Mailchimp/SendGrid going to spam. They authenticate via their own domain by default. To authenticate via your domain (and benefit from your reputation), configure their “Sender Authentication” feature, which adds CNAME records to your DNS pointing at their key servers.

“SPF PermError: too many DNS lookups”. SPF allows max 10 DNS lookups (each include: counts). If you have many includes, you’ve broken SPF. Solutions: SPF flattening services (rare), or consolidate senders so you don’t need more than 10 includes.

DMARC reports show your own IPs failing. Probably running mail through a third-party (a CRM, contact form plugin) that doesn’t authenticate. Either authenticate that source, or stop sending mail through it.

“Why is one mailbox passing and another failing?” Different senders may use different “from” addresses. Each “from” domain needs its own SPF/DKIM/DMARC stack. If you send as both info@yourdomain.com and info@yourdomain.co.uk, both need full setup.

What’s next

• Email going to spam after authentication setup? Complete deliverability guide.
• Checking mail logs and bounces: Mail logs and bounce management.
• Setting up mail clients: Device setup guide.

Authentication is the foundation of email delivery. Get SPF + DKIM + DMARC set up properly once, monitor DMARC reports monthly for the first quarter, and the email side of your hosting essentially runs itself.