What does Mailgun’s 550 5.1.9 policy violation mean in 2025?

Imagine sending an important message—only to get back a hard bounce with the cryptic error: 550 5.1.9 policy violation. You’re not alone. In 2025, this is no longer a minor hiccup. It’s a signal that your sender domain lacks the foundational authentication Mailgun and major inbox providers now require.

This isn’t a temporary delay. It’s a hard rejection. The email never reaches the inbox—because the domain isn’t properly set up to prove it’s legitimate. Without valid SPF or DKIM records, even well-intentioned senders are blocked by default.

Think of SPF and DKIM as a digital ID badge for your domain. In 2025, if that badge is missing or invalid, the system assumes you’re not who you claim to be. And when Mailgun enforces DMARC policies more rigorously than ever, a single missing record can stop an entire campaign dead in its tracks.

Key takeaways

  • Mailgun’s 550 5.1.9 error in 2025 means your domain lacks valid SPF or DKIM authentication at the DNS level.
  • This is a hard bounce—delivery fails permanently unless the domain's DNS records are corrected.
  • Major inbox providers, including Gmail and Outlook, now enforce DMARC policies strictly, blocking emails from unauthenticated domains by design.

Why does Mailgun enforce SPF and DKIM in 2025?

You’re blocked by Mailgun with a 550 5.1.9 policy violation because your domain lacks SPF or DKIM — fundamental email authentication protocols. In 2025, major providers like Gmail, Outlook, and Apple Mail treat unauthenticated sending as a high risk, meaning messages without proper signing are likely to be rejected or marked as spam. Mailgun enforces this to protect inbox placement and ensure only authorized senders reach inboxes.

Authentication is the foundation of modern email trust

SPF and DKIM aren’t optional extras — they’re how email providers verify that a message actually came from your domain. SPF checks whether the sending server is listed in your domain’s DNS records. DKIM adds a digital signature that confirms the message wasn’t altered in transit. Without either, Mailgun can’t confirm you’re authorized to send on behalf of that domain.

Let’s be clear: impersonation and spoofing are real threats. If your domain has no SPF or DKIM, spammers could send emails that appear to come from your address — and inbox providers will treat your entire domain as a vector for abuse. A single misconfigured or unauthenticated send can poison your sender reputation before you’ve sent a single message.

Reputation matters more than ever in 2025

As of 2025, over 90% of major email providers enforce strict authentication requirements, often rejecting or quarantining messages that lack SPF or DKIM. This isn’t a Mailgun policy — it’s an industry-wide standard. Major players like Google and Microsoft rely on these protocols to maintain user trust and prevent phishing at scale.

Even if your content is legitimate, unauthenticated sends often end up in spam folders or trigger immediate delivery failures. This harms not only your current campaign but your long-term deliverability. It’s not just about passing a single test — it’s about building consistent, trusted sending behavior over time.

For teams managing high-volume sends, proactive validation reduces the risk of hitting these blocks. You can verify your domain’s authentication setup and clean your list before sending. With tools like our bulk email list cleaning, you can identify and remove invalid, risky, or unauthenticated emails ahead of time, reducing bounce risks and improving your sender reputation on platforms like Mailgun.

Authentication isn’t a one-time fix. It’s part of sustained deliverability hygiene. As long as providers like Gmail, Outlook, and Apple Mail depend on SPF and DKIM to vet senders, compliance isn’t optional — it’s the baseline for being heard.

How do SPF and DKIM work together to prevent 550 5.1.9 errors?

Mailgun’s 550 5.1.9 policy violation occurs when a message fails authentication because the sending domain lacks valid SPF or DKIM records. SPF checks if the server sending the email is listed in the domain’s DNS as an authorized sender. DKIM adds a cryptographic signature to the message, proving it hasn’t been altered in transit. Both are required: SPF stops spoofing, DKIM ensures integrity. Without either, recipients reject the email — triggering the 550 5.1.9 error.

SPF: The Sender’s Permission Slip

SPF acts like a permission slip stored in your domain’s DNS. When you send an email, receiving servers check if the sending IP address is on the approved list. If not, the message is flagged. It’s not foolproof — SPF only validates the envelope sender (Return-Path), not the visible from address. Still, it blocks simple spoofing attempts and is a baseline requirement for delivery.

DKIM: The Message’s Tamper-Proof Seal

DKIM works by attaching a digital signature to the message header and body. When the email arrives, the recipient’s server retrieves the public key from DNS and verifies the signature. If the signature matches, the message hasn’t been altered. This protects against man-in-the-middle attacks and phishing, where content is modified after sending. A single corrupted byte breaks the signature.

