A provider's sending-address change can expose a stale allowlist, an incomplete configuration or a route nobody realised was active. The response should establish which of those occurred. Adding the IP shown in the first rejection may restore one sample while leaving the underlying maintenance problem intact.
Confirm the change and its scope
Collect affected and unaffected message evidence, including event times, receiver-observed IPs and evaluated envelope identities. Check the provider's current authenticated console instructions, official documentation or support response for your service. A reverse DNS name or network-owner lookup alone does not establish that an address is authorised for your tenant's mail.
Determine whether the affected traffic uses the configured primary service, a newly enabled region, a different relay or a custom route. Do not infer a provider-wide incident from one application's behaviour. Keep any unconfirmed explanation labelled as a hypothesis until the routing evidence supports it.
Identify how your policy follows the provider
A dependency-based policy can reflect changes made to the referenced provider policy. A static copied range needs an update. A managed generator introduces an additional chain between the provider source and your published value. RFC 7208 section 5.2 explains include evaluation; it does not promise a particular provider refresh service.
Compare the provider's supported configuration, your intended policy and the actual DNS answer. If you use flattening, inspect freshness and both added and removed ranges using the stale-copy workflow. If you use a provider include, confirm it is the right one for the product and tenant configuration, and inspect its current evaluation rather than assuming the word “include” guarantees correctness.
Reproduce one failure precisely
Use the failing connection IP and envelope domain in a standards-aware evaluator. Preserve the dependency trace and result category. A genuine fail differs from an error caused by excessive evaluated terms, missing policy or temporary DNS failure. RFC 7208 §2.6 and RFC 7208 §4.6.4 provide the relevant distinctions.
Consider this illustrative incident. A service moves some traffic from 192.0.2.10 to 192.0.2.20, while the customer retains a manual entry for the former. These documentation addresses are examples only. The appropriate correction depends on the provider's supported authorisation, not on treating those two observations as its complete sending fleet. Include IPv6 in the investigation when the route uses it.
Choose a supported repair
If the documented policy dependency is missing or wrong, prepare the correct supported configuration. If a flattened copy is stale, fix its refresh or publishing stage as well as the current output. If the provider's own published policy appears inconsistent with its sending route, preserve a minimal reproducible case for its support team and avoid inventing a permanent workaround.
Any temporary exception should have confirmed scope, approval, a named owner and an expiry or review condition. Do not authorise an entire hosting platform because the new address belongs to it. Preserve the existing record and check the complete replacement for syntax, lookup behaviour and unintended authorisation changes before publication.
Verify recovery and prevent recurrence
Test the affected application through its ordinary route and inspect a trusted receiver result. RFC 8601 is the reference for interpreting authentication assertions across trust boundaries. Repeat tests across relevant routes rather than extrapolating from one successful message.
Keep the provider evidence, exact DNS diff, received-message results and remaining exceptions in the incident record. Remove temporary entries when the supported durable repair is verified. Add monitoring for the stage that failed: source changes, generator freshness, publishing errors or unexpected routing. The goal is not a longer emergency allowlist. It is a maintainable authorisation path that follows the service you actually use.
Put the decision in writing
For a hypothetical failed message, retain one row for provider instruction/version, intended envelope domain, observed IP/family, source policy at capture time, generated value, published answer and receiver result. If the provider source includes the new address but the generator does not, investigate generation; if generation is current but DNS is old, investigate publication and resolver state. These are conditional diagnostic cases, not findings about a named provider.