ARC and Secure Email Gateways: understand indirect mail paths and filters before the mailbox

What this covers and who needs it

Both topics concern the same point in the mail path: an intermediary accepts a message and passes it on, often modified. The question you need to answer depends on your role.

“Secure Email Gateway” is a product term, not a term from the mail standards. In the Internet mail architecture of RFC 5598, a filter before the mailbox is a forwarding intermediary acting as a boundary filter, checking and potentially modifying content. A “gateway” as defined by RFC 5598, by contrast, is a transition between different kinds of mail system. In this chapter, gateway means the filter placed before the mailbox.

ARC: pass authentication results through intermediaries

Forwarding sends the message again. If the forwarder retains the original envelope sender, SPF usually fails because its address is not authorised by the sender domain's SPF record. If it rewrites the envelope sender to its own domain, SPF can pass but is no longer aligned with the visible sender domain. DMARC then depends on a valid, aligned DKIM signature. RFC 7960, section 2.2

DKIM often survives simple forwarding because the signed parts remain unchanged. Mailing lists and filters, however, often modify messages: adding a subject prefix or footer, restructuring MIME parts or replacing links. This invalidates the original DKIM signature. If no aligned SPF or DKIM pass remains, DMARC fails. RFC 6376, appendix B.2, RFC 7960, sections 2.3 and 3.2.3, DMARC alignment

This is where ARC comes in. Each participating intermediary adds an ARC set of three headers with the same instance number i=; numbers start at 1 and may go up to 50. RFC 8617, sections 4.1–4.2

Sources: RFC 8617, sections 3.4, 4.1.1–4.1.3 and 4.4.

The first set carries cv=none. Later sets carry cv=pass if the intermediary found the existing chain valid. If an intermediary finds an invalid chain, it seals with cv=fail; further intermediaries do not continue that chain. A validator checks that each set is complete, the numbers run consecutively from 1 to N and the cv values fit. It then cryptographically verifies the newest message signature and every seal. It should record its result as arc=pass, arc=fail or arc=none in its own Authentication-Results. It must treat a chain with result fail like a message without a chain; DNS errors during key retrieval also count as a permanent failure here. RFC 8617, sections 5.1–5.2.1

A valid chain binds the signed claims to the sealing domains. An intermediary thus states which message state it passes on, which authentication results it claims to have obtained on receipt and which earlier sets it found. It can still claim false results; a signature does not make the claim true. ARC therefore authenticates the identity of some participating intermediaries, but does not assess their trustworthiness. A valid chain indicates neither harmless content nor delivery. The specification explicitly says ARC is not a trust framework. RFC 8617, sections 9–9.4 and appendix A.2

Read ARC headers and Authentication-Results

The following abbreviated example corresponds to the situation in the figure. Received fields are omitted and signature values are placeholders. Domains and the address come from ranges reserved for documentation; mx.example.org is assumed to be your own trusted receiving system solely for this explanation.

Authentication-Results: mx.example.org;
  spf=pass smtp.mailfrom=team-bounces@lists.example.net;
  dkim=fail (body hash did not verify) header.d=example.com header.s=sel2026;
  dkim=pass header.d=lists.example.net header.s=list2026;
  dmarc=fail header.from=example.com;
  arc=pass header.oldest-pass=0 smtp.remote-ip=198.51.100.25
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.net; s=arc2026;
  t=1790000000; b=PLACEHOLDER
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
  d=lists.example.net; s=arc2026; t=1790000000;
  h=from:to:subject:date:message-id:dkim-signature;
  bh=PLACEHOLDER; b=PLACEHOLDER
ARC-Authentication-Results: i=1; lists.example.net;
  spf=pass smtp.mailfrom=alice@example.com;
  dkim=pass header.d=example.com header.s=sel2026;
  dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.example.net;
  s=list2026; h=from:to:subject:date:message-id; bh=PLACEHOLDER;
  b=PLACEHOLDER
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=sel2026; h=from:to:subject:date:message-id; bh=PLACEHOLDER;
  b=PLACEHOLDER
From: Alice <alice@example.com>
To: team@lists.example.net
Subject: [Team] Meeting minutes
Date: Mon, 21 Sep 2026 16:12:05 +0200
Message-ID: <protokoll-0921@example.com>

Read the excerpt in this order:

