Skip to content
Koltrix
Start free trialOpen app
Guides

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.

Koltrix Team5 min read
Rows of metal mailboxes stuffed with letters and papers
Photo by Thierry Chabot on Unsplash
On this page(9 sections)
  1. Minute 1 to 3: look at what is already there
  2. Minute 3 to 5: is the list of senders complete?
  3. Minute 5 to 6: count the lookups
  4. Minute 6 to 8: read the DMARC record out loud
  5. Minute 8 to 9: publish once, in the right place
  6. Minute 9 to 10: confirm it, then send a test
  7. After it is live
  8. A short checklist
  9. Key takeaways

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 and DMARC record 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.
  • 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.

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 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.
  • 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.
  • 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.

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 reads them for you, in your browser.
  4. Run a domain check with the SPF, DKIM and 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, and 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.

Start with Koltrix

Your domain, one inbox, and an API that sends.

A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.

Start your 7-day free trialOpen KoltrixRead the docs
SharePost on XLinkedIn

Keep reading

More in Guides →