Fix 5.7.1 Sender Unauthorized

Why is your Mailgun or Mandrill email being rejected with 5.7.1 Sender Unauthorized?

You sent the email. The system says it went out. But the bounce says “5.7.1 Sender Unauthorized.” You’re not sure what went wrong — not a typo, not a bad list. You’re using Mailgun or Mandrill. The message isn’t rejected because it’s spam. It’s rejected because the recipient doesn’t trust you as the sender.

This error is about identity, not content. It’s not a list issue. It’s not a typo. It’s a domain infrastructure problem. The recipient server sees your domain and says, “I know who you claim to be — but I don’t believe you.”

How to resolve 5.7.1 sender unauthorized in Mailgun or Mandrill? The fix is in your DNS records, your sending configuration, or your domain’s reputation. We’ll show you exactly where to look — and how to fix it without guessing.

Key takeaways

5.7.1 Sender Unauthorized means the recipient server recognizes your domain but refuses delivery due to untrusted sender identity.
Common causes are missing, incorrect, or misaligned SPF/DKIM records, unauthorized sending IPs, or poor domain reputation.
Resolving 5.7.1 requires verifying your email authentication setup, not just checking addresses or retrying sends.

What does 5.7.1 Sender Unauthorized actually mean in SMTP logs?

The 5.7.1 Sender Unauthorized error is an SMTP status code defined in RFC 5321, indicating the recipient server rejected your message because it couldn’t verify your sender identity. It’s not about the email address being invalid—more likely, your domain or IP fails authentication checks like SPF, DKIM, or DMARC. This happens when Gmail, Outlook, or corporate filters see your message but can’t confirm you’re authorized to send from that domain.

How Authentication Rules Trigger 5.7.1

When you send through Mailgun or Mandrill, the receiving server checks your domain’s SPF record to see if your sending IP is listed. If not, or if DKIM signatures don’t match, the server flags the sender as unauthorized. The same applies if your domain’s DMARC policy rejects the message—especially with strict policies (p=reject). This is not a bounce from a user, but a technical rejection at infrastructure level.

Let’s say you’re using a third-party service like Mandrill that sends via a shared IP pool. If SPF is misconfigured or your domain doesn’t allow that IP, Gmail will reply with 5.7.1. It’s a common issue when organizations don’t update DNS records after switching providers or using non-compliant tools.

What You Can Actually Control

You can’t fix the recipient’s policy—but you can prevent 5.7.1 by ensuring SPF, DKIM, and DMARC are set up correctly. A valid SPF record must include the IP addresses or hosts permitted to send on your domain’s behalf. DKIM signing must align with the From address. DMARC reports help spot misconfigurations, and policies should be set to monitor first before enforcing strict rejections.

Even if you’ve done it right, a single mismatch can cause rejection. For instance, if Mailgun is listed in SPF but not in a DMARC-reported policy, some servers may still reject the message. The result? Your carefully crafted emails land in spam or disappear with no trace.

Before sending to a large list, use a tool like bulk email verification to catch invalid or risky addresses early. Even more useful: test inbox placement with an inbox placement tester to see if your authenticated emails actually land in the inbox—before you waste time fixing config issues after the fact.

How to diagnose the root cause of 5.7.1 in Mailgun or Mandrill

5.7.1 sender unauthorized means the receiving server rejected your message due to failed authentication checks—commonly because SPF, DKIM, or DMARC policies aren’t properly configured, or your domain/IP is blacklisted. Let’s go through the exact steps to confirm where the failure lies.

Check your DNS records and authentication alignment

Use MxToolbox or the command-line dig to check your domain’s SPF, DKIM, and DMARC records. Ensure SPF includes Mailgun’s or Mandrill’s sending IP ranges (typically 54.197.x.x or 54.221.x.x).
Verify that your DKIM signature is published in DNS with the correct selector and domain. Misalignment between your "From" domain and the DKIM-covered domain will trigger rejection.
Test your setup with real-time tools like Spamhaus Lookup to check if your domain or IP is listed on any blocklists—these can cause hard bounces even with correct authentication.

Evaluate sending behavior and reputation signals

Review recent sending volume. Sudden spikes in email volume—even from a valid domain—can trigger reputation-based filters at large providers like Gmail or Outlook.
Confirm that your "From" domain matches the domain used in SPF and DKIM. Mismatched domains are a common root cause of 5.7.1.
Use MailTester’s bulk email verification to identify invalid or disposable addresses before sending—bad lists harm sender reputation over time.

