SPF, DKIM, and DMARC Setup: A Practical Guide With Real DNS Records

If your campaigns are bouncing with 550 5.7.26 or landing in the spam folder despite a clean list, the problem is probably authentication. SPF, DKIM, and DMARC are the three DNS records that let receiving servers verify your domain actually authorized the mail being sent in its name. Without them, Gmail and Microsoft 365 treat your domain as suspicious by default, especially since February 2024, when both started requiring SPF, DKIM, AND DMARC for bulk senders (more than ~5,000 messages per day).

This is the practical setup guide. What each record does, the real DNS entries to add for the common ESPs, how to verify each one is working, and the rollout sequence that doesn't accidentally start sending all your mail to quarantine.

01A 30-second mental model

When a receiving server gets a message claiming to be from [email protected], it needs to answer three questions:

1. Is the sending server allowed to send for this domain? SPF answers this with a list of authorized IPs/servers.
2. Has the message been tampered with in transit? DKIM answers this with a cryptographic signature.
3. What should I do if the answer to either is "no"? DMARC answers this by stating your policy (none / quarantine / reject) and giving you reports.

All three are DNS TXT records on your domain. None require code changes or product integrations. The setup is one-time work that compounds forever.

02SPF (Sender Policy Framework)

SPF is a TXT record that lists the IP addresses and hostnames allowed to send mail using your domain in the MAIL FROM envelope. When a receiver checks SPF, it looks up your TXT record and confirms the sending server is on the list.

What the record looks like

A typical SPF record for a domain that sends via Google Workspace + SendGrid + Mailgun:

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all"

Breakdown:

• v=spf1: version marker, always present
• include:<domain>: pulls in the authorized senders that domain has published. Use the one your ESP tells you to use.
• ~all: "softfail" anything not in the list. Other options: -all (hardfail, riskier), ?all (neutral, useless), +all (allow everything, never use this).

How to add it

Go to your domain registrar's DNS settings (Cloudflare, Namecheap, GoDaddy, Route 53, etc.). Add a new record:

• Type: TXT
• Name: @ (or your domain root)
• Value: the SPF string above, customized for your senders
• TTL: 3600 (1 hour) is fine

Common pitfall: multiple SPF records

Only one SPF record per domain is allowed. If you already have an SPF record (e.g., your registrar created one when you set up email), don't add a second one. Merge the new senders into the existing record. Multiple SPF records cause a permerror and SPF fails entirely.

Verify it works

dig +short TXT yourdomain.com | grep spf1

Or use MXToolbox SPF lookup for a web view. A green checkmark means SPF is published; a red flag usually means syntax error or multiple records.

03DKIM (DomainKeys Identified Mail)

DKIM is a cryptographic signature added to outgoing messages. The sending server signs the message with a private key; the receiver fetches the matching public key from your DNS and verifies the signature. If the signature is valid, the message hasn't been tampered with and the sender controls the domain.

What the record looks like

The DKIM record lives at a subdomain like <selector>._domainkey.yourdomain.com. Your ESP gives you the selector name and the public key value.

Example for SendGrid:

s1._domainkey.yourdomain.com.  IN  CNAME  s1.domainkey.uXXXXXX.wlXXX.sendgrid.net.
s2._domainkey.yourdomain.com.  IN  CNAME  s2.domainkey.uXXXXXX.wlXXX.sendgrid.net.

SendGrid uses CNAME records that point at their managed DKIM. Other ESPs publish a TXT record directly:

mailgun._domainkey.yourdomain.com.  IN  TXT  "k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

How to add it

Get the selector + key from your ESP's domain authentication settings (every major ESP has a one-click setup that generates this). Add the record(s) at your registrar. CNAME and TXT are both fine; use whichever format your ESP provides.

Common pitfall: rotating keys

