Mailgun 550 5.1.9 Policy Violation | Email List Validation

Why did Mailgun return a 550 5.1.9 policy violation after I added an MX record?

You set up an MX record to handle inbound mail, and suddenly Mailgun starts rejecting your outbound emails with a 550 5.1.9 policy violation. You didn’t change anything on Mailgun’s side—so why the sudden block?

The error isn’t about Mailgun changing its rules. It’s about how your domain’s DNS now conflicts with Mailgun’s own policies. Adding an MX record doesn’t break Mailgun’s service—but misconfiguring it, especially with SPF or DKIM, creates a mismatch that triggers a rejection.

This happens when your domain claims to accept mail via an MX server that Mailgun doesn’t recognize, or when your SPF record doesn’t align with the new MX setup. The result? A policy violation even though your email is technically valid.

Key takeaways

Mailgun rejects 550 5.1.9 errors when your domain’s DNS configuration conflicts with its anti-abuse policies, especially around MX/SPF alignment.
Adding an MX record does not automatically disable Mailgun; but if the MX points to a server not authorized by your SPF/DKIM setup, it creates a policy conflict.
Even if your inbound mail flow is working, a misaligned MX can break outbound delivery if it creates ambiguity about who is allowed to send on your domain.

What does the 550 5.1.9 error mean in SMTP terms?

The 550 5.1.9 error means your email was permanently rejected because the recipient’s mail server rejected it due to a policy violation. Specifically, 5.1.9 refers to a recipient address policy issue, often caused by misaligned SPF, DKIM, or MX records that conflict with the sending domain’s authorization. This commonly happens when you add an MX record for a domain you’re sending from without properly configuring SPF or DKIM to allow the sending system.

Understanding the SMTP response codes

SMTP response codes like 550 are standardized by RFC 5321. The 5xx series means a permanent failure — the message won’t succeed later. Code 550 specifically indicates a permanent refusal, and 5.1.9 is a subcode pointing to a policy-level rejection, not a technical glitch like a bad address or temporary server downtime.

When Mailgun returns this error after you add an MX record, it usually means the domain’s DNS records now conflict with the sending infrastructure. For instance, if you set up an MX record pointing to a third-party email service but continue sending emails through Mailgun without aligning SPF or DKIM, the recipient server will reject the mail. This is a common result of not updating sender policies when changing mail routing.

How SPF, DKIM, and MX must align

SPF (Sender Policy Framework) controls which servers are allowed to send on behalf of a domain. DKIM signs emails cryptographically to prove authenticity. MX records point to where incoming mail should be delivered. If your MX record now routes inbound mail to a different system, but your SPF still includes Mailgun without proper alignment, the mismatch triggers a policy violation.

You can test your setup with tools like MXToolbox, which checks SPF, DKIM, and MX configurations in one place. If you’re unsure whether your domain’s current DNS setup supports sending from Mailgun, a real-time email verification service can confirm whether a sending domain is valid and aligned. Test your sending domain’s authorization before sending any bulk email to avoid these rejections.

How does DNS configuration affect Mailgun’s sender policy acceptance?

Mailgun checks your domain’s SPF record before accepting any outgoing email. If your SPF doesn’t explicitly include Mailgun’s IP ranges or is too restrictive, your message will be rejected with a 550 5.1.9 policy violation—regardless of whether you’ve added an MX record. Adding an MX record doesn’t break SPF directly, but it can signal a shift in email handling, which means your SPF must reflect the new sending source.

SPF: The gatekeeper of sender authorization

When you send via Mailgun, it validates your domain’s SPF record during connection. SPF is a DNS record that lists which mail servers are allowed to send email on behalf of your domain. If Mailgun’s IP addresses aren’t included in that list, the message gets blocked at the gateway. This is how Mailgun enforces sender policy compliance.

SPF is not optional—it’s a core part of email authentication, and it’s governed by RFC 7208. If your SPF record includes only your old provider or blocks any legitimate sender, Mailgun won’t accept the message, even if the address is valid. This includes cases where you've added an MX record for incoming mail but failed to update SPF to include Mailgun for outgoing sends.

MX records don’t cause failures—misaligned configurations do

Adding an MX record doesn’t inherently trigger a 550 5.1.9 error. MX records tell other servers where to deliver incoming mail, not where outgoing messages can originate. But if you add an MX for a new provider, especially one that handles all inbound traffic, it may imply you’re now managing email entirely in-house or via another system.

That shift triggers a red flag if your SPF still only permits one old system. You must update SPF to include both the new incoming server and Mailgun, if you’re still sending from it. A common mistake is assuming that because you’ve added an MX, you can ignore SPF—this leads to policy violations, even if the MX is correct.

