Mailgun: SPF, DKIM and subdomain DMARC alignment

mg.example.com.            TXT    "v=spf1 include:mailgun.org ~all"
k1._domainkey.mg.example.com.  TXT    "k=rsa; p=MIIBIjANBgkq…"
mg.example.com.            MX     10 mxa.mailgun.org.
mg.example.com.            MX     10 mxb.mailgun.org.
email.mg.example.com.     CNAME  mailgun.org.

DMARC alignment: relaxed mode in action

DMARC only validates a message if SPF or DKIM passes and aligns with the From domain. Mailgun's subdomain arrangement relies on relaxed alignment, which is DMARC's default mode.

In relaxed mode, a subdomain aligns with its organisational domain: mg.example.com aligns with example.com. So a message sent with a From on @example.com, a DKIM signature d=mg.example.com and an envelope on the subdomain passes DMARC on both mechanisms. Under DMARCbis, the organisational domain is determined by the DNS tree walk rather than the old Public Suffix List, but the outcome is identical: the subdomain and the root domain are recognised as belonging to the same organisation.

One detail deserves stating about the From header. Two arrangements coexist: a From on @example.com — the most common, the brand identity — which relies on the subdomain's relaxed alignment, or a From directly on @mg.example.com, which then aligns in strict as in relaxed but exposes the technical subdomain to recipients. The first is almost always preferable for the readability of the displayed address; the second is met only on purely machine flows where the address's appearance matters little.

The one case where this arrangement fails is strict alignment, which demands an exact domain match. A DMARC policy imposing adkim=s or aspf=s would break the alignment of a send via mg.example.com under a From @example.com. Barring a specific need, relaxed mode remains the right choice — it is what makes the subdomain arrangement viable. The worked examples, from the simplest to the strictest show where these alignment tags are set.

US or EU region: data residency

Mailgun operates two distinct regions, American and European, chosen when the sending domain is created. The choice has two effects. The first is technical: the API and the SMTP entry point differ, and a domain created in one region must be driven through that region's endpoint — a frequent confusion when a legacy script still points at the US endpoint for a European domain.

The second effect concerns data residency. For an organisation subject to sovereignty requirements, the European region keeps the processing of emails and their associated logs within the EU. This is less a matter of authentication than of compliance, but it is decided at the same moment — when the domain is created — and corrects poorly afterwards: changing region means recreating the sending domain and re-placing every record. Better settled from the outset.

Shared IP, dedicated IP and warm-up

Mailgun offers two sending-address regimes. By default, sends go through a shared IP pool: reputation there is pooled across customers, which suits moderate volumes and starts without warm-up. Beyond a certain regular volume, a dedicated IP becomes relevant — reputation then belongs to the organisation alone, but it has to be built: a fresh IP must be warmed, that is, ramped up in volume gradually over several days, or receiving providers will treat it as suspect.

This choice has no effect on DMARC alignment — DKIM and SPF align the same way whatever the sending IP — but it weighs on deliverability, and therefore on reading the reports. A fresh dedicated IP may see part of its messages deferred during warm-up, with nothing wrong on the authentication side. Telling a reputation problem from an alignment problem is precisely what aggregate reports allow: the former reads in delivery rates, the latter in the SPF and DKIM columns.

Common configuration mistakes

Several traps recur in the body of reports the free DMARC analyzer processes daily.

Placing the records on the root domain. Configuring Mailgun on example.com instead of mg.example.com loses the reputation isolation and mixes the platform's SPF with that of human mail — an entanglement that complicates any later diagnosis.

Confusing the regions. A domain created on the EU side but driven through the US endpoint will not authenticate as expected, and the reports will show it.

Forgetting to verify the domain in the console. As with other platforms, publishing the records is not enough: Mailgun must observe their propagation and mark the domain as verified before signatures are actually applied.

Tightening the policy too early. Moving to p=reject, or worse to strict alignment, before confirming through reports that all legitimate traffic aligns means risking the rejection of one's own mail.

The final proof: RUA reports

The only proof that a configuration holds is not the Mailgun console, but what recipients report. Once a _dmarc record is published with a rua= address, aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the reports the receivers send back confirms that Mailgun traffic is properly attributed to the domain: the source matching the sending subdomain should appear there with DKIM and SPF aligned.

A simple cadence is enough: a first read a few days after publishing the _dmarc record, once several recipients have reported, then a weekly glance while the policy stays at p=none. Mailgun traffic is quick to recognise by its stable address ranges; any new or unaligned source stands out immediately — a forgotten second sending domain, a misconnected region, a DKIM selector never verified. Once alignment is confirmed over several days and across every flow, the move to p=reject carries no risk. The online analyzer reconstructs this state from the published records and the reports received, and places the domain on the path that leads to p=reject.