Why You Need SPF, DKIM, and DMARC — and How to Set Them Up

If emails from your domain are landing in spam — or bouncing entirely — the most common cause isn't your message content. It's missing or misconfigured email authentication. SPF, DKIM, and DMARC are three DNS records that tell receiving mail servers your emails are genuinely coming from you, not an impersonator. Without them, providers like Gmail and Outlook have no way to trust your domain, and they'll often play it safe by routing your mail to spam.

This guide explains what each record does, why you need all three, and how to add them to your domain's DNS through your hosting control panel.

What each record actually does

Think of these three protocols as layers that build on each other, checked in order:

• SPF (Sender Policy Framework) lists which mail servers are allowed to send email for your domain. When a message arrives, the receiving server checks the sending IP against your SPF record. If it's not listed, the email looks unauthorized.
• DKIM (DomainKeys Identified Mail) attaches a digital signature to each outgoing email. The receiving server checks that signature against a public key published in your DNS, confirming the message wasn't altered after it was sent.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of both. It checks whether the domain shown in your "From" address actually matches the domain that passed SPF or DKIM, then tells receiving servers what to do with messages that fail — ignore it, quarantine it, or reject it.

Because DMARC depends on SPF and/or DKIM passing first, a broken SPF or DKIM record can cause DMARC failures even if your DMARC record itself is set up correctly. That's why all three need to be configured together, not just one or two.

Before you start

• Access to your domain's DNS zone editor (in cPanel, this is under Domains → Zone Editor)
• A list of every service that sends email on your domain's behalf (your website's contact form, a CRM, a marketing platform, etc.) — each one needs to be included in your SPF record
• The DKIM selector and public key provided by your email sending platform, if you use one outside of your hosting mailbox

Step 1: Add your SPF record

1. Log in to your hosting control panel and open the DNS zone editor for your domain.
2. Add a new TXT record for your root domain (e.g. yourdomain.com).
3. Set the value to v=spf1 followed by an include: entry for each service that sends mail on your behalf, ending in ~all or -all. For example:
   v=spf1 include:_spf.yourhostingprovider.com include:sendgrid.net ~all
4. Save the record. A domain should have only one SPF record — if you already have one, add your new include: statement to it instead of creating a second record, since two SPF records will cause both to be treated as invalid.

Keep your SPF record under 10 DNS lookups total (each include: typically counts as one). Going over this limit causes a permanent error that breaks SPF checking entirely — a good reason to remove any unused include: entries when you clean up.

Step 2: Add your DKIM record

1. Get the DKIM selector and public key from your email platform's settings (this is usually shown as a ready-to-copy DNS record).
2. In your DNS zone editor, add a new TXT record with the host set to selector._domainkey.yourdomain.com, replacing selector with the value your platform gave you.
3. Paste the public key as the record's value.
4. Save the record. Use a key length of at least 1024 bits — 2048 bits is the current best practice if your platform supports it.

Step 3: Add your DMARC record

1. Add a TXT record with the host _dmarc.yourdomain.com.
2. Start with a monitoring-only policy so you can see what's happening before you start blocking mail:
   v=DMARC1; p=none; rua=mailto:[email protected]
3. The rua= address is where providers will send you periodic reports showing which messages passed or failed authentication. Without it, you have no visibility into problems.
4. After a few weeks of reviewing those reports and confirming all your legitimate mail sources pass, move your policy from p=none to p=quarantine, and eventually p=reject, to actually start enforcing authentication.

Common issues

• Email still going to spam after setup: DNS changes can take up to 24–48 hours to propagate. If it's been longer than that, double-check each record with a DNS lookup tool to confirm it's published correctly.
• Two SPF records on one domain: Merge them into a single record — having both invalidates SPF checking entirely.
• DMARC fails even though SPF and DKIM pass individually: This usually means the domain in your visible "From" address doesn't match the domain authenticated by SPF or DKIM. Confirm your sending platform uses the same domain for both.
• Emails still land in spam with clean records: Authentication alone doesn't guarantee inbox placement — sender reputation (spam complaints, bounce rates, engagement) and sending history also matter, especially for newer domains.

FAQ

Do I need all three records?
Technically, SPF or DKIM alone will pass basic checks, but DMARC — which most major providers now expect for bulk senders — requires at least one of them to be correctly aligned. Setting up all three gives you the strongest protection and best deliverability.

Will this break my existing email?
No, as long as you don't skip legitimate sending sources when building your SPF record, and you start DMARC at p=none before moving to stricter enforcement.

How do I check if my records are working?
Use any public DNS lookup tool to query your domain for TXT, the DKIM selector record, and _dmarc.yourdomain.com, or send a test email to a mailbox and check its authentication headers.