Configuring SPF, DKIM, and DMARC for reliable delivery

Gmail and Yahoo now require SPF, DKIM, and DMARC on any domain sending more than a handful of messages per day. Without all three, legitimate mail lands in spam within weeks. This article explains what each record does, publishes the correct values, and shows how to read DMARC reports.

What each record does

SPF: who is allowed to send

A TXT record at the domain root that lists every server authorized to send mail on your behalf. Receiving servers check the sending IP against this list. If the sender is not on the list, the message fails SPF.

DKIM: who actually sent

Each outgoing message gets signed with a private key; the public key is published in DNS. Receivers verify the signature. DKIM tells the receiver: yes, this message really originated from a server holding the private key for yourdomain.com.

DMARC: what to do when SPF or DKIM fail

A policy record. You tell receivers: if a message claiming to be from yourdomain.com fails both SPF and DKIM alignment, do this (none / quarantine / reject). DMARC also asks for reports, so you see who is sending mail as you.

SPF for Omega Digital mail servers

text

# If all mail originates from Omega Digital:
@   TXT   "v=spf1 +a +mx +ip4:198.51.100.42 ~all"

# If you also send via Google Workspace:
@   TXT   "v=spf1 include:_spf.google.com +a +mx ~all"

# If you also send via Mailgun, SendGrid, etc.:
@   TXT   "v=spf1 include:mailgun.org include:_spf.google.com +a +mx ~all"

A domain can only have ONE SPF record. Multiple SPF TXT records invalidate each other. Merge every sender into one includes chain.

DKIM from cPanel

cPanel generates DKIM keys automatically. Verify or regenerate them:

01. Open cPanel → Email Deliverability.
02. You will see a status list for each domain. Green = correct.
03. If DKIM is yellow or red, click Manage next to the domain, then Install the Suggested Record.
04. cPanel publishes a TXT record at default._domainkey.yourdomain.com if you use our nameservers. If you use external DNS, copy the record and add it yourself.

bash

# Verify DKIM public key is published
dig +short TXT default._domainkey.yourdomain.com

# Expected output (one line, truncated here for readability):
# "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUA..."

DMARC: start with monitoring, move to enforcement

Do not publish p=reject on day one. Start in monitoring mode, review the reports for a week or two, then tighten.

text

# Phase 1: monitoring only (publish this first)
_dmarc   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100"

# Phase 2: after 2 weeks of clean reports
_dmarc   TXT   "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25"

# Phase 3: once quarantine looks clean
_dmarc   TXT   "v=DMARC1; p=reject; rua=mailto:[email protected]"

The rua address receives aggregate reports: XML files summarizing pass/fail counts per sending IP. Tools like Postmark's free DMARC Digests or dmarcian make these readable.

Reading a DMARC report

A typical report entry looks like this, with one record per sending source per reporter per day:

xml

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
    <spf><domain>yourdomain.com</domain><result>pass</result></spf>
  </auth_results>
</record>

You want to see dkim=pass and spf=pass for every legitimate source. If an unfamiliar IP appears with fail results, either it's a forgotten service you need to add to SPF or it's a spoofer (in which case DMARC is doing its job).

Common gotchas

· Multiple SPF records. DNS allows it; SPF does not. Merge into one.
· SPF over 10 DNS lookups. Every include: counts. Too many lookups and SPF returns PermError. Consolidate providers or use SPF flattening.
· DKIM selector mismatch. Your mail server uses a specific selector (default, selector1, google). Publish the record at the matching subdomain.
· Jumping to p=reject immediately. Breaks legitimate mail you didn't know about (marketing automation, calendar invites from SaaS tools). Always monitor first.

Still stuck?

Email [email protected] with your domain and a recent test-email header, and we will decode the authentication results with you.