Quick answer: MIDAS v4.43 documents a fixed sender email address for its Cloud sending option. Changing the displayed sender name or Reply-To is not custom-domain authentication. Do not publish guessed MIDAS DKIM records or add a generic SPF include to your company domain simply to brand these notifications.
This guide covers the cloud-hosted Cloud route, not a complete setup for customer-operated SMTP or self-hosted Sendmail. It helps you choose the correct next action before changing production DNS. No tenant configuration, DNS changes or email delivery tests were performed for this article.
Check your MIDAS version and sending route first
In MIDAS v4.43 Manage Email Settings, open MIDAS Admin Options → Email and inspect Send email through. Cloud is for cloud-hosted systems; SMTP is available in both hosting models; Sendmail is self-hosted only. These are different operational paths, not interchangeable labels.
For Cloud, the manual permits a sender name, while the sender email address is fixed. Use this for all outgoing email? controls whether user-triggered messages use that same name or the initiating user's name. Reply To supplies the address for replies, not a new authenticated From domain. Record the current selections before proposing any change. Only an authorised operator should alter them.
Do not switch a working SMTP route to Cloud as a shortcut for a DNS warning. A route change can change the sender identity, reply handling and delivery infrastructure. Agree those consequences first, then test the chosen route separately.
Why an older MIDAS article may describe different controls
The v4.42 Cloud delivery announcement describes a Zero Configuration option and customisable From/Reply-To settings when it is disabled. The current v4.43 manual instead documents a fixed Cloud sender address. Do not combine the older checkbox instructions with the current manual into an invented workflow.
Use the documentation matching your actual version and ask MIDAS support to resolve any discrepancy in your account before treating Cloud as a branded-domain sender. An old article is not evidence that the same customisation remains available to every current tenant. Likewise, the announcement's Mailgun partnership does not give you access to a Mailgun account or customer-specific signing keys.
What SPF and DKIM can—and cannot—change here
SPF evaluates a server's permission to use an SMTP envelope identity, not a displayed company name. DKIM validates a message signature associated with its signing domain. Neither mechanism turns a Reply-To address into the message's From address. Adding records at a domain you own cannot change the identity that MIDAS actually puts into a Cloud message.
For this Cloud branding task, there is therefore no customer DNS packet to copy from this article. Leave your existing SPF policy, DKIM selectors, DMARC protection, MX records and nameserver delegations intact. A sender-name edit is not a reason to lower DMARC enforcement, add duplicate TXT policies or remove another application's records.
The provider controls its sending configuration; this guide does not assert that every MIDAS message passes authentication. You still need evidence from the actual message. A branded name next to the actual fixed Cloud From address is not proof of company-domain DKIM, and a successful delivery is not proof that authentication passed.
Verify the real notification, not just the branding screen
After an approved configuration change, use a harmless booking scenario and a controlled external mailbox to inspect both a system-generated notification and a user-triggered message. Avoid real customer invoices, personal data or broad recipient lists. This is a test plan for your operator, not a claim that EmailAuth has run those tests.
- Confirm the actual From address, displayed name and Reply-To. Expand the address details rather than relying on the inbox label. Verify replies reach the intended authorised mailbox.
- Obtain authentication results produced by the receiving mailbox service inside its known processing boundary. Ask its administrator how externally supplied Authentication-Results are removed or distinguished. A familiar server name or a header appearing near the top is not enough: an attacker can insert a look-alike result. This follows RFC 8601's forged-header guidance.
- Record the evaluated SPF identity/result, DKIM signing domain (
d=), selector (s=), signature result and receiver DMARC result. Do not invent the expected MIDAS address, selector or envelope domain; derive them from your genuine message and resolve unexpected identities with support. - Evaluate alignment against the actual visible From domain. DMARC requires a passing aligned SPF or DKIM identity, not merely a pass for an unrelated domain.
adkimcontrols DKIM alignment;aspfcontrols SPF alignment. Relaxed alignment uses the same Organizational Domain; strict alignment requires an exact domain match. A child envelope domain therefore does not automatically satisfy strict SPF alignment. See RFC 9989 sections 4.4 and 4.7.
For Cloud mail, an aligned pass validates the actual fixed Cloud From domain shown in the message. If that is a provider-owned domain, its aligned pass does not prove that MIDAS is sending as your company domain. The manual does not reveal the fixed address or domain; verify it from the real message and resolve unexpected identities with support. Keep authentication success, correct branding and correct reply routing as three separate acceptance checks.
Troubleshoot without weakening domain protection
- The company name changed but the email address did not: that matches the documented Cloud model. Do not keep editing DNS to solve a display-name limitation.
- Replies go to the wrong team: check the intended Reply-To and mailbox ownership. Do not add unrelated SPF or DKIM records for a reply-routing problem.
- A receiver reports an authentication failure: preserve the complete original message privately, timestamp, MIDAS version, route and failure details. Give MIDAS support only the necessary diagnostic material through your established support channel. Do not send passwords, private keys or unnecessary booking/customer data.
- Some messages work and others do not: compare system-triggered and user-triggered paths, actual identities, recipients and receiving services. A forwarded copy may have different authentication outcomes from a direct test; retain both separately.
- SPF fails while DMARC passes: inspect which aligned DKIM signature supplied the pass. Do not label SPF healthy;
fail,temperrorandpermerrorare different findings requiring diagnosis. - You need mail to come from your own domain: stop treating Cloud display-name settings as sufficient. Decide whether an authorised SMTP integration is appropriate and obtain the actual mail provider's account-specific authentication requirements. For a Microsoft 365 sending account, see EmailAuth's Microsoft 365 SPF and DKIM guide. That is a separate configuration decision, not a claim that this Cloud guide completes it.
If a branding change causes a problem, restore only the approved settings you recorded and retest. Do not delete shared keys or alter DNS routing as an improvised rollback.