Your website loads fine, SSL is green, everything looks normal — but your emails keep landing in the recipient's spam folder, or worse, bounce outright with a message like "550 5.7.1 not authorized." Nine times out of ten this isn't a mail server problem. It's a missing or misconfigured DNS record. Let's walk through the four records that control whether your mail gets delivered, marked as spam, or rejected: MX, SPF, DKIM, and DMARC.
Symptom: Mail Bounces or Lands in Spam
A few patterns that point straight at DNS:
- Emails sent from your domain go to the recipient's Junk/Spam folder, especially at Gmail and Outlook.
- You get a bounce-back mentioning SPF, DKIM, or "sender not authenticated."
- Mail simply never arrives, with no bounce at all — often an MX record pointing at the wrong host.
- Gmail shows a small "via" tag next to your domain name in the sender line, or flags the message with a warning banner.
If any of that sounds familiar, check your DNS zone before you touch anything on the mail server itself.
Cause: One (or All Four) Records Are Missing or Wrong
Modern mail providers — Gmail, Outlook, Yahoo — verify that a message actually came from where it claims to. Since early 2024, Gmail and Yahoo made SPF and DKIM mandatory for any domain sending more than a handful of messages a day, and DMARC is quickly becoming the same. If even one of these records is absent, inconsistent, or points at the wrong provider, your legitimate mail gets treated as suspicious.
Here's what each record actually does:
| Record | Purpose | What breaks without it |
|---|---|---|
| MX | Tells the internet which server accepts mail for your domain | Mail bounces or never arrives |
| SPF | Lists which servers are allowed to send mail "from" your domain | Mail from unauthorized IPs gets rejected or spam-flagged |
| DKIM | Cryptographically signs outgoing mail so it can't be altered in transit | Receiving servers can't verify the message wasn't tampered with |
| DMARC | Tells receivers what to do if SPF/DKIM fail, and where to send reports | Spoofed mail using your domain goes unchecked; your own mail may fail delivery |
Fix: Set Up All Four Records Correctly
1. MX Record
In cPanel, go to Zone Editor (or WHM > DNS Zone Manager on a VPS) and confirm the MX record points at your actual mail host. For cPanel's built-in mail server, this is usually just your domain itself:
Type: MX
Name: yourdomain.com
Priority: 0
Destination: yourdomain.comIf you're using Google Workspace or Microsoft 365 instead of cPanel mail, delete the default MX record and add the provider's MX records exactly as they give them to you — priority numbers matter, don't guess them.
2. SPF Record
SPF is a single TXT record listing every server allowed to send as your domain:
Type: TXT
Name: yourdomain.com
Value: v=spf1 +a +mx include:_spf.google.com ~allSwap include:_spf.google.com for whatever you actually use — for cPanel-only mail, v=spf1 a mx ~all is often enough. The critical rule: you can have only one SPF record per domain. If you use both cPanel mail and a marketing tool like Mailchimp, merge them into one record with multiple include: statements rather than adding a second TXT record — two SPF records will cause validation to fail entirely.
3. DKIM Record
In cPanel, go to Email Deliverability under the Email section. It shows you exactly what DKIM (and SPF) records should look like and flags anything missing with a red "Not Valid" badge. Click Repair and cPanel will push the correct records to the zone automatically if you're using its DNS. A DKIM record looks like this:
Type: TXT
Name: default._domainkey.yourdomain.com
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSq...If you're using an external mail provider (Google Workspace, 365, SendGrid), generate the DKIM key from that provider's admin console instead — the selector name (the part before ._domainkey) will differ.
4. DMARC Record
Add this once SPF and DKIM are both passing. Start in monitor-only mode so you don't accidentally block your own mail:
Type: TXT
Name: _dmarc.yourdomain.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comAfter a week or two of reviewing the reports and confirming everything authenticates cleanly, tighten the policy to p=quarantine, and eventually p=reject once you're fully confident no legitimate mail is being caught.
Verify the Records Actually Propagated
Don't just trust cPanel's dashboard — check the live DNS from the command line:
dig TXT yourdomain.com +short
dig TXT default._domainkey.yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short
dig MX yourdomain.com +shortIf these come back empty right after adding records, give it 15-30 minutes for propagation. If they're still empty after an hour, double check the record was saved against the correct DNS zone — this is the most common mistake when a domain's nameservers point somewhere other than where you're editing.
Once the records resolve, send a test email to check-auth@verifier.port25.com or use mail-tester.com — both will show you a pass/fail breakdown for SPF, DKIM, and DMARC in plain English.
Prevention: Keep Deliverability Healthy Long-Term
- Whenever you add a new sending tool (a CRM, a form plugin, a newsletter service), update your SPF
include:list rather than creating a second TXT record. - Revisit cPanel's Email Deliverability page after any migration or nameserver change — moving hosts is the single most common way DKIM records get silently lost.
- Review DMARC aggregate reports (the
rua=address) monthly. They'll show you exactly which servers are sending mail as your domain, which is often how people first discover a spoofing attempt or a forgotten sending service. - Don't jump straight to
p=rejecton DMARC. Move from none to quarantine to reject over a few weeks so you catch anything misconfigured before it starts bouncing real mail.
Frequently Asked Questions
Do I need all four records, or is SPF alone enough?
SPF alone used to be enough, but Gmail and Yahoo now require both SPF and DKIM to pass for any meaningful volume of mail, and increasingly expect a DMARC record too. Set up all four if you send mail from your domain at all.
I already have an SPF record from my hosting provider. Can I add another one for Google Workspace?
No — having two separate SPF TXT records breaks validation for both. Combine them into a single record with multiple include: mechanisms, for example v=spf1 include:_spf.google.com include:mailgun.org ~all.
How long does it take for these records to start working after I add them?
DNS propagation for a single record is usually 15 minutes to a couple of hours, though it can take up to 24-48 hours in rare cases depending on TTL settings and resolver caching. Test with dig before assuming something's broken.
What does DMARC's p=none actually do?
It tells receiving mail servers to take no enforcement action on failures, but still send you reports. It's the safest starting policy — you get visibility into who's sending as your domain without risking your own mail being blocked while you're still verifying everything is correct.
My DKIM shows "Not Valid" in cPanel even though I set it up. What's wrong?
This almost always means the domain's nameservers point somewhere other than cPanel's own DNS (e.g., Cloudflare), so cPanel can generate the record but can't publish it. In that case, copy the exact DKIM value cPanel shows you and add it manually in your actual DNS provider's dashboard.
