Maxio Advanced Billing SPF, DKIM and DMARC setup, step by step

To authenticate Maxio Advanced Billing email, register your sending subdomain in Tools → Email Insights → Setup Info → Mailgun, publish the exact SPF TXT, DKIM TXT and tracking CNAME records issued for that site, then select Check DNS Records Now. Once verification succeeds, the domain becomes active automatically. Verify the intended branded DKIM signature and DMARC on received mail, including dunning messages as well as ordinary templates. Maxio Enhanced Email Delivery

This guide covers Enhanced Email Delivery through Maxio's own Mailgun account in Advanced Billing, formerly Chargify. You do not need your own Mailgun account or a private-key upload. Maxio Core, legacy e-Bill configuration and both customer-owned and Maxio-managed Mandrill are separate workflows. Chargify's current identity, Separate Mandrill workflow

No customer account, DNS configuration or delivered message was tested for this article. The validation steps below are proposed implementation checks.

What you need before setup

Maxio documents Enhanced Email Delivery as self-service with no additional fee. You need an existing Advanced Billing site, a sending subdomain you control and an authorized DNS administrator. Work with your IT team and validate the setup on a test site before applying it to a live site.

Permissions are different for viewing and changing the setup:

A site can have only one active custom email delivery provider at a time. If it already uses Mandrill, do not treat this guide as permission to switch providers. Plan that migration separately so billing notifications are not interrupted. The Enhanced Delivery procedure does not require a customer Mailgun API key, generated DKIM keypair or access to a Mailgun dashboard. Maxio prerequisites, Provider exclusivity

1. Inventory the sending domain and all From addresses

Choose a subdomain intended for this mailstream, such as billing.example.com, rather than casually reusing a name that hosts a website, mailbox or another service. It will hold the DNS records Maxio issues. Existing use is not automatically safe simply because the name is a subdomain.

Before registering it, record:

• The correct Advanced Billing account and site, and whether it is a test or live site.
• The proposed registered sending domain.
• Every intended visible From address: site default, template-specific addresses and Dunning Default.
• The authoritative DNS provider and zone. Your registrar might not host your DNS.
• Existing SPF policies, DKIM selectors, CNAMEs, website and mailbox records, and who depends on them.
• The direct or inherited DMARC policies that apply to the visible From domains, including alignment settings and approved reporting destinations.

Keep a recoverable record of the existing DNS and sender settings. Do not replace your root-domain SPF, MX or nameservers as a shortcut. Maxio describes the sending subdomain as the scope of Enhanced Delivery, but shared DNS records and From identities still need careful review.

The registered sending domain, visible From domain, SMTP envelope domain and tracking hostname are distinct observations. A domain registered in the UI is not proof of the exact MAIL FROM or DKIM d= that a message will use. Maxio's current page does not publish a universal envelope-address format or a strict-alignment guarantee, so obtain that evidence from your actual configuration and delivered mail.

2. Register the subdomain before looking for DNS records

With Admin access to the correct site:

1. Open Tools → Email Insights.
2. Select Setup Info and find the Mailgun setup card.
3. Choose Connect an existing one if the organization has already connected the intended domain, or enter the new sending subdomain under Create a new domain.
4. Select Save.
5. Open Mailgun DNS Entries Required and copy the actual record table for that registered domain.

Registration comes first because Mailgun generates the DNS instructions only afterward. The table contains Name, Record Type, Enabled and Value. Save the exact names, types and values, not just the status indicators. The Enabled column reports each record separately, which helps isolate a single incorrect owner or value.

Do not use a screenshot from another site or a generic Mailgun setup as your account's record set. The key and exact names may differ. Maxio provides Change domain on the same card for later changes; it documents no self-service removal of a domain entirely and directs deletion requests to Support. Treat either operation as a deliberate change, not a troubleshooting reset. Domain registration and issued records

3. Map Maxio's record names to your actual DNS zone

Maxio's table expresses names relative to the registered sending domain. If you registered billing.example.com, @ means billing.example.com, not example.com.

The following maps the documentation's illustrative record names. Use your own site's exact issued names and values. k1 and email are examples, not guaranteed values for every account.

These relative forms apply to editors that append the selected zone suffix. If the editor requires a full name, use the full owner instead. Confirm the resulting owner before saving so you do not create a name such as k1._domainkey.billing.example.com.example.com.

A separately delegated child zone changes where edits belong. Publish at the authority that actually serves the required owner, not in the parent below a delegation cut. This setup does not instruct you to delegate DNS to Maxio or replace your nameservers. Maxio subdomain-name guidance

Publish SPF at the registered sending domain

The vendor's example SPF value is:

v=spf1 include:mailgun.org ~all

Use the actual value issued for your site. For the billing.example.com example, its owner is billing.example.com, not the organization's apex. SPF policies do not inherit from example.com to billing.example.com.

