Why does Mailgun return a 550 5.1.1 error when sending emails?

You send a message through Mailgun. The logs show a 550 5.1.1 error. No bounce-back with a clear reason. Just silence. That’s not Mailgun failing—it’s your domain’s DNS configuration blocking delivery before the message even leaves your server.

This error is not about your credentials. It’s not about Mailgun’s service. It’s about DNS-level authentication: SPF, DKIM, and DMARC records that tell recipient servers, “This sender is authorized.” Skip one, get it wrong, and the recipient’s mail server rejects the message with a 550 5.1.1, meaning “sender domain not recognized.”

Even with perfect SMTP settings and valid API keys, a missing SPF record or misconfigured DKIM signature will trigger this rejection. You don’t need to guess. A structured, real-time domain authentication checklist can identify exactly where the flaw lies, and fix it before your next campaign ships.

Key takeaways

  • Mailgun’s 550 5.1.1 error points to a DNS-level sender authentication failure, not a Mailgun service issue.
  • SPF, DKIM, and DMARC records must be correctly published and verified to avoid authentication rejections.
  • A domain authentication checklist, including real-time DNS record testing, is essential for diagnosing and resolving 550 5.1.1 errors.

Is your domain’s DNS setup causing Mailgun to fail with 550 5.1.1?

Yes. A 550 5.1.1 error in Mailgun typically means the receiving server couldn’t verify your domain’s identity due to missing or misconfigured DNS records. SPF, DKIM, and DMARC are required for trust. If any one is wrong, blocked, or absent, even a single email can fail — especially at scale. Major providers like Gmail and Outlook use these records to block spoofing and spam. Fixing them is step one.

How DNS records tie to Mailgun delivery

Mailgun doesn’t send emails on its own — it acts as a relay. But every email must prove it comes from a legitimate domain. That’s what DNS records do. When you send via Mailgun, the recipient server checks your domain’s SPF, DKIM, and DMARC records in real time. If any are missing or invalid, the server rejects the message with a 550 5.1.1 error.

SPF defines which servers are allowed to send for your domain. DKIM signs each message with a cryptographic key. DMARC tells receivers what to do if those checks fail. You need all three. One gap opens the door to rejection — and volume makes the gap more obvious. A single bad record can cause every message from that domain to fail, regardless of content.

Common mistakes that break email delivery

It’s not just about having the record — it’s about getting the syntax right. An SPF record with a typo, an expired DKIM key, or a DMARC policy that says "quarantine" but isn’t enforced can trigger rejection. Some senders use outdated or poorly formatted SPF records that max out the 10 DNS lookup limit, triggering a failure even before delivery starts.

Even if you think your setup is correct, it can still break. If a record isn’t published or takes time to propagate, the server sees it as missing. DNS changes can take up to 48 hours to resolve globally. You can check the status of your records with tools like MxToolbox or the official RFC 5321 and RFC 5322 standards for email delivery.

Don’t guess. Use a tool to validate your DNS setup properly. If you're sending at scale, it’s not enough to check one email. Test the full setup with real-world inbox placement tests — not just SPF or DKIM checkers, but services that simulate how actual providers treat your messages. This includes checking deliverability across multiple providers, including Gmail and Microsoft 365.

For teams using Mailgun, validating your domain setup before sending is critical. You can also verify recipient addresses before including them in your list — that helps prevent bounces and keeps your sender reputation clean. A bulk email list cleaning tool like email list validation will remove invalid or risky addresses before send, reducing the risk of failure due to poor data hygiene.

What are the three core DNS records required for Mailgun deliverability?

You need SPF, DKIM, and DMARC records to ensure Mailgun emails reach inboxes. SPF authorizes Mailgun’s servers to send on your domain’s behalf. DKIM adds a cryptographic signature to verify email integrity. DMARC enforces policies when SPF or DKIM fail, giving receivers clear instructions. Without all three, your messages face higher rejection or filtering.

