# Multi-perspective domain validation (MPIC) becomes mandatory

> Ballot SC-067v3 requires CAs to check domain control and CAA from several network locations, phased in from March 2025 to December 2026.

Source: https://ssl.sh/news/mpic-multi-perspective-validation-required/
Last updated: 2026-11-10

Since 15 March 2025, publicly trusted CAs must confirm domain control and [CAA](https://ssl.sh/glossary/caa/) records from several network locations instead of one. This multi-perspective issuance corroboration ([MPIC](https://ssl.sh/glossary/mpic/)) comes from CA/Browser Forum Ballot SC-067v3 and phases in until December 2026. It makes a BGP hijack in one region much less useful for obtaining someone else's certificate.

## What happened

The CA/Browser Forum adopted SC-067v3 in August 2024. Under the [Baseline Requirements](https://ssl.sh/glossary/baseline-requirements/), a CA's primary [domain control validation](https://ssl.sh/glossary/dcv/) and CAA lookup must now be repeated by a set of remote network perspectives, and enough of them must agree with the result. The phase-in:

| Date | Requirement |
|---|---|
| 2025-03-15 | At least 2 remote perspectives; CA may still issue without quorum |
| 2025-09-15 | Quorum mandatory |
| 2026-03-15 | At least 3 remote perspectives in at least 2 RIR regions |
| 2026-06-15 | At least 4 remote perspectives |
| 2026-12-15 (upcoming) | At least 5 remote perspectives |

Perspectives must be at least 500 km apart. An RIR region is the service area of one of the five Regional Internet Registries: ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC.

## Who is affected

Site owners rarely see MPIC directly, but it changes where validation traffic comes from:

- **[HTTP-01](https://ssl.sh/glossary/http-01/)**: the challenge file under `/.well-known/acme-challenge/` is fetched from several networks. If a firewall, security group, WAF or geo-blocking rule lets only one country or one IP range reach port 80, some perspectives fail and the order is refused.
- **[DNS-01](https://ssl.sh/glossary/dns-01/)**: the TXT record must resolve the same way everywhere. GeoDNS that answers differently by region, or DNS servers that rate-limit or drop foreign queries, can cause disagreement.
- **[TLS-ALPN-01](https://ssl.sh/glossary/tls-alpn-01/)**: the same reachability rules apply to port 443.
- **CAA**: the CAA lookup is corroborated too, so a record that is visible from one region but not another can block issuance.

Let's Encrypt does not publish a fixed list of validation IP addresses, and MPIC makes allowlisting by IP even less practical.

## What you should do

Allow port 80 from anywhere for the challenge path (everything else can still redirect to HTTPS), or switch to DNS-01 if port 80 must stay closed. Then check that the relevant records resolve consistently:

```bash
curl -sI http://example.com/.well-known/acme-challenge/test
dig +short CAA example.com
dig +short TXT _acme-challenge.example.com @1.1.1.1
dig +short TXT _acme-challenge.example.com @8.8.8.8
```

A 404 from the first command is fine; a timeout or connection reset is not. If issuance fails with connection timeouts, see [certbot timeout during connect](https://ssl.sh/errors/certbot-timeout-during-connect/); if CAA blocks it, see [CAA record prevents issuance](https://ssl.sh/errors/caa-record-prevents-issuance/). The [CAA checker](https://ssl.sh/tools/caa-checker/) shows what CAs are authorised for your domain, and the [CAA records guide](https://ssl.sh/learn/caa-records/) explains the syntax.