Business Security

How to Set Up SPF and DMARC Records Correctly in 2026

Email spoofing still works on most domains because SPF and DMARC records are misconfigured. Here's how to get them right the first time.

📅 Jul 27, 2026·⏱️ 6 min read·✍️ Cikal Studio Labs
📧

Why Your Domain Is Still Spoofable in 2026

Every year, business email compromise (BEC) costs organizations billions of dollars, and a huge share of it starts with a spoofed "From" address that looks like it came from your own domain. The tools to stop this — SPF, DKIM, and DMARC — have existed for over a decade, yet a surprising number of company domains still have no DMARC record at all, or an SPF record with a syntax error that silently breaks it. Getting these three records right is one of the highest-leverage security changes a small business can make, and it costs nothing but a few DNS edits.

The Three Records, in Plain Language

  • SPF (Sender Policy Framework) — a TXT record on your domain that lists which mail servers are allowed to send email as you. Receivers check the sending server's IP against your list.
  • DKIM (DomainKeys Identified Mail) — a cryptographic signature added to outgoing mail, verified against a public key published in your DNS. This proves the message wasn't altered in transit and really came from a server holding your private key.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance) — a policy record that tells receivers what to do when SPF and/or DKIM fail (nothing, quarantine, or reject), and where to send reports about who's sending mail as your domain.

DKIM keys are generated by your mail provider (Google Workspace, Microsoft 365, SendGrid, etc.), so this article focuses on SPF and DMARC, which you build and publish yourself.

Common SPF Mistakes That Break Deliverability

  1. Missing the terminal "all" mechanism. Every SPF record should end in ~all (soft-fail) or -all (fail). Without it, unauthorized senders get an ambiguous "neutral" result instead of an explicit rejection.
  2. Exceeding the 10-lookup limit. RFC 7208 caps SPF at 10 DNS lookups. Every include:, a, mx, ptr, and exists mechanism counts toward that limit. Stack too many third-party include: statements (a CRM, a marketing tool, a helpdesk, a payroll provider) and your SPF record silently starts failing with a "permerror."
  3. Publishing two SPF records. A domain must have exactly one SPF TXT record. If a new tool tells you to "just add this SPF record," and you already have one, you need to merge the mechanisms into a single record, not add a second one.
  4. Using +all. This explicitly allows any server on the internet to send mail as your domain. It is effectively the same as having no SPF record, but worse, because it looks intentional.

Common DMARC Mistakes

  1. No rua reporting address. Without aggregate reports, you have zero visibility into who is actually sending email using your domain — including attackers testing your defenses.
  2. Jumping straight to p=reject. Start with p=none to monitor for a few weeks, fix any legitimate senders that fail alignment, then move to p=quarantine and eventually p=reject.
  3. Malformed rua/ruf syntax. These must be mailto: URIs, e.g. rua=mailto:dmarc@yourdomain.com. A bare email address without the mailto: prefix is invalid.
  4. Invalid pct values. The percentage tag must be an integer between 0 and 100 — anything else is ignored or treated as an error by strict validators.

Step-by-Step: Getting It Right

  1. List every service that legitimately sends email as your domain — your office 365/Google Workspace, your CRM, your marketing platform, your support desk, your payroll provider.
  2. Build an SPF record that includes exactly those services, using -all once you're confident the list is complete.
  3. Publish a DMARC record starting at p=none with a rua address you actually monitor.
  4. Watch the aggregate reports for 2-4 weeks. Fix any legitimate sender that shows up failing alignment.
  5. Move to p=quarantine, then eventually p=reject once reports are clean.
  6. Re-check your live DNS periodically with dig TXT yourdomain.com and dig TXT _dmarc.yourdomain.com — configuration drift happens as teams add and remove tools.

Getting SPF and DMARC right isn't a one-time task — it's something worth re-validating every time you add a new sending tool to your stack. A quick syntax check before you publish a change catches the vast majority of real-world mistakes before they ever reach a live DNS record.

← Back to BlogShare on X →