Even if one is missing, many email providers still accept the message — but with degraded trust. The 550 5.1.9 error specifically calls out missing authentication, often leading to rejection by services like Mailgun or Gmail. It’s not a failure of the message itself, but of the sender’s identity verification.

Both SPF and DKIM are part of a broader ecosystem governed by industry standards. The IETF outlines their use in SPF (RFC 7208) and DKIM (RFC 6376). These protocols are not optional — they’re how modern email systems verify legitimacy at scale.

For teams using third-party services, especially in high-volume campaigns, ensuring both records are properly configured is non-negotiable. Many platforms — including Mailgun — require authentication to avoid policy violations. Without it, even well-written content won’t reach the inbox.

Before you send, validate your DNS settings. Use a tool like MXToolbox to test SPF and DKIM records, or check your sender reputation with a real-time deliverability test.

For teams who want to reduce sending risk at scale, cleaning your list beforehand helps. Invalid or unverified emails can trigger delivery issues, even with proper DNS setup. Use bulk email list cleaning to identify and remove addresses that would otherwise cause policy violations — whether due to missing authentication, invalid formats, or poor sending history.

What does a 550 5.1.9 error look like in your logs?

You’ll see the error 550 5.1.9 <[email protected]> Recipient address rejected: Access denied by policy (missing SPF or DKIM) appear immediately in your SMTP transaction logs when sending to Gmail, Yahoo, Outlook, or most corporate domains. It’s a hard failure—no retry, no delay. The email never reaches the recipient’s inbox. If you’re seeing this, your sending infrastructure lacked either SPF or DKIM validation at the time of delivery, and the receiving server blocked it outright due to policy enforcement.

How does this error manifest in real logs?

Log entries will show the SMTP response within seconds of the MAIL FROM or RCPT TO command. There’s no bounce later—this is a rejection at handshake level. For example, a transaction might log:

  • 250-SIZE 35651584
  • 250-STARTTLS
  • 250-ENHANCEDSTATUSCODES
  • 250-8BITMIME
  • 550 5.1.9 <[email protected]> Recipient address rejected: Access denied by policy (missing SPF or DKIM)

Why does it happen across major providers?

Gmail, Yahoo, Outlook, and enterprise email systems enforce sender policies strictly. They check for proper SPF and DKIM alignment before accepting mail. If either is missing or fails verification, the server treats this as a policy violation—even if the email is otherwise legitimate. This has become standard across most modern domains. According to RFC 7208, SPF is designed to prevent sender spoofing, and failing to publish a valid record leaves your sending domain vulnerable to abuse. DKIM, outlined in RFC 6376, provides cryptographic proof of message integrity. Skipping either leaves you exposed.

Even if your list is clean and your content is compliant, a missing record can cause instant rejection. This isn’t about content quality—it’s about sender infrastructure. You can’t rely on “good intent” or “trusted reputation” here—authentication is mandatory at the SMTP level. Mailgun’s 550 5.1.9 is a direct result of this policy. It’s not a soft bounce. It’s a hard no.

If you’re using an email list, especially one compiled from third-party sources or scraped data, the odds of missing alignment records are high. You can check for SPF and DKIM using tools like MXToolbox or DNS Lookup. But manual checks won’t scale across thousands of addresses. For real-time validation, use a service that checks for authentication headers, deliverability, and domain health. Verify emails in real time to catch these issues before they block your sends.

How to verify your SPF and DKIM setup (step by step)

You can fix a Mailgun 550 5.1.9 policy violation by ensuring your domain’s SPF and DKIM records are correctly published in DNS. This includes verifying that your SPF record authorizes Mailgun’s IPs via include:mailgun.org, and that your DKIM selector (like mailgun._domainkey.example.com) has a valid public key. Use a public DNS checker to confirm both records are visible and parse without error.

Step-by-step verification process

  1. Log in to your DNS provider (Cloudflare, AWS Route 53, GoDaddy, etc.). SPF and DKIM are configured at the DNS level, so you need access to your domain’s DNS zone.
  2. Find your SPF record. Look for a TXT record with a name (host) matching your domain (e.g., example.com). Its value should start with v=spf1. If it doesn’t exist, you need to create one.
  3. Confirm Mailgun is included. Your SPF value must include include:mailgun.org to authorize Mailgun to send email on your behalf. Without it, Mailgun cannot pass authentication checks, leading to 550 5.1.9 errors.
  4. Check for the DKIM record. Look for a TXT record with a name like mailgun._domainkey.example.com. The value should be a long string starting with v=DKIM1; followed by a pubkey= value.
  5. Test both records. Use a public tool like MxToolbox or Mail-Tester to query your domain’s DNS and verify that both the SPF and DKIM records are correctly published and parse as intended.
  6. Wait for DNS propagation. DNS changes can take up to 48 hours to update globally. If a tool returns “record not found,” wait at least 15 minutes before retrying.