SPF: Authorizing Mailgun as a Sending Server

SPF defines which servers are allowed to send mail using your domain. If you're using Mailgun, your SPF record must include include:mailgun.org or include:mailgun.org (depending on region) to authorize Mailgun’s IP ranges. Without this, receiving servers see your message as unverified and may block it.

Spam filters often flag emails from domains with missing or misconfigured SPF. You can test your current SPF record using tools like MxToolbox or RFC 7208, which details SPF syntax and best practices.

DKIM: Verifying Email Authenticity with Digital Signatures

DKIM adds a digital signature to each email sent through Mailgun. The receiving server checks this signature against your public key in DNS. If it matches, the email is trusted. This prevents spoofing and improves inbox placement.

Mailgun provides a unique DKIM selector and public key. You must add a TXT record to your DNS with the selector (e.g., mailgun._domainkey), followed by the full public key. If the key is missing or malformed, DKIM verification fails — even if SPF passes.

Even a small typo in the TXT value can break DKIM. Always double-check the record in your DNS provider’s dashboard and validate with tools like Mail-Tester.

To catch and correct such issues before sending at scale, use a real-time email verification API. Validating your list helps prevent sending to non-existent or malformed addresses that could hurt your sender reputation. Verify every email in your list before sending using our API, which detects invalid addresses, role accounts, and common typos.

How to verify your domain's DNS records for Mailgun setup

You can resolve a Mailgun 550 5.1.1 DNS issue by verifying your domain’s SPF, DKIM, and DMARC records are correctly published and within technical limits. Use a real-time DNS lookup tool to confirm each record exists, then ensure SPF includes include:_spf.mailgun.org, DKIM is published under a subdomain with a valid key, and DMARC starts with p=none before tightening. This prevents authentication failures and reduces the risk of your emails being rejected or marked as spam.

Check each DNS record in real time

  • Use MxToolbox or DNSChecker.org to verify your records are live and return expected values.
  • Check that your domain’s SPF record includes include:_spf.mailgun.org, and no more than 10 DNS lookups are used in total—exceeding this triggers SPF failures.
  • Confirm DKIM is published under a subdomain like mailgun._domainkey.yourdomain.com—this is required for Mailgun’s signing infrastructure.
  • Ensure the DKIM TXT record contains a valid public key in the correct format, with no syntax errors or extra whitespace.

Set DMARC policy based on observability

  • Start with p=none in your DMARC record to monitor how your domain performs without enforcing filtering.
  • After collecting data over 7–14 days using tools like dmarcanalyzer.com, consider switching to p=quarantine if you see consistent reporting from ISPs.
  • Only move to p=reject once you’ve confirmed all legitimate senders are correctly authenticated and no false positives are being triggered.
  • Use a tool that checks DMARC reports, such as Postmark's guide on DMARC reporting, to interpret data and refine policy.

Even with correct configuration, some issues persist due to delayed DNS propagation. Wait at least 5 minutes after updating records before testing. A poorly formatted TXT record, missing subdomain, or overly long SPF can silently break delivery. Let’s treat these checks as standard operating procedure—not just for Mailgun, but for any authenticated sender.

Common DNS errors that trigger Mailgun 550 5.1.1 and how to fix them

Mailgun 550 5.1.1 errors often stem from DNS misconfigurations: duplicate SPF records, too many DNS lookups in SPF, mistyped DKIM selectors, or missing DMARC policies. You can resolve these by merging SPF includes, trimming unnecessary records, verifying DKIM key placement, and adding a DMARC record at _dmarc.yourdomain.com. These fixes ensure your domain passes basic email authentication checks and avoids delivery rejection.

SPF and DKIM configuration issues

Multiple SPF records confuse receivers and trigger 550 5.1.1 errors. You must consolidate all SPF entries into a single TXT record using include: directives. For example, you might have v=spf1 include:_spf.google.com include:sendgrid.net ~all. Exceeding the 10 DNS lookup limit for SPF (per RFC 7208) causes validation to fail. Reduce include chains to avoid this — avoid nested includes like include:example.com that point to other includes.

