Trusted forwarders
Sometimes the server refuses genuine mail only because somebody forwarded it: a mailing list you subscribe to, an alumni address that redirects to your real mailbox, a service that forwards your old mailbox. Mail through any of them can bounce with nothing wrong with it.
The fix is to list the forwarder as trusted on your domain. The trust applies to your domain only.
Why the server refuses forwarded mail
Forwarding breaks SPF. SPF authorizes the servers that may send for a domain, but when a forwarder passes a message to you, we see the forwarder's server, not the original sender's, so the sender's SPF record no longer matches.
That alone doesn't cause a refusal. DKIM signs the message itself, and a DKIM signature normally survives a forward, so DMARC still passes and the mail arrives.
The problem appears in two situations:
| Situation | What goes wrong |
|---|---|
| The sender's domain publishes a DMARC policy but does not sign its mail with DKIM. | SPF was the only evidence DMARC had. The forward broke it, so a genuine message is refused. |
| The forwarder changed the message, e.g. a mailing list that adds a tag to the subject or a footer to the body. | The change invalidates the DKIM signature, and again DMARC has no evidence. |
ARC exists for exactly this. A forwarder that supports ARC records the authentication results it saw when it received the message, then seals that record with its own signature. If we trust the forwarder that sealed it, we can accept its report of a check we can no longer make ourselves.
You probably don't need this
The major providers, Gmail, Outlook, Yahoo, and other well-known services among them, are already trusted for every domain on the server, and so is mail that Elpan itself forwards.
Add a forwarder here only when the server actually refuses its mail.
Add a trusted forwarder
Open Services, select the zone, then the domain's Mail service. Press Edit on the Trusted Forwarders section, type one domain name per line, and save.
The value is the ARC seal domain: the d= value in an ARC-Seal
header, not the service's brand name or the address the mail appears to
come from. For this header you'd type lists.example.org:
ARC-Seal: i=1; a=rsa-sha256; d=lists.example.org; s=arc; ...
The refused message never reached you, so you can't read its headers. Take the value from a message that did arrive through the same forwarder: any earlier message from the same mailing list or forwarding service carries the same seal domain. Use your mail client's "show original" or "view source" option.
If no such message exists, ask the forwarding service which domain it seals with, or ask your provider to read the value out of the mail server's logs.
What trust does, and what it doesn't
| The trust covers your domain only. | It applies to mail the server delivers to this domain and doesn't change how another domain's mail is handled. One exception: a single message can go to recipients in several hosted domains at once, and then one result must cover the whole delivery. A forwarder delivers to each recipient separately, so this is rare. |
| It isn't an allow list. | A message from a trusted forwarder still goes through the spam filter as before. The trust only removes the authentication penalty; spam from a trusted forwarder is still spam. |
| No recorded pass, no help. | The seal must record that the message passed authentication at the forwarder's hop. If it recorded a failure, or nothing, the server still refuses the message. |
| A broken chain changes nothing. | The ARC chain must verify end to end. The server ignores a forged or damaged seal. |
Choose carefully
A trusted forwarder can pass mail to your domain that authentication would otherwise refuse. That's the purpose of the setting, but the trust is real: you accept the forwarder's report about senders you can no longer verify yourself.
A forwarder that doesn't check its own senders carefully, or that an attacker compromises, can pass on forged mail the server would otherwise refuse.
List only the services you actually use and expect to behave correctly, and remove an entry you no longer need. An empty box returns the domain to normal handling.