Maxemail by Xtremepush SPF, DKIM and DMARC setup, step by step

Maxemail requires DKIM verification of your From domain, but does not require a separate customer SPF TXT record. For a standard Maxemail customer space, publish a CNAME at maxemail._domainkey.<your-From-domain> pointing to dkim.mxmfb.com, then ask Maxemail Support to complete the setup. You can also configure one unused custom subdomain for the envelope sender and tracking links by pointing it to mxm.mxmfb.com. That optional change also needs Support activation. Maxemail domain verification

This guide covers Maxemail customer-space marketing email, not the separate Xtremepush project setup or an Amazon SES integration. Reseller customers need their reseller's issued DNS values and support process, as explained below.

The instructions are based on public documentation. No customer account, DNS change, Support activation or delivered-message test was performed in preparing this guide.

Identify the domains and the people responsible

An email has several domain identities. Getting the right one into the DNS request prevents a technically valid record from being installed in the wrong place.

Before making changes, identify the correct customer space and its business owner. Agree the intended From domain and have an authorized DNS administrator locate its authoritative DNS service. The registrar, website host and DNS host may be different companies. Keep an export or change record of the existing DNS, including SPF, DKIM selectors, DMARC, MX and any subdomain delegations.

The reviewed Maxemail setup documentation does not identify a separate DKIM subscription tier or a minimum self-service role. It does require coordination with Maxemail Support. Do not assume that creating a record activates signing or that an administrator in a different customer space can complete this space's setup.

Check the product before copying records. Core Xtremepush's email-verification documentation uses different targets and a different selector, permits more than one custom send domain per project, and directs Amazon SES projects to a separate procedure. Those instructions do not replace Maxemail's customer-space records. Xtremepush product boundary

Add the DKIM CNAME for the actual From domain

For a standard, directly supported Maxemail space, the published record is:

Replace example.com with the domain after the @ in your intended From address. Keep the target as documented for this standard route. DNS editors differ: some want the full owner, while others append the zone name automatically. Inspect the saved result to avoid creating maxemail._domainkey.example.com.example.com.

If you send as newsletter@news.example.com, the full owner becomes maxemail._domainkey.news.example.com. In the parent example.com zone its relative label is maxemail._domainkey.news. If news.example.com is a separately delegated zone, publish at its authoritative DNS host using maxemail._domainkey there. Do not delete delegation records to make a record in the parent zone appear to work.

Maxemail manages the signing infrastructure behind the CNAME. Do not replace the alias with a public key copied from a lookup, and never put a private key into DNS. Support must configure the matching signature in the sending system. Maxemail's IP-allocation documentation explicitly assigns that signing setup to its Support Team. DKIM record, Support's signing responsibility

If you use a Maxemail reseller

Obtain the selector and targets from your reseller before publishing anything. The reseller documentation uses a reseller-specific selector and a reseller-controlled DKIM target; its sample names are demonstrations, not universal values. The custom send domain can also point through the reseller's domain.

Reseller clients receive support from the reseller, which coordinates configuration of the client space with Maxemail. Do not apply the retail maxemail selector or dkim.mxmfb.com target simply because the underlying platform is Maxemail. Ask the reseller to confirm the exact From domain, full owners, targets and activation owner for your space. Maxemail reseller setup and onboarding

Decide whether to use a custom envelope and tracking domain

The default envelope and link-tracking domain is mxm.mxmfb.com. You can instead choose a new, previously unused subdomain under your domain, such as email.example.com, and publish:

email.example.com. IN CNAME mxm.mxmfb.com.

This is an example using the reserved domain example.com; choose your own unused subdomain. In the example.com DNS zone, the relative name would normally be email.

Maxemail permits one custom domain per customer space and uses it for both the envelope/bounce identity and tracking links. It is not a tracking-only toggle, and publishing a second alias does not create a second supported custom domain. Ask Support to complete the custom-domain configuration after DNS publication. Custom-domain requirements and activation

Do not reuse a website hostname, an active mailbox domain, an existing tracking host or a delegated zone's apex. A literal CNAME cannot occupy a zone apex alongside its required SOA and NS records. If the intended name is already delegated or in use, leave it intact and agree a different unused name with the DNS owner and Support. Adding MX or TXT records beside the required CNAME is not a workaround.