Some ESPs rotate DKIM keys periodically for security. If you use the CNAME format (SendGrid, Mailgun's "automatic" mode), key rotation happens transparently. If you use TXT with the public key inline, you need to manually update the record when the ESP rotates, otherwise signing breaks and messages start failing DKIM.

Verify it works

dig +short TXT s1._domainkey.yourdomain.com

Or send yourself a test message and view the raw headers in Gmail (Show original → look for dkim=pass).

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

DMARC ties SPF and DKIM together. It tells receivers what to do when authentication fails AND it gives you aggregate reports about who's sending mail using your domain (legitimately or otherwise).

What the record looks like

A starter DMARC record:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

Breakdown:

• v=DMARC1: version marker
• p=none: the policy: do nothing, just report. Used during rollout.
• rua=mailto:...: where receivers send aggregate reports (XML files showing what passed/failed authentication)
• pct=100: what percentage of failing mail to apply the policy to

The policy escalation (this is the part everyone gets wrong)

DMARC policies go: none → quarantine → reject. Always start at none. Never start at reject.

The mistake: a sender sets p=reject on day one, assumes their SPF/DKIM is correct, and silently kills all their own mail for the next week because something (a forgotten newsletter tool, a CRM that sends transactional mail, a calendar invitation system) wasn't authenticated. By the time anyone notices, customer-facing email has been bouncing or quarantined for days.

The safe rollout:

1. Week 1-2: p=none. Watch the DMARC reports come in (services like Postmark DMARC Monitoring, EasyDMARC, dmarcian, or Valimail parse the XML for you). Identify every legitimate sender that's failing SPF or DKIM.
2. Week 3-4: Fix the gaps. Add SPF includes for missed senders. Set up DKIM where it wasn't. Re-check reports.
3. Week 5-6: Move to p=quarantine; pct=10. 10% of failing mail goes to spam; you can still see in reports if legit senders are caught.
4. Week 7-8: Increase pct gradually: 25 → 50 → 100. Each step, watch the reports for new legitimate failures.
5. Week 9+: Move to p=reject. Mail that fails authentication is rejected outright. This is the final state; most senders never need to leave p=quarantine; pct=100.

A common alternative if you can't run reports: stay at p=quarantine; pct=100 indefinitely. It's nearly as good as p=reject for protecting your domain from spoofing, and slightly safer.

Verify it works

dig +short TXT _dmarc.yourdomain.com

Or MXToolbox DMARC lookup. The DMARC report tools above are also worth setting up day one; without them, you're flying blind through the rollout.

05Why all three together (and not just one)

A few senders set up SPF and call it done. SPF alone is meaningfully weaker than the combination, because:

• SPF only checks the envelope MAIL FROM, not the visible From: header. A spammer can pass SPF for their own domain while showing your domain in the From line.
• DKIM proves the message wasn't tampered with, which SPF can't.
• DMARC ties From-header alignment to the SPF/DKIM result, which is what closes the spoofing hole.

Modern receivers (Gmail, Microsoft 365, Yahoo) increasingly require all three for bulk senders. February 2024 was the inflection point. Gmail and Yahoo both made SPF + DKIM + DMARC mandatory for senders above ~5,000 messages per day. Microsoft 365's equivalent requirement is rolling out through 2026.

06Where verification fits in this picture

Authentication and list quality are two halves of the same deliverability problem.

• Authentication (SPF/DKIM/DMARC) tells the receiver the message came from who it claims to come from. Fixes spoofing, fixes the 550 5.7.x family of bounces.
• Validation (the kind MailCull does) tells the sender this address is real before you send. Fixes the 550 5.1.1 family of bounces and the open-rate damage from sending to dead mailboxes.

You can have impeccable authentication and still bounce at 8% because the list is full of dead addresses. You can have a perfectly clean list and still land in spam because DMARC failures tag your domain as suspicious. The healthy sender does both.

07What MailCull does on the validation side

For every address we verify, we run the full SMTP probe and surface the protocol reply in the evidence chain. If you're investigating why a campaign bounced more than expected, the SMTP reply per row tells you whether each bounce was an address problem (you needed verification) or an authentication problem (you need to look at the receiver's 5.7.x codes and check your DMARC reports).

Start free: 500 credits/month, no credit card. The validation half of deliverability; SPF/DKIM/DMARC remains your job at the DNS level.

Want to check your own records right now? The free SPF checker, DKIM checker, and DMARC checker each show the raw record and flag the common mistakes, no account needed.