Without properly configured DKIM, SPF, and DMARC, mail from your domain lands in spam or gets rejected by Gmail and Outlook servers en masse. All three records solve one task — proving to the recipient that a message really was sent on behalf of your domain and was not forged by a scammer.

Why DKIM, SPF, and DMARC are needed

Record	What it does
SPF	Lists which servers may send mail on behalf of the domain
DKIM	A digital signature for every message
DMARC	The policy for what to do when SPF/DKIM fail

The records work together, not in isolation: SPF without DMARC is easily bypassed by spoofing the From header, DKIM without SPF does not protect against forging the message envelope, and DMARC without both earlier records has nothing meaningful to check.

Enabling DKIM in cPanel

cPanel → Email → Email Deliverability → click Repair next to the domain. cPanel automatically creates a DKIM record in DNS and shows a "Valid" status once the record is published and passes verification. If the status stays "Not Valid" for more than a day after Repair, the domain most likely uses external nameservers (for example, Cloudflare) instead of the hosting's built-in DNS — cPanel cannot publish the TXT record itself in that case, and it has to be copied from cPanel → Email Deliverability into the DNS provider's control panel manually.

SPF record

# Add a TXT record for the domain:
v=spf1 +a +mx +ip4:YOUR_SERVER_IP include:spf.protection.outlook.com ~all

# If you only send through your own server:
v=spf1 +a +mx ~all

Common error: two SPF records at once

If a new SPF record is added without removing the old one (for example, one left over from a previous email provider), a mail server check reports an error:

$ dig TXT example.com +short
"v=spf1 +a +mx ~all"
"v=spf1 include:_spf.google.com ~all"

# Check result:
permerror: Two or more SPF records found

The SPF standard explicitly forbids more than one v=spf1 TXT record per domain — when a second record is found, the recipient's mail servers treat the check as failed (permerror) and often send the message to spam for exactly this reason, not because of its content. The fix is to merge every needed sending source into a single line using include: and delete the duplicate TXT records in Zone Editor.

DMARC record

# TXT record for _dmarc.yourdomain.com
# Start with monitoring only (p=none):
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

# After analyzing the reports, move to quarantine:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com

# Final strict policy:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com

Jumping straight to p=reject without a monitoring period is a common reason legitimate messages (for example, sent through a third-party CRM or newsletter tool) start being rejected: if their SPF/DKIM are not aligned with the domain in the From field, a strict DMARC policy blocks them the same as forged mail.

Reading check results

Result	What it means
SPF: pass	The sender's IP is in the domain's allowed list
SPF: softfail	The IP is not listed, but the policy is soft (~all) — the message is flagged, not blocked
DKIM: pass	The message signature matches the public key in DNS
DMARC: pass	At least one of SPF/DKIM passed AND matches the domain in From

When the records will not save you from spam filters

The server's IP is already blacklisted (Spamhaus, Barracuda) — perfect SPF/DKIM/DMARC will not help until the IP is delisted
Messages are sent through a third-party mailing service (Mailchimp, SendGrid) without adding it to SPF — you need to add that provider's specific include:, otherwise its mail sent on your behalf will fail the check
The message content looks like spam by formal signals — excessive capital letters, links to suspicious domains, attachments with macros — this is scored separately from sender authenticity
The recipient runs an aggressive corporate filter (for example, requiring strict DMARC alignment) — then even valid records that are not perfectly aligned can still get blocked

Verification

# From the command line
dig TXT yourdomain.com
dig TXT _dmarc.yourdomain.com
# Through an online service:
# mxtoolbox.com → SuperTool → DKIM Lookup

Checks should be repeated after every change to the records, not just once during initial setup — different DNS resolvers do not refresh their cache instantly, and the result can differ depending on where the check is run from. The most reliable way to check everything at once is to send a message to a test address at the mail-tester.com service: it returns a report scored from 0 to 10 and tells you exactly which of the three records failed. More on protecting incoming mail from spam is in the article SpamAssassin in cPanel.