Once you’ve verified these components, your 5.7.1 errors should resolve. If they don’t, it’s likely a policy or configuration issue at the receiving side, which you can test by using Inbox Placement tools like MailTester’s inbox tester to simulate delivery under real-world conditions.

Step-by-step: Fix SPF misconfiguration causing 5.7.1 errors

If you're seeing a 5.7.1 sender unauthorized error in Mailgun or Mandrill, it means your domain’s SPF record isn’t allowing their sending IPs. You need to update your SPF TXT record to include include:mailgun.org or include:mandrillapp.com, merge all authorized providers without exceeding 10 DNS lookups, and ensure only one SPF record exists per domain. Test the result with a public validator to confirm.

Check and update your SPF record

Log in to your domain’s DNS provider (like Cloudflare, GoDaddy, or AWS Route 53). You’ll need access to edit DNS records directly.
Find your existing SPF record. It’s usually a TXT record starting with v=spf1. If you have multiple TXT records for SPF, that’s invalid—only one SPF record is allowed per domain.
Check whether Mailgun or Mandrill is listed in the include clauses. If not, add include:mailgun.org or include:mandrillapp.com to your SPF line.
If you use other email services (like SendGrid, AWS SES, or your hosting provider), add their includes too. But keep the total DNS lookups under 10—the SPF standard limit.
Combine all includes into a single, well-structured SPF record. For example: v=spf1 include:mailgun.org include:sendgrid.net include:aws SES -all.

Validate the fix

After saving changes, wait up to 48 hours for DNS propagation. Then test your SPF record with a public validator like MxToolbox or SPF Checker. These tools show exactly how your record resolves and spot issues like too many lookups or missing includes.

The 5 steps described in “Check and update your SPF record”, in order.

Be cautious: never use multiple SPF records. If you do, receiving servers ignore them entirely, leading to authentication failures.

When you're ready to prevent sending issues at scale, use a tool like MailTester’s bulk email verification to clean your list before sending and double-check that every address can receive mail—before you even send. This catches invalid or unverifiable domains early and reduces the risk of trigger warnings like 5.7.1.

Remember: SPF is one part of a full sender reputation strategy. Even if SPF is correct, poor send behavior—like high bounce rates or spam complaints—can still cause rejection. Use tools like inbox placement testing to see how your messages land in real inboxes.

How to verify DKIM alignment for Mailgun or Mandrill sending

If you're seeing a 5.7.1 sender unauthorized error with Mailgun or Mandrill, DKIM alignment is likely misconfigured. You must publish the correct DKIM selector (mailgun or mandrill) in a DNS TXT record at selector._domainkey.yourdomain.com, ensure the public key matches what the provider issued, verify the DKIM-Signature appears in the email’s raw headers, and confirm it aligns with the From domain. Use a header analyzer to validate the signature structure against RFC 6376.

Check DNS record setup

Confirm your DNS provider hosts a TXT record at mailgun._domainkey.yourdomain.com (for Mailgun) or mandrill._domainkey.yourdomain.com (for Mandrill).
Ensure the value of the TXT record starts with v=DKIM1; k=rsa; and includes the full public key, with no truncation or encoding issues.
Use Google’s DNS lookup tool or MxToolbox to verify the record is published and resolves correctly.

Validate DKIM signature and alignment

Fetch a recent email from your Mailgun or Mandrill account and inspect its raw headers using a tool like Mail-Tester or the MailTester inbox tester.
Locate the DKIM-Signature: field and confirm it references the correct selector (e.g., s=mailgun or s=mandrill).
Check that the d=yourdomain.com tag in the signature matches your sending domain exactly — case-sensitive and without subdomain mismatches.
Verify that the signature passes basic structure validation per RFC 6376 — all required tags are present, values are correctly formatted, and no malformed base64 occurs.
If the signature is missing or malformed, recheck the email’s signing configuration in Mailgun or Mandrill’s control panel and ensure you’re not overriding defaults unexpectedly.

Aligning DKIM correctly is one of the few ways to directly resolve 5.7.1 errors from Microsoft’s systems. Misaligned or missing signatures are commonly blocked before even reaching spam filters. Once verified, this fix typically results in a noticeable improvement in inbox placement for recipients using Outlook or Exchange.