If that owner has no SPF policy and the issued value matches the intended sending route, publish the issued TXT value there. If it already has SPF, reconcile the new authorization with the existing policy instead of adding a second v=spf1 record or replacing other senders. Preserve deliberate qualifiers and mechanisms needed by legitimate routes. Unrelated TXT verification records can remain alongside the single SPF policy.

Evaluate the entire SPF tree, including nested include and redirect processing. SPF permits at most 10 DNS-query-causing terms during evaluation, not 10 visible includes. The mechanisms a, mx, ptr and exists also consume that budget; ip4, ip6 and all do not. Duplicate SPF records, syntax errors, excessive lookups and empty DNS lookups can cause permerror. Do not flatten provider IPs into a static list merely to conceal a problem. SPF record selection and lookup limits

Publish the issued DKIM public key

Create the TXT record at the exact selector owner from Maxio. Preserve the complete public-key value. The documented example uses k=rsa; p=..., but the actual key and selector belong to your registered domain and must come from your site's table.

Do not generate a replacement keypair with an unrelated tool, upload a private key or reuse a key from an older Chargify article. The current managed workflow supplies the public record; Maxio's sending infrastructure holds the signing capability. DKIM authenticates a signature over selected message content. It does not encrypt the email or prove a human author's identity.

If the DNS host splits a long TXT value into quoted character strings, keep them as parts of one resource record. They are concatenated without added spaces. Do not create separate DKIM records for each chunk or insert display quotes, line breaks or spaces inside the public key. Preserve unrelated active selectors and investigate any collision at the exact issued owner before replacing it. Maxio-issued DKIM data, DKIM public-key lookup

Publish the tracking CNAME without confusing it with DKIM

Create the CNAME with its exact issued owner and target. Maxio's example email CNAME points to mailgun.org, but your site's table is authoritative for its required value. That tracking alias is a different record from the DKIM TXT key and does not prove that a message is signed.

Before adding it, check for existing A, AAAA, MX, TXT or CNAME data at the same owner and identify any website or other service using it. A conventional CNAME cannot coexist with ordinary records at its owner. Do not remove conflicting records until the service owners agree on a supported design. DNS alias rules

If your DNS provider offers proxying, use DNS-only for a provider-required literal CNAME unless Maxio explicitly documents a different configuration. Also inspect per-record and zone-wide CNAME flattening. A DNS dashboard can display a CNAME while public DNS returns only addresses, preventing an external check from seeing the alias.

For example, Cloudflare automatically flattens apex and same-zone CNAMEs. Its zone-wide flattening option cannot be overridden per record. A name that appears to be a subdomain can be the apex of a separately delegated zone, where a literal CNAME conflicts with required apex records. Do not change a shared zone's proxy, flattening or security settings broadly to fix one Maxio record. Review dependencies and ask Maxio and your DNS administrator for a compatible record location or supported design. Cloudflare flattening behavior

4. Verify records and confirm automatic activation

After publishing the records, return to the same site's Setup Info tab and select Check DNS Records Now. Maxio states that an unverified domain cannot send. When Mailgun confirms the records, the domain becomes active and Advanced Billing sends through it. Do not look for an additional customer Mailgun “start signing” action that this managed procedure does not document.

Maxio advises allowing 24–48 hours for DNS propagation. That is a caching window, not proof that every immediate failure is harmless. Check each record's full owner, type and value, then the Enabled column. A wrong-zone record or duplicated suffix will not repair itself by waiting.

The page also reports SPF and DMARC checks. SPF may show pass, warning or failure. Missing DMARC is shown as a warning, not a failure. An active domain or non-blocking warning is therefore not a substitute for reviewing the author-domain DMARC policy and checking received mail. Verification and status meanings

5. Confirm defaults, template overrides and dunning separately

On Setup Info, inspect Your emails are set to come from. Maxio lists the addresses and links to the settings that control them:

Retain the intended visible From for each route. Do not replace it with a different address merely to obtain an authentication pass. If an existing address is incompatible with the supported sending domain or the organization's strict-alignment requirements, resolve that design with Maxio and the domain owner before live activation.

Advanced Billing's general communications documentation places ordinary email settings under Config → Settings → Emails and dunning under Config → Retries & Dunning. Use the links on Setup Info to check the controlling settings, and do not assume a template preview's address governs dunning. From-address precedence, Advanced Billing communications

6. Preserve the applicable DMARC policy

DMARC compares authenticated identifiers with the domain in the visible From. It does not simply use whichever domain was registered in Maxio or appears in a tracking link.

Before adding a record, inspect the direct policy for each author domain and any applicable inherited policy under DMARC discovery. Preserve enforcement, alignment settings, approved report destinations and dependencies of other senders. Do not replace p=reject or p=quarantine with p=none to clear an onboarding warning, and do not create a child policy that silently overrides inherited protection.

