ChargeOver SPF, DKIM and DMARC setup, step by step

For ChargeOver's built-in mail service, open Settings > Email Personalization > Deliverability > New Email Domain, enter your sender domain, and publish the DNS entries ChargeOver generates. Its documented SPF authorization is include:chargeovermail.com. Complete validation, then confirm that a real billing notification carries a passing DKIM signature aligned with your intended From domain. ChargeOver says DMARC alignment requires a paid account. ChargeOver domain authentication.

This guide covers ChargeOver billing communications through its built-in mail service and explains the boundary with external sending integrations. No account configuration, DNS changes or message tests were performed.

Identify the mail service and account first

An invoice created in ChargeOver may be delivered by ChargeOver or by an external provider. The correct DKIM setup follows the delivery service.

ChargeOver explicitly directs users of external integrations to manage DKIM in those platforms rather than its built-in workflow. Its custom SMTP documentation confirms that an external server can replace ChargeOver's mail servers.

Before editing anything, record the ChargeOver account, paid/trial status, active transport, visible From addresses and affected notification categories. Include the operational owner of scheduled billing messages. Do not change transport simply to make an authentication badge turn green: a switch can change the service, identities and credentials on which delivery depends.

You also need permission to administer the selected account and access to the authoritative DNS zone. If the domain is delegated to a separate DNS service, the registrar's unused DNS editor will not change the records recipients see.

Set up ChargeOver's generated DKIM records

1. Open the Deliverability tab under Email Personalization and choose New Email Domain.
2. Enter the intended domain and select Save and Continue.
3. Copy the generated DNS list for that account and domain. Preserve record type, complete owner, value and any instructions.
4. Publish the list through the authoritative DNS provider after reviewing existing records.
5. Select Continue to start ChargeOver's validation.

ChargeOver documents hourly validation attempts for three days, followed by email on success or instructions if validation fails. It also revalidates monthly and emails when updates are needed. Keep a responsible owner for those notices. Configuration and revalidation.

Do not guess the number of records, a selector such as default, or a CNAME destination. The public instructions establish the generated-record process, not a universal DKIM record set. Follow the type actually issued. If ChargeOver supplies a TXT public key, publish the entire value. If it supplies a CNAME, publish the exact alias target. Do not substitute a key generated by a third-party utility: the service must sign with the corresponding private key. How DKIM retrieves public keys.

Validation confirms a configuration checkpoint. Keep the generated values and the confirmation's domain and date, then proceed to a new delivered-message test. Do not treat a confirmation for one domain as evidence for every sender profile.

Add ChargeOver to SPF without breaking other senders

The documented mechanism for ChargeOver's own servers is:

include:chargeovermail.com

This is a mechanism, not a complete standalone SPF policy. Merge it into the existing SPF TXT policy at the appropriate owner, before its terminal all, preserving other authorized services and the reviewed qualifier. ChargeOver SPF instructions.

If the existing SPF policy uses redirect=, reconcile its authorizations with the DNS owner before changing it. An all mechanism makes redirect ineffective regardless of their order; do not append all as an automatic merge step. SPF qualifiers express authentication results, not a guaranteed receiver delivery or rejection decision. SPF all and redirect processing.

The following is an illustrative before-and-after merge. spf.existing-provider.example is a placeholder for an already-authorized provider, not a record to publish:

Before: v=spf1 include:spf.existing-provider.example -all
After: v=spf1 include:spf.existing-provider.example include:chargeovermail.com -all

For a genuinely new owner whose only authorized source is ChargeOver, a policy can be constructed around the documented include and an owner-approved ending. Do not copy the vendor's example a and mx mechanisms unless those hosts really send your outgoing mail. Adding those mechanisms can authorize more infrastructure than intended.

Specifically, a authorizes the applicable A/AAAA addresses resolved for its name, while mx authorizes addresses of its mail exchangers. Compare the actual resolved destinations with the approved outbound-sender inventory; a website/CDN or inbound mail host is not automatically an authorized billing sender. SPF a and mx evaluation.

SPF evaluates the SMTP MAIL FROM identity, not the customer-visible From address. Inspect smtp.mailfrom in a trusted receiver result to identify the evaluated domain. If the service uses a provider-controlled return path, your company-domain SPF record does not cause that path to align. The built-in public guide does not establish a universal customer-configurable return-path control; ask ChargeOver about your route if SPF alignment is a requirement. SPF MAIL FROM definition.

Keep these safeguards:

• Publish only one v=spf1 policy per owner. Other unrelated TXT records can remain.
• Count nested DNS-dependent terms across the evaluation, not just top-level includes. SPF limits those terms to ten.
• A policy at example.com does not automatically apply to billing.example.com or bounce.billing.example.com.
• Do not replace a working policy, change its final qualifier or flatten provider IPs without reviewing all senders and maintenance responsibilities. SPF publication and evaluation rules.

For an external integration, use that provider's SPF instructions. Do not add ChargeOver's include merely because ChargeOver generated the notification.

Map DNS names to the actual zone

Below, issued-selector represents the value generated for your account. These are owner-name examples only, not reusable DKIM records.

Compare the finished fully qualified owner with ChargeOver's generated name. Avoid billing.example.com.example.com. If the child zone is delegated, publish its records there; a record left beneath the delegation in the parent zone is not an effective replacement.

If _domainkey.billing.example.com itself has an existing NS delegation, the example selector owner is issued-selector in that delegated zone. Publish with that authority and preserve its NS records and other active selectors. Do not change nameservers, DNSSEC or forwarding to make a parent-zone record visible. DNS zone boundaries.

