What goes into the record
The output always opens with v=spf1 and closes with the qualifier you picked, and the order between them is fixed: a, then mx, then your ip4 and ip6 entries, then one include per selected service and per extra domain. Duplicate includes are removed, and an include: prefix is stripped if you paste it into the extra includes box, so include:spf.example-crm.com and spf.example-crm.com give the same result.
With only Google Workspace ticked and the defaults left alone you get v=spf1 mx include:_spf.google.com ~all. If nothing is selected the record collapses to v=spf1 ~all, and the Checks card warns that this authorizes no server at all. That is the right record for a domain that never sends mail, provided you also publish a DMARC reject policy for it.
Choosing between mx, a and explicit ranges
mx authorizes whatever hosts your MX records point to. That fits a self-hosted server that both receives and sends, but with a hosted mailbox provider the MX hosts usually do not send your outbound mail, so the mechanism only spends a lookup. a authorizes the address your domain's A record points to, which is normally the web server. Tick it only if that server really sends mail, for example from a contact form.
An ip4 or ip6 term costs no lookup, so fixed addresses are the cheapest way to authorize a machine you control. Use a single address for one host and a CIDR range such as 198.51.100.0/24 for a block. Do not copy a provider's current addresses by hand instead of using their include. Their ranges change, and you will find out when mail starts failing.
Reading the Checks card
Failures are inputs the generator refused: an IPv4 or IPv6 value that is not an address or range, an include domain that is not a valid host name, or more than 10 top-level lookups. Invalid entries are dropped from the record until you fix them, so the output stays publishable.
The rest is advice. Seven or more lookups turns the lookup note into a warning, ?all is flagged as giving no protection, -all gets a reminder to list every sender first, and a record over 255 characters gets a note that most DNS hosts split long TXT values into 255-character strings for you while some expect you to do it yourself.
Publishing and verifying
At your DNS host, create a TXT record with the host name @ (or the bare domain, depending on the interface) and paste the value. If a v=spf1 record is already there, edit it instead of adding a second. The change spreads as the old TTL expires, so a check a minute later may still show the previous record.
The link under the output opens the SPF Checker for your domain. It expands every include and counts the full tree, which is the number receivers apply. If that count is close to 10, move a bulk-mail service to a subdomain with its own record. Then publish DKIM for each service and a policy from the DMARC Generator.
- Host @ (the root of the domain), type TXT, value the generated record.
- One v=spf1 record per name. A subdomain that sends mail needs its own.
- Changes take effect as the previous TTL expires, not instantly.
What the generator does not do
It does not query DNS. The provider includes are the documented ones for each service, but the generator cannot tell you whether a provider still uses that include, how many nested lookups it holds today, or whether your domain already has a record. Those are the questions the checker answers after you publish.
It also does not know your senders. Invoicing software, a ticketing system, a newsletter tool a colleague signed up for, or a printer that emails scans can all send as your domain and will fail SPF if they are missing. Aggregate reports read in the DMARC Report Analyzer list every source IP that used your domain, which is the dependable way to build the list.