Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Define the Mailgun route before changing DNS
Mailgun domain authentication should start with the application that sends the message. Record the Mailgun account, selected sending domain, API or SMTP integration, region used by that integration, visible From address and responsible application owner. A domain that appears in the account may belong to a different application or an older environment. This guide covers Mailgun sending-domain configuration; it does not prove that a particular customer has enabled a feature or that an application is using the intended credentials.
In the control panel, use Sending > Domains to select or add the intended domain and obtain its records. Mailgun recommends a sending subdomain and documents merging its SPF authorization into an existing policy rather than creating a duplicate. Its published mechanism is include:mailgun.org; the DNS owner and the full approved policy still depend on your setup. Mailgun domain setup.
Before implementation, save a restricted baseline containing the domain settings, existing authoritative DNS answers and a received message from the current working route. Ask the application owner which scheduled jobs, password notifications, receipts or newsletters use that domain. Agree a test window and a rollback owner. Do not assume a successful test from a developer's separate sandbox represents production.
Choose the correct DKIM publication mode
Mailgun supports different DNS arrangements for signing. The domain-creation API documents Automatic Sender Security as using CNAME records for DKIM instead of a manually published TXT key. It also exposes controls affecting the DKIM signing authority; choosing a root signing domain does not automatically change the SMTP envelope domain. Obtain the active mode and generated records for the account rather than adopting the selector from a screenshot. Mailgun domain-creation reference.
Build a change list with the exact owner, type, value and intended function of each record. Label DKIM delegation separately from a tracking CNAME. The same record type can serve unrelated purposes, and a working tracking hostname says nothing about signature verification. Publish only public values supplied for the intended domain. Private signing material and API credentials do not belong in DNS, screenshots shared outside the authorized team, or the article's worked examples.
If changing an existing domain's Automatic Sender Security setting, treat the operation as a signing migration. The update API says that changing this field requires domain reverification. Plan DNS publication and verification together, and do not remove the prior configuration merely because the new setting was saved. Mailgun update-domain reference.
Preserve incoming mail and other domain users
Mailgun's DNS FAQ distinguishes sending authentication from inbound reception: MX changes are relevant to receiving through Mailgun, and pointing an already-used mailbox domain at Mailgun can disrupt existing incoming mail. Its tracking CNAME has a separate purpose. Follow the account's requirements for the requested functions without moving the organization's mailbox service as an incidental authentication fix. Mailgun DNS FAQ.
For SPF, inspect all TXT answers at the exact owner that will be evaluated. Retain one applicable SPF policy, account for every still-authorized sender, and check the protocol's DNS-lookup limit before adding mechanisms. A root-domain edit does not repair a malformed policy on a distinct sending subdomain. Have another administrator review the proposed difference against the saved baseline, especially when the root domain also supports employee email. SPF specification.
Verify publication and active signing separately
After DNS changes are visible, run the control-panel verification or the documented verification API. Mailgun's verification guide allows for DNS caching and identifies a Verified badge as the domain-configuration result. It also explains that historical or secondary DKIM keys can remain unverified without preventing the required active configuration from signing. Mailgun domain verification.
The useful question is which key signs the message now. An unverified row is not, by itself, a reason to rotate keys or delete records. During Automatic Sender Security adoption, active manual keys are deactivated after the required CNAMEs verify, while old rows can remain visible. Check the actual active configuration and dependencies before cleanup. DKIM-status explanation.
For a failed lookup, compare the saved fully qualified owner with the name actually published. Check whether the DNS host appended the zone twice, whether the record was added to an inactive zone, and whether the response is missing, stale or a different type. Use an authoritative query to establish publication, then a separate resolver to assess what a receiver may see. Keep those observations timestamped instead of treating a screenshot of an unsaved form as evidence.
Prove authentication through the application
Send harmless content to a controlled mailbox through the actual production-like workflow. Open the original received message and collect the trusted receiver's authentication results. Identify the From domain, SMTP envelope identity represented by the receiver's SPF result, and every DKIM signing domain and selector. The Return-Path is useful context, but the receiver's evaluated identity is the stronger evidence for interpreting SPF. SPF and DKIM.
Evaluate alignment against the domain policy actually in force. DMARC can pass through an aligned passing SPF result or an aligned passing DKIM signature. A subdomain relationship can behave differently under relaxed and strict alignment, so record the effective mode rather than assuming that shared branding guarantees a match. Neither a provider delivery event nor inbox arrival alone proves that DMARC passed. DMARC specification.
Use an original acceptance table
Create one evidence row for each materially different application, sending domain and signing mode. The row should contain account identifier, integration name, workflow, timestamp, visible From, Return-Path, SPF identity/result, each DKIM d=/s=/result, DMARC result, observed alignment, DNS capture reference and the restricted original-message location. Keep expected values in separate columns from observed values. Leave untested fields blank or explicitly pending.
Add functional tests for links, replies and any Mailgun receiving route that was intentionally changed. Test at more than one controlled recipient system when practical, and include a forwarded sample if forwarding is part of the business requirement. Compare those cases without treating forwarding-related SPF changes as proof that the direct route is broken. Record content and reputation-related delivery problems separately from authentication failures.
Diagnose and recover without widening trust
If DNS verifies but the live message fails, first confirm that the application used the intended domain and integration. Then compare the observed selector with the published key, and compare the authenticated domain with From. If SPF passes but DMARC fails, investigate alignment and DKIM before adding another SPF include. If no message arrives, distinguish an application submission failure from a receiver rejection; avoid repeated bulk tests while the route is unresolved.
Pause only the affected workflow when necessary. Restore its last approved application and signing settings through a reviewed change, retain useful evidence, and involve Mailgun support with sanitized identifiers and headers. Do not weaken the organization's DMARC policy, move its MX records or reactivate unknown historical keys as an improvised recovery step.
This is a researched candidate, not a tenant test. No live customer DNS, Mailgun configuration or received message was inspected. Current first-party setup evidence is present, but the original exact-route received-message identity table and human mail-security SME approval remain open publication gates.