Astonish

Appearance

Email Sender Authentication Setup ​

This is an administrator setup step for the mailbox Astonish monitors, not a setting each user must supply when linking their personal email address. It applies to both IMAP/SMTP and Microsoft 365 (Graph API) email channels.

Astonish relies on the receiving email infrastructure to perform SPF, DKIM, and DMARC checks. It reads the receiver's authentication results before using a message's From address as an Astonish identity. Delivery to the inbox alone is not proof that the claimed sender passed authentication.

Sender authentication is enabled by default (require_sender_auth: true). The current implementation requires a configured trusted_authserv_id and rejects messages without a passing DMARC result for the From domain. Mailbox credentials and a successful Test Connection establish mailbox access; they do not establish incoming sender authentication.

Find the Receiver's authserv-id ​

  1. Open a recent message received by the Astonish mailbox, preferably a test message sent from a known external account. Do not use the sender's Sent Items copy.

  2. View its full internet headers:

    • Outlook on the web / new Outlook: open the message → … (More actions) → View → View message details.
    • Classic Outlook for Windows: open the message in its own window → File → Properties → Internet headers.
    • Other mail clients: use the equivalent Show original, View source, or View full headers command.

  3. Find every Authentication-Results: field, including any continuation lines. A standard result can look like this:

    text
    Authentication-Results: mx.receiver.example;
    dkim=pass header.d=sender.example;
    dmarc=pass header.from=sender.example
From: Alice <alice@sender.example>

    In this example, the authserv-id is mx.receiver.example. It is the receiver identifier at the start of the field, before the first semicolon. An optional version number or parenthesized comment is not part of the identifier. This is an example only, not a value to copy into a real deployment.

  4. Confirm with the receiving mail administrator or provider which result was generated by the receiver. The receiver must strip or otherwise prevent externally supplied Authentication-Results fields from impersonating its own authserv-id. Finding a name in a header does not prove that protection exists.

Do not guess the receiver identity

The authserv-id is not necessarily the mailbox domain, IMAP hostname, Microsoft tenant ID, or Microsoft client ID. Do not choose a header merely because it contains dmarc=pass, or assume a Microsoft-looking hostname makes it trustworthy. An earlier mail server or the sender can supply other authentication-results fields.

Microsoft 365 Headers Without an authserv-id ​

Some Microsoft 365 authentication-results formats begin directly with results, for example:

text
Authentication-Results: spf=pass smtp.mailfrom=sender.example;
    dkim=pass header.d=sender.example;
    dmarc=pass action=none header.from=sender.example;
    compauth=pass reason=100

There is no authserv-id in this example. Do not enter spf=pass, microsoft.com, a hostname copied from Received, or an invented value. Astonish's current receiver-authentication parser does not support this format; setting an arbitrary identifier will not make these messages pass.

Ask your mail administrator or provider whether a supported receiver-generated result is available and how its origin is protected. Microsoft Graph mailbox access does not automatically supply a compatible authserv-id, and it does not silently enable provider-trust.

If no compatible, trustworthy result is available, keep the channel in strict mode until a supported authentication path exists, or explicitly select Trust mail provider after confirming that the mailbox infrastructure will not admit spoofed mail. Do not treat inbox delivery as proof that authentication passed.

Configure Astonish ​

Platform Deployments ​

  1. Sign in as a platform administrator.
  2. Open Platform Administration → Channels → Email.
  3. Choose Sender authentication. Strict is the default and still requires a verified identifier in Trusted mail receiver authserv-id. Trust mail provider is an explicit policy; it does not require an authserv-id.
  4. Save the email settings and ensure the channel is enabled.

This configuration is stored in the platform database. Redeploying the application alone does not populate it, and personal channel-linking settings are not the place to configure it.

File-Configured Deployments ​

Add the values to the existing channels.email configuration, retaining your other connection settings:

yaml
channels:
  email:
    sender_auth_mode: strict # or provider-trust
    trusted_authserv_id: "mx.receiver.example" # Required in strict mode; replace with the verified receiver ID

Restart the daemon after changing file-based configuration. Configuring mailbox access through the CLI wizard does not replace this receiver-trust setup step.

Verify Inbound Processing ​

  1. Check channel status and daemon/worker logs after applying the configuration. A successful mailbox connection test alone is insufficient.
  2. Send a new message from an allowed, verified/linked email address whose domain passes the receiver's DMARC checks.
  3. Confirm that Astonish processes the message and sends a reply to that mailbox.

The current check requires exactly one From mailbox, preserved authentication headers, and exactly one result with the configured receiver ID. That trusted result must be the first Authentication-Results occurrence and report dmarc=pass with header.from matching the From domain. Ambiguous, malformed, missing, or failing evidence is rejected before dispatching to an agent.

Troubleshooting ​

SymptomWhat to check
Startup reports configure trusted_authserv_idStrict mode is active and the receiver ID is missing or invalid. Configure it, or explicitly select Trust mail provider.
Startup logs sender_auth_mode=provider-trustExpected when that policy is selected. Confirm the mailbox will not admit spoofed mail.
Test Connection succeeds but no replies arriveConnection testing proves mailbox access only. Check channel startup and sender-authentication logs, then the allowlist and verified user link.
Logs report sender authentication did not passStrict mode rejected the message. Inspect From and Authentication-Results occurrences, receiver ID, order, duplicate fields, DMARC result, and matching From domain.
Logs report From header must contain exactly one valid mailboxProvider-trust still requires an unambiguous RFC 5322 From mailbox.
Microsoft headers begin with spf=... instead of an identifierStrict mode cannot use this format. Follow the Microsoft 365 guidance above, or select Trust mail provider after confirming mailbox policy.
Multiple Authentication-Results headers appearAsk the receiver administrator which result is authoritative and how forged copies are handled. Do not select any passing result at random.

For support, share redacted header excerpts rather than message bodies or credentials. Retain authentication field order and syntax, but redact personal addresses, IP addresses, and internal hostnames as appropriate. Never share access tokens, refresh tokens, passwords, or client secrets.

References ​

References ​

References ​