Let’s say your SPF says: v=spf1 include:oldprovider.com -all. If Mailgun is now your sending source, that record denies Mailgun, and the send will fail. Fix it by adding include:mgmt.mailgun.org to the list, or use a more permissive mechanism like SPF 2.0 (where supported) with proper mechanisms.

The bottom line: SPF must always reflect your actual sending infrastructure. Even if you didn’t change your sending method, a misconfigured SPF can break delivery—especially after DNS changes like adding an MX. You can double-check your SPF with tools like MxToolbox or Spamhaus to catch issues before they cause delivery failures.

If you're managing a large list, you can avoid such risks by validating sender infrastructure ahead of time. Use bulk email list cleaning to verify that your sending domain’s DNS setup is consistent with your actual email delivery behavior.

What are common DNS misconfigurations leading to 550 5.1.9?

You’re seeing a 550 5.1.9 policy violation after adding an MX record in 2025 because your DNS setup conflicts with Mailgun’s requirements. Common triggers include incorrect SPF syntax, missing or misaligned DKIM, MX records pointing to a non-compliant server, or multiple conflicting SPF records. These break email policy alignment and trigger blocking, even if the MX record appears valid on surface inspection.

SPF record issues

Using an SPF record that excludes Mailgun’s IP ranges (e.g., v=spf1 include:mailgun.org ~all) results in policy non-compliance.
Omitting the include mechanism or using an incorrect syntax like ip4:1.2.3.4 ~all without adding Mailgun’s approved ranges breaks DMARC validation.
Overusing all mechanisms (e.g., ~all when -all is required) can lead to rejection if the policy isn’t strict enough to satisfy receiving servers.

DKIM and MX misalignment

DKIM must be configured with the correct selector and key, tied to the domain and sending subdomain (e.g., mailgun._domainkey.yourdomain.com), and published correctly in DNS.
If your DKIM selector doesn’t match the one Mailgun uses, or if the key is missing or malformed, the signature fails validation.
An MX record pointing to a third-party mail server that doesn’t support Mailgun’s sender policies or lacks proper alignment breaks the overall authentication chain.
Multiple SPF records (e.g., one in the root zone, another in a subdomain) are treated as conflicting by Mailgun and can trigger a 550 5.1.9 error, even if one is technically valid.

These DNS errors often go unnoticed until delivery fails. Check your DNS via tools like MXToolbox or RFC 7208 for SPF and SPF alignment. If you're using Mailgun, ensure your DNS reflects their latest IP ranges and domain policies.

Prevent issues before they hit your inbox. Run bulk list validation to catch invalid or misconfigured sending domains early. Clean your sender list and verify records automatically. You can start with 100 free verifications—no expiry, no risk.

How to verify your SPF, DKIM, and MX records are correctly aligned

Run a full DNS lookup with a tool like MxToolbox to check SPF, DKIM, and MX records together. Make sure your SPF includes Mailgun’s IPs or include:mailgun.org;, DKIM uses the correct selector and public key, and your MX record points to a valid mail server—ideally one that matches your SPF and DKIM policy. Avoid multiple SPF records; merge them into one using the include mechanism or a list of IPs.

Step-by-step DNS verification

Use MxToolbox or a similar DNS checker to inspect your domain’s full DNS record set. You’re looking for SPF, DKIM, and MX records in one place. This helps catch conflicts, misconfigurations, or hidden errors that only appear when all entries are evaluated together.
Confirm your SPF record includes Mailgun. If you use Mailgun for sending, your SPF must explicitly list it—either via include:mailgun.org; or by listing Mailgun’s IP ranges. A missing or incorrect inclusion causes sender policy violations, like the 550 5.1.9 error you’re seeing.
Verify DKIM is published correctly. Check that the DKIM TXT record is in place using the selector specified in your Mailgun settings (usually mailgun._domainkey). The public key must be exact and not truncated. Misformatted or missing DKIM records lead to failed authentication and higher spam likelihood.
Check that your MX record points to a supported mail server. If you've added an MX record but don’t use the server it points to, you’re creating a policy gap. SPF and DKIM authenticate the sender, but MX handles delivery. If MX points to a non-existent or unsupported service, delivery fails even if the authentication is valid.
Eliminate multiple SPF records. Having more than one SPF record causes a validation failure. If you’re using third-party tools (e.g., Google Workspace, SendGrid), combine them into a single record using include: directives or merge all IPs into one list. The DNS system validates only the first SPF record it finds.

