SPF, DKIM & DMARC record generator

What the generator builds from your four inputs

Type a sending domain, choose the provider that actually delivers your mail, pick a policy and optionally a reporting mailbox, and the tool assembles two DNS TXT records ready to paste. The domain is tidied as you type: a pasted scheme and everything after the first slash are stripped, so the host names come out right even when you paste a full URL from the address bar. Leave the field blank and the records fall back to a clearly marked placeholder domain.

The provider choice does one job — it selects the include mechanism inside the SPF value. Google Workspace resolves to the Google SPF include, Microsoft 365 to the Outlook protection include, Amazon SES and SendGrid to their own, and the custom option leaves an obvious placeholder for you to replace with whatever your provider documents.

Everything is assembled in the page as you type. That matters here more than on most calculators, because a DMARC reporting mailbox is a real address you probably do not want handed to a third party just to see a sample record.

Reading the SPF value it gives you

The record comes out as a version tag, one include for your provider, and a soft-fail mechanism at the end. The tilde on that last mechanism asks receivers to accept but mark anything that did not come from an authorised host, which is the safe setting while you confirm you have listed every system that sends on your behalf. Publish it at the root of the domain rather than on a subdomain host.

The rule broken most often is publishing more than one. A domain is allowed exactly one SPF record; when a receiver finds a second, evaluation returns a permanent error and you effectively lose both. If your help desk, your newsletter platform and your mailbox provider all send as you, every one of those includes belongs inside the same single record. Keep an eye on the lookup budget too — each include costs DNS lookups during evaluation, and a chain that grows long enough fails no matter how correct it reads.

Choosing a DMARC policy and tightening it safely

DMARC does two jobs at once. It tells receivers how to treat mail that fails alignment, and it asks them to send you aggregate reports about everything claiming to be you. The record written here enables failure reporting, sets strict alignment on both SPF and DKIM, and points the aggregate reports at the address you supply — or at a dmarc mailbox on the domain itself if you leave that field empty. It belongs on the _dmarc host, not the root.

p=none

Monitoring only. Delivery is unaffected, but the reports start arriving, and those reports are the only way to discover the legitimate senders you had forgotten about. Begin here every time.

p=quarantine

Failures are diverted to the spam folder. Move here once the reports have shown a stretch of your genuine sending passing alignment with no unexplained sources left in the list.

p=reject

Failures are refused outright. This is the end state and the one that stops others spoofing your brand, but it also punishes any legitimate source you have not authorised yet, so it is the last move rather than the first.

Why DKIM comes as steps instead of a finished record

DKIM is the one part no generator can hand you complete, and that is a property of the protocol rather than a shortcoming. The key pair is created by your provider, the private half never leaves them, and only they can tell you the public half to publish. So the panel gives you the exact route to your own key for the provider you selected.

The shape differs by provider. Google issues a TXT record you publish under the google selector on your domain. Microsoft 365 uses two CNAMEs, selector1 and selector2, pointing into its own service, with signing switched on in the admin portal after the records resolve. Amazon SES gives you three CNAMEs through its Easy DKIM flow, and SendGrid follows the same pattern with two. Publish them exactly as supplied, including any trailing dot your DNS host expects.

Then wait before you test. Records that look wrong minutes after publishing are usually just not visible yet, and the common failure after that is a mismatch between what is signed and what you send: if you later add a subdomain or a relay that rewrites the envelope, relax the two strict alignment tags to their relaxed form before you tighten the policy, or legitimate mail starts failing the moment you leave monitoring.