1. Your own authentication result first. Only an Authentication-Results added by your own receiving system within your trust boundary is reliable; identify it by the authentication service identifier (here mx.example.org). A compliant system must remove fields with that name arriving from outside and falsely carrying your identifier. With several fields, position alone therefore does not determine which to trust. RFC 8601, sections 1.2 and 5
2. The individual results. Here, spf=pass applies to the list's domain, not example.com, and is not aligned. example.com's signature is invalid after the list's changes. lists.example.net's valid signature is not aligned either. The result is dmarc=fail.
3. Your system's ARC result. arc=pass means your system found the chain structurally and cryptographically valid. The sealer is identified by d= in the ARC-Seal. i=1 with cv=none shows that the list is the first and only participating intermediary. header.oldest-pass=0 means all older message signatures in the chain were also still valid.
4. The intermediary's claim. The AAR with i=1 reports that the message passed SPF, DKIM and DMARC for example.com when it arrived at the list. This is a claim by lists.example.net, not a check by your system.
5. The decision. The receiver's local policy determines whether this claim matters. Only if it trusts the sealer may it treat the DMARC failure differently on this basis. RFC 8617, section 7.2.1

Sources: RFC 8617, sections 4.4, 5.2 and 6.

Providers record additional details differently. Microsoft describes the following for Microsoft 365: when a trusted sealer is recognised, the last ARC-Authentication-Results contains oda=1 alongside arc=pass; compauth=pass reason=130 in Authentication-Results indicates that the ARC result overrode a DMARC failure. These are Microsoft-specific indicators, not general notation. Microsoft Learn: Configure trusted ARC sealers

If you have saved a message as an .eml file, this small Python script lists the relevant fields in their order. It only reads them and does not verify signatures; the position number shows which field is further up.

# Lists Authentication-Results and ARC headers from a saved
# message in their original order. Read-only; does not verify signatures.
import sys
from email import policy
from email.parser import BytesParser

FIELD_NAMES = {"authentication-results", "arc-seal",
         "arc-message-signature", "arc-authentication-results"}

with open(sys.argv[1], "rb") as source:
    message = BytesParser(policy=policy.default).parse(source, headersonly=True)

for position, (name, value) in enumerate(message.items(), start=1):
    if name.lower() in FIELD_NAMES:
        print(f"{position:>3}  {name}: {' '.join(str(value).split())}")

Run it with: python3 arc-fields.py message.eml. The script was tested only with our own synthetic files. Cryptographic ARC verification needs an ARC-capable validator; reading the fields does not replace it.

ARC is a receiver's trust decision

The specification permits receivers to include ARC results in their local decision; it does not require them to. Its wording is that a DMARC validator “MAY choose to accept the authentication assessments provided by an Authenticated Received Chain”, as a matter of local policy. It also says receivers should treat every sealer with caution, to prevent attackers sealing their own spam or fraudulent messages to facilitate delivery. RFC 8617, sections 7.2.1 and 9.4

DMARC itself leaves the final treatment of every message to the receiver. For p=reject, RFC 9989 states: “Mail Receivers MUST NOT reject incoming messages solely on the basis of a "p=reject" policy by the sending domain.” Without further knowledge, receivers must treat such failures as p=quarantine. If a receiver departs from the published policy, it should report the fact and reason in the aggregate report. RFC 9989, sections 5.3.6, 5.4 and 7.4

How receivers actually use ARC therefore varies and is established only where they document it:

Sources: Microsoft Learn: Configure trusted ARC sealers, Rspamd: ARC module, Gmail: check authentication, Gmail: Best practices for forwarding email to Gmail, Gmail: Email sender guidelines, RFC 9989, section 7.4.

In DMARC aggregate reports, such an exception is not shown by changing the DKIM and SPF result fields: those must show the values evaluated for DMARC, not the values used by the receiver to override the result. If alignment failed and the applied treatment differs from the published policy, the report must contain a reason element. Permitted types are local_policy, mailing_list, trusted_forwarder, policy_test_mode and other; for ARC-based exceptions, RFC 8617 suggests local_policy with a comment about the sealers. A comment is free text and may be absent. RFC 9990, sections 3.1.1.9 and 3.1.6, RFC 8617, section 7.2.2

<record>
  <row>
    <source_ip>198.51.100.25</source_ip>
    <count>3</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
      <reason>
        <type>local_policy</type>
        <comment>arc=pass as[1].d=lists.example.net as[1].s=arc2026</comment>
      </reason>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>sel2026</selector>
      <result>fail</result>
    </dkim>
    <dkim>
      <domain>lists.example.net</domain>
      <selector>list2026</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>lists.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

The invented excerpt belongs to a report about example.com with p=reject. It shows three messages from the list that the receiver accepted despite DMARC failure (disposition none) and gives its local policy as the reason. Embedded in a complete synthetic report, it was successfully checked locally against the XML schema from RFC 9990. It is not a real report. The DMARC chapter explains how to analyse aggregate reports overall.