Common missteps and quick fixes

Do not add multiple SPF TXT records. Instead, combine them into one string using include: or list all authorized IPs directly.
Ensure DNS propagation completes after changes. Use MxToolbox’s DNS lookup to check if your new records appear globally within 10–30 minutes.
Test real email delivery after fixing DNS. A record can be correct but still produce errors if it’s not properly synchronized with the sending infrastructure.

For teams managing large email lists, using a bulk list verification tool helps identify invalid or risky addresses before sending, reducing the chance of policy triggers and sender reputation damage.

What happens if you add a new MX record without updating SPF?

Adding a new MX record means your domain now accepts inbound mail through a different mail server, but if you don’t update SPF to include Mailgun’s sending IPs, incoming servers will see your outbound messages as unauthorized. Even with a valid MX, SPF failures can cause rejection — Mailgun’s sending infrastructure is no longer aligned with your own email policy.

SPF and MX are not tied together — but they must work together

MX tells receivers where to deliver incoming mail. SPF tells them which IPs are allowed to send on your domain’s behalf. They’re independent, but a mismatch creates a clear red flag. If you route inbound mail through a new server (say, a new cloud provider) but still send outbound from Mailgun without updating SPF, you’re sending from an IP not listed in your policy.

Receiving servers use multiple checks. When they see a message from Mailgun’s IP, they check SPF. If that IP isn’t authorized in your SPF record, the message fails. Some systems will reject it immediately; others may mark it as suspicious. Either way, your deliverability drops.

Mailgun’s 550 5.1.9 error isn’t about the MX record itself. It’s about policy enforcement: you’ve declared a policy (via SPF) that doesn’t permit the sending IP, even if you’ve updated your mail server setup. This is a common configuration oversight — especially during migration or when using multiple platforms.

Prevention and repair: Keep your policies in sync

After adding a new MX, check your SPF record. If Mailgun is still used to send email, ensure its IP addresses are included. You can do this by using a tool that shows the actual IPs Mailgun uses at RFC 7208, Section 5.5 or by checking Mailgun’s official documentation.

If you don’t update SPF, your outbound messages may be blocked or flagged, even with a correct MX. This isn’t just theory — organizations that neglect SPF alignment after server changes commonly see spikes in bounce rates. A single misaligned record can impact thousands of messages.

Use real-time email verification to catch these mismatches before sending. For example, real-time verification can flag invalid or unverifiable addresses based on current DNS rules, helping you catch policy-driven delivery failures early.

How to fix the Mailgun 550 5.1.9 policy violation after MX update

If you're seeing a Mailgun 550 5.1.9 policy violation after updating your MX record, it’s almost certainly due to a misconfigured SPF record or a conflict between your new MX settings and your email authentication setup. Recheck your sender authentication—especially SPF and DKIM—and confirm you're still using Mailgun’s legitimate IP ranges. Never assume the update was seamless. Let’s walk through the fix.

Verify your sending path

Confirm you’re still sending through Mailgun’s official IP ranges. A new MX record doesn’t change where your outbound mail originates. Check your SMTP logs or the Mailgun dashboard under “Sending” to verify the sending IP matches Mailgun’s current ranges.
If your outbound mail is going through a different system now—like an old ESP or a misconfigured internal server—this breaks SPF alignment and triggers a 550 5.1.9 error. You must route all mail through Mailgun’s infrastructure if you’re using their sending services.

Fix SPF and DKIM alignment

Update your SPF record to include Mailgun’s current mechanisms. Use include:mailgun.org to ensure your domain authorizes Mailgun’s IPs for sending. Avoid manually listing IPs; they change often. The SPF specification explicitly supports include mechanisms for such cases.
Do not remove or replace Mailgun’s SPF entry unless you’ve fully migrated to another email delivery platform. Even if you set up a new MX, SPF must still authorize Mailgun unless you’re switching providers entirely.
Verify DKIM is still published and valid. Check a recent email header and look for a valid DKIM-Signature field from mailgun.org. You can validate it using a tool like MXToolbox’s DKIM lookup or analyze headers in your inbox app.
Test with a new message sent via Mailgun’s API or SMTP. Use a simple, clean message with a known recipient. Monitor the email headers and bounce messages. If you still see 550 5.1.9, check if the return-path in headers matches your authenticated domain.

Authentication must align across SPF, DKIM, and the From: domain. A mismatch at any layer triggers policy rejection.

After fixes, monitor bounce reports and logs for 24–48 hours. If the error persists, verify your domain isn’t on a blocklist using services like Spamhaus or MXToolbox. For broader email health audits, consider using bulk email list cleaning to eliminate outdated or malformed addresses that might indirectly affect your sender reputation.