Why sender reputation matters even with correct SPF/DKIM

You can have perfect SPF, DKIM, and DMARC alignment, but if your domain has a poor sender reputation, your emails still get blocked—especially with Mailgun, Mandrill, or other ESPs using sender reputation as a gating factor. Even newly authenticated domains are not immune to 5.7.1 errors if engagement is low, complaints are high, or bounce rates spike unexpectedly.

Reputation isn’t just about authentication

Authentication checks are a baseline. But ISPs like Google and Yahoo assess whether your emails are actually wanted. A new domain sending thousands of messages in a day looks suspicious—even if every header is correct. The system learns from behavior over time: open rates, click-throughs, unsubscribes, and spam complaints matter more than technical compliance.

Even legitimate senders get blocked if their reputation drops. A sudden surge in volume from a cold list can trigger throttling. Mailgun and Mandrill both apply behavioral filters. If your sending habits seem aggressive—like many hard bounces or zero engagement—your IP or domain gets penalized, regardless of technical setup.

Proactively clean your list before sending

That’s why using a tool like MailTester before sending is essential. You’re not just verifying syntax; you’re checking whether addresses are live, active, or tied to risky patterns. Disposable domains, catch-all accounts, or addresses on blocklists can drag down your sender reputation even if they technically pass SPF/DKIM.

MailTester checks for these red flags before you send. It identifies high-risk emails, disposable domains, and outdated addresses. You can test thousands of emails at once using the bulk verification feature or integrate real-time validation via the API. This reduces bounces, keeps your bounce rates low, and helps prevent ISPs from marking your domain as spam.

For more context, the M3AAWG (Messaging, Malware, and Mobile Anti-Abuse Working Group) outlines how sender reputation influences inbox placement. You can read about their industry-wide framework on their official site here. Understanding how reputation compounds over time helps you avoid sudden 5.7.1 blocks—even when every authentication check passes.

How to use MailTester to preemptively catch sender authorization issues

Use MailTester’s real-time API and bulk verification to check domain records, authentication (SPF, DKIM, DMARC), and inbox placement before sending. It finds invalid, risky, or catch-all addresses, reducing bounces and complaints. With inbox tests simulating Gmail, Outlook, and corporate inboxes, you can catch delivery issues early. The in-app AI assistant explains results and suggests fixes based on real-world best practices. You can verify up to 100 addresses for free—credits never expire.

Check sender authentication before sending

Run your domain through MailTester’s real-time Verification API to validate SPF, DKIM, and DMARC records. This catches misconfigurations before they trigger a 5.7.1 error in Mailgun or Mandrill.
Use the API to verify individual sender addresses for validity and domain setup. A single bad domain configuration in your list can ruin sender reputation across all messages.
MailTester checks the full validation chain—not just whether an address exists, but whether it’s authorized to receive mail from your domain.

Test deliverability before full deployment

Run inbox-placement testing to simulate delivery to Gmail, Outlook, and corporate providers. This identifies whether a 5.7.1 error is already baked into the recipient’s filters.
Identify and remove addresses that are likely to land in spam or bounce due to poor sender reputation, invalid domains, or role-based accounts (e.g., admin@, sales@).
Use the bulk verification tool to clean large lists. It detects catch-all domains, disposable emails, and high-risk addresses that could trigger blocking.
The in-app AI assistant interprets results and suggests practical steps—like updating SPF records or removing outdated role accounts—based on industry standards like those outlined in RFC 5321 and RFC 5322.

MailTester does not rely on guesswork. It uses live SMTP checks and domain reputation signals to deliver accurate verdicts. It’s used by teams to reduce bounce rates by up to 50% in real-world sending, and to catch authentication issues that break delivery before they hit Mailgun’s filters.

“Sender authorization errors are rarely about the email system. They’re about the domain context. Fixing the root cause early is more effective than chasing bounces.”

With 98.9% accuracy, MailTester gives you a clear view of your email list’s health. You can verify up to 100 addresses for free—no expiry on purchased credits. It's a reliable instrument for teams that need to send at scale without triggering delivery failures.

Common mistaken fixes that don’t work for 5.7.1 errors

