Choose the ChargeOver transport before adding records
ChargeOver can send billing-related email through its own mail infrastructure or through an integrated sending platform. Its Improving Email Deliverability guide explicitly separates the built-in domain-authentication workflow from SendGrid, Mailgun, Mandrill and Custom SMTP. For those integrations, the guide says DKIM is managed in the external platform instead. Start with the actual route, not merely the application that created the invoice. A domain verified in one transport does not establish that a different transport signs with it.
Record the ChargeOver account, current plan, sender domain, selected transport and message categories before opening a DNS change. Include invoices, subscription notices and other material automated messages in the inventory without copying customer financial details into the configuration worksheet. If a transport is being changed, identify the scheduled messages and responsible owner before making that change. This article describes proposed configuration and acceptance work; no billing account or real message has been accessed.
Use the issued domain records rather than a universal recipe
For the built-in workflow, ChargeOver documents Settings, Email Personalization, the Deliverability tab and New Email Domain. Enter the intended domain, then choose Save and Continue. The service supplies a list of DNS entries to create. Publish the entries issued for that account and domain through the actual authoritative DNS provider, then choose Continue to start validation. The documentation does not give this article a universal selector, key, record count or reusable target, so none is invented here.
Before publishing, compare every generated owner with the DNS editor's resulting fully qualified name. A panel that appends the zone suffix can turn an apparently complete name into the wrong owner if the suffix is entered twice. Check existing records at each proposed location and preserve unrelated senders. Keep a controlled reference to the generated public values and the approved DNS change, rather than substituting a screenshot from a different account. Public authentication records are not passwords, but their configuration still represents a consequential authorization dependency.
Understand validation and re-validation timing
ChargeOver says it attempts domain validation every hour for three days. It sends an email when validation succeeds, or an email with next steps if validation has not succeeded after three days. This is a documented retry schedule, not proof that any particular domain is correct or a promise that DNS errors disappear with time. Identify the administrative notification recipient in the actual account so that a failed-validation message is not overlooked.
The same guide says domains are re-validated monthly and that an email is sent when something needs updating. Treat that as part of ongoing ownership: assign a person to review notices and DNS changes that could invalidate the configuration. Do not claim that this manuscript has registered monitoring or that every future failure will necessarily be observed. A sensible operational process records the notification path, accountable owner and escalation condition before relying on recurring checks.
When validation is pending, distinguish the provider's latest observation from the public record and its publication time. A wrong owner, omitted value or record created in a non-authoritative panel requires correction. Waiting for the next scheduled check only helps after the underlying configuration is right. Preserve the exact status and time rather than translating all pending states into a generic “DNS propagation” diagnosis.
Integrate SPF with the complete sender inventory
The ChargeOver guide names include:chargeovermail.com for its mail servers and shows adding it to an existing SPF policy. It also prints a complete example with a and mx mechanisms. That example is not blanket authorization to replace an organization's policy or authorize every address behind its website and MX records. Choose only the authorization needed for the real transport and preserve other legitimate sources during a reviewed change.
RFC 7208, sections 2.4, 3.2 and 4.6.4 define the MAIL FROM identity, multiple SPF records and the shared limit on evaluated DNS-dependent terms. Review the envelope domain actually used by the selected sending route. Count nested dependencies along the relevant evaluation path, not just visible include strings. Publish one coherent SPF policy at the applicable owner. SPF does not create an SMTP integration or make an application use a particular envelope domain merely because its include appears in DNS.
Keep plan eligibility separate from the DMARC standard
ChargeOver's guide states that DMARC alignment can only be achieved for paid ChargeOver accounts. That is a provider-specific eligibility boundary to confirm for the account, not a limitation in the DMARC protocol itself. A trial or unpaid account should not be assumed to demonstrate the production paid-account signing and identity behavior. Record the applicable plan and actual available controls without making an unrequested purchase or upgrade.
The ChargeOver guide states that SPF and DKIM must both be configured with ChargeOver. Preserve that provider-specific configuration prerequisite and confirm its applicability to the current account and selected route. It is separate from the DMARC evaluation rule: RFC 9989, section 4.4 defines DMARC alignment and does not universally require both mechanisms to pass. A passing aligned SPF result or passing aligned DKIM result can satisfy the authentication condition. Conversely, two passing results for unrelated domains do not automatically align with the visible author domain. Avoid turning the guide's informal phrase “DKIM policies” into a separate standard or acceptance state.
Verify representative billing mail without exposing customer data
After separately authorized configuration, an acceptance exercise should inspect trusted receiver results for representative messages using harmless test content. Record the author domain, envelope identity, signing domain and selector, transport and observation time. RFC 6376, section 3.5 defines signature fields needed for that comparison. A provider verification email and a delivered invoice are different pieces of evidence; neither alone proves every automated category behaves identically.
Do not upload an actual invoice or customer header to a diagnostic website merely because the documentation links a tool. Diagnostic sharing should be minimized and approved for the actual data and recipient. Successful authentication also does not establish inbox placement, customer attention or payment. Those outcomes need separate evidence and must not be inferred from a green domain status. No test mail, invoice, external upload or provider notification was generated for this manuscript.
Fictional diagnosis: the transport changed after verification
A fictional service business, Meadow Repairs, verifies its domain using ChargeOver's built-in workflow. Later, its administrator selects a Custom SMTP integration while assuming the verified domain badge covers all future mail. The acceptance reviewer notices that the selected transport has changed and that the guide assigns DKIM management for Custom SMTP to that external platform.
The proposed response is to reopen the transport-specific acceptance item, establish the external sender's actual signing configuration and obtain authorized message evidence before marking the route ready. It is not to add arbitrary ChargeOver selectors or remove the external platform's authorization. This scenario contains no real account, billing event, customer record or executed test; it illustrates why a configuration status must be tied to the route that produced it.
Blank acceptance worksheet and release hold
- ChargeOver account, plan and current transport: ______
- Sender and envelope domains by message category: ______
- Issued DNS records and authoritative change reference: ______
- Complete SPF policy and evaluated dependency review: ______
- ChargeOver both-configured SPF/DKIM prerequisite and current account/route confirmation: ______
- Validation state, latest attempt and notification recipient: ______
- Monthly re-validation owner and escalation process: ______
- External-platform DKIM responsibility, if applicable: ______
- Trusted message-level authentication and alignment evidence: ______
- Exceptions, rollback decision and release owner: ______
Original implementation evidence, current source applicability, human subject-matter review, production-route testing, visual accessibility and owner release remain open. The catalogue's implementation requirement is not satisfied by this documentary guide. No DNS change, transport change, account upgrade or message test has been performed.