What data do providers expect in a remediation request?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

Your emails are being blocked, so you fill out a remediation form or fire off a message to a postmaster team. Two days later, nothing. Why? Often because the request was thin on details, and providers won't chase you down for more information. They'll just move on.

Providers are evaluating a few things when they read your request. They want to know you're a legitimate sender, that you understand what went wrong, and that you've actually fixed it. If any of those three pieces are missing, your request stalls.

Here's what a complete request looks like.

Who you are

Start with your organization name, the sending domains you use, the IP addresses the mail is coming from, and a real contact email. This sounds obvious, but plenty of requests skip the IPs or list a domain that doesn't match the one flagged. Match everything exactly to what the provider is seeing.

Your sending profile

Describe what you send and to whom. Are these transactional emails (receipts, password resets) or marketing campaigns? How many emails do you send per day or per month? How did subscribers get on your list? Providers want to understand the shape of your program before they dig into the complaint data.

Your technical setup

Confirm that SPF, DKIM, and DMARC are properly configured on the sending domain. If you have access to postmaster tools (like Gmail Postmaster Tools or Outlook's SNDS), include screenshots or data showing domain reputation and spam rate trends. Attach relevant email headers if you can. This gives the provider something concrete to verify on their end.

What went wrong and when

Describe the issue clearly. When did you first notice the problem? What bounces or error codes are you seeing? Did something change right before it started, like a new IP, a list import, or a sudden volume spike? Providers are pattern-matching here. Help them connect the dots.

What you've already fixed

This is the section that separates weak requests from strong ones. A weak request says "we're sorry and it won't happen again." A strong request says "we removed 4,200 unengaged addresses, tightened our opt-in flow, added a confirmed opt-in step for new signups, and our complaint rate dropped from 0.4% to 0.08% over the last 10 days." Specific actions and measurable results. That's what moves things forward.

And the bare minimum gets you acknowledged. The complete package gets you reviewed. If you're not sure whether your documentation is strong enough, it probably needs more specifics on what changed and why it won't happen again.

Need help building a credible evidence trail? The next question covers exactly that: what counts as credible evidence when you're asking a provider for help.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Build my remediation request

I need to contact a mailbox provider about a delivery problem. Based on my situation below, help me draft a complete remediation request. Tell me if anything is missing and what a 'strong' version of my evidence section would look like compared to a weak one. My sending domain: domain IP addresses: IPs Mail type: marketing / transactional / both Monthly volume: number Issue I'm seeing: describe the block, bounce, or spam placement When it started: date What I've changed so far: list actions taken Authentication in place: SPF yes/no, DKIM yes/no, DMARC yes/no Complaint rate before / after: if known

Edit the yellow boxes, then send to the AI of your choice.