Email Deliverability for Hosting: SPF, DKIM, and DMARC (No More Spam Folder)
Why Your Emails End Up in Spam (and How to Fix It)
You have built a solid website, set up a professional email address on your domain, and started sending invoices, order confirmations, or newsletters to your customers. Then one day you learn that half of them never arrived. They were not lost in transit — they were quietly dumped into spam folders by receiving mail servers that did not trust your domain.
The root cause, in most cases, is missing or misconfigured email authentication records. SPF, DKIM, and DMARC are three DNS-based mechanisms that prove to the world that your emails are legitimate. Without them, receiving servers have no reliable way to distinguish your messages from spoofed ones sent by bad actors abusing your domain name.
This guide walks through each protocol in practical terms, explains how they work together, and gives you a step-by-step path to getting your email deliverability on solid ground.
Understanding the Problem: Email Spoofing
Email was designed in an era when trust was assumed. The SMTP protocol — the foundation of email delivery — does not verify the sender's identity by default. Anyone can send an email claiming to be from your domain. Spammers and phishers exploit this constantly, which is exactly why mailbox providers aggressively filter messages that lack authentication.
When your domain has no SPF, DKIM, or DMARC records, receiving servers treat your emails with suspicion. You look exactly the same as a spammer who forged your address. Authentication records change that dynamic by giving receiving servers a way to verify that you actually authorized the message.
SPF: Declaring Who Can Send on Your Behalf
Sender Policy Framework (SPF) is a DNS TXT record that lists the IP addresses and servers authorized to send email for your domain. When a receiving server gets an email from your domain, it checks the SPF record to see if the sending server's IP is on the approved list.
A basic SPF record looks like this: v=spf1 include:_spf.google.com include:sendgrid.net -all. This tells the world that Google Workspace servers and SendGrid are allowed to send email for your domain, and everything else should be rejected (-all).
Common SPF Mistakes
- Too many DNS lookups: SPF has a limit of 10 DNS lookups per evaluation. Each
include:counts as one, and nested includes count too. Exceeding this limit causes SPF to fail entirely — which is worse than not having SPF at all. - Using
+allor?all: These effectively disable SPF enforcement. Use~all(soft fail) during testing and-all(hard fail) in production. - Forgetting services: If your application sends transactional emails through a third-party service, that service must be included in your SPF record. A common oversight is adding your email provider but forgetting your CRM, helpdesk, or marketing automation tool.
DKIM: Signing Your Messages Cryptographically
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing email. The sending server signs the message with a private key, and the corresponding public key is published in your DNS as a TXT record. When the receiving server gets the message, it retrieves the public key and verifies that the signature matches — proving that the message was not altered in transit and that it genuinely came from an authorized source.
DKIM is typically set up through your email provider or sending service. They generate the key pair and give you a DNS record to publish. The record looks something like: selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...". The "selector" is a label that allows you to have multiple DKIM keys — useful when you use different services for different types of email.
DKIM Best Practices
- Use 2048-bit keys: Older 1024-bit keys are still common but increasingly considered weak. Use 2048-bit keys for stronger security.
- Rotate keys periodically: Key rotation — generating new keys and updating DNS records — limits the exposure window if a key is compromised. Rotate at least annually.
- Sign with your own domain: Some email services sign messages with their own domain by default. Configure them to sign with yours for alignment with DMARC.
DMARC: The Policy Layer That Ties It Together
Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM by adding a policy that tells receiving servers what to do when authentication fails. It also provides a reporting mechanism so you can see who is sending email on behalf of your domain — both legitimate services and unauthorized sources.
A DMARC record is published as a DNS TXT record at _dmarc.example.com. A starting configuration looks like: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. The p=none policy means "do not take action on failures, just send reports." This is the correct starting point — you need to review reports before enforcing a policy.
The DMARC Rollout Path
- Start with
p=none: Collect aggregate reports for two to four weeks. Review them to identify all legitimate email sources sending on behalf of your domain. - Ensure SPF and DKIM alignment: For DMARC to pass, either SPF or DKIM must pass and be aligned with the From domain. Alignment means the domain in the SPF check or DKIM signature matches the domain in the visible From header.
- Move to
p=quarantine: Once all legitimate sources are properly authenticated, set the policy to quarantine. Failing messages get sent to spam instead of the inbox. - Advance to
p=reject: The strongest policy. Failing messages are rejected outright — they never reach the recipient. This fully protects your domain from spoofing.
How SPF, DKIM, and DMARC Work Together
Think of these three as layers of a single defense system. SPF verifies the sending server. DKIM verifies the message content and origin through a signature. DMARC defines the enforcement policy and ensures that at least one of the other two passes with proper alignment.
A message that passes both SPF and DKIM with alignment is highly trusted. A message that fails both is almost certainly spoofed or misconfigured. DMARC gives receiving servers a clear instruction on how to handle each scenario, removing guesswork from the equation.
Practical Steps for Hosting Customers
Here is a concrete action plan for getting your email authentication right:
- Inventory all email sources: List every service that sends email using your domain — email hosting, transactional email services, marketing platforms, CRM, helpdesk, notification systems.
- Publish SPF: Create a single TXT record that includes all authorized sources. Stay within the 10-lookup limit. Test with an SPF validation tool.
- Enable DKIM for each source: Configure DKIM signing in each email service and publish the corresponding DNS records. Verify signatures with online DKIM checkers.
- Deploy DMARC at
p=none: Add the DMARC record and set up a mailbox or reporting service to receive aggregate reports. - Review reports and fix alignment issues: Spend two to four weeks analyzing reports. Fix any services that are failing SPF or DKIM alignment.
- Tighten the policy: Move to
p=quarantineand thenp=rejectas confidence grows.
Monitoring and Maintenance
Email authentication is not a set-and-forget task. New sending services get added, IP addresses change, and DKIM keys should be rotated. Build a habit of reviewing DMARC reports monthly. Many free and commercial DMARC reporting tools parse the XML reports into readable dashboards that show authentication pass rates, failure sources, and trends over time.
Also monitor your domain's sender reputation through mailbox provider postmaster tools. These dashboards show spam complaint rates, authentication success rates, and any issues that might affect deliverability. A sudden spike in failures usually means a new email source was added without updating SPF or DKIM.
The Bottom Line
SPF, DKIM, and DMARC are not optional extras — they are the minimum standard for email that actually reaches inboxes. Without them, your domain is vulnerable to spoofing, your emails land in spam, and your brand reputation suffers with every undelivered message. The setup takes an afternoon. The payoff lasts as long as your business sends email. Get it done, monitor it, and keep it current.