Authenticated Received Chain (ARC)

Enable ARC on your own mail server

First decide what your server does. A receiving mailbox server needs validation and a trust policy. A forwarding gateway needs those checks plus sealing. A server that only originates your own messages should prioritize working SPF, DKIM and DMARC.

Receiving only? Keep the ARC module enabled, set sign_inbound, sign_local and sign_authenticated to false, and skip key generation and sealing in steps 3–4. Verification uses the remote sealers’ public DNS keys, so it does not need your own signing key.

The worked example below uses an existing Postfix + Rspamd installation on Linux with systemd. Replace relay.example.net, paths and the _rspamd account with your installation’s values. It is a configuration template for a forwarding gateway, not a universal install script. Back up your configuration before editing.

For other stacks, use their supported ARC implementation and keep the same receive/check/modify/seal order. Exim requires its own integration; do not copy Postfix parameters into it. Start with the Rspamd MTA integration guide. Managed mail platforms usually expose provider-specific controls.

1. 1. Connect the mail flow to the filter

   Postfix passes mail to Rspamd through a Milter connection. Confirm the proxy worker is listening locally on port 11332 in Milter mode; it is not the controller’s port. If Rspamd is already connected, reuse that integration.

   Postfix configuration /etc/postfix/main.cf

   # Merge with existing filter lists; do not remove other milters.
   smtpd_milters = inet:127.0.0.1:11332
   non_smtpd_milters = $smtpd_milters
   milter_protocol = 6

   SMTP arrivals use smtpd_milters; local sendmail submissions use non_smtpd_milters. Check service-specific overrides in master.cf. Choose your filter-outage policy deliberately: milter_default_action = accept permits unfiltered mail during an outage, while tempfail temporarily defers it.

   References: Rspamd proxy worker and Postfix Milter configuration.

2. 2. Establish trustworthy inbound results

   Run SPF, DKIM, DMARC and ARC checks at ingress, using the actual SMTP connection context. If scanning happens behind another gateway, configure that boundary explicitly so the checker does not mistake an internal relay’s IP for the original connection.

   Do not accept externally supplied headers that impersonate your own authentication service. Generate local results; only reuse upstream results across a protected, configured trust boundary. Simply matching a familiar server name is insufficient.

   See Authentication-Results trust boundaries. Validate existing ARC before any message modification; seal after the final modification. If separate processes handle these stages, their results must be carried securely between them.

3. 3. Generate a key for the forwarding service

   Use a domain you control as the sealer identity, rather than each external sender’s From domain. This example uses a separate ARC selector and a 2048-bit RSA key. Create a new selector for rotation; do not overwrite an active key.

   Run after replacing the example values

   sudo install -d -m 0750 -o _rspamd -g _rspamd /var/lib/rspamd/arc
   sudo -u _rspamd sh -c 'umask 077; rspamadm dkim_keygen -b 2048 -d relay.example.net -s arc2026 -k /var/lib/rspamd/arc/relay.example.net.arc2026.key'

   The private key stays on the server, readable by the Rspamd service account only. Publish the generated public TXT record at arc2026._domainkey.relay.example.net. Its value begins v=DKIM1; k=rsa; p= followed by your public key. There is no separate _arc policy record.

   Check public DNS

   dig +short TXT arc2026._domainkey.relay.example.net

   Reference: Rspamd key generation. Keep old public keys available during rotation so delayed messages can still be verified.

4. 4. Configure sealing for the intended traffic

   Rspamd ARC configuration /etc/rspamd/local.d/arc.conf

   # Dedicated inbound forwarding gateway example
   enabled = true;
   use_domain = "relay.example.net";
   use_esld = false;
   selector = "arc2026";
   path = "/var/lib/rspamd/arc/relay.example.net.arc2026.key";
   sign_inbound = true;
   sign_local = false;
   sign_authenticated = false;
   allow_hdrfrom_mismatch = true;
   reuse_auth_results = false;

   This example seals inbound mail under the gateway’s own domain. It leaves local and authenticated submission signing off. The mismatch option accommodates different envelope and visible sender domains; it does not make those identities authenticated. Local authentication results are generated instead of copying an incoming header.

   A mailing-list reinjection path may count as local traffic and need different eligibility. Check the actual path and avoid adding multiple sets accidentally. Footer, subject, MIME and DKIM-signing changes must finish before the seal is created.

   Check options against your installed version in the Rspamd ARC module documentation. Keep its DKIM verification dependency enabled.

5. 5. Decide which sealers your receiver trusts

   Cryptographic validity and operational trust are separate decisions. In Rspamd, whitelisted_signers_map identifies trusted signing domains; adjust_dmarc controls the associated DMARC adjustment. Add only intermediaries you have evaluated. Never trust every valid signer or bypass malware and spam checks.

   Publishing your own key does not make other providers trust you. In Microsoft 365, an administrator can configure trusted ARC sealers for their organization using the service’s signing domain from d=. That receiving-side setting does not enable ARC signing on your Postfix server.

   References: Rspamd trusted forwarders and Microsoft 365 trusted ARC sealers.

6. 6. Validate configuration, then activate it

   Run checks first

   sudo rspamadm configtest
   sudo rspamadm configdump arc
   sudo postfix check

   Inspect the effective configuration and resolve errors before activation. After those checks pass, restart Rspamd and reload Postfix during a suitable maintenance window. Syntax checks alone do not prove that the correct mail path is sealed.

   Linux with systemd; only after successful checks

   sudo systemctl restart rspamd
   sudo postfix reload

   Reference: Rspamd configuration tools. Containerized or managed installations need their own restart procedure.

Test the complete delivery path

Use a test mailbox and an independent receiving service. Keep the original message source from each test, plus the corresponding mail-filter logs.

1. Direct delivery: send a message with known working SPF, DKIM and DMARC directly to the destination. Establish a baseline before adding forwarding.
2. Forwarded delivery: send through your gateway. Look for its signing domain and selector, a complete ARC set, and the destination’s own ARC validation result.
3. A real modification: test your actual footer or mailing-list rewrite. Confirm that sealing happens after that change and that the destination can still validate the ARC chain.
4. Negative controls: in an isolated test, change the body after sealing, or use an invalid signature. The receiving validator should detect the failure. A valid but untrusted sealer must not automatically bypass your DMARC policy.

In Microsoft 365, follow its trusted-sealer validation procedure. An arc=pass result does not guarantee inbox placement. Gmail also considers earlier authentication assessments; see Google’s authentication guidance.

If rollout causes problems, restore the previous filter configuration and disable the new sealing policy. Preserve normal authentication checks and investigate before widening trust.

The browser email analyzer helps inspect these headers. Its “reported” and “unverified” labels are intentional: use the destination server or a cryptographic validator to establish whether the signatures actually verify.