Standards status: Experimental, proposed Historic status and DKIM2

• RFC 8617 was published in July 2019. It is explicitly not a Standards Track document, but “published for examination, experimental implementation, and evaluation”. The errata search shows technical reports 7910 (whitespace grammar) and 8357 (missing SMTP reference), both only “Reported”. They are not incorporated as adopted corrections to the specification. RFC 8617, Datatracker
• draft-ietf-dmarc-arc-to-historic-00 has been a DMARC working group document since 22 April 2026, so far only in this first revision. The Datatracker shows no further procedural step; without a new revision, the draft expires on 24 October 2026. It declares the experiment concluded: operators should stop relying on ARC, avoid further Internet-wide deployments and remove existing deployments or restrict them to controlled environments with bilateral agreement. RFC 8617 is to be marked “Historic”. The draft's central lesson is that signatures do not create trust: without reliable reputation for every intermediary, DMARC cannot safely be overridden. Datatracker: draft-ietf-dmarc-arc-to-historic
• RFC 9989 of May 2026 cites ARC as the best-known example of attempts to make mailing lists work with DMARC without rewriting the From field, and notes that none of these approaches is widely used. RFC 9989, section 7.4
• DKIM2 is being developed in the DKIM working group. Active working group drafts are draft-ietf-dkim-dkim2-spec-06 of 28 August 2026, draft-ietf-dkim-dkim2-dns-00 of 20 July 2026 and draft-ietf-dkim-dkim2-bcp-01 of 9 September 2026; the motivation draft has expired. There is no RFC or promised timetable, so there is no adopted standard ready as a replacement yet. Datatracker: DKIM working group

The implications for your decision are an assessment, not statements from a standard:

Forwarding and mailing lists: what actually helps

For domains with p=reject, RFC 9989 requires that they “MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages”. Forwarding is precisely the reason: SPF fails, but DKIM usually survives. For domains whose users participate in mailing lists, the RFC advises against p=reject. The DMARC enforcement chapter explains how to introduce a stricter policy gradually while considering these constraints. RFC 9989, section 7.4

Sources: RFC 7208, appendix D, RFC 7960, sections 2.2 and 4.1.3, RFC 6376, appendix B.2, RFC 9989, section 7.4, Gmail: Best practices for forwarding email to Gmail.

Alias services, university addresses and association addresses usually have no relationship with the sender domain. Solutions therefore must not assume that every sender knows every forwarder or adds them to its SPF record. RFC 7960, section 3.2.1

Secure Email Gateway: a filter in the mail path

A Secure Email Gateway checks messages that are actually routed through it. Depending on the product, licence and configuration, this may include spam and malware checking, link and attachment analysis, quarantine and rules for outbound messages. SPF, DKIM and DMARC, by contrast, check domain authorisation and alignment, not a person's identity or whether content is harmless. The two tasks complement each other.

Filters can be integrated in different ways:

• Before the mailbox service: MX records point to the gateway, which passes messages to the mailbox service after checking. The next section covers this architecture in detail.
• Behind the mailbox service: MX records continue to point to the mailbox service, which routes incoming messages to the filter and back. Microsoft describes this as a separate scenario with its own challenges. Microsoft Learn: Mail flow with a third-party cloud service
• Through an API: some products access mailboxes after delivery. They do not change MX records and cannot be detected in DNS.
• Integrated: large mailbox services include their own filtering functions, whose scope depends on the plan and settings.

Sources for the effects of changes: RFC 8617, section 7.1.1, RFC 7960, section 3.2.5.

Gateway before the mailbox: mail flow, bypass and authentication

Placing a gateway in front of the mailbox service changes who accepts messages from the Internet and where authentication can usefully be checked. The following points apply regardless of provider; a vendor is named where it documents specific settings.

Changing MX records and managing the transition

The domain’s MX records point to the gateway; the gateway knows the accepted domains and forwards messages to the mailbox service. Plan the change with both operators and keep the previous receiving path available until the new path demonstrably works. If you publish MTA-STS, your policy’s mx entries must cover the gateway hosts, and the old policy should continue to work during the transition. A backup MX must enforce the same filters because any published MX can be contacted directly. RFC 8461, sections 4.1 and 8.1, Deploying MTA-STS, MX infrastructure

