# Before you publish a generated SPF or DMARC record: a 10-minute review > A generator gives you a record in seconds. These checks decide whether it helps: look for an existing record, publish it once, and confirm it works. - Published: 2026-10-24 - Author: Koltrix Team - Category: Guides - Source: https://koltrix.com/blog/before-you-publish-a-generated-spf-or-dmarc-record-a-ten-minute-review Record generators are handy. You pick the services that send your mail, copy a line of text and paste it into your DNS settings. The risk is that the easy part feels like the whole job. A perfectly formed record published in the wrong way can break mail that worked yesterday, and it will not warn you. This post is a ten-minute review to run between "I have the record" and "it is live". It applies to any generator, including the free [SPF record generator](/tools/spf-generator) and [DMARC record generator](/tools/dmarc-generator) on this site, which run in your browser and do not upload what you type. ## Minute 1 to 3: look at what is already there The most common mistake is not a bad record. It is a second record next to a good one. - **Look up the current TXT records at the root of your domain.** If one already starts with `v=spf1`, you are editing it, not adding a new one. A domain with two SPF records gets a permanent error from receivers, and neither record counts. The cause and the fix are in [multiple SPF records and the permerror](/blog/multiple-spf-records-permerror). - **Look for `_dmarc.yourdomain.com`.** If a DMARC record is there, someone set it for a reason. Find out why before you replace it. - **Write down the old values.** Paste them in a note. If anything goes wrong, rolling back is a copy and paste instead of a guess. If a record exists, merge. Keep the services you already authorized, add the new ones, and end with a single policy. ## Minute 3 to 5: is the list of senders complete? SPF only helps if it names everyone who sends as your domain. Walk through the places mail comes from: 1. Your mailboxes (the service that hosts your email). 2. A website or app that sends receipts, password resets or form messages. 3. A newsletter or marketing tool. 4. A support desk or CRM that replies for you. 5. An old tool someone set up years ago that still sends something. A sender you forget will fail SPF once the record says "reject everything else". That is why a new record should end in the softer `~all` first, and move to `-all` only when you are sure the list is complete. For the larger picture of what each of the three records does, see [SPF, DKIM and DMARC in plain English](/blog/spf-dkim-dmarc-in-plain-english). ## Minute 5 to 6: count the lookups SPF allows at most ten DNS lookups when a receiver evaluates it. Every `include:`, `mx` and `a` costs one, and each include can contain more of its own. Past ten, receivers treat the record as an error. A generator can count what it sees, but it cannot see inside every provider's include. If the total is already near eight or nine, the real number may be over. [The SPF 10-lookup limit](/blog/spf-10-dns-lookup-limit) explains how to find the true count and what to cut. Dropping a service you no longer use is the cleanest fix. ## Minute 6 to 8: read the DMARC record out loud DMARC records are short enough to read in full. Read each part and ask whether it says what you mean. - **`p=none`** means "watch and report, take no action". It is the right starting point, but only if reports go somewhere you will read. - **`rua=mailto:...`** is where daily summary reports are sent. If this address is on a different domain than the one you are protecting, that other domain must publish a small record that agrees to receive them, or most receivers will not send anything. See [authorizing external DMARC report addresses](/blog/dmarc-external-report-authorization). - **`pct`** applies the policy to only part of failing mail. It is a gentle way to ramp up a stricter policy, and `100` is the default when it is left out. - **`adkim` and `aspf`** control how closely the domains must match. Relaxed is the default and is right for most small senders. The difference is covered in [DMARC alignment: relaxed or strict](/blog/dmarc-alignment-relaxed-strict). - **`sp`** sets a different policy for subdomains. Leave it out unless you have a reason; subdomains then follow `p`. If the record contains anything you cannot explain, remove it. A shorter record has fewer ways to be wrong. ## Minute 8 to 9: publish once, in the right place Publishing is where small mistakes creep in. - **The name matters.** The SPF record goes at the root of the domain (often shown as `@`). The DMARC record goes at `_dmarc`. Some DNS panels add your domain automatically, so entering `_dmarc.yourdomain.com` produces `_dmarc.yourdomain.com.yourdomain.com`. Check how your panel treats the name field. - **The type is TXT** for both. - **Paste the value as it is.** Do not add quotes unless your provider asks for them, and do not add line breaks. - **Lower the TTL first when you are replacing a record.** A short TTL means a mistake is corrected quickly. The reasoning is in [DNS TTLs and changes to email authentication](/blog/dns-ttl-auth-changes). Change one record at a time. If you change SPF, DMARC and DKIM together and mail breaks, you will not know which change did it. ## Minute 9 to 10: confirm it, then send a test After the change has had time to reach the resolvers: 1. **Look the record up again** and compare it, character for character, to what you meant to publish. 2. **Send a real message** from each system that sends as your domain to a mailbox you control. 3. **Open the headers** of what arrives and look for `spf=pass`, `dkim=pass` and `dmarc=pass`. The free [header analyzer](/tools/header-analyzer) reads them for you, in your browser. 4. **Run a domain check** with the [SPF, DKIM and DMARC checker](/tools/dmarc-checker) to see all three records as a receiver would. If a test message fails, do not change several things. Go back to the old value you saved, and work out which sender was missing from the list. ## After it is live A DMARC record at `p=none` is a starting line. The reports it generates tell you who is sending as your domain, including things you forgot about. Read them for a few weeks, fix the senders that fail, and only then consider a stricter policy. The staged approach is in [DMARC from none to reject](/blog/dmarc-none-to-reject-rollout), and [reading DMARC aggregate reports](/blog/reading-dmarc-aggregate-reports) shows how to make sense of what arrives. Koltrix generates the records for a domain you add and checks them live, so you are not copying anything by hand. If you set up DNS yourself elsewhere, the review above is the same. ## A short checklist 1. Look up the existing SPF and DMARC records and save the old values. 2. Merge into an existing SPF record. Never add a second one. 3. List every system that sends as your domain. 4. Count the SPF lookups and stay under ten. 5. Start with `~all` and `p=none`, with a report address you will read. 6. Check the name, type and value in your DNS panel before saving. 7. Change one record at a time, with a short TTL. 8. Look the record up again, send test mail from every sender and read the results in the headers. ## Key takeaways A generator saves you from typing syntax, not from thinking about your domain. Most failures come from a duplicate record, a forgotten sender or a typo in the name field, not from the record itself. Spend ten minutes checking what exists, what is missing and what you actually published, and a two-minute change stays a two-minute change.