The Adelante provider in this guide is Adelante Software's go2pay.uk payment platform. Its official Emails & SPF documentation concerns messages such as payment links sent on a customer's behalf. Do not confuse this service with an unrelated company that shares the Adelante name.
The retained first-party page captured for the earlier documentary review identifies an April 2022 update. It supplies a sending IP and does not establish current custom DKIM or custom Return-Path capabilities. This guide therefore provides a bounded SPF configuration and verification method. It does not claim a fully demonstrated DMARC-capable Adelante route.
Confirm the documented sender before changing DNS
The official page asks the customer's IT team to incorporate 37.35.91.34 into the SPF DNS record. Adelante Emails & SPF
Because the page is old, confirm that this IP still applies to the payment product and account in use before production publication. A successful retrieval of a documentation page does not prove that its sending infrastructure has remained unchanged. Obtain the actual envelope identity from a controlled received payment-link email or current provider guidance, then identify the SPF owner name that receivers evaluate.
An IPv4 address is authorized with an SPF ip4: mechanism. It is not converted to an include: term: include evaluates another domain's SPF policy. Do not infer that a numeric-looking include means an IP authorization. Preserve existing authorized senders in the one policy at the relevant name and place any new mechanism before the terminal all term. SPF specification
Build a narrow proposed change
Illustrative syntax only, conditional on current provider confirmation and the observed SPF identity: an existing v=spf1 include:mail.example.net -all policy could become v=spf1 include:mail.example.net ip4:37.35.91.34 -all. The example include domain is invented, not an instruction to publish it. The exercise shows preserving another authorization and the policy's terminal qualifier while adding an IP mechanism.
Capture the before-and-after DNS diff, the business owner, confirmation of current service use and the planned test. Do not modify the apex merely because it appears in the visible From address if the actual SPF identity is elsewhere. Do not change receiving MX records: the cited Adelante page does not call for that action.
Do not turn an SPF pass into an unsupported DMARC claim
After an authorized test through the real payment-link workflow, record visible From, envelope identity and SPF result, every DKIM signature's domain and receiver result, and DMARC outcome. SPF must both pass and align to contribute to DMARC. If it authenticates an unrelated provider domain, adding authorization to your visible From domain does not necessarily change that identity.
The reviewed source does not supply a custom DKIM selector or activation workflow. Do not invent either, and do not state that DKIM is unsupported merely because this page omits it. If neither aligned SPF nor aligned DKIM can be demonstrated, hold the branded sending configuration and ask for the supported solution. A provider-owned From address with a suitable reply route may be a design option to discuss, not a documented Adelante feature here.
Recover and retain the evidence boundary
Pause the affected mail workflow if the change causes failures. Restore the prior policy if appropriate while the service owner resolves the route, rather than publishing +all or weakening domain-wide DMARC to conceal a mismatch. Retain the documentation age, provider response and redacted received-message evidence. No real Adelante message, DNS change or payment transaction was executed for this article.
Use a two-part go or hold decision
The proposed change needs both current service confirmation and a controlled identity sample. Record who confirmed the address, which payment product and account it applies to, and when. Separately record the real envelope and aligned passing path. If either row is unknown, hold production authorization rather than treating documentation age or an old policy as proof. This decision card is a proposed safeguard, not a provider response or a performed payment test.