SPF and DMARC Record Generator Guide

Email spoofing is the quiet back door into almost every phishing campaign. An attacker who can forge your domain name in the From header can impersonate your brand, your invoices, and your staff. SPF and DMARC exist to close that door, but they only work when the records are generated correctly. A single malformed TXT record does nothing to stop spoofing and can even break legitimate mail flow.

The good news: you do not need to hand-craft these records from memory. A reliable SPF record generator produces a syntactically valid record, but you still need to understand what you are publishing and why. This guide walks through SPF and DMARC from first principles, covers the SPF policy syntax you will actually use, and points out the mistakes that silently cripple a record.

What SPF and DMARC actually do

SPF (Sender Policy Framework) lets the owner of a domain publish a list of servers allowed to send mail from it. When a receiving server gets mail claiming to be from example.com, it looks up the SPF TXT record, checks whether the sending IP is listed, and applies the policy you set. SPF answers one question: is this IP authorized to send as this domain?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on top of SPF and DKIM. Instead of asking whether an individual message passed, DMARC tells receiving servers what to do when authentication fails: deliver it, quarantine it, or reject it. It also returns aggregate reports so you can see who is sending mail as your domain and whether it is passing.

SPF alone is easy to bypass because it does not cover the visible From address. DMARC closes that gap by requiring that the domain in the header aligns with the authenticated sending domain. Together they are the difference between a spoofable domain and a defended one.

SPF policy syntax, explained

An SPF record is a single TXT record at the root of your domain. It starts with a version tag and then a series of mechanisms, each ending with a qualifier that says what to do when the mechanism matches. The four qualifiers you will use are:

A realistic record looks like this:

v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

Breaking it down: v=spf1 declares the version, ip4:203.0.113.10 authorizes one mail server, include:_spf.google.com pulls in the list of servers that a provider like Google publishes, and ~all says every other sender is not you. The ~all soft-fail qualifier is the safe place to start because it lets you monitor results without dropping mail.

The most common SPF policy syntax mistakes are all with no qualifier (a pass-all record that authorizes every server in the world, meaning SPF does nothing), exceeding the ten DNS lookup limit, and accidentally listing IPv4 addresses as ip6. Every extra include counts toward the lookup limit, and a record that hits eleven lookups is treated as permanent error, which most receivers interpret as neutral.

Generating DMARC records correctly

A DMARC record is a TXT record at _dmarc.example.com with a v=DMARC1 tag. The two tags that matter most are p and pct. The policy (p=none, p=quarantine, or p=reject) sets the enforcement level, and pct controls what percentage of non-compliant mail it applies to.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100

This record asks receivers to send aggregate reports to dmarc@example.com and to quarantine mail that fails alignment. The rollout order is deliberately conservative: start at p=none, read the reports for a few weeks, then tighten to p=quarantine, and finally p=reject once you have confirmed every legitimate sender passes.

Generation is where most people get tripped up. The tags must be separated by semicolons and whitespace, the policy value must match one of the three legal options, and the record must be at _dmarc rather than the zone root. If you are unsure, use a DMARC record generator that emits the correct tag order and syntax, then validate the result before publishing.

The three failures that break email authentication

1. Incomplete coverage. You publish SPF and DMARC but forget the marketing platform, the transactional email provider, or the CRM that sends on your behalf. Their servers fail SPF, and once you enforce p=reject, real mail starts bouncing.
2. Mismatched alignment. DMARC requires the From domain to match the domain that passed SPF or DKIM. If your senders use a different envelope domain, alignment fails even though SPF itself passed.
3. Skipping the report step. Publishing p=reject on day one, without looking at rua reports, is how production mail dies. The reports are the instrument panel; ignore them and you are flying blind.

The fix for all three is the same: publish with p=none, study the aggregate reports until you recognize every sender, then enforce. Check your existing records with the tool below as a starting point.

Next steps

Run your current records through the SPF and DMARC generator, fix any syntax errors it finds, and publish a p=none DMARC policy with a report address. Revisit the reports in two weeks and tighten the policy.

More posts →