Email Going to Spam? Fix SPF, DKIM & DMARC Records
A customer emails your sales inbox from Gmail, hits send, and it's the last you ever hear from them — because their reply landed in your spam folder, or your first email never left your server's queue. Nine times out of ten, this isn't a hosting problem. It's a missing or broken DNS record. Here's how to actually fix it, not just "try again later".
Symptom: mail bounces, or lands in spam
You'll usually see one of these:
- Emails you send go straight to the recipient's spam/junk folder
- You get a bounce-back like
550 5.7.1 SPF check failedor550 5.7.26 Unauthenticated email is not accepted - Gmail shows a red question mark next to your name and "via getwebup.in" under it
- Your own domain's mail arrives fine internally but never reaches @gmail.com or @outlook.com addresses
All of these point to the same root cause: the receiving mail server can't verify that your email actually came from you.
Cause: your domain's DNS doesn't say who's allowed to send mail
Every mail server that receives your email checks three things before deciding whether to trust it, deliver it, or bin it: SPF, DKIM, and DMARC. If even one is missing or misconfigured, providers like Gmail, Outlook, and Yahoo start treating your mail as suspicious — and since February 2024, Gmail and Yahoo actively enforce this for anyone sending more than ~5,000 emails/day, and apply it loosely to everyone else too.
Here's what each record actually does:
| Record | Purpose | What breaks without it |
|---|---|---|
| MX | Tells the internet which server accepts incoming mail for your domain | You can't receive email at all, or it silently disappears |
| SPF | Lists which servers are allowed to send mail as your domain | Receiving servers see an unauthorized sender and reject or flag the mail |
| DKIM | Signs outgoing mail with a private key so receivers can verify it wasn't tampered with | Mail looks unsigned/unverified — a strong spam signal |
| DMARC | Tells receivers what to do if SPF/DKIM fail, and where to send reports | Receivers fall back to their own judgment, which usually means spam |
Fix: set up the records correctly, in the right order
Do this from your domain's DNS zone. If your domain is hosted through Getwebup, that's cPanel → Zone Editor; if your nameservers point elsewhere (Cloudflare, GoDaddy, etc.), add these records there instead — MX and email records must live wherever your domain's authoritative DNS actually is.
Step 1: Confirm your MX record exists and is correct
In cPanel, go to Zone Editor → Manage and look for an MX entry. For Getwebup-hosted email it should look like:
yourdomain.com. MX 10 mail.yourdomain.com.If you're using Google Workspace or Microsoft 365 instead, delete any old hosting-provider MX record first, then add the provider's exact MX records — running two sets of MX records is a common cause of mail vanishing entirely.
Step 2: Add or fix your SPF record
SPF is a single TXT record at the root of your domain. Only one SPF record is allowed — if you already have one, edit it rather than adding a second (that's an automatic SPF failure).
Type: TXT
Host: @
Value: v=spf1 include:secureserver.net include:_spf.google.com ~allAdjust the include: entries for whatever actually sends mail on your behalf — your hosting mail server, Google Workspace, Mailchimp, SendGrid, whatever you use. Missing one of these is the #1 reason "we sent a newsletter and it all bounced" tickets show up.
Step 3: Enable DKIM
In cPanel, go to Email → Email Deliverability. It scans your domain and tells you exactly which records are missing. Click Repair next to DKIM and cPanel will generate the key pair and publish the public key as a TXT record automatically, something like:
Type: TXT
Host: default._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSq...If you're on Google Workspace instead, generate the DKIM key from Admin Console → Apps → Gmail → Authenticate Email, then add that TXT record to your DNS instead of cPanel's.
Step 4: Publish a DMARC policy
Start conservative — monitor before you enforce:
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comp=none means "just tell me what's happening, don't reject anything yet." Watch the aggregate reports for a week or two, confirm your legitimate mail is passing, then tighten it:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.comOnce you're confident nothing legitimate is failing, move to p=reject for the strongest protection against spoofing.
Step 5: Verify it actually worked
Don't just trust that you typed it right. Two quick checks:
- Send a test email to mail-tester.com and check the SPF/DKIM/DMARC lines in the report
- In cPanel, revisit Email → Email Deliverability — all three should show green
DNS changes can take anywhere from a few minutes to a few hours to propagate, so if a record still shows as missing right after you add it, wait 30–60 minutes and re-check before assuming it failed.
Prevention: keep it healthy going forward
- Whenever you add a new email tool (a CRM, a transactional email API, a marketing platform), add its SPF
includeand DKIM selector before you start sending from it, not after the bounces start - Review your DMARC aggregate reports occasionally — they'll show you if someone else is trying to spoof your domain
- Never let SPF grow past 10 DNS lookups (nested includes count) — it silently fails validation if it does; keep the include list trimmed
- If you migrate mail providers, update MX, SPF, and DKIM together in the same change window so nothing sends unauthenticated in between
Get these four records right once and your mail just works — no more guessing why a customer never replied.
Frequently asked questions
Do I need SPF, DKIM, and DMARC, or is one enough?
You need all three. SPF and DKIM each verify the mail in a different way, and DMARC ties them together by telling receiving servers what to do when a check fails. Having only SPF, for example, still leaves your domain open to spoofing and doesn't stop mail from landing in spam.
I added the DNS records but mail is still going to spam. Why?
Give it a few hours for DNS to propagate, then re-check with mail-tester.com. If the records show as valid but mail still lands in spam, look at content-based spam triggers (too many links, spammy subject lines) and your sending reputation — a domain with no sending history or a shared IP with a poor reputation can still get flagged even with perfect DNS.
Can I have two SPF records if I use two email providers?
No — having two separate SPF TXT records causes an automatic SPF failure (a "permerror"). Combine every sending source into one record using multiple include: mechanisms, e.g. v=spf1 include:_spf.google.com include:sendgrid.net ~all.
What does the ~all vs -all at the end of an SPF record mean?
~all (soft fail) tells receivers to accept but flag mail from unlisted senders as suspicious; -all (hard fail) tells them to reject it outright. Start with ~all while you confirm your SPF include list is complete, then switch to -all once you're confident nothing legitimate is being missed.
Where do I add these DNS records if my domain uses Cloudflare nameservers?
Add them in the Cloudflare DNS dashboard instead of cPanel's Zone Editor — whichever service holds your domain's authoritative nameservers is where MX, SPF, DKIM, and DMARC records need to live. Make sure the TXT and MX records are set to "DNS only" (grey cloud), not proxied.