7 min read

If your emails are landing in spam or recipients aren’t getting them at all, the problem is usually missing or broken email authentication records. SPF, DKIM, and DMARC are three DNS records that prove to receiving mail servers that your emails are legitimate.

Why This Matters

Without proper authentication:

  • Emails from your domain can land in spam folders
  • Anyone can spoof your domain and send emails pretending to be you
  • Large providers like Gmail, Outlook, and Yahoo may reject your emails outright (since February 2024 Google and Yahoo require SPF, DKIM and a DMARC record, even p=none, from bulk senders)

Reliable delivery to the large providers now needs all three records.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses and mail servers are allowed to send email on behalf of your domain.

How It Works

You add a TXT record to your domain’s DNS that lists your authorized mail servers. When someone receives an email from your domain, their server checks this record. If the sending server isn’t on the list, the email fails SPF.

Setting Up SPF

The safest SPF record names the exact server that sends your email, and nothing else. You don’t have to work that out yourself. In cPanel, go to Email Deliverability, click Manage next to your domain, and use the SPF record shown there. It already contains your server’s IP address; change its ending from ~all to -all. On Enhance, the record is created for you (see Email Authentication in Enhance).

If you add the record by hand, it takes this form, with YOUR.SERVER.IP replaced by the IP address of your hosting server:

  Type:  TXT
Host:  @
Value: v=spf1 ip4:YOUR.SERVER.IP -all

If your server also has an IPv6 address, add it as ip6: (for example v=spf1 ip4:YOUR.SERVER.IP ip6:YOUR:SERVER::IPV6 -all), or mail sent over IPv6 will fail SPF. The cPanel record already includes it when one exists.

If you also send email through other services (like Google Workspace or Mailchimp), include them too:

  v=spf1 ip4:YOUR.SERVER.IP include:_spf.google.com include:servers.mcsv.net -all

You will also see the shortcut v=spf1 a mx ~all (Enhance creates it by default). It works, but it authorizes whatever your A and MX records point to, which can include a CDN or a shared IP, and it changes whenever your DNS does. Listing the server IP is tighter.

Important rules:

  • You can only have one SPF record per domain. If you need multiple providers, combine them into a single record using multiple include: statements.
  • The ending decides what happens to mail from servers that aren’t listed. See Hard fail or soft fail? below.
  • SPF has a 10 DNS lookup limit. Each include: counts as one lookup. If you hit this limit, your SPF record will break.

Hard fail or soft fail?

The last part of the record tells receiving servers how to treat mail from a server that isn’t listed:

EndingMeaningWhat receivers usually do
-allHard fail: unlisted servers are not allowed to send for this domainTreat the message as unauthenticated; a few reject it immediately
~allSoft fail: unlisted servers probably aren’t allowedAccept it, but count the failure against it (often spam folder)

We show -all in our examples because a record built from your server’s own IP address is precise, and -all states that clearly. It is stricter, not automatically safer, so know the trade-off:

  • Forwarded mail fails SPF. When a recipient forwards your message, or it passes through a mailing list, it arrives from a server that isn’t on your list. Most large providers (Gmail, Outlook) then check DKIM and DMARC before deciding, so the message still gets through. A few servers reject on the SPF hard fail alone, before DKIM is checked.
  • A forgotten sender bounces. If a newsletter tool, CRM or invoicing service sends as your domain and isn’t in the record, -all makes its mail fail outright.

If you’re not yet sure every service that sends for you is listed, start with ~all, set up DKIM and DMARC, and switch to -all once your DMARC reports show every legitimate sender passing. Either way, the real protection against spoofing comes from DKIM plus a DMARC policy of quarantine or reject, not from the SPF ending alone.

Testing SPF

Send a test email to a Gmail address and click “Show original” in Gmail. Look for:

  SPF: PASS

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to every outgoing email. The receiving server verifies this signature against a public key stored in your DNS. If the signature matches, it proves the email wasn’t tampered with in transit.

How It Works

Your mail server signs each outgoing email with a private key. The corresponding public key is published as a DNS record. Receiving servers use the public key to verify the signature.

Setting Up DKIM

DKIM setup depends on your mail server. On GoZen Host shared hosting with cPanel:

  1. Log in to cPanel
  2. Go to Email Deliverability (under the Email section)
  3. Find your domain and click Manage
  4. If DKIM is not installed, click Install the suggested record
  5. cPanel will automatically add the DKIM DNS record

For VPS or dedicated servers, DKIM is typically configured through your mail server software (Exim, Postfix) or control panel (Enhance, Plesk).

The DNS Record

A DKIM record looks like this:

  Type:  TXT
Host:  default._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... (public key)

The default part is the selector - it varies depending on your hosting provider.

Testing DKIM

In the same Gmail “Show original” view, check for:

  DKIM: PASS

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when an email fails authentication checks. It also lets you receive reports about emails sent using your domain.

How It Works

DMARC checks whether the “From” domain in an email aligns with the domain that passed SPF or DKIM. If neither aligns, DMARC fails, and the receiving server follows your DMARC policy.

Setting Up DMARC

Add a TXT record to your DNS:

  Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]

DMARC Policies

PolicyWhat It DoesWhen to Use
p=noneMonitor only - emails are delivered normally, but you receive reportsStart here to understand your email traffic
p=quarantineFailed emails go to the spam folderAfter you’ve confirmed legitimate emails pass
p=rejectFailed emails are blocked entirelyFull protection, once you’re confident nothing legitimate will fail

Recommended approach: Start with p=none for 2-4 weeks, review the reports, then move to p=quarantine, and finally p=reject.

Understanding DMARC Reports

Reports are sent to the email address in the rua= field. They’re XML files that show:

  • Which IP addresses sent email using your domain
  • Whether those emails passed or failed SPF/DKIM
  • How many emails were sent

Use a free tool like DMARC Analyzer or Postmark’s DMARC tool to make the XML reports readable.

Verification Checklist

After setting up all three records, verify them:

CheckTool
SPF record syntaxMXToolbox SPF Check
DKIM recordMXToolbox DKIM Lookup
DMARC recordMXToolbox DMARC Lookup
Full email testSend a test email to mail-tester.com
GoZen Host DNS Toolstools.gozenhost.com

A perfect setup looks like this in email headers:

  SPF:   PASS
DKIM:  PASS
DMARC: PASS

Common Mistakes

  • Multiple SPF records. You can only have one. Combine all providers into a single record.
  • Missing DKIM. SPF alone is not enough. Gmail and Yahoo now require DKIM for bulk senders.
  • Jumping straight to p=reject. Start with p=none and monitor before enforcing.
  • Forgetting subdomains. If you send email from shop.yourdomain.com, set up SPF/DKIM/DMARC for that subdomain too.

Last updated 21 Oct 2026, 00:00 +0300. history

Was this page helpful?