A branded envelope can supply an SPF-aligned path under relaxed DMARC alignment, but only after Maxemail actually uses it and SPF passes. A CNAME found in DNS or a branded tracking link alone does not prove that the message's envelope changed.

Publish literal CNAMEs without disrupting shared DNS

A CNAME owner cannot coexist with ordinary A, AAAA, MX or TXT data at the same name. Check every owner before saving. Although Maxemail describes its DKIM record as non-conflicting, that cannot account for a selector already used in your zone. Preserve existing records and ask Support for a supported resolution if a collision exists. Renaming a selector only in DNS will not change the selector used by the signer. DNS alias rules

If your DNS service offers HTTP proxying or CNAME flattening, confirm that the public response still exposes the literal alias Maxemail expects:

• On Cloudflare, use DNS only for these records rather than proxying them.
• Check any per-record Flatten control as well as the zone-wide CNAME flattening for all CNAME records setting. DNS-only status by itself does not rule out flattening.
• A zone-wide flatten-all setting cannot be overridden with a per-record exception in Cloudflare's documented workflow. Have the zone owner review dependencies before changing it. Do not alter a shared zone's settings blindly to repair one record.
• Keep existing DNSSEC, nameservers and subdomain delegations. If the DNS service cannot provide the required alias safely, resolve that with the DNS host and Maxemail rather than replacing the record type.

Cloudflare warns that flattening can prevent third-party CNAME verification. The relevant control is how these specific aliases are answered, not a broad reduction in DNS or email security. CNAME flattening controls

Understand SPF and alignment before editing any policy

Do not add a Maxemail include to your root SPF record for this documented route. Maxemail says no separate SPF configuration is required because it maintains the sender's SPF records. Leave existing SPF used by Microsoft 365, Google Workspace or other senders intact. Maxemail SPF behavior

SPF normally evaluates the SMTP MAIL FROM domain, not the visible From. The receiver commonly records that identity as smtp.mailfrom, with the final envelope also reflected in Return-Path. For a null reverse-path, SPF uses the HELO identity. A successful lookup of your root domain's SPF does not establish how a Maxemail message was evaluated. SPF identities

For a normal From domain of example.com:

Relaxed alignment requires the same Organizational Domain; strict alignment requires exact domain equality. DKIM has its own alignment control, adkim. For From: newsletter@example.com, a passing d=example.com signature aligns even under strict DKIM mode. A passing signature from a related but different subdomain needs relaxed alignment. Preserve the organization's chosen modes rather than changing them to make a test green. DMARC authentication and alignment

SPF's limit still applies to the policy actually evaluated: no more than 10 DNS-querying terms across the evaluation, including nested include and redirect paths. The relevant terms include include, a, mx, ptr, exists and redirect; the rule is not simply a count of visible includes. Exceeding the limit produces permerror. Multiple v=spf1 records at one evaluated owner are also invalid. SPF lookup limits

For provider-managed SPF errors, give Support the actual envelope domain, sending IP, trusted result and DNS evidence. For a broken custom CNAME, involve your DNS administrator too. Do not hide an SPF failure behind a DKIM pass, or try to repair a provider envelope by adding unrelated authorization to your apex SPF.

Preserve DMARC, or establish a first policy deliberately

Look for the policy applying to the exact visible From domain before making a change. For example.com, query _dmarc.example.com. For a From at news.example.com, query _dmarc.news.example.com and determine whether an applicable parent policy is inherited. An empty answer at the exact subdomain does not prove that DMARC is absent. Use policy discovery that follows the current DMARC rules, not just a single-name lookup. DMARC policy discovery

Keep an existing policy and its reporting destinations, alignment modes and subdomain treatment. Do not add a second DMARC TXT record, reset p=reject or p=quarantine to p=none, or create a weaker subdomain exception merely to activate Maxemail.

If no direct or inherited policy applies, the domain owner can approve an initial observation policy. For a From domain of example.com, the DNS administrator would create one TXT record:

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

In the example.com zone the relative name is _dmarc. For news.example.com, a policy specifically approved for that From domain belongs at _dmarc.news.example.com: use _dmarc.news in the parent zone, or _dmarc in a separately delegated news.example.com zone. This example does not request reports and does not ask receivers to quarantine or reject failing mail. It is a starting policy, not evidence of authentication or a finished anti-spoofing rollout.