A CNAME owner must not contain conflicting ordinary records. Keep existing selectors used by other senders. If the requested owner is already in use, resolve the collision with the provider instead of deleting a working record. Keep CNAME targets as hostnames, without https://, and disable HTTP proxying for mail-authentication aliases. Never replace the domain's inbound-mail MX records just to complete a DKIM setup.

These alias controls apply only when ChargeOver or the selected external provider actually issues a CNAME; they do not turn a direct-TXT public key into an alias. Where literal CNAME answers are required, the end state is a DNS-only alias returning the exact issued target, without HTTP proxying or flattening hiding it. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.

Configure an external sending integration separately

When SendGrid, Mailgun, Mandrill or Custom SMTP is active, open the account that actually accepts mail from ChargeOver. Verify the visible From domain, generate its DKIM records, publish them, and complete that provider's activation. If a branded return path is available, configure it through the provider rather than inventing a bounce-domain record.

ChargeOver's Custom SMTP page places external configuration under Settings, Integrations and More Integrations. Its current text contains an unspecified integration label, so use the actual named integration in your account rather than interpreting that placeholder as a control. Enter only the selected provider's supported connection settings, save them, and verify a new notification through that connection.

If your selected integration is SendGrid, follow the SendGrid domain-authentication guide for its account-generated records, then test the notification initiated in ChargeOver.

Use the provider's supported encrypted submission and authentication method. Do not weaken account security to follow a legacy password example. Credentials authorize a connection; DNS records authorize or validate domain use. Neither is a substitute for the other, and neither proves which From address a specific invoice will use.

Preserve DMARC and understand the paid-account boundary

ChargeOver's paid-account restriction is a product eligibility condition. It does not change the DMARC protocol: a message passes DMARC if either SPF or DKIM passes with an identifier aligned to the visible From domain. Two passes for unrelated provider domains can still fail DMARC. DMARC alignment rules.

For relaxed alignment, the organizational domains must match. Strict adkim=s or aspf=s requires exact domain equality for that mechanism. Check the existing policy before choosing sender and return-path domains. Do not infer production eligibility or identity behavior from an unpaid trial test.

ChargeOver also asks for both SPF and DKIM configuration in its setup guidance. Follow the provider's setup requirements while keeping them separate from DMARC's either-aligned-method pass rule.

Preserve existing DMARC enforcement, reporting addresses and subdomain policy. If no applicable policy exists and a monitored rollout is approved, an illustrative starting point is:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and mailbox. In the example.com zone, enter relative owner _dmarc to create _dmarc.example.com when the editor appends the zone name. A deliberate policy for billing.example.com belongs at _dmarc.billing.example.com: relative name _dmarc.billing in the parent zone or _dmarc in the delegated child. Inspect inherited policy before adding an override. Do not publish multiple policies at one owner or weaken an established policy as a routine fix.

Choose an authorized, monitored report destination. Aggregate reports can reveal failing sources across billing cycles; they do not prove that a customer received, read or paid an invoice. Aggregate reporting specification.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the reporting service's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

Validate public DNS and a real billing message

Check records independently of the dashboard

Replace the examples below with the issued owner names, expected record types and actual authoritative nameserver. The commands only read DNS.

dig +short NS example.com
dig +short NS billing.example.com
dig @ns1.dns-provider.example issued-selector._domainkey.billing.example.com CNAME +noall +answer
dig +short TXT issued-selector._domainkey.billing.example.com
dig +short TXT actual-envelope-domain.example
dig +short TXT _dmarc.billing.example.com
dig +short TXT _dmarc.example.com

Check each generated record against the issued list. For CNAME DKIM, verify both the alias and the public key reached through it; for direct TXT DKIM, verify the complete key at the issued owner. Inspect SPF at the actual MAIL FROM domain, including dependencies. Compare authoritative and public recursive answers after the previous TTL has elapsed. An empty answer from the wrong record type is not proof of a missing record.

Accept the DNS stage when the published values match and ChargeOver or the external provider confirms verification. If validation remains pending, examine exact names and authoritative answers before attributing it to propagation.

Require the intended branded DKIM pass

Use an authorized, harmless notification through the intended account, transport and sender domain. Inspect the recipient's trusted Authentication-Results alongside the message's From and DKIM-Signature fields. Do not trust an arbitrary sender-inserted authentication header. Authentication-Results security considerations.

Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Reject attacker-supplied or otherwise untrusted fields; obtain the receiver's own diagnostic evidence when provenance is uncertain. Operational receiving-result trust.

The acceptance worksheet should record:

• Account, transport, notification category, observation time and visible From domain.
• SPF result and evaluated smtp.mailfrom domain.
• The intended branded DKIM d= and s= values, and a dkim=pass result for that signature.
• Alignment of that passing branded signature under the applicable adkim mode.
• The receiver's DMARC result and any remaining discrepancy.

A provider-owned DKIM pass is insufficient. A DMARC pass through SPF alone is also insufficient to declare the branded DKIM setup complete. For this setup's acceptance, require the intended branded signature to pass and align with the unchanged approved From, plus trusted receiver dmarc=pass for that intended From domain.

SPF passing for an unaligned provider return path is different from SPF failing. Document the former if aligned DKIM supplies DMARC. Investigate fail, softfail, neutral, none, temperror and permerror on a direct-delivery sample even if DKIM lets DMARC pass. Recheck each materially different From domain or route and keep only redacted diagnostic evidence.

Troubleshooting and recurring checks

Record an owner for validation emails and retest after transport, From-domain or DNS changes. Avoid sharing customer invoices with public diagnostic tools when a minimized header extract is sufficient.