DKIM signing must match the selector and subdomain. If your DKIM key is published under mailgun._domainkey.yourdomain.com, ensure the selector in your Mailgun settings is mailgun. A mismatch here results in failed authentication, even if SPF is correct. Always verify DNS TXT records using tools like MxToolbox or DNSChecker.org before sending.

DMARC and authentication fundamentals

Without a DMARC record, receivers don’t know how to handle emails that fail SPF or DKIM. Add a basic DMARC policy at _dmarc.yourdomain.com with v=DMARC1; p=none;. This sets the baseline policy to monitor delivery. While p=none is safe, it won’t block fraudulent emails. You’ll want to gradually shift to p=quarantine or p=reject after reviewing reports.

These three records — SPF, DKIM, and DMARC — form the core of email authentication. If any are missing or misconfigured, services like Mailgun will reject your messages with a 550 5.1.1 error. Use a DNS validator to check alignment and record reachability. For consistent verification, consider testing your entire list with a trusted tool like bulk email list cleaning to catch problematic domains before sending.

Authentication Method Required Record Placement Common Issue Fix
SPF Single TXT record with v=spf1 Root domain Multiple records or excessive includes Merge with include:; limit total lookups to 10
DKIM TXT record with public key selector._domainkey.yourdomain.com Misconfigured selector or wrong subdomain Match selector exactly in DNS and Mailgun config
DMARC TXT record with v=DMARC1 _dmarc.yourdomain.com Missing or invalid policy Add v=DMARC1; p=none; and monitor reports

How to test if your domain’s authentication is working before sending batches

You can verify your domain’s authentication setup in Mailgun by using the built-in domain verification tool, then sending a test email to Gmail or Outlook and inspecting the full message headers for Received-SPF: pass and Authentication-Results: pass. If either check is missing or shows fail, your domain’s SPF or DKIM configuration is flawed — even a single misstep can cause a 550 5.1.1 DNS error during bulk sends.

Step-by-step: Validate your domain’s authentication

  1. Use Mailgun’s domain verification page — Go to the Mailgun Control Panel, navigate to the Domains section, and use the built-in verification page to check that your DNS records (SPF, DKIM, and DMARC) are correctly published. This step catches common syntax issues, like duplicate records or incorrect values.
  2. Send a test email to a real inbox provider — Use a personal Gmail or Outlook account. Send a test email from your Mailgun domain, then immediately open the message and view the full headers. This is the closest thing to a real-world test — inbox providers apply strict filters on incoming mail.
  3. Check headers for SPF and DKIM pass results — Look for two lines: Received-SPF: pass (or neutral or softfail — but pass is ideal) and Authentication-Results: dmarc=pass or dkim=pass. These confirm your domain’s alignment with sender policies.
  4. Confirm your DMARC record is actionable — Ensure your DMARC policy in DNS includes a reporting email (e.g., rua=mailto:[email protected]). Without it, you won’t get feedback if other domains impersonate you.

Why missing or failed results mean trouble

If you don’t see pass in those header lines, your email may not pass filters during bulk sends — even if your DNS looks correct. Some providers, like Gmail, will silently reject messages that fail authentication and deliver them to spam or blocklist them entirely.

For example, a 2022 report by Return Path found that 46% of emails from unauthenticated domains were rejected by major providers — not due to content, but because of failed SPF or DKIM checks. These errors trigger server-level 550 responses, including 550 5.1.1 DNS issues, especially when the receiving server checks DNS records for a non-existent or misconfigured domain.

Running this test on your own email list before a campaign avoids mass bounces and reputation harm. Use a tool like Bulk Email List Cleaning to scrub invalid or risky addresses, reducing the risk of sending to domains with weak or broken authentication — even if they’re technically valid.