Why this matters for deliverability

SPF and DKIM are core email authentication protocols. An incomplete or missing SPF record means mail servers have no way to verify that Mailgun is authorized to send emails on your domain’s behalf. DKIM ensures message integrity—without it, even legitimate emails may be flagged as forged. Together, they prevent your messages from being blocked or marked as spam. Per RFC 7672, failure to authenticate significantly reduces inbox placement rates.

Authenticating your domain reduces the risk of your emails being filtered or rejected by major providers—especially critical for transactional or marketing sends.

Once your records are verified, test sending a message to a service like Mail-Tester to confirm inbox placement. If issues persist, use inbox placement testing to simulate real-world delivery under common filtering rules.

Common causes of SPF/DKIM misconfigurations

Mailgun 550 5.1.9 policy violations in 2025 often stem from misconfigured SPF or DKIM records. The most frequent issues include overly restrictive SPF policies that omit Mailgun’s IP ranges, multiple SPF records causing DNS parsing errors, DKIM keys expiring without renewal, and missing or incorrect DNS entries—especially when using subdomains. These flaws lead to send failures or blacklisting.

SPF misconfigurations

  • You’re blocking Mailgun if your SPF record doesn’t include include:_spf.mailgun.org or the current Mailgun IP ranges—verify your record with tools like MxToolbox.
  • Multiple SPF records in DNS cause parsing errors. You can only have one SPF record per domain; use include to combine policies, never duplicate SPF TXT records.
  • SPF has a 10-dnslookup limit. Overusing include or redirect chains can invalidate your record. Test with RFC 7208.

DKIM misconfigurations

  • DKIM keys expire after 12–18 months. If you don’t re-sign messages with a new key, your emails fail validation. Set calendar reminders to renew keys before expiry.
  • You’re using a subdomain like newsletter.yourdomain.com but haven’t published the DKIM TXT record at default._domainkey.newsletter.yourdomain.com. The selector name must match exactly.
  • Using an incorrect selector or missing the domainkey subdomain (e.g., mailgun._domainkey.yourdomain.com instead of default._domainkey.yourdomain.com) breaks DKIM verification.
  • DKIM signing can fail on custom domains if the public key isn’t properly published. Validate with Mail-Tester or check the DKIM RFC 6376.

Don’t guess—use a real-time validation API to catch these issues before you send. With Email List Validation’s real-time email verification API, you can test whether an email is actually deliverable and whether its domain has correctly configured SPF/DKIM, all without sending. This helps avoid 550 error triggers like the one from Mailgun.

How Email List Validation helps prevent 550 5.1.9 issues

You can prevent Mailgun 550 5.1.9 policy violations by running your email list through Email List Validation before sending. It catches invalid domains, flags those missing SPF or DKIM, and removes high-risk addresses that trigger delivery failures. This prevents bounces, protects sender reputation, and ensures your messages reach inboxes—without guesswork.

Many 550 5.1.9 errors stem from domains that don’t enforce strong authentication policies. You might send to a valid-looking email, but if the domain lacks SPF or DKIM, the receiving server may reject it outright as a policy violation. Email List Validation scans each address and checks the domain’s infrastructure in real time, identifying missing or broken authentication records before you send.

Let’s say your list includes an address from example.com. If that domain has no SPF record or a malformed DKIM setup, the system flags it as risky. You don’t need to wait for Mailgun to reject the message—your list is cleaned ahead of time. This reduces bounce rates and avoids the reputation damage that comes from consistent failures.

Clean at scale, with confidence

A bulk list of 10,000 addresses? No problem. Email List Validation’s bulk verification API checks every address in hours, not days. It checks syntax, domain existence, mailbox responsiveness, and infrastructure policies—all in one pass. You get clear status codes: valid, invalid, catch-all, or risky. You only send to the valid ones.

With 98.9% accuracy, this tool gives you confidence that you’re not over-cleaning—only removing the high-risk entries that would cause problems. According to RFC 5321 and industry feedback from providers like Return Path and MxToolbox, domain-level authentication gaps are among the top reasons for delivery rejection, especially for high-volume senders using services like Mailgun.

