Every HostDango account comes with SPF, DKIM, and DMARC records already configured. Most customers have never heard of them. That’s fine — they’re working in the background whether you know about them or not. But if your email is landing in spam, or you’re about to start sending newsletters or transactional email, or you just want to understand what’s actually protecting your domain, this is the post.
Plain English. No unnecessary jargon. Everything you actually need to know.
Why This Matters More Than It Used To
A few years ago, SPF, DKIM, and DMARC were considered best practices — things serious senders did but nobody enforced. That era is over. Google and Yahoo made SPF, DKIM, and a published DMARC record mandatory for bulk senders in early 2024. Microsoft followed with strict enforcement in May 2025. In 2026, mail that fails authentication gets rejected at the server level before it ever reaches an inbox.
For most small business owners sending normal transactional email — contact form notifications, order confirmations, client correspondence — you’re not sending at bulk volume and you’re unlikely to hit enforcement thresholds. But misconfigured or missing records still hurt deliverability, make you easier to spoof, and will cause problems if you ever start a newsletter or marketing campaign. It’s worth understanding what you have and whether it’s set up correctly.
SPF: Who’s Allowed to Send Email for Your Domain
SPF stands for Sender Policy Framework. It’s a DNS record — a TXT record on your domain — that lists the mail servers that are authorized to send email on behalf of your domain.
Here’s the problem it solves: without SPF, anyone can send an email that claims to be from you@yourdomain.com. The “From” field in an email is just text — there’s nothing stopping a spammer from putting your address there. SPF gives receiving mail servers a way to check: did this email actually come from a server I recognize as belonging to this domain?
When a receiving server gets an email claiming to be from your domain, it checks your SPF record and compares the sending server’s IP address against the list. If it matches, the email passes SPF. If it doesn’t, the email fails — and what happens next depends on your DMARC policy (more on that below).
Your SPF record looks something like this in your DNS:
v=spf1 +a +mx +ip4:YOUR.SERVER.IP ~allThe ~all at the end is a “soft fail” — it says that email from unlisted servers should be treated with suspicion but not outright rejected. A -all is a “hard fail” — reject it. More on soft vs hard fail in a moment.
DKIM: Proof the Email Wasn’t Tampered With
DKIM stands for DomainKeys Identified Mail. Where SPF verifies where an email came from, DKIM verifies that the email wasn’t modified in transit.
Here’s how it works: when your mail server sends an email, it adds a digital signature to the message headers. That signature is generated using a private key that only your server knows. Your DNS contains the corresponding public key. When a receiving server gets the email, it uses the public key to verify the signature. If the signature checks out, the email is confirmed to have come from your server and to be unmodified since it left.
What this prevents: man-in-the-middle attacks where someone intercepts your email and changes the content before it’s delivered. Without DKIM, a receiving server has no way to know whether the email it received is the same email that was sent.
DKIM shows up in your DNS as a TXT record under a selector subdomain — typically something like default._domainkey.yourdomain.com.
DMARC: What to Do When SPF or DKIM Fails
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s the policy layer that sits on top of SPF and DKIM and tells receiving servers what to do when an email fails authentication.
SPF and DKIM can both pass, both fail, or one can pass while the other fails. DMARC takes those results and applies a policy you’ve defined. There are three possible policies:
- p=none — Do nothing. Monitoring mode only. Failed emails are delivered normally, but reports are sent to you so you can see what’s failing. This is where you start when you’re figuring out your email flow.
- p=quarantine — Send failed emails to the spam folder instead of the inbox. The email still gets delivered, just not to the inbox.
- p=reject — Reject failed emails outright. They don’t get delivered at all. This is full enforcement.
DMARC also has a reporting function — it can send you aggregate reports showing which servers are sending email claiming to be from your domain, and whether those emails are passing or failing authentication. This is how you find out if someone is spoofing your domain.
How SPF, DKIM, and DMARC work together
Soft Fail vs Hard Fail — What the Difference Actually Means
This is the part that trips people up. In your SPF record, the all mechanism at the end determines what happens to email from unlisted servers:
~all(tilde) = soft fail — the email is suspicious but should be accepted and possibly marked. Most receiving servers will deliver it, maybe to spam.-all(minus) = hard fail — the email should be rejected. Receiving servers that enforce SPF will not deliver it.+all(plus) = pass everything — don’t use this. It means any server can send as your domain, which defeats the entire purpose.
The right choice depends on your setup. If you’re confident that your SPF record lists every single legitimate source of email for your domain — your hosting server, any third-party services you send from — a hard fail is stronger protection. If you’re not sure whether you’ve captured everything, a soft fail lets you enforce gradually while monitoring for legitimate email that might be failing.
For most small business accounts on HostDango with a single mail server and no third-party email services, a soft fail is a reasonable default. If you add a newsletter service like Mailchimp or a transactional service like SendGrid, you’ll need to add their sending servers to your SPF record — otherwise their email will fail SPF and potentially get marked as spam.
How to Check Your Records Right Now
MXToolbox is the tool for this. It’s free and it tells you everything.
Check SPF:
Go to MXToolbox, select SPF Record Lookup from the dropdown, enter your domain. It’ll show you your current SPF record and flag any issues — too many DNS lookups, missing includes, syntax errors.
Check DKIM:
Select DKIM Lookup, enter your domain and selector. For cPanel hosting the selector is typically default. So for yourdomain.com you’d enter default as the selector. It’ll show you the public key and confirm the record exists.
Check DMARC:
Select DMARC Lookup, enter your domain. It’ll show your current DMARC policy and flag anything misconfigured.
All three should pass with no errors. If any of them show red, open a support ticket and we’ll look at the DNS records with you.
What HostDango Sets Up By Default
Every account on HostDango gets SPF, DKIM, and DMARC records created automatically when the domain is added. The defaults are:
- SPF: Authorizes your hosting server to send mail for your domain, with a soft fail for everything else
- DKIM: Enabled via cPanel with a 2048-bit key — the current recommended key size
- DMARC: Set to
p=none— monitoring mode, no enforcement, reports sent to the admin address
The DMARC p=none default is intentional. It lets you see what’s passing and failing before you enforce anything. If you want to move to quarantine or reject, you can — but do it after checking the MXToolbox reports to make sure you’re not accidentally blocking legitimate email first.
One thing to be aware of: if you add any third-party service that sends email on your behalf — a newsletter tool, a booking system, a CRM with email capabilities — you’ll need to add that service’s sending infrastructure to your SPF record. Missing that step is one of the most common reasons marketing email ends up in spam despite everything looking correct on the surface. If you’re not sure how to add a third-party sender to your SPF record, open a ticket.