SPF and DMARC Record Generator

What this tool does

It builds the two DNS records that authenticate your email — SPF and DMARC — through a wizard, and warns you about the mistakes that genuinely hurt before you publish them.

It exists because the catalogue had nineteen checkers and no generator: you could learn that your SPF was missing, but not obtain the one you need to publish. And this is the side where getting it wrong is expensive: a badly built SPF does not block spam, it kills your own mail.

SPF: the order and the limit

An SPF record declares which servers may send mail on your domain’s behalf. Two things break it, and both are invisible at a glance.

There can only be one

The spec allows exactly one SPF record per domain. With two, the receiver does not combine them: the check fails and it is left with nothing to act on.

This happens constantly. You sign up for an invoicing service, it asks you to publish its SPF, you add it as a new TXT record, and without noticing you have just broken authentication for all of your mail. The correct move is to merge the includes into a single record, which is what this generator does when you tick several providers.

The 10-lookup limit

Every include, a, mx or exists mechanism forces the receiving server into an extra DNS query, and the spec cuts off at ten. Past that point evaluation returns permerror and your SPF stops protecting anything.

The treacherous part is that includes nest: Google Workspace’s spends four lookups on its own, because it includes others internally. Three or four providers and you are already brushing the limit with a record that looks short.

This tool’s counter adds the real lookups, not the mechanisms you can see, and turns red when you go over. If you do: replace a provider’s include with its direct IPs using ip4:, which cost no lookup.

The final qualifier

This is what you tell the receiver about anyone not on the list:

• -all (reject) — the recommendation once you have identified all your senders.
• ~all (suspicious) — where to start. It marks without rejecting, so a forgotten sender does not vanish: it arrives flagged and you find out.
• ?all (neutral) — asserts nothing, so it barely helps.
• +all — never publish this. It authorises the entire internet to send as you, and it is worse than having no SPF because it looks like protection where there is none.

DMARC: the part almost nobody finishes

DMARC tells the receiver what to do when SPF and DKIM fail, and asks it to send you reports of what it sees.

The policy has three steps, and the usual mistake is stopping at the first:

1. p=none — observe only. You collect reports, nothing is blocked. It is the correct starting point.
2. p=quarantine — to spam.
3. p=reject — refused at the door.

The real benefit lives in the second and third. With p=none, an attacker spoofing your domain still lands in the inbox; the only change is that you find out. But moving up too early kills your own invoicing, so the path is: publish p=none with rua, wait a few weeks, read the reports, fix the legitimate senders that fail, and then move up.

The tag you cannot omit

rua is the mailbox where aggregate reports arrive. Without it, DMARC does nothing for you: you do not know who sends in your name, you do not know which of your senders fail, and you have nothing to decide when to tighten with. It is the most useful tag in the record and the most frequently forgotten.

ruf, forensic reports, is a different matter: it carries content from real emails — with the privacy implications that brings — and very few providers send them. You can comfortably do without it.

Where each record goes

If your provider asks for the full name rather than the relative one, the tool shows it below the record.

Why DKIM is not generated here

Because it is not a record you write: it is a public key. DKIM works with a key pair — your mail server signs each message with the private key, and the receiver verifies it with the public one you publish in DNS. Your mail provider generates that pair and hands you the exact value to paste.

What you can do here is see where it goes, and check it afterwards with the DKIM checker.

After publishing

DNS changes take time to propagate, from minutes to a few hours depending on the TTL. Once they do, verify with the domain health report, which checks all three at once and tells you what is left to do.