This isn’t about removing every questionable address—it’s about removing the ones that break the rules. A single failed delivery due to missing SPF can hurt your sender reputation over time. By catching these issues early, you protect your domain, maintain inbox placement, and avoid the 550 5.1.9 error that derailed your campaign before it started.

What happens to your sender reputation if you ignore 550 5.1.9 errors?

If you keep sending emails without SPF or DKIM records, Mailgun will eventually restrict your sending access. Repeated 550 5.1.9 policy violations signal to receiving servers that your mail isn’t authenticated, leading to throttling, IP blocks, or long-term reputation damage that can take weeks or months to fix—even after you add the missing records.

Mailgun enforces compliance—repeated failures trigger escalation

Mailgun doesn’t just reject a single failed email. When your sending IP consistently fails SPF or DKIM checks, it’s flagged as non-compliant. Over time, Mailgun may reduce your sending rate, block new messages, or even blacklist your IP entirely. This isn’t theoretical—spammers and misconfigured senders get hit in practice, and the system is designed to protect the entire ecosystem. If you’re getting 550 5.1.9 errors, you’re already on the radar.

Damage spreads beyond Mailgun—your deliverability takes a hit

Even if Mailgun eventually lets your emails through after you fix SPF/DKIM, the damage is done. Receiving servers learn from aggregate reports about your sending behavior. Every failed delivery, every bounce, every spam trap you trigger compounds against your sender reputation. Once a domain or IP is linked to poor authentication, ISPs treat it as high risk. You'll see inbox placement drop—your messages land in spam folders, or worse, vanish entirely. Recovery isn’t instant. Major email providers like Gmail and Outlook maintain reputation databases that track a sender’s behavior over time, often without public visibility.

According to the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), email authentication is one of the most effective ways to reduce spam and improve sender trust. But it only works if consistently applied. M3AAWG guidelines explicitly recommend SPF and DKIM as baseline requirements for mail sent through third-party platforms.

Let’s be clear: fixing SPF/DKIM after you’ve accumulated 550 5.1.9 errors is like patching a leaking roof after your basement flooded. The fix is necessary, but the impact on reputation may already be baked in. Monitoring and validating your email list regularly can help you avoid this. If you’re sending at scale, check for misconfigured domains or invalid addresses before they cause delivery failures.

For teams using Mailgun, real-time verification can prevent many of these issues. It checks both domain authentication and individual email syntax, format, and reachability before you send. Use our real-time API to catch bad addresses and misconfigured domains before they degrade your deliverability.

How to integrate Email List Validation with Mailgun for full deliverability safety

You can stop Mailgun 550 5.1.9 policy violations by validating your list before sending. Use Email List Validation’s API to filter out invalid, catch-all, or poorly configured addresses, and verify SPF/DKIM readiness. Automate checks via webhooks to only send to domains with proper authentication, and test inbox placement to ensure DMARC compliance—before you ever hit “send.”

Run list hygiene before sending to Mailgun

  1. Scrub your list with the Email List Validation API before uploading to Mailgun. This identifies invalid, disposable, and role-based emails that trigger authentication failures. A single bad address can trigger a policy violation across the entire sending domain.
  2. Check for missing SPF or DKIM records in real time. Many bounces stem from misconfigured domains. Email List Validation flags domains with incomplete or incorrect DNS records, helping you preempt Mailgun’s anti-abuse filters.
  3. Use inbox-placement testing to simulate real delivery. This step verifies whether your email would reach the inbox under current sender reputation and infrastructure rules—including DMARC alignment checks. This is key: even correctly formatted addresses can be rejected if their domain’s authentication doesn’t align with Mailgun’s policy.

Automate compliance and fix issues proactively

  1. Integrate Email List Validation via webhook into your send workflow. Only authorized domains—those passing real-time validity and authentication checks—get routed to Mailgun. This prevents misdelivered emails and blocks policy violations before they occur.
  2. Use the in-app AI assistant to diagnose domain health. If a domain fails verification, the AI highlights whether the issue stems from SPF, DKIM, MX, or DMARC misconfiguration. It then suggests specific DNS record adjustments—no guesswork.
  3. Run a full inbox-placement test after fixing records. This simulates delivery with Mailgun’s environment, including spam filters and reputation scoring. It confirms that corrective actions are sufficient to ensure deliverability, not just technical correctness.

For teams using Mailgun at scale, this integration is a necessity, not a feature. As outlined in RFC 7208 (SPF) and RFC 6376 (DKIM), strict authentication policies are enforced globally to prevent spoofing and abuse. Violations like Mailgun 550 5.1.9 are not errors—they’re intentional rejection signals.