Why bulk verification with Email List Validation prevents 550 5.1.1 issues

You prevent Mailgun 550 5.1.1 errors—common DNS and authentication rejections—by cleaning your list before sending. Invalid, catch-all, or role-based addresses often trigger backend delivery failures. Using Email List Validation’s bulk verification catches these issues upfront, ensuring only deliverable, properly authenticated addresses reach Mailgun, reducing bounces and protecting your sender reputation.

Invalid and role-based addresses are a primary source of 550 5.1.1 errors

Many 550 5.1.1 errors stem from malformed or non-existent email addresses. Addresses like admin@, sales@, or support@ are often catch-alls or role-based. If your list includes these, Mailgun can’t deliver, and the recipient server rejects the message with a 550 5.1.1 code—commonly because the domain or MX record isn’t properly set up or the mailbox doesn’t exist.

Role-based addresses often appear in large batches in poorly maintained lists. Mailgun treats them with suspicion, especially if they’re used for mass sends. A 2022 report from Return Path (now Validity) found that role-based addresses frequently lead to higher bounce rates and lower deliverability due to misconfigurations, including missing SPF or DKIM records on the domain side.

Proactive list hygiene avoids damage to your sender reputation

Every undeliverable email—especially one that triggers a 550 5.1.1 error—can harm your sender reputation. If Mailgun or any ESP sees repeated failures, it may start throttling your sending or blacklisting your IP range. This isn’t just about bounces; it’s about trust signals.

Disposable domains like mailinator.com or 10minutemail.com are a red flag. These domains are typically used for temporary accounts and are often blocked by ESPs. Sending to them inflates your bounce rate and may signal poor list hygiene. Email List Validation detects these domains during bulk validation, flagging them before you even send.

With a 98.9% accuracy rate, Email List Validation checks every address in your list—validating syntax, domain existence, MX records, catch-all status, and domain reputation. It doesn’t just check if an email exists. It checks whether it’s likely to be deliverable.

Let’s say you’re planning to send a campaign to 10,000 subscribers. Without verification, you might hit a 15–20% bounce rate, much of it from invalid or disposable addresses. Using Email List Validation’s bulk verification first cuts that risk dramatically. You reduce the number of addresses Mailgun has to reject, keeping your delivery rate high and your reputation intact.