If you use DANE on the path to the mailbox service, the gateway must support validation. For Exchange Online, Microsoft explicitly notes that, with a third-party gateway, inbound SMTP DANE with DNSSEC protects only the path from the gateway to Exchange Online, and only if the gateway can validate DANE. MX names under mx.microsoft are now also available there alongside the older mail.protection.outlook.com. Microsoft Learn: How SMTP DANE secures email

Preventing direct delivery that bypasses the gateway

The mailbox service’s receiving server remains reachable from the Internet, and its name can often be inferred. At Microsoft 365, for example, it follows a pattern such as <Domain>-com.mail.protection.outlook.com. If the mailbox service accepts messages from arbitrary senders, attackers can bypass the gateway and submit messages directly there. Microsoft Learn: Direct Send and SMTP relay

• Microsoft 365: Microsoft recommends securing the organisation so that it accepts messages only from the third-party service: through an inbound partner connector bound to the gateway’s certificate (preferred) or IP addresses. Directly submitted messages are then rejected. The RejectDirectSend setting has a narrower effect: it rejects anonymous messages with one of your own accepted domains in the envelope sender that do not match a connector. Microsoft Learn: Mail flow with a third-party cloud service, Microsoft Learn: Set-OrganizationConfig
• Google Workspace: “Reject all mail not from gateway IPs” restricts incoming mail to the listed public gateway addresses; “Require TLS for connections” requires TLS for this path. Google also explicitly notes that Gmail does not enforce the sender’s DMARC policy for messages arriving through the configured inbound gateway. Authentication data still contributes to spam and phishing assessment. This decision must fit the checks performed by your gateway. Google: Inbound mail gateway
• Your own server: Restrict acceptance on port 25 for the affected domains to the gateway’s addresses, using a firewall or MTA rule.

Old relay and forwarding permissions at the gateway, together with orphaned DNS references, are a related attack surface; the section on Echospoofing and SubdoMailing explains them.

Checking authentication at the boundary

Behind the gateway, the mailbox service sees the gateway’s IP address as the source of the SMTP connection; the message’s sender fields are separate. Microsoft explains that the message takes on the source address of the last hop before Microsoft 365: this is how SMTP works, rather than a limitation of Microsoft 365. An SPF check against that address says nothing about the original sender. RFC 7208 therefore places the check at the border MTAs, including all secondary MX hosts; elsewhere, the RFC says it is likely to produce unreliable results. Microsoft Learn: Enhanced Filtering for Connectors, RFC 7208, Appendix F

If the gateway changes messages — banners, rewritten links or removed attachments — the original DKIM signature also fails afterwards. Without a countermeasure, the mailbox service may therefore classify legitimate messages as DMARC failures or spoofing. Two documented approaches address this:

• Passing on the gateway’s result: The gateway checks SPF, DKIM and DMARC before making changes and seals the message with ARC. The mailbox service trusts this seal; in Microsoft 365, this is configured by adding a trusted ARC sealer. RFC 8617 describes precisely this use by scanning services to which MX records are redirected. RFC 8617, section 7.1.1
• Skipping the gateway’s address: Microsoft 365 offers “Enhanced Filtering for Connectors”, also called skip listing. According to Microsoft, the feature preserves the original source address and compensates for DKIM failures caused by modifications. Microsoft explicitly recommends it for gateways that do not support ARC and advises against disabling spam filtering for gateway addresses across the board: many filtering providers share addresses among many customers, so an exception could also admit spoofed messages from those addresses. Microsoft Learn: Mail flow with a third-party cloud service

The gateway also shifts the trust boundary for Authentication-Results. A provider-operated gateway can be inside your trust boundary if you configure it that way; RFC 8601 explicitly includes systems operated by a service provider in its data centre. Define which system writes which results and which field your administrators evaluate. The receiving system must remove fields arriving from outside that carry your identifier. RFC 8601, sections 1.2 and 5

The outbound path

Whether outbound messages pass through the gateway is a separate decision. The gateway belongs in the SPF record only if they do; Microsoft states this explicitly for Microsoft 365. If the gateway changes outbound messages, for example by adding a signature block or notice, the DKIM signature must be created afterwards: either by the gateway itself using an aligned domain, or through a design that makes no further changes after signing. RFC 6376 explicitly requires modifying intermediaries such as mailing lists to make their changes before signing again. Microsoft Learn: Mail flow with a third-party cloud service, RFC 6376, section 5.4, SPF, DKIM

The following DNS query shows which MX targets your domain publishes. It was not run for this chapter; the names and output are examples.

dig +short MX example.com
# Example output (invented):
# 10 mx1.gateway.example.net.
# 20 mx2.gateway.example.net.