Proactive list validation doesn’t just reduce bounces—it reduces the risk of being flagged for abuse, even if you didn’t send the email.

Test your process with a free batch: clean your first 100 emails with no risk. Then scale with the real-time API. You’re not just verifying addresses—you’re verifying sender readiness.

Why list hygiene reduces the risk of 550 5.1.9 errors

You reduce the chance of Mailgun rejecting your emails with a 550 5.1.9 policy violation by cleaning your list—removing domains without SPF or DKIM, which are common in old, unused, or role-based addresses. These addresses often fail authentication checks, triggering rejection even if the email exists. A clean list means fewer such addresses, lower bounce rates, and better sender reputation.

Authentication starts at the domain level

Many domains in low-quality lists haven’t set up basic email authentication like SPF or DKIM. These are not optional—they’re required by modern email providers to prevent spoofing and spam. If a domain lacks these records, any message sent from it risks being rejected with a 550 5.1.9 error, especially by strict services like Mailgun. It’s not just about the individual address—it’s about whether the sender’s domain has been properly authorized.

Let’s be clear: a valid-looking email address isn’t enough. Even if it formats correctly and exists on a server, it can still be blocked if the domain misconfigures SPF or DKIM. This is why removing domains with weak or missing authentication is a critical step in list hygiene. Tools like bulk list cleaning identify and eliminate these risky addresses before you send.

Reputation and deliverability go hand-in-hand

Every time you send to a poorly authenticated domain, you’re indirectly stressing your own sending reputation. High bounce rates, especially from temporary or invalid domains, signal to providers that your list isn’t maintained. This can result in your IP being flagged or throttled—even if you’re otherwise compliant.

By removing old, unused, or role-based addresses (like admin@, support@, or sales@), you reduce the number of poorly authenticated domains in your list. This directly lowers your overall bounce rate and helps sustain a clean sender reputation. The result? Fewer 550 5.1.9 errors, better inbox placement, and less operational stress. As RFC 7208 states, SPF is a cornerstone of email authentication—without it, trust breaks down at scale.

A well-maintained list isn’t just about avoiding errors—it’s about building consistent sender trust. You can automate verification at scale using a real-time API for live checks during sign-up, or proactively audit your entire database. Over time, this practice becomes part of your delivery reliability foundation.

Final takeaway: fix authentication, clean your list, send with confidence

The 550 5.1.9 error stems from missing SPF or DKIM — not from your email content or sending volume. This is a sender authentication failure, and it’s preventable.

Even the most polished message will be blocked if the domain lacks proper setup. High volume or better copy won’t bypass this. Only correct authentication and a clean list will.

How to avoid it

  • Verify your domain’s SPF and DKIM records using tools like MxToolbox or your mail provider’s DNS check.
  • Use Email List Validation to catch invalid or poorly authenticated domains before sending.
  • Regularly scrub inactive or placeholder emails to maintain sender reputation.

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

Does Mailgun require SPF and DKIM for all sending?

Yes. In 2025, Mailgun enforces authentication by default. Messages from domains without valid SPF or DKIM are rejected with a 550 5.1.9 error.

Can I send from a subdomain without SPF/DKIM?

No. Subdomains must have their own SPF and DKIM setup. If they lack it, messages from them will fail with 550 5.1.9.

How long does it take for SPF/DKIM to take effect?

DNS propagation typically takes 5 to 30 minutes, but full validation may take up to 24 hours in some cases.

Can Email List Validation test my domain’s SPF/DKIM?

Yes. It includes domain-level checks that flag domains with missing or misconfigured SPF/DKIM records during list verification.

What if my domain has SPF but not DKIM?

You may still get rejected by strict providers. Both are strongly recommended. Mailgun requires at least one in 2025.

Do role-based addresses like info@ or sales@ cause 550 5.1.9 errors?

Not directly. But role-based addresses often belong to domains with weak authentication, making them high-risk. Clean them from your list.

How does disposable email affect SPF/DKIM checks?

Disposable domains usually lack stable SPF/DKIM records. Email List Validation identifies and removes them during verification.

Is it safe to reuse old domains for email campaigns?

No. Old domains often lack modern authentication or have poor sender history. Use Email List Validation to assess domain health before reuse.

What if I can’t set up SPF or DKIM?

You cannot reliably send from that domain. Consider using a verified domain with full authentication or an alternate ESP like SendGrid with proper setup.

How many free verifications does Email List Validation offer?

100 free verifications to start. Purchased credits never expire. No time limits or hidden fees.