You’re not fixing a 5.7.1 sender unauthorized error by tweaking the From name, using a fresh domain, sending less, or blasting the same message repeatedly. These don’t address broken authentication—only real DMARC, SPF, and DKIM setup will resolve it. Attempting these fixes wastes time and risks increasing spam signals.

What doesn’t fix 5.7.1 errors

Changing the From name (e.g. from "Sales" to "Marketing") doesn’t alter sender identity policies. The receiving server checks authentication headers, not display names—your email still fails if SPF or DKIM fails.
Using a different sending domain might bypass the block temporarily, but it won’t fix the underlying misconfiguration. If that new domain lacks valid DKIM or SPF, you’ll just repeat the same error.
Reducing volume doesn’t resolve broken authentication. It may delay the hard fail, but mail servers like Gmail or Outlook still enforce policies based on technical setup, not sending frequency.
Re-sending the same email 50 times increases spam signals. This triggers reputation penalties—especially if the same content goes to multiple recipients across domains. The receiving server sees this as potential abuse.
Adding a reply-to address or using a different return-path doesn’t resolve 5.7.1. This error lies in sender authentication, not in email header routing.
Assuming the recipient’s server is blocking you without checking logs? You could be missing a DMARC policy failure. Use tools like MxToolbox to verify your SPF, DKIM, and DMARC records are properly published and correctly configured.

Real fixes require technical alignment

5.7.1 errors originate from failed authentication checks—often due to missing, incorrect, or inconsistent SPF, DKIM, or DMARC records. The fix isn’t behavioral; it’s configuration. Ensure your domain’s DNS records include valid SPF and DKIM, and that DMARC policies aren’t set to reject without alignment.

For example, if your SMTP protocol expects authenticated senders, a failed DKIM signature triggers 5.7.1. Even one broken record can cause this.

Before mass-sending, verify addresses with real-time checks. Use MailTester’s email checker to validate identities before sending—this catches invalid or risky addresses before they trigger bounces or complaints.

What to do if you’re still getting 5.7.1 after fixing SPF, DKIM, and DMARC

If you’ve confirmed SPF, DKIM, and DMARC are properly set but still see 5.7.1 errors in Mailgun or Mandrill, the issue may lie with the recipient’s internal filtering policies. These policies—like reputation blocks, IP reputation history, or domain behavior rules—aren’t always visible in standard delivery logs. You need to investigate beyond DNS records and reach out directly to the recipient’s email administrator with full headers for further analysis.

Step-by-step: Resolve 5.7.1 after validating core authentication

Check full message headers from the failed delivery. Look for X-headers like X-MS-Exchange-Organization-SCL or X-Spam-Status—these often reveal the exact filtering reason. You can use tools like Mail-Tester to analyze incoming message structure and identify filtering signals beyond DNS.
Reach out to the recipient’s postmaster at [email protected] or [email protected]. Include the full raw headers, the sending IP, and the domain you're sending from. Email administrators can see internal policy decisions that aren’t exposed in public logs.
Ask directly about domain or IP whitelisting. Some organizations have strict filters that block new or unfamiliar domains—even with valid SPF/DKIM. Request they check if your domain is being filtered due to reputation or behavior, or if their system is blocking based on a non-DNS rule.
Give it time to reset. Internal filters, especially in enterprise environments (e.g., Microsoft 365 or Google Workspace), may take 24–72 hours to re-evaluate your domain after authentication fixes. Don’t assume immediate success—monitor delivery logs and retry tests after the window.
Warm up your sending domain gradually. If you're transitioning from low volume, start with 10–20 emails per day and double each week. Sudden spikes trigger spam filters even with correct DNS settings. Tools like MailTester’s inbox placement tester help you check how your messages land across inboxes before scaling.

Even with correct authentication, you may still face 5.7.1 if the receiving server uses additional internal policies. These aren't always visible in standard error messages. The best way forward is transparency: share the full headers, ask for feedback, and wait for policy re-evaluation. It's not just about DNS—it’s about trust, reputation, and behavior.

How to prevent 5.7.1 issues before they happen

Prevent 5.7.1 sender unauthorized errors by validating your domain’s email authentication setup, scrubbing your list of invalid or risky addresses, and gradually ramping up sending volume. Use tools like MailTester to check your domain records, detect catch-alls, role accounts, and disposable domains before they trigger blocks.

Validate your email authentication setup