The output answers only which targets senders should use. Configuration and your own test messages establish whether the mailbox service also accepts mail directly, whether filtering takes place and whether your messages arrive correctly authenticated. Where the Email Security Check offers a private test email, it shows the SPF, DKIM and DMARC findings for that one message; it does not include ARC analysis.

Choose a gateway: questions to ask instead of brand lists

This chapter does not list providers, market shares or ownership structures. Such information changes quickly and establishes nothing about the protection provided by a particular installation. Provider categories in market studies and market shares are different measures; a study can only be assessed alongside its date, products covered and methodology. Detection rates are meaningful only with the test setup, selection of attacks, product version, configuration and false-positive rate. Registered office and ownership are information for the contract, but neither evidence of protection nor proof of compliance.

Your own forwarding service or mailing list: use ARC only for a clear purpose

If you operate a forwarding service, mailing list or gateway yourself, first review the measures in Forwarding and mailing lists. ARC signing supplements them; it replaces none of them. Before sending sealed messages for the first time, publish and check the corresponding public key. In live mail flow, follow this order:

1. Check on arrival. Evaluate the incoming message’s SPF, DKIM and DMARC and record the results in an Authentication-Results field with your own identifier. This becomes the AAR.
2. Modify and sign. Complete all changes, including your own DKIM signature, before sealing.
3. Seal last. Add the ARC set with the next instance number. If the message already contains a chain whose most recent seal has cv=fail, do not add another seal.
4. Maintain the keys. ARC uses the same key publication mechanism as DKIM, under <selector>._domainkey.<signing domain>. The selector name can be chosen freely; the name arc is not mandatory. The specification imposes no requirements on the selectors and domains used by the seals.
5. Test and document. Check results at receiving systems you control, and tell recipients who want to trust you which signing domain you use.

Sources: RFC 8617, sections 4.1.2, 4.1.3 and 5.1.

The state of common implementations as documented on 27 September 2026:

• OpenARC: Development continues in the flowerysong/OpenARC project. Its changelog lists version 1.3.0, dated 29 October 2025, and describes the changes since the Trusted Domain Project’s last release starting with version 1.0.0 in October 2024. The README still describes ARC as experimental and the package as intended for operators who want to participate in the experiment. Check separately which version your distribution ships. OpenARC: CHANGELOG, OpenARC: README
• Exim: Experimental ARC support has been available since version 4.91 and must be enabled when building (EXPERIMENTAL_ARC). The Exim documentation still refers to ARC draft 11 and notes that alignment with RFC 8617 remains outstanding. Exim: NewStuff, Exim: experimental-spec.txt
• Rspamd: According to its documentation, the ARC module has verified and signed messages since version 1.6. Mailcow includes Rspamd as its filtering component. Rspamd: ARC module, Mailcow documentation

What the Email Security Check observes about ARC and gateways

The Email Security Check reads your domain’s public DNS data. For ARC and gateways, it provides only unweighted hints; they do not change the grade, and an absent hint is not a defect.

Older stored results may still show ARC with the points awarded at that time; they retain their stored scale and likewise do not prove that a message chain was checked.

The free Email Security Check lets you examine your own domain, or one you are authorised to check, without registration; the check page explains the exact scope. For this chapter’s questions — trust in a sealer, restricted acceptance and the effectiveness of a filter — you also need your systems’ configuration and your own test messages.

Typical symptoms and next steps

Keep evidence and documentation within their limits

For a gateway, record the MX record set and timestamp, forwarding destination, acceptance restriction at the mailbox service, configured ARC sealers and their signing domains or the setting for skipping the gateway address, message modifications, the outbound path with SPF and DKIM, and the headers of dated test messages. For a forwarding service or list, include rewriting and any ARC seal.

Neither a set of ARC headers, an MX pattern nor an Email Security Check result demonstrates effective filtering or fulfilment of organisational or legal requirements. The chapter on Compliance and documentation addresses which requirements apply to your organisation; this chapter makes no statement on that question.

Related next topics

• DMARC: alignment, policy and reports — why an aligned pass is needed and how to read aggregate reports.
• DKIM: signatures and selectors — which modifications invalidate a signature.
• SPF: authorising senders — when a gateway belongs in the SPF record.
• DMARC enforcement — introducing a stricter policy while accounting for forwarding.
• MTA-STS and TLS-RPT and MX infrastructure — the MX record set and transport policy when changing gateways.
• Threats against which a suitably operated filter can provide additional help: phishing, Business Email Compromise, dangerous attachments and Echospoofing and SubdoMailing.

Previous chapter: DNS security: DNSSEC, DANE and CAA. Next chapter: Email alias strategy.