SPF, DKIM and DMARC:Stop Your Email Going to Spam

SPF, DKIM and DMARC are three DNS records that prove email from your domain is genuine:

• SPF lists the servers allowed to send email for your domain.
• DKIM adds a cryptographic signature to each message, which receivers check against a public key in your DNS.
• DMARC tells receivers what to do when a message fails those checks, and sends you reports.

Together they help your legitimate email reach inboxes and make it much harder for others to send email pretending to be you. Major mailbox providers now expect them, especially from domains that send in volume.

SPF (Sender Policy Framework)

SPF is a TXT record on your domain:

example.com.  TXT  "v=spf1 a mx include:_spf.mailprovider.com ~all"

• v=spf1 starts the record.
• a and mx allow the domain's own A and MX hosts.
• include: allows another service's sending servers (an email provider, a newsletter tool, a helpdesk).
• ~all (soft fail) or -all (fail) says what to do with everything else.

Rules:

• Only one SPF record per name. Two SPF records make SPF fail. Merge them.
• SPF allows at most 10 DNS lookups (each include, a, mx and similar mechanism counts). Too many services can exceed it.
• SPF checks the envelope sender, not the "From" address people see, which is why DMARC is needed.

DKIM (DomainKeys Identified Mail)

The sending server signs each message with a private key. The matching public key is published in DNS, usually as a TXT (or CNAME) record on a name like:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The selector lets you have several keys, one per sending service. Your email provider or hosting control panel generates the key; you publish what it gives you. In cPanel, Email Deliverability shows the DKIM record and can install it when DNS is hosted on the server.

DKIM survives forwarding better than SPF, because the signature travels with the message.

DMARC

DMARC is a TXT record on _dmarc.example.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p= is the policy: none (monitor only), quarantine (treat as spam) or reject.
• rua= is where receivers send aggregate reports.
• DMARC passes when SPF or DKIM passes and aligns with the domain in the visible "From" address.

A safe rollout order

1. List every service that sends email as your domain: your mailboxes, website contact forms, newsletter tool, invoicing system, helpdesk.
2. Publish one SPF record that includes all of them.
3. Enable DKIM for each service that supports it.
4. Publish DMARC with p=none and a reporting address.
5. Read the reports for a few weeks. They show which sources pass and which fail.
6. Fix failing legitimate sources, then move to p=quarantine, and later p=reject if you are confident.

Worked example: a small business with three senders

A company sends email from:

1. its mailboxes, hosted on its cPanel server;
2. a newsletter service;
3. an invoicing tool that emails invoices "from" [email protected].

The records:

example.com.         TXT  "v=spf1 a mx include:spf.newsletter.example include:mail.invoicing.example ~all"
default._domainkey   TXT  "v=DKIM1; k=rsa; p=..."      (from cPanel)
nl1._domainkey       CNAME  nl1.dkim.newsletter.example. (from the newsletter service)
inv._domainkey       CNAME  inv.dkim.invoicing.example.  (from the invoicing tool)
_dmarc               TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

After three weeks of reports showing all three sources passing, the company changes DMARC to p=quarantine, and some months later to p=reject. Spoofed emails pretending to come from example.com now fail at most large receivers.

Reading a DMARC aggregate report

Aggregate reports are XML files summarising, per sending IP address: how many messages were seen, whether SPF and DKIM passed and aligned, and what the receiver did. When reviewing:

• Known sources passing: good.
• Known sources failing: fix their SPF include or DKIM setup before tightening the policy.
• Unknown sources: either a service you forgot (add it) or someone spoofing your domain (which a stricter policy will block).

Report-processing services turn the XML into readable dashboards.

How to check your setup

• Send a message to a mailbox you control at a large provider and view the original headers: look for spf=pass, dkim=pass and dmarc=pass.
• Use a DNS lookup tool to view the TXT records.
• In cPanel, Email Deliverability flags missing or incorrect SPF and DKIM.

Common problems

Problem	Cause	Fix
SPF "permerror"	Two SPF records, or too many lookups	Merge records, reduce includes
Contact form email goes to spam	Website sends as your domain from an unlisted server	Send through authenticated SMTP, or add the server to SPF
DKIM fails	Wrong or truncated key in DNS	Copy the full key again; check the selector name
DMARC fails although SPF passes	SPF domain does not align with the From domain	Ensure DKIM signs with your domain

Frequently Asked Questions

Do I need all three?

Yes for reliable delivery. SPF and DKIM authenticate; DMARC ties them to your visible domain and gives you visibility.

Will DMARC stop all spoofing?

A DMARC policy of quarantine or reject stops receivers that check DMARC from accepting direct spoofing of your exact domain. It does not stop look-alike domains.

Where do DMARC reports go?

To the address in rua=. They are XML files; a DMARC reporting service makes them readable.

Related reading

For how mail routing works, see MX records explained. For DNS basics, read what is DNS and domain names explained. Business email is available with the ServerNeed shared hosting plans.

Sources

• Google: Email sender guidelines
• DMARC.org: Overview
• cPanel documentation: Email Deliverability