Can an email verifier help prevent 550 5.1.9 errors before sending?

If you’re getting a 550 5.1.9 policy violation after adding an MX record in 2025, it’s likely because your domain’s email policy isn’t aligned with how you’re sending—especially if SPF, DKIM, or MX records are misconfigured. An email verifier like Email List Validation can catch that before you send. It checks whether your domain’s DNS setup (MX, SPF, DKIM) is likely to pass authentication checks, flagging domains with missing, conflicting, or invalid records. That stops you from trying to send from a domain that’s inherently blocked—or worse, flagged as a spoofing risk.

How verification prevents domain policy issues

When you add an MX record, you’re telling the world how to receive mail for your domain. But if SPF and DKIM aren’t properly configured to match, receiving servers see a mismatch. That’s exactly why Mailgun returns a 550 5.1.9 error: the receiving system checks your policy and finds inconsistency. You might assume your MX is correct, but SPF might be missing, conflicting with other records, or not aligned with your sending method. Email verification tools test that alignment before you send.

At a technical level, tools like Email List Validation scan your domain’s public DNS records—including SPF (sender policy framework), DKIM (domain signature), and MX (mail exchanger)—and assess whether they’re likely to pass common email authentication checks. They don’t just validate individual email addresses; they audit the overall policy coherence of the sending domain. If you've added an MX record for Mailgun but forgot to update SPF to allow it, the system flags that as risky.

What this means for your deliverability

A domain with misaligned policy—like SPF excluding Mailgun while MX points to it—isn’t just likely to bounce. It can trigger sender reputation flags, blocklists, or outright rejection. According to RFC 5321, the core SMTP protocol, sending systems must validate sender authority before accepting mail, and failure to do so results in 5xx errors like 550 5.1.9.

Let’s say you’ve built a new campaign using Mailgun, added an MX record, but skipped SPF configuration. Testing your list with a real-time verification API can catch that gap before one message goes out. You don’t have to wait for your first bounce report to discover that your domain isn’t trusted. You can fix the issue in the DNS layer—before sending.

Use bulk verification to scan your entire list and validate both addresses and domains: clean and verify your list at scale. Or integrate our real-time verification API at the point of capture, so you never collect a bad domain in the first place. These aren’t just spam filters—they’re policy validators.

How Email List Validation can stop 550 5.1.9 issues before they happen

You can prevent Mailgun 550 5.1.9 policy violation errors by identifying and removing invalid or risky email addresses before sending. Bulk verification checks every address against real DNS records and SMTP behavior. If a domain has misconfigured SPF, DKIM, or MX records—common triggers for 550 5.1.9—Email List Validation flags it as 'risky' or 'invalid' and blocks it from your send. This preserves sender reputation and reduces bounces.

Real-world verification catches alignment issues

The 550 5.1.9 error often appears when the receiving server detects a policy mismatch—usually due to SPF, DKIM, or MX misalignment. This isn’t just a technical glitch—it’s a security safeguard. Let’s say you send from yourcompany.com but the MX record points to a domain that doesn’t authorize your sending IP. The receiving server will reject it outright. Email List Validation simulates this real-world check at scale, using actual DNS and SMTP interactions.

Each email is tested for validity not just by syntax, but by whether the domain’s configuration supports sending from your IP or domain. We verify SPF records to ensure your sending domain allows the sending infrastructure. We validate DKIM alignment, ensuring cryptographic signing matches the domain. And we confirm MX records point to a mailserver that recognizes mail for that address. If any of these are broken or mismatched, the address gets a 'risky' or 'invalid' verdict.

Stop problems before they impact your deliverability

According to RFC 5321, SMTP servers are allowed to reject mail based on policy violations—550 5.1.9 is a standardized response code for such cases. If you send to invalid or misconfigured addresses, you risk triggering rate limits, blacklisting, or a drop in inbox placement. You’ve likely seen the results: higher bounce rates, lower engagement, and degraded sender reputation.

Email List Validation reduces this risk by filtering out addresses with misaligned records. It’s not just about catching typos or disposable domains—it’s about catching the invisible technical issues that can break sendability silently. For example, a domain might accept mail from [email protected] in theory but block it because the SPF record doesn’t include your sending IP. This breaks the policy and causes 550 5.1.9. Our tool detects this.

By cleaning your list at scale—before any campaign runs—you reduce hard bounces, improve sender reputation, and keep your messages in the inbox. It’s a proactive measure, not reactive. You're not waiting for an email to be rejected. You're preventing the rejection in the first place. Run your list through bulk verification to catch these issues early and keep your Mailgun or SendGrid deliverability intact.

