Evidence and research

Can AI Write a Safe SPF Record?

By EmailmetryReviewed 3 min read

A convincing SPF record can still authorise the wrong services. Generating a record and keeping flattened IP addresses current are different jobs.

An SPF record written by AI can be perfectly valid and still leave out a service your business uses.

The problem is not necessarily a mistake in the syntax. A record can follow every formatting rule while describing the wrong set of authorised senders.

A correct-looking record can remove a working sender

Suppose a business authorises Microsoft 365 and a separate application in the same SPF record. Someone asks an AI assistant to “fix our Microsoft 365 SPF record”, and it returns a valid record containing only Microsoft 365.

Replacing the existing record with that answer would remove the other application’s authorisation.

Microsoft’s documentation distinguishes between a Microsoft 365-only setup and one with other senders. The right record depends on which setup you have. Microsoft’s SPF documentation

Publishing the suggestion as a second SPF record does not preserve both configurations. Multiple SPF records at the same DNS name cause an error. SPF standard, section 3.2

Compare the proposed record with the existing one

Here is a fictional version of that mistake, using reserved addresses:

VersionSPF record
Existing policyv=spf1 ip4:192.0.2.10 ip4:198.51.100.20 -all
Proposed replacementv=spf1 ip4:192.0.2.10 -all

Both records use valid SPF syntax. The second no longer authorises 198.51.100.20. If the invoice application still sends from that address, the edit breaks its authorisation even though a syntax check succeeds.

To preview this edit in the SPF change simulator, paste the existing policy and enter ip4:198.51.100.20 under Remove exact rules. The preview shows the rule change within the tool’s supported policy rules. It still needs the application owner to establish whether a removed sender is obsolete. This is an illustrative proposal, not a result from a recorded AI experiment.

Valid syntax can still leave out a sender

The existing SPF policy authorises staff email and the invoice application; a proposed replacement authorises only staff email, even though both have valid syntax.
This fictional proposal removes a sending address that the invoice application still uses. Syntax validation alone cannot establish which applications the business needs to authorise.
Read the diagram as text
  1. The existing record authorises both staff email and an invoice application.
  2. The proposed record has valid syntax but authorises only staff email.
  3. Publishing it removes the invoice application's authorisation if the application still uses that address.
  4. The existing senders and business requirements need checking before accepting a proposed edit.

Reading DNS helps, but leaves questions unanswered

An AI assistant with DNS tools can inspect current records and follow their references.

But public records describe what is authorised, not everything the business intends to send. An old service might still be listed after its contract ended. A new application might be sending without having been added correctly.

Deciding whether to keep or remove those services requires account settings, actual messages or confirmation from the people using them. A syntax check cannot supply that context either.

The service name is only part of the answer

Amazon SES normally uses an Amazon-owned MAIL FROM domain. SPF checks that domain, which can differ from the address the recipient sees. Amazon supplies the relevant SPF authorisation for this default setup.

If a customer configures a custom MAIL FROM domain, they must publish SPF for that domain instead. A recommendation based only on “we use Amazon SES” could put the change in the wrong place. Amazon SES documentation

Flattening needs more than a one-off answer

AI can help turn SPF references into a list of IP addresses. With suitable tools and correct inputs, that list could be accurate when generated.

Those addresses can change. A flattened record saved once will not update itself when a provider adds or removes sending infrastructure. Microsoft notes the maintenance required when replacing references with IP addresses. Microsoft’s SPF guidance

Automatic SPF flattening combines reduced lookup requirements with ongoing updates to the flattened addresses. A one-off generated record does not provide that maintenance.

AI can help explain or draft a change. Whether the result is suitable depends on the intended senders, the domain the message actually uses, and how the record stays current.

Sources and further reading

Sources reviewed 12 September 2026.