SPF, DKIM and DMARC Explained: Stop Your Mail Going to Spam

If your server's emails keep landing in spam, or Gmail and Yahoo have started rejecting them outright, the cause is almost always a missing or misconfigured SPF, DKIM or DMARC record. These three DNS records are how mailbox providers verify that an email claiming to be from your domain is actually authorized to send on its behalf, and since 2024's bulk sender requirements from Gmail and Yahoo, having all three configured correctly is no longer optional for reliable delivery.

What each record actually does

• SPF (Sender Policy Framework): a DNS TXT record listing which mail servers are allowed to send email for your domain. When a receiving server gets mail claiming to be from you, it checks whether the sending server's IP is on your SPF list.
• DKIM (DomainKeys Identified Mail): attaches a cryptographic signature to outgoing mail, generated with a private key on your server and verified against a public key published in your DNS. This proves the message was not altered in transit and genuinely came from a server holding your private key.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): tells receiving servers what to do when a message fails SPF or DKIM checks (quarantine it, reject it outright, or do nothing), and where to send reports about authentication failures so you can monitor abuse of your domain.

Each one alone provides partial protection; together, they let a receiving mailbox provider confirm both that the message came from an authorized server and that it was not tampered with, which is exactly what modern spam filters weight heavily.

Setting up SPF

Add a TXT record at your domain's root with a value listing your authorized sending sources, for example: v=spf1 a mx include:_spf.yourserver.com ~all. The ~all at the end means "soft fail" anything not listed (mark as suspicious, do not hard-reject), while -all means "hard fail" (reject outright) — most guides recommend starting with a soft fail while testing, then tightening to a hard fail once you have confirmed no legitimate sending source is missing from the record.

Setting up DKIM

On cPanel, DKIM is generated automatically for each domain under Email → Email Deliverability, which shows whether the required DNS records are correctly published and lets you copy the exact values if your DNS is hosted elsewhere. Plesk offers the same functionality under Mail Settings. The key steps are the same regardless of panel:

1. Generate a DKIM key pair for the domain (most panels do this automatically when the domain is created).
2. Publish the public key as a TXT record at the selector's DNS name (typically something like default._domainkey.yourdomain.com).
3. Confirm the mail server is configured to sign outgoing messages with the matching private key — this is usually automatic once the DNS record is verified as correctly published.

Setting up DMARC

Add a TXT record at _dmarc.yourdomain.com with a policy value, starting conservatively: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. The p=none policy means "just send me reports, do not act yet," which lets you monitor authentication failures for a couple of weeks without risking legitimate mail being blocked. Once the reports show your legitimate sending sources are all passing SPF and DKIM cleanly, tighten the policy to p=quarantine and eventually p=reject for full protection against spoofing.

Common mistakes that keep mail landing in spam

Mistake	Effect
SPF record listing the wrong sending server	Legitimate mail fails SPF and lands in spam
Two SPF records on the same domain	SPF becomes invalid entirely — only one SPF TXT record is allowed per domain
DKIM signing enabled but DNS record never published	Every outgoing message fails DKIM verification
Jumping straight to p=reject on DMARC without testing	Legitimate mail from a source you forgot about gets silently rejected

Frequently asked questions

Do I need all three (SPF, DKIM and DMARC), or is one enough?

All three work together and address different gaps; SPF alone can still be bypassed in certain spoofing scenarios that DKIM and DMARC close, and major mailbox providers now expect all three for bulk senders.

Will setting these up guarantee my email stops going to spam?

It removes authentication failures as a cause, which is the most common technical reason for spam-folder placement, but content, sending reputation, and recipient engagement also affect spam filtering and are not controlled by these records alone.

Can I have more than one SPF record for different mail services?

No — only one SPF TXT record is valid per domain; if you use multiple sending services (your server plus a third-party marketing tool, for example), all authorized sources must be combined into that single record using include: statements.

Conclusion

SPF, DKIM and DMARC together are what modern mailbox providers expect before trusting mail from your domain, and misconfiguring any one of them is the most common reason legitimate emails end up in spam or get rejected outright. Set DMARC to p=none first and watch the reports for a couple of weeks, confirm every legitimate sending source passes SPF and DKIM cleanly, then tighten the policy — that order avoids the classic mistake of blocking your own mail before testing is complete.