Ensure your domain has only one SPF record. Multiple SPF records cause alignment failures and increase the risk of rejection.
Use a verified DKIM signature for every sending domain. This proves message integrity to receiving servers.
Set a DMARC policy of none initially, then move to quarantine or reject once alignment and authentication are stable. DMARC is your primary enforcement layer for sender authorization.
Check your setup with a tool like MxToolbox or RFC 7483 to confirm correct DNS configuration.

Keep your list clean and your sending behavior trustworthy

Run your entire list through a real-time verification tool like MailTester’s bulk verification to catch invalid addresses, catch-alls, and disposable domains before sending.
Exclude role accounts (like admin@, info@, support@) — many of these are monitored for spam and can hurt sender reputation.
Avoid sending to known spam trap addresses. These are rarely user-facing, so if you hit one, it signals poor list hygiene.
Start with a small volume — send to 1–2% of your list initially. Gradually increase volume over days to build sender reputation with receiving servers.
Test inbox placement with actual email delivery tests, not just bounce logs. Bounces tell you about failures, but inbox placement tests confirm whether your message reaches the intended folder.
Use inbox placement testing to simulate how your email lands in real inboxes across multiple providers.

Authentication is not a one-time setup. It must be monitored and validated over time, especially when changing sending infrastructure or domains.

Conclusion: Sender authorization isn’t optional—it’s required

The 5.7.1 error is a hard rejection at the receiving server level. It signals a failure in domain-level authentication, not a problem with your list or message content.

SPF, DKIM, and DMARC are not optional checks. A single misconfigured SPF record or overlooked DMARC warning can block delivery for thousands of messages across all providers.

Use MailTester to validate both individual email addresses and the full domain infrastructure. It catches misconfigurations before they cost you inbox placement.

Sources

The platform-wide average cold email reply rate is 3.43%, while the top 25% of senders achieve 5.5%+ and the top 10% reach 10.7%+, based on billions of emails sent in 2025. — Instantly Cold Email Benchmark Report 2026 (via Satellyte) (2026)
Adding a single follow-up email to a cold outreach sequence generates roughly 40–50% more replies than sending the initial email alone. — Instantly Cold Email Reply Rate Benchmarks (2026)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does 5.7.1 sender unauthorized mean?

It means the receiving server knows your domain but refuses to accept email because it doesn’t trust your sender identity. Often due to missing or incorrect SPF, DKIM, or DMARC records.

Does 5.7.1 mean the email address is invalid?

No. The error is about sender identity, not address validity. The recipient server accepts the domain but blocks the message based on policy.

Can I fix 5.7.1 by changing the From address?

No. Changing the From name does not resolve sender authentication. The issue lies in domain configuration, not sender display.

How long does it take for SPF/DKIM fixes to work?

DNS changes may take 10 minutes to 48 hours to propagate. Deliverability changes depend on receiver servers re-evaluating your domain reputation.

Should I include both Mailgun and Mandrill in my SPF?

Yes, if you use both services. But ensure you don’t exceed the SPF limit of 10 DNS lookups. Use mechanisms like include:mailgun.org and include:mandrillapp.com with care.

Is there a tool to test if my domain is blocked?

Yes. Use tools like Spamhaus, MxToolbox, or MailTester’s inbox-placement testing to check blocklist status and deliverability.

Why does my email work for some users but not others?

Different receivers enforce different policies. One may allow your sender with weak authentication; another may block it. Consistent configuration across all providers is key.

Can MailTester help me diagnose 5.7.1 issues?

Yes. MailTester verifies domain records, identifies risky addresses, and tests inbox placement—helping catch infrastructure and deliverability issues before sending.

Do I need DMARC if I have SPF and DKIM?

Yes. DMARC gives receivers a policy for handling messages that fail SPF or DKIM checks. It improves reputation visibility and protects against spoofing.

What if I can't change my DNS settings?

You cannot fix 5.7.1 without DNS access. Work with your hosting or email provider to update SPF, DKIM, and DMARC records.

How do I know if my domain has good sender reputation?

Monitor bounce rates, spam complaints, and delivery success. Use tools like MailTester to validate address quality and simulate inbox placement.

Is 5.7.1 more common with Mailgun or Mandrill?

The error is not tied to a provider. It occurs when domain settings are misconfigured. Both Mailgun and Mandrill require correct DNS records for deliverability.