What should you do if you’re still getting 550 5.1.9 after fixing DNS?

If you’ve fixed your DNS records but still see Mailgun’s 550 5.1.9 policy violation, the issue likely lies beyond basic DNS configuration. The error points to a policy mismatch—typically in sender authentication, alignment, or infrastructure abuse. Verify the full sending path: check the email header to confirm the originating domain and sending IP, ensure no third-party service is spoofing your domain, and test delivery with inbox-placement tools to rule out blocklists or filtering. If the header shows a mismatch between the envelope sender and the HELO/IP, or if the IP is untrusted, the problem is not DNS alone.

Verify the full email header and sender origin

Open the full email header (in Outlook: File → Properties → Internet Headers) and check the Return-Path and Received-SPF fields.
Confirm the From domain matches the envelope sender and that the sending IP is authorized in your SPF record.
Use RFC 5321 as a reference: the MAIL FROM domain must align with the sender’s identity or be explicitly allowed.

Check for third-party services or proxies

Some email platforms or proxies (like shared load balancers or content delivery networks) can inject their own HELO or MAIL FROM values.
If you’re using a relay or proxy between Mailgun and the mail server, the sender policy may be rewritten, causing policy violations.
Test the same message with a direct Mailgun send and compare headers to isolate interference.

Engage Mailgun support with full evidence

Mailgun support can only assist with policy-related errors if you provide the full delivery log and full header.
Include timestamps, the original message ID, and any DNS or SPF logs from your system.
Mailgun may flag a sending IP or domain if it exhibits patterns of abuse, even if your DNS is correct—support needs to see the proof.

Test inbox placement with real inboxes

Even if DNS is correct, some domains are blocked at the receiving end due to reputation, blacklists, or filtering rules.
Use inbox placement testing to send to real inboxes across Gmail, Yahoo, Outlook, and others to confirm if messages are landing in spam or bouncing.
Look for signs of alignment issues, missing authentication, or sudden spikes in volume that could trigger filters.

Summary: Fixing 550 5.1.9 after adding an MX record

The 550 5.1.9 error after adding an MX record is rarely caused by the record itself, but by misaligned email policies. The sender authentication setup must match the new delivery path.

Root causes and fixes

SPF policies often exclude Mailgun, blocking legitimate mail. Add include:mailgun.org to your SPF record.
DKIM signatures must be correctly generated and published. A missing or invalid key breaks authentication.
DNS records should be verified using a reliable tool. Errors like typos or missing tags commonly cause policy violations.

You can prevent these issues by validating your domain’s sender policies before sending. Email List Validation checks SPF, DKIM, and domain alignment as part of bulk verification.

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

Can I keep using Mailgun after adding an MX record?

Yes, as long as your SPF record includes Mailgun’s IP addresses and DKIM is properly configured. The MX record can coexist with Mailgun’s sending policy.

Does adding an MX record disable Mailgun sending?

No. Mailgun can still send emails as long as the sender domain’s SPF record authorizes Mailgun’s IPs, regardless of the MX configuration.

Why does Mailgun return 550 5.1.9 only sometimes?

It usually indicates inconsistent sender policy behavior—possibly due to a transient issue, misconfigured SPF, or temporary blocklist status.

How long does it take to resolve 550 5.1.9 after fixing DNS?

Once DNS changes propagate (typically 5–30 minutes), the error should stop. If it persists, recheck SPF/DKIM alignment and test with a clean header.

Do I need to remove my MX record to send with Mailgun?

No. MX records only affect incoming mail. Sending via Mailgun only requires SPF/DKIM alignment with the sending domain.

Can a domain have multiple MX records and still send via Mailgun?

Yes—multiple MX records are allowed, but SPF must include all authorized sending IPs, including Mailgun’s.

How does Email List Validation check for 550 5.1.9 risks?

It assesses sender domain health by validating SPF, DKIM, and MX records in real-time. It flags domains with misalignments that could lead to policy violations.

Is 550 5.1.9 the same as a soft bounce?

No. 550 5.1.9 is a permanent SMTP error (hard bounce), not a soft bounce. It indicates a policy-based rejection, not temporary delivery failure.

Can Mailgun automatically fix SPF issues?

No. Mailgun enforces policy but does not modify DNS. You must configure SPF and DKIM correctly on your domain side.

How do I test if my domain will pass Mailgun’s policy check?

Use inbox-placement testing or real-time verification services like Email List Validation to confirm alignment before sending.