Choose the business identity before editing DNS
FreeAgent can send estimates and invoices using its own default From identity or a verified custom domain. Decide which identity customers should see and which mailbox should receive their replies. Document the invoice and estimate workflows, their owner and the DNS administrator before changing either. A finance application's successful send is not the same as proof that the intended business domain authenticated.
The reviewed FreeAgent guide says the default From address is noreply@remail.freeagentcentral.com. A domain you own can be authorized through a custom-domain setup; a consumer mailbox on a shared public domain cannot give you control over that domain's DNS. Verification of an individual address and authorization of its domain are distinct steps. Source: FreeAgent, Authorise FreeAgent to send emails from your business address.
Complete the current custom-domain workflow
Open Settings > Sending Emails, choose Add a Custom Email Domain and select a domain associated with a verified sender address. If it is absent, first add and verify an address on that domain. Copy the host/key and value information displayed in step 2 into the authoritative DNS service, then return and add the domain. FreeAgent checks those records. Source: FreeAgent's custom-domain guide.
Treat the account's displayed records as authoritative for this setup. Do not replace them with a historical selector, key or SPF value found in an old article. Capture the record types, complete owner names, values and date in the change record. If the screen and documentation differ, resolve the discrepancy before proceeding rather than combining both generations of setup.
Inspect existing records at each owner before editing. A TXT public key and a verification token can have different purposes even when both appear in one wizard. Preserve other applications' entries. The registrar and DNS host may differ: verify the delegated nameservers instead of assuming the company where the domain was purchased publishes its records.
Review the SPF instruction in context
The current FreeAgent guide names include:spf.mtasv.net when an existing strict SPF policy ends in -all. It says a separate new SPF policy is not generally needed for its workflow. Do not substitute an older FreeAgent include found elsewhere. Source: FreeAgent's SPF section.
That product instruction is not a reason to remove a working SPF policy, weaken its final qualifier or assume all mail now passes DMARC. If an SPF change is needed, merge the authorization into the one existing policy after inventorying all senders and checking DNS-lookup limits. Preserve other services. Keep this narrow authorization task separate from a domain-wide policy redesign.
Verify the change using a controlled invoice route
Before testing, avoid a real customer transaction or financial commitment. Use an authorized test workflow and a controlled recipient, with clearly fictitious content. Record which FreeAgent workflow sent the message and whether its visible From matches the approved business address. Check Reply-To independently by inspecting and, where appropriate, testing the reply destination.
Retain the original received message with trusted receiver Authentication-Results, From, envelope identity and DKIM signing domain/selector. SPF authenticates the envelope identity, not automatically From. DKIM verifies a signature associated with its d= domain. DMARC needs a passing SPF or DKIM identity aligned with From under the applicable alignment mode. Product verification and inbox appearance cannot replace this evidence.
Synthetic example: an estimate arrives with From accounts@example.com, SPF pass for a provider-owned envelope domain, and DKIM pass with d=example.com. The exact-match DKIM signature can provide the aligned DMARC path; unrelated SPF success cannot. If a later message uses the provider's default From, it may authenticate correctly for that default identity while still failing your branding acceptance condition. Treat delivery and intended identity as separate outcomes.
Diagnose reversion and retain safe recovery
FreeAgent warns that removing or changing its required DNS records can make the custom domain unverified and revert the From address to its default; it also sends a notification. Monitor the operational consequence of a DNS migration, not only whether the new zone loads. Preserve the required records when changing DNS providers, and test the customer-facing workflows afterward.
If validation fails, compare the account values with authoritative DNS, checking owner-name suffix duplication and omitted characters before waiting for cache expiry. If the configuration is correct but mail is missing, retain the exact sending status and receiver evidence and investigate delivery separately. Do not promise that a time delay alone will fix the problem.
Before removing historical FreeAgent-specific records, confirm they are obsolete and not used by another active route. Keep a reversible copy and an approved known-working sender arrangement. Completion requires account verification, authoritative records and actual received-message evidence for relevant invoice and estimate routes. This documentary guide performed none of those live operations; independent review, human SME approval and publication remain pending.
Classify a delivered estimate without inventing a payment test
Written case FA-01 assumes the approved From is accounts@example.com, but a fictitious estimate sample shows the documented provider default From after required DNS records were removed. The receiver authentication result and Reply-To are unknown. Successful delivery alone cannot establish either the intended identity or aligned authentication for example.com. The finance workflow owner should reconcile current account verification and DNS with the administrator, then use an authorized non-binding test and inspect the actual sender and reply fields. Do not create a real invoice or payment obligation merely to obtain headers. No customer, transaction, record or message was accessed for this case.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.