These three DNS records decide whether your email arrives or lands in spam. They are not optional extras any more, major providers treat mail without them as suspect, and a domain with none of them configured will see delivery problems that look random and are not.
Each answers a different question. SPF says which servers may send for your domain. DKIM proves a message was not altered in transit and really came from you. DMARC tells receiving servers what to do when the first two fail, and asks them to report back.
SPF: which servers may send
SPF is a TXT record listing the servers permitted to send mail using your domain. A receiving server compares the sending address against that list.
A minimal record for mail sent from your hosting account:
v=spf1 +mx +a +ip4:203.0.113.10 ~all
+mx and +a permit the servers named in your MX and A records. ip4: adds a specific address. The ending matters most:
~all, soft fail. Mail from elsewhere is accepted but marked suspicious. Start here.-all: hard fail. Mail from elsewhere is rejected. Move here only once you are certain the record is complete.?all: neutral, which does nothing at all. Avoid.
One SPF record per domain. Two records is a configuration error and receiving servers may ignore both. If you use several senders, hosting, a marketing platform, a helpdesk: they all go in one record:
v=spf1 +mx +a include:_spf.google.com include:sendgrid.net ~all
There is also a limit of ten DNS lookups per evaluation, and each include counts. Long chains of includes silently exceed it, at which point SPF fails for everyone; a failure mode that is invisible until you check.
DKIM: proof the message is genuine
DKIM signs outgoing mail with a private key held on the sending server. The matching public key is published as a TXT record, and the receiving server verifies the signature.
A valid signature proves two things: the message really came from a server authorised for your domain, and its content was not altered on the way.
On Ahosting, cPanel's Email Deliverability page generates the key pair and shows the record to publish. If DNS is managed on the same server, it can add the record for you; if DNS lives elsewhere, copy the value to your DNS provider exactly.
DKIM records are long, and truncating one is the most common mistake: it produces a signature that fails to verify, which is worse than having no DKIM at all. Copy the entire value.
DKIM also survives forwarding, where SPF does not. When a message is forwarded, the forwarding server is not in your SPF list and SPF fails; the DKIM signature still verifies. That is a large part of why both matter.
DMARC: the policy and the reports
DMARC does two jobs. It tells receiving servers what to do when SPF and DKIM fail, and it asks them to send you reports about mail claiming to be from your domain.
Publish it as a TXT record named _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:[email protected]
The policy value is the important part:
p=none, do nothing, just report. Where everyone starts.p=quarantine: send failing mail to spam.p=reject: refuse it outright.
Start at p=none and mean it
This is the step people rush, and the consequences are the kind you discover from an angry colleague.
Publish p=none, then read the reports for several weeks. They will show you every system sending mail as your domain, and there are always more than you remembered: a newsletter platform, an invoicing system, a form on an old site, a monitoring tool.
Add each legitimate sender to SPF and set up DKIM where they support it. Only when the reports show your real mail passing consistently should you move to p=quarantine, and later to p=reject.
Going straight to p=reject means every sender you forgot about is now being refused, silently, by everyone. The mail does not bounce back to you. It is simply gone.
Publishing the records
All three are TXT records. If DNS is managed on your hosting account, add them in the zone editor. For that, see using the zone editor in cPanel.
SPF and DKIM should be configured through cPanel's Email Deliverability page where possible, since it generates correct values for this server instead of making you assemble them.
DMARC is added by hand, at the name _dmarc.
Verify rather than assume
dig TXT yourdomain.com dig TXT _dmarc.yourdomain.com dig TXT default._domainkey.yourdomain.com
Then send a message to an account at a major provider and look at the received headers. They report the result of each check plainly. A pass on all three is what you are aiming for, and it takes a minute to confirm.
Common problems
Two SPF records. Merge into one. Two is a configuration error.
SPF passes for direct mail, fails on forwarded mail. Expected, and exactly why DKIM matters.
DKIM fails after a change. The published key no longer matches the signing key, or the record was truncated when copied.
DMARC reports arrive as unreadable XML. Correct: they are machine-readable. Point rua at an address you can feed into a report parser, or accept that you will skim them.
Mail still lands in spam with all three passing. Authentication is not reputation. A new IP address, or one with history, takes time to build trust, and content matters too. The email troubleshooting guide deals with the wider set of delivery problems.
If mail is already going out claiming to be from you, the rollout has an order that avoids breaking your own. See How to Stop Your Domain Being Used for Spoofing.
Your control panel can check all three per domain and show what should be published. For reading it, see How to Use the Email Deliverability Tool.
To see whether these checks actually passed for a given message, read its headers. How to Read Email Headers and Trace a Message goes into the line that answers it.