Only where no direct or inherited policy applies, and the owner approves an initial non-enforcing policy, this is a minimal first record for an example author domain:

_dmarc.example.com. IN TXT "v=DMARC1; p=none"

In a DNS editor that appends the example.com suffix, enter _dmarc. If the actual From domain is billing.example.com, its full policy owner is _dmarc.billing.example.com: enter _dmarc.billing in an authoritative parent example.com zone, or _dmarc in a separately authoritative billing.example.com zone. In a full-name editor, use the complete owner. Make changes only at the responsible authority and retain the no-existing-policy guard above.

This minimal record requests no reports. Add rua only for an approved collection destination. Where the reporting destination's Organizational Domain differs from that of the policy, the report receiver must provide the required DNS authorization. Review report access, retention and privacy because aggregate data can expose source IPs and domain activity. Do not paste an arbitrary reporting address or change existing recipients without approval. DMARC policy discovery, External reporting authorization

Know which alignment you are testing

DKIM's d= identifies the signing domain and s= identifies the selector. SPF normally authenticates the SMTP MAIL FROM domain, commonly reflected in Return-Path; for a null reverse-path, SPF uses the HELO identity. Neither the tracking hostname nor the sender's login is the SPF identity.

Relaxed DMARC alignment compares Organizational Domains; strict adkim=s or aspf=s requires exact equality for that mechanism. As a hypothetical example, a passing signature with d=billing.example.com may align with From at example.com under relaxed rules, but not strict DKIM rules. This does not assert the signer or envelope your Maxio site will use. Inspect the real message and effective policy. Identifier alignment

If SPF passes on an unrelated provider envelope, record it as passing but unaligned. Adding an include to the visible From domain does not change that envelope. If SPF actually fails or returns temperror or permerror, diagnose the problem even when aligned DKIM can satisfy DMARC. Do not invent a custom Return-Path control absent from Maxio's current procedure.

7. Validate public DNS, then test each real mailstream

DNS checks

Replace the examples with the actual registered domain, issued selector and tracking owner. These are diagnostic commands, not recorded customer results:

dig example.com NS
dig billing.example.com TXT
dig ISSUED_SELECTOR._domainkey.billing.example.com TXT
dig ISSUED_TRACKING_LABEL.billing.example.com CNAME
dig _dmarc.billing.example.com TXT
dig _dmarc.example.com TXT

If the account's issued names have a different shape, query those exact full names. Check authoritative responses and a recursive resolver, retaining timestamps, TTLs and response status. Verify one SPF policy at the intended owner, the full matching DKIM public key, the literal tracking alias and the applicable DMARC policy. Distinguish NXDOMAIN, an empty answer, a timeout and SERVFAIL; an empty short result alone is not a diagnosis.

Public DNS confirms publication. The provider's Enabled status confirms its validation. Neither proves that a particular template emitted the intended From or that a receiver validated the signature.

Delivered-message checks

With authorization to send, use a test site and controlled recipient addresses. Do not trigger real invoices, payments, overdue notices or subscriber communications merely to test authentication. Maxio's templates support test-data preview, but a rendered preview is not a message-delivery test. Its guidance also describes test-mode subscriptions using your own address to inspect real rendered values. Keep the test separate from live billing. Template testing boundaries

Use a small test matrix that reflects your actual configuration:

Maxio documents that a test-site email addressed to more than five recipients is not delivered. Use one or a few controlled recipients rather than a broad distribution list. Start with direct delivery to a trusted mailbox, then separately test any forwarding or gateway path that matters. Test-site limitations

For each received message, record the message ID, UTC time, template/route, intended and observed From, actual SPF identity and result, intended branded DKIM d= and s=, and DMARC result. Store raw evidence securely; redact billing content, personal recipient data and unnecessary identifiers before sharing it for support.

Trust Authentication-Results from receiving infrastructure you control or trust, which must remove or distinguish forged upstream fields. An attacker can prepend a convincing header, including a familiar authserv-id; that string alone proves nothing. If the trust boundary is unclear, use an independent trusted mailbox or receiver trace. Authentication-Results trust boundary

Accept the setup only when the intended visible From is unchanged, the intended Maxio-managed branded DKIM signature passes and aligns, and the trusted receiver reports DMARC pass. Record SPF independently and resolve failures or errors. A DMARC pass supplied by SPF or another signature does not prove that the new branded DKIM configuration works.

An authentication pass does not guarantee inbox placement or prove that all templates are correct. If a Microsoft 365 recipient's delivery action differs from the authentication verdict, EmailAuth's inbound DMARC handling guide explains how receiver policies and overrides affect disposition.

Troubleshooting Maxio Enhanced Email Delivery

If the account is using Mandrill rather than the Mailgun card, stop applying this record set. The provider connection and DNS requirements belong to that separate route. Do not delete active keys, disable the working provider or change shared DNS simply to make the current instructions fit.