Skip to main content

Relayed Mail, Gateways and ARC

Sometimes a sending source is configured perfectly and still shows up in Palisade with a DKIM authentication failure. The usual reason is that something sat between the sender and the recipient and changed the message on the way through: a security gateway, a filtering service, a mailing list, or a forwarding rule.

This page explains why that breaks DKIM, what ARC does and does not do about it, and how to actually fix it.

Why a relay breaks DKIM​

A DKIM signature covers the message body and a chosen set of headers. It is valid only for as long as those stay byte for byte identical.

An inline gateway usually rewrites something. It might add a banner to the body, prepend [EXTERNAL] to the subject, rewrite links for click protection, or strip and re-add headers. Every one of those invalidates the signature that was applied upstream, and the receiver sees dkim=fail for a message that was signed correctly when it left.

SPF often survives, because the relay is frequently listed in the sending domain's SPF record. When it does, DMARC still passes on SPF alone and nothing looks wrong. The trouble starts when the envelope belongs to a third party, such as mail sent through a marketing platform, because then SPF cannot align either and the broken DKIM signature was the only thing holding DMARC up.

note

This is why a domain can show a healthy overall pass rate while one particular sender fails badly. Look at the sender rather than the domain total.

Which side is the relay on?​

This is the question to settle first, because the answer decides whether there is anything for you to fix at all. There are two shapes, and they look identical in a DMARC report.

On your sending path. Your mail leaves your mail platform, goes through the service, and then out to the world. The service is yours, you configured it, and it can usually be made to sign with your key.

In front of the people you are mailing. Your recipient runs a security product that scans and modifies mail as it arrives, before their mail platform evaluates DMARC. The service is theirs. You have no account with it, and there is nothing for you to publish.

How to tell them apart: look at who is reporting it. If the service is on your sending path, every receiver you mail sees its addresses, so reports naming it arrive from Google, Yahoo, Microsoft and everyone else. If reports naming it arrive from one mail platform only, while your ordinary mail is reported by many, then the service is not sending your mail. It is sitting in front of recipients who all happen to use that platform.

On the domain's Reports page, turn on the Forwarded filter, because a relay's traffic is classified as forwarded and the page opens on Compliant only. Then expand the sending domain and the source. The Reporter column names the receiver that reported each message, which is where to check this before opening a ticket with the vendor.

tip

A vendor telling you "we do not modify your outbound mail" is usually right, and worth testing rather than arguing with. The reporting spread settles it in a minute.

What ARC is​

ARC, or Authenticated Received Chain, is a way for an intermediary to record what authentication looked like before it touched the message. Each hop adds a sealed set of headers saying "when this reached me, SPF and DKIM looked like this."

A receiver further down the chain can then choose to trust that record instead of judging the message only on what survived the trip.

What ARC does not do​

ARC does not make a message pass DMARC. It is advisory. It gives a receiver grounds to deliver something it would otherwise have quarantined or rejected, and nothing more.

Two consequences matter in practice.

The receiver decides, and receivers differ.

  • Gmail evaluates ARC and honours chains from sealers it judges trustworthy. There is nothing to register and nothing you configure.
  • Microsoft 365 honours a sealer only after the receiving tenant has added it under Trusted ARC sealers in Defender's email authentication settings. Until then the chain is ignored.
  • Everyone else varies. Some evaluate ARC and record a failure when the chain does not hold. Many ignore it entirely.

Which way that cuts depends on the shape above. If the relay is on your sending path, you are relying on strangers to trust your vendor, so ARC is a supplement and DKIM signing is the fix. If the relay is in front of recipients whose tenant you administer, the decision is yours to make, and ARC is usually the only lever there is.

The authentication results still say fail. When a receiver honours an ARC chain, it changes what it does with the message. It does not change the SPF and DKIM verdicts it reports. A DMARC aggregate report from a receiver that honoured ARC still shows dkim=fail, alongside a policy override explaining that it delivered the message anyway.

That is why turning on ARC sealing does not close a Palisade ticket. Palisade reads the authentication results, and they still record the failure.

If the relay is on your sending path​

The fix is to get an aligned signature back onto the message after the relay has finished modifying it.

Most gateways and relays can sign outbound mail with a DKIM key for your domain. The feature is usually called DKIM signing, DKIM management, or DKIM hosting in the vendor's console. Once it is on:

  1. The vendor gives you a selector and a DNS record.
  2. Publish the record on your domain, or add it in Hosted DKIM if the domain is managed by Palisade.
  3. The relay signs with d=yourdomain.com after it modifies the message, so the signature is intact when it arrives.
  4. DMARC then passes on DKIM at every receiver, whether or not they evaluate ARC, and whatever the envelope domain is.

The ticket closes on its own as the next reports come in.

tip

If your vendor offers both, ask for DKIM signing first and treat ARC sealing as a supplement. Signing works everywhere. ARC works where the receiver already trusts your vendor.

If the relay is in front of your recipients​

There is nothing to publish, and asking the vendor for a DKIM record will get you a polite no. They are not sending your mail, so they hold no key for your domain and cannot make one. The lever is on the receiving side instead:

  • Where you manage the receiving tenant, which is the common case for an MSP mailing its own clients, turn off the features that rewrite incoming mail, or add the security vendor under Trusted ARC sealers so the receiving platform honours the authentication result from before the message was touched. This is the case ARC was designed for, and it is usually the only lever that exists.
  • Where you do not manage it, you cannot fix it, and you should size it instead. Check what share of your mail this actually affects and whether it would survive an enforcing policy on SPF alone.

Check your SPF record before changing anything. If the vendor's relay is listed in your SPF, mail carrying your own envelope domain still passes DMARC on SPF even with the signature broken, and that may be carrying the great majority of it. Removing that entry to tidy up would turn a cosmetic finding into lost mail.

What stays exposed is mail whose envelope belongs to someone else, typically anything sent through a marketing platform, because SPF cannot align for it and the broken signature was the only thing holding DMARC up.

If you decide to live with it​

Sometimes the relay cannot sign, or the traffic is not worth the change. In that case:

  • Check whether SPF is carrying the sender on its own. If the relay is in your SPF record and the envelope aligns with your domain, DMARC is passing and the DKIM failure costs you nothing today.
  • Understand what happens at enforcement. Anything failing both checks is delivered today only because your policy is p=none. Moving to p=quarantine or p=reject is exactly when it stops being delivered. See Locking Down DMARC.
  • If you have weighed it and want the finding to stop, open the ticket and choose Ignore forever. Palisade stops raising DKIM tickets for that sender and keeps monitoring everything else.