Build the email authentication DNS records per provider, count SPF lookups against the limit of 10, generate a DKIM key and follow the Gmail and Yahoo sender rules.
Since February 2024, Gmail requires SPF or DKIM from every sender and SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day, with the spam rate under 0.3% (Google recommends staying under 0.10%). Yahoo asks for the same from bulk senders, with a DKIM key of at least 1024 bits and unsubscribes processed within 2 days. This tool builds each record as TXT, MX or CNAME with the name and value ready for your DNS panel. For SPF, you tick your providers and the tool writes each include (for example include:_spf.google.com for Google Workspace and include:spf.protection.outlook.com for Microsoft 365), each one checked against the provider's official help page. SPF has a hard limit: at most 10 DNS lookups, counting include, a, mx, exists and redirect, and also counting what sits inside each include. Ip4, ip6 and all cost nothing. The meter shows the local floor and, with one click, follows the chain over DNS-over-HTTPS to give the real number and the void lookups (maximum 2). Records over 255 characters go in several strings, and the 450-character warning follows RFC 7208. For DMARC, you choose p, sp, pct, rua, ruf, alignment and fo, and get a staged rollout plan from none to reject. RFC 9989, published in May 2026, replaces RFC 7489, drops pct, ri and rf and adds np, psd and t, and the tool generates both syntaxes. DKIM generates a 2048-bit RSA pair in the browser with WebCrypto, sending nothing to a server, though the best path is still your own provider's key. BIMI, MTA-STS and TLS-RPT complete the set. Everything runs in the browser.
Paste the code into your HTML and the tool shows up on your page, without J-Kit's navigation and ads. It still runs in the browser of whoever visits your site.
<iframe
src="https://jkit.tools/embed/en-US/spf-dkim-dmarc-generator"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="SPF, DKIM, DMARC and BIMI Record Generator"
></iframe>These references help contextualize formulas, standards, APIs and limitations used on this page. They do not replace professional validation when a result has legal, financial, medical or operational impact.
RFC 7208 caps at 10 the terms that cause a DNS query: include, a, mx, ptr, exists and redirect. Ip4, ip6 and all do not count, but each include counts plus whatever lookups exist inside it. Above 10 the result is a PermError and the whole SPF is ignored. There is also a limit of 2 void lookups, queries that return nothing. Use Count real lookups to follow the chain and see the total.
The example works without typing anything. Enter your domain to get complete record names.
include:_spf.google.comofficial sourceIncludes checked against each provider's help pages on 2026-10-18. If your provider is not here, use the field below.
~all: soft fail. Accept and flag. The default on Google Workspace's page and a good place to start.
@example.com
v=spf1 include:_spf.google.com ~all
Include, a, mx, exists and redirect cost one lookup each; ip4, ip6 and all cost none. The limit is 10 in total, counting what is inside each include.
Prefer the key your provider generates (Google Workspace, Microsoft 365, SES and others): it also signs your messages and handles rotation. A key generated here only helps if you configure your own mail server to sign with the private key. Never share or commit the private key.
The selector is the prefix of the record name: mail._domainkey. It lets you hold several keys at once and rotate without breaking signing. Use one name per key and per service, for example with the year.
Generate or paste a public key to see the DKIM record.
Use what its panel shows. Google Workspace publishes a TXT at google._domainkey by default, and Microsoft 365 uses two CNAMEs at selector1._domainkey and selector2._domainkey. Type and value come from the provider: this tab is for people who generate the key themselves. After publishing, check it in the SPF, DKIM and DMARC checker.
Tags p, sp, pct, rua, ruf, adkim, aspf, fo and ri. Every receiver understands them.
none: monitor and send reports only. Nothing is blocked. The starting point of any rollout.
Blank uses dmarc@your-domain. Several addresses separated by spaces. Addresses on another domain need an authorization record.
In practice receivers only apply 0 and 100 reliably (RFC 9989, appendix A.6). In-between values work as a transition with no guarantee.
Optional. See the privacy warning. Many receivers do not send them.
0: when everything fails. 1: when any check fails. d: DKIM failure. s: SPF failure. Only matters with ruf.
Stay at each step long enough to read the reports and fix every legitimate sender that fails. There is no fixed duration; a few weeks per step is common.
v=DMARC1; p=none; rua=mailto:[email protected]
Delivery does not change. You only receive reports.
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
The policy applies to only part of the failures. Receivers do not always honor in-between values.
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]
The policy applies to only part of the failures. Receivers do not always honor in-between values.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Failures go to spam. Fix legitimate senders before reject.
An SVG Tiny PS file over HTTPS, hosted on your domain.
The certificate comes from a certificate authority. The tool does not validate the certificate or the logo design.
XDMARC with p=quarantine or reject (Gmail does not accept p=none).
OKNo pct below 100 and no test mode.
?A VMC or CMC issued by a certificate authority. It cannot be checked here.
The first two lines follow the policy on the DMARC tab.
Enter the logo or certificate URL to build the record.
Turn on MTA-STS or TLS-RPT to generate the records.
Google's page treats as bulk anyone sending more than 5,000 messages a day to personal Gmail accounts. Yahoo does not define the term.
Every sender needs at least one of the two on the sending domains.
Bulk senders need both.
Bulk senders need a DMARC policy, even p=none, and the message must pass it.
The From header domain must align with the SPF or the DKIM domain. Relaxed alignment is accepted.
1024 bits minimum for Gmail and Yahoo. Google recommends 2048.
Yahoo strongly recommends the rua tag. Without it you do not see failures.
Each sending IP needs a PTR pointing to a name, and that name must resolve back to the same IP. Yahoo prefers a meaningful, non-generic PTR.
Google requires TLS when transmitting email.
Track it in Google Postmaster Tools. Google recommends staying under 0.10% and never reaching 0.30%.
Follow RFC 5322 (Yahoo also cites 5321): a single address in From, a valid Message-ID, single-instance headers not repeated.
Include List-Unsubscribe with a URL and List-Unsubscribe-Post with List-Unsubscribe=One-Click (RFC 8058). The header generator is right below.
Marketing and subscribed messages need a clearly visible unsubscribe link in the body.
Yahoo asks for unsubscribes to be processed within 2 days.
Yahoo asks for an active complaint feedback loop for all DKIM domains.
Do not send with an @gmail.com From address from servers that are not Google's. Google warns that it affects delivery.
Paste the HTTPS URL that receives the unsubscribe POST and, optionally, an email address. The headers follow what Google's page describes (RFC 2369 and RFC 8058).
Panels change their screens. Check the full-name preview before saving: it should match the smaller line under each record name.
@example.com
v=spf1 include:_spf.google.com ~all
Records are built in your browser. No domain, key or address is sent to any server. The optional real SPF lookup count only asks public DNS for the names of the includes.