For teams managing high-volume sends, a pre-send cleanup is non-negotiable. Start with a free test: [bulk email list cleaning](https://emaillistvalidation.com/bulk-email-list-cleaning) and see how many invalid addresses you’re actually trying to deliver to. The 100 free verifications are yours to use—no expiration, no catch.

Integrating Email List Validation with Mailgun to stop delivery failures

Run every email through Email List Validation before sending via Mailgun—catch invalid, catch-all, or risky addresses in real time. Use the API to block bad addresses at signup, sync with your CRM or ESP to clean lists before campaigns, and test inbox placement across Gmail, Outlook, and Yahoo to avoid deliverability pitfalls. This stops 550 5.1.1 DNS errors and sender reputation damage before they happen.

Prevent 550 5.1.1 errors with real-time address validation

  • Use the real-time verification API to check every new email address immediately upon entry—before it ever reaches Mailgun.
  • Validate high-volume lists in under 15 seconds per 1,000 addresses, filtering out invalid, role-based, or disposable domains that trigger DNS or authentication errors.
  • Set up automated verification on forms, signups, and imports so only valid addresses enter your Mailgun sending queue.
  • Use the API response codes—such as "invalid," "catch-all," or "risky"—to take action, like revalidating or flagging the address for manual review.

Pre-clean campaigns and test deliverability post-verification

  • Connect your Mailchimp, HubSpot, Klaviyo, or SendGrid account to automatically clean your list before launching any Mailgun campaign.
  • Remove addresses that return "550 5.1.1" errors—often due to missing or broken DNS records, incorrect SPF/DKIM configurations, or domain blacklisting.
  • Run inbox-placement testing after verification to simulate how your email lands in real inboxes across Gmail, Outlook, and Yahoo. See where it lands—inbox, spam, or blocked—before sending.
  • Use the results to tweak your sending practices: adjust sender reputation, improve content alignment, or modify headers to meet provider expectations.
  • According to RFC 5321 (the core SMTP standard), a 550 5.1.1 error means the recipient's domain is not found or has misconfigured mail servers—fixing this upfront prevents bounces and reputational harm.
Deliverability is not just about sending. It’s about sending only to addresses that can receive—and that your domain is allowed to reach.

What to do if DNS records are correct but 550 5.1.1 still occurs

If your DNS records are correct but you're still hitting a 550 5.1.1 error with Mailgun, the issue is likely not DNS itself—but sender reputation, IP blacklisting, or infrastructure limits. Even with perfect DNS, your message can fail if the receiving server distrusts your sender. Let's go through the next-level checks.

  1. Check if your domain is on a blocklist
    Even if DNS is flawless, a domain flagged on a major blocklist like Spamhaus can cause immediate rejection. Use a public checker such as Spamhaus’ lookup tool to verify. If your domain appears, follow their delisting process.
  2. Verify your sending IP isn’t blacklisted
    Shared infrastructure (like Mailgun’s default relay service) means your IP might be sharing space with other senders who triggered filters. Check your IP against major blocklists using MxToolbox. If the IP shows up, consider moving to a dedicated IP or reviewing sending volume.
  3. Review sending volume and rate limits
    Mailgun enforces rate limits based on your plan and history. If you’re sending too many emails too quickly—even with valid DNS—you may trigger throttling. Review Mailgun’s documentation on [daily sending limits and pacing](https://documentation.mailgun.com/en/latest/user_manual.html#sending-limits) and adjust batch sizes or delivery timing.
  4. Check for mismatched authentication headers
    Even with correct DNS, SPF, DKIM, or DMARC records can fail due to misconfiguration. For example: missing or overlapping SPF mechanisms, or DMARC policies set to "none". Use tools like MXToolbox’s DKIM checker to test alignment across headers.
  5. Use the Email List Validation in-app AI assistant to analyze logs
    If you’ve checked DNS, IP, and rate limits, and the error remains, pull your raw Mailgun logs into the inbox-placement testing tool. The AI assistant can parse delivery logs, identify authentication mismatches or suspicious send patterns, and suggest fixes—often pinpointing the exact field or policy causing the 550 5.1.1.

Why the 550 5.1.1 error persists despite correct DNS

It’s a common mistake to assume DNS is the root cause. The 550 5.1.1 error is actually a delivery rejection, not a validation failure. It points to the receiver’s server deciding your email is unwelcome. This decision can be based on reputation, IP history, or alignment—even if your domain name resolves perfectly.

Many senders overlook the importance of historical context. A new domain with sudden high-volume sends often gets flagged. Even with flawless DNS, reputation thresholds trigger rejection before your content is evaluated.

How to maintain domain authentication health over time

You can prevent Mailgun 550 5.1.1 DNS issues and keep your sender reputation strong by auditing SPF, DKIM, and DMARC records monthly, updating SPF when adding new services, reviewing DMARC reports for signs of spoofing, and re-verifying your email list every 90 days. Automated checks and regular cleanup stop bounces, reduce spam complaints, and maintain inbox placement.

Monthly Authentication Audits

  • Run a DNS record check every month using tools like MxToolbox or dnscheck.org to spot mismatches or outdated entries in your SPF, DKIM, or DMARC records.
  • Validate that your SPF record doesn’t exceed the 10 subdomain limit — if it does, use a mechanism like SPF delegation or a CIDR-based policy.
  • Ensure your DKIM selector and public key are correctly published and aligned with the sending domain.
  • Confirm DMARC policies are enforced (p=reject) and reports are being sent to a valid email address or aggregator.

Active List and Service Management

  • Add new email services (like Mailchimp, HubSpot, or SendGrid) to your SPF record only after verifying the correct mechanism and avoiding redundant or conflicting entries.
  • Monitor DMARC aggregate reports — even if your domain has no history of spam — to catch unauthorized senders early; these reports often reveal internal misconfigurations or compromised accounts.
  • Re-verify your email list every 90 days using a trusted service to remove addresses that have been unsubscribed, deleted, or failed delivery for months. This stops your sender reputation from dragging down due to low engagement.
  • Use real-time verification APIs — like the Email List Validation API — when building new lists to prevent invalid addresses from entering your database in the first place.

Final checklist: Fixing Mailgun 550 5.1.1 once and for all

The Mailgun 550 5.1.1 error typically stems from misconfigured DNS records or poor sender reputation. Fixing it requires verifying that your domain’s core authentication protocols are correctly published and validated.

Core DNS Authentication

  • Ensure your SPF record includes include:_spf.mailgun.org and does not exceed 10 DNS lookups.
  • Deploy a valid DKIM record using the selector mailgun._domainkey.yourdomain.com.
  • Set up a DMARC policy at _dmarc.yourdomain.com with v=DMARC1; p=none; to begin monitoring.

Verification and Testing

  • Use real email headers from test sends to confirm SPF and DKIM alignment.
  • Check your domain’s reputation with tools like MxToolbox or Spamhaus.
  • Filter your entire email list through Email List Validation to remove invalid, risky, or disposable addresses before sending.

Once all checks pass, your Mailgun deliveries should reach inboxes consistently. Proactive list hygiene and correct DNS setup eliminate the root causes of 550 5.1.1 issues.

Keep reading

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

Frequently asked questions

What does Mailgun 550 5.1.1 mean?

It means the recipient’s server rejected your email due to a DNS-level authentication failure in your domain’s configuration, usually from missing or invalid SPF, DKIM, or DMARC records.

Can I fix the 550 5.1.1 error without changing DNS?

No. The error originates from DNS-level verification. Correcting SPF, DKIM, or DMARC records in your domain’s DNS zone is required.

How often should I verify my email list with Email List Validation?

Every 90 days or before major sends. This prevents bounces from invalid or disposable addresses and protects sender reputation.

What happens if I skip DNS authentication with Mailgun?

Most major providers will block your emails. Rejection will be logged as 550 5.1.1 or similar, and your domain’s reputation may be harmed.

Does Email List Validation find DNS issues?

No. It verifies email address validity and deliverability risk but does not check DNS records. Use MxToolbox or similar for DNS diagnostics.

Can role-based emails like admin@ or info@ cause 550 5.1.1 errors?

Only indirectly. Role emails may be rejected by recipients, but they do not cause Mailgun’s 550 5.1.1 error. The error stems from domain authentication, not the address content.

Does DKIM need a subdomain?

Yes. Mailgun uses a subdomain like `mailgun._domainkey.yourdomain.com` to publish your DKIM public key. This must be correctly configured.

Why does my SPF record need include:_spf.mailgun.org?

It authorizes Mailgun’s servers to send on your behalf. Without it, SPF fails and triggers rejection by receiving servers.

What is the maximum number of DNS lookups allowed in SPF?

Ten. Exceeding this limit causes SPF validation to fail, even if the rest of the record is correct.

How do I test my domain’s DMARC policy?

Set `p=none` initially, then monitor reports via DMARC analyzers. Use these reports to detect spoofing attempts and adjust policy safely.

Can I use Email List Validation with Mailgun?

Yes. It integrates directly with Mailgun and other platforms, allowing real-time address validation before sending.

Are Mailgun’s 550 5.1.1 errors permanent?

No. They are temporary delivery errors caused by misconfigured domain records. Once DNS is fixed, messages can be sent successfully.