USAePay custom-branded receipts require a domain you control. The gateway's Email From choice changes what recipients see, so inventory merchant receipts, invoices and any partner-mail flow separately. Do not use a customer's real transaction as an authentication test or put payment details into diagnostic services.
Configure custom-domain authentication
The provider documents include:spf.usaepay.com for SPF. Add it to the existing applicable SPF policy, before the terminal all mechanism, rather than publishing another SPF record. The official guide discourages maintaining a copied IP list because provider addresses can change.
For DKIM, create three CNAME records beneath your sending domain: gps1._domainkey points to gps1._default.dkim.safewebservices.com; gps2 and gps3 follow the same numbered pattern. Replace only your own sending-domain portion, not the provider targets. The guide says gps2 and gps3 public keys are intentionally empty reserves for rotation. Publish their delegations even if a key validator flags the empty targets; acceptance of today's message depends on the selector actually used. USAePay configuration reference
The portal offers SPF and DKIM validation. Use it as a configuration check, then inspect a delivered test receipt. The documentation says unauthenticated custom branding can fall back to safewebservices.com. Record the observed From address instead of assuming that a delivered receipt still carries your brand. If you cannot control the desired domain, agree on an approved sender identity rather than forging a public webmail address.
The provider now requires these authentication records for all custom sending domains, not only bulk campaigns. Treat the public sample IP used in an old validation example as a diagnostic illustration, not evidence of the current egress IP or of the envelope identity actually emitted.
Verify DNS and a real receiving result
Before changing merchant receipt and invoice sender settings, export the existing DNS values, record the approved diff and name the rollback owner. Confirm whether the DNS editor expects a relative label or a fully qualified name; doubling the domain suffix creates a record that no intended verifier will find. Query the actual owner name after saving, including any CNAME target, rather than relying on the editor's success banner.
SPF must remain one policy at the relevant domain and stay within the DNS-querying-term limits in RFC 7208. Adding an include does not itself establish alignment. Under RFC 9989, DMARC passes when at least one successful SPF or DKIM result aligns with the visible From domain under the applicable mode. Do not require both mechanisms to align as a condition imposed by the standard, and do not mistake a provider-domain pass for an aligned customer-domain pass.
Send a harmless test receipt generated by the actual merchant workflow to a mailbox you control. Save the receiving system's trusted authentication results, visible From, envelope identity, DKIM d= and s= values, timestamp and provider status. A DNS lookup only shows the available key; RFC 6376 verification also evaluates the signature over the received message. Use non-sensitive content and avoid exposing full customer messages to public checkers.
Use a bounded acceptance and rollback decision
Fictional written diagnostic case only: UP-01 assumes a harmless receipt was intended to use receipts@shop.example but its visible From is noreply@safewebservices.com. SPF and all DKIM identities/results are unknown. Delivery does not meet the custom-brand requirement. The merchant owner must check the gateway identity and validation status, and the DNS owner must compare all three documented delegations before a new approved test. Empty reserve keys alone do not establish failure of the active selector. No account, DNS, relay or message was tested for this example.
If the test fails, separate missing DNS, wrong selector, inactive provider configuration, unexpected routing and message modification before making another change. Retest the same workflow after each approved correction. Do not weaken the whole domain's DMARC policy to hide a single sender problem. Where rollback is needed, restore the approved prior routing or sender configuration and retain key records while queued signed messages still need them. Keep the test evidence and unresolved exceptions with the domain inventory. No tenant access, DNS change or real sending was performed in preparing this guide.
Keep an accountable acceptance record
Create one row per account, domain and materially different route. Record the business owner, DNS owner, change reference, intended From, observed From, envelope domain and SPF result, each DKIM d= and s= with its result, applicable alignment mode, trusted receiver and timestamp, provider activation state, placement observation, unresolved question and next action. Mark missing values unknown rather than treating them as pass or fail. The owner accepts only the intended route and identity supported by the recorded evidence; otherwise hold that route and follow the approved recovery plan.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.