Add rua only for an approved reporting mailbox or service that will actually be monitored. Aggregate reports can reveal sending IPs, domains, volume and authentication outcomes. Approve the recipient, access and retention before transmitting that information. If the destination is outside the policy domain's Organizational Domain, the report consumer must publish the appropriate external-report authorization, commonly a TXT record at <policy-domain>._report._dmarc.<destination-host> containing v=DMARC1. Use the consumer's issued instructions, including any supported wildcard authorization, rather than an arbitrary example address. External authorization

Move toward enforcement only after reviewing all legitimate senders covered by the policy, not just Maxemail.

Complete Support activation and verify actual delivery

1. Check public DNS

For the standard example, inspect these records with dig or an equivalent DNS lookup tool:

dig CNAME maxemail._domainkey.example.com +noall +answer
dig TXT maxemail._domainkey.example.com +noall +answer
dig TXT dkim.mxmfb.com +noall +answer
dig CNAME email.example.com +noall +answer
dig TXT email.example.com +noall +answer
dig TXT mxm.mxmfb.com +noall +answer
dig TXT _dmarc.example.com +noall +answer

Replace the example names; omit the custom-domain checks if you are not configuring one. The DKIM CNAME should lead to dkim.mxmfb.com and usable public-key material. The optional custom CNAME should lead to mxm.mxmfb.com, where the relevant provider-managed SPF data can be resolved. A recursive TXT query can follow the alias and show the chain. Do not copy the returned key or SPF policy into the CNAME owner.

Check the authoritative server as well as a recursive resolver when answers differ. Record the time, TTL, complete answer and any NXDOMAIN, SERVFAIL or timeout. Cached and negative-cached answers can outlast a change; waiting will not fix a misspelled owner or a broken delegation.

2. Ask Support to complete the correct space

Supply the customer-space identity, intended From domain, full DKIM owner and target, and optional custom envelope/tracking hostname. Ask Support to confirm signing configuration and, if requested, the custom-domain activation. Reseller clients should send this through their reseller. Public DNS working is a prerequisite, not proof that the space is configured.

3. Inspect a controlled message from the actual workflow

After activation, an authorized operator should send a controlled campaign or test through the relevant space to a mailbox they control. Obtain the original received message and the receiver's authentication results.

Trust only results added by receiving infrastructure you control or trust. An attacker can prepend an Authentication-Results header. A familiar authserv-id string alone proves nothing. If your receiver cannot identify or remove untrusted fields, use a separate trusted mailbox or receiving trace. Authentication-results trust boundary

Record the following together:

1. The visible From is the intended address, unchanged.
2. The intended Maxemail DKIM signature has the expected d= and selector s=, passes verification, and aligns with that From under the applicable adkim mode.
3. The actual envelope domain and SPF result are understood. The default provider domain may pass without aligning; a custom domain must really appear in the envelope before claiming SPF alignment.
4. The trusted receiver reports dmarc=pass for the intended From domain.
5. Any SPF fail, temperror or permerror is investigated independently, even if DKIM allows DMARC to pass.

For a standard example.com sender, an illustrative successful branded-DKIM result could contain:

From: Newsletter <newsletter@example.com>
DKIM-Signature: ... d=example.com; s=maxemail; ...
Authentication-Results: trusted.receiver.example;
 dkim=pass header.d=example.com header.s=maxemail;
 dmarc=pass header.from=example.com

This is a synthetic excerpt, not a real captured result or a complete message. Inspect SPF separately and correlate each signature with its own trusted verdict. A generic DMARC pass through another signature or SPF path does not prove that the Maxemail signature you configured works. EmailAuth's guide to finding the DKIM selector in the actual message explains how to pair s= with the correct d= when several signatures are present.

Troubleshoot the failed layer

Maxemail documents corporate inbound blocking separately from authentication. Its suggested IP allowlisting is not a required DKIM/SPF step and should not become a blanket bypass of malware, phishing or spoofing checks. Likewise, a valid DKIM signature does not guarantee inbox placement. Consent, complaints, reputation and content still affect delivery; no universal warm-up volume or duration follows from these DNS records.