Mailgun 554 5.1.8 DNS/SPF Fix | Email List Validation

Why is your Mailgun email being rejected with 554 5.1.8 in 2025?

You hit send. The confirmation says “sent successfully.” Then a few hours later, you get a bounce: “554 5.1.8 Sender address rejected: invalid or missing DNS or SPF record.” You’re not sure what DNS or SPF even is—but your emails aren’t landing.

This error isn’t a Mailgun bug. It’s a signal from the receiving server: “Your domain doesn’t prove it’s authorized to send.” The root cause usually lies in a misconfigured SPF record, a missing DNS entry, or a domain not properly set up at all. Even a single missing space or incorrect syntax in your SPF record can break everything.

And no, you don’t need to reconfigure your entire email system from scratch. You just need to debug the real culprits—and fix them before your next campaign goes out.

Key takeaways

Mailgun’s 554 5.1.8 rejection means the recipient server rejected your message due to an unverifiable sender domain.
The most common cause is a malformed or missing SPF record in your DNS settings—often due to syntax errors like extra spaces or unsupported mechanisms.
Even if your domain has other records, a single misconfigured or missing DNS record for email sending can trigger this error.

What does 554 5.1.8 mean in the context of Mailgun and email delivery?

The 554 5.1.8 SMTP error means the recipient's mail server rejected your message because it couldn't verify the sender’s domain—specifically, due to a failure in DNS or SPF configuration. In Mailgun’s case, this often surfaces during the initial handshake, when the receiving server checks if your domain is valid and properly authorized. It’s not about spam content; it’s a rejection at the envelope level, indicating your domain is not trusted or configured correctly, even if your email body is fine.

Why DNS and SPF matter at the SMTP handshake

When Mailgun sends an email, the receiving server checks your domain’s DNS records before even opening the message. If SPF (Sender Policy Framework) is missing, malformed, or inconsistent with your sending infrastructure, the server treats your domain as suspect. This is especially common if you're using Mailgun with a custom domain that hasn’t been properly set up with authorized sending IPs.

The 554 5.1.8 code is a standard SMTP response defined in RFC 5321, meaning “User unknown.” While it sounds like a recipient issue, in practice, it's usually a sender-side problem—a red flag that the infrastructure underpinning your email is broken. The receiving server never gets past authentication; the message never enters filtering or content inspection.

For example, if you send from a domain with no SPF record, or with a record that doesn’t include Mailgun’s IPs, the server will deny delivery immediately. This is not a delivery failure due to content—no spam score, no blacklisting. It’s a hard stop at the protocol level. You’re not being blocked for what you say; you’re being blocked for who you claim to be.

What to do when Mailgun returns 554 5.1.8

Let’s walk through the fix: First, verify your domain’s DNS records—specifically the SPF record. Use tools like MxToolbox or DNSLeakTest to check for missing or invalid entries. Ensure your SPF record includes include:mailgun.org and doesn’t exceed 10 DNS lookups.

Next, confirm your domain is correctly set in Mailgun and verified through DNS. If you’re using a custom domain, you’ll need to add the required TXT and MX records. Even small typos in SPF syntax can trigger 554 5.1.8 errors.

If you’re validating a large list before sending, consider using a verification service to catch invalid or poorly configured domains early—before they cause delivery failures. Bulk email list cleaning can help prevent these issues by identifying domains with missing or misconfigured SPF records.

How DNS and SPF records work together to enable delivery

When your Mailgun emails fail with a 554 5.1.8 error, it often means the recipient’s server found no valid SPF record in your domain’s DNS or found one that’s misconfigured. DNS acts as the internet’s phone book, mapping your domain to the right mail servers. SPF tells receiving servers which IP addresses are allowed to send email from your domain. If either is missing, broken, or inconsistent, your messages get rejected before they even reach the inbox. Let’s break down how they work together.

DNS: The foundation of email routing

DNS (Domain Name System) translates human-readable domains like yourcompany.com into the IP addresses of mail servers. Without a correct DNS setup, even if your email is technically valid, it can’t be delivered.

Every email send starts with a DNS query: "Where does this domain’s mail server live?" If the answer is missing or incorrect, delivery fails. This is why SPF, DKIM, and DMARC all require DNS configuration—they rely on DNS to be discoverable and valid.

SPF: The gatekeeper of sender authorization

SPF (Sender Policy Framework) is a DNS record that lists the IP addresses authorized to send mail on behalf of your domain. When a recipient server receives your email, it checks your domain’s SPF record to validate the sender.

If the SPF record is missing, it can show up as "no SPF," which many servers treat as a red flag. If the record is malformed or includes unauthorized IPs, your message may be rejected outright. That’s exactly what happens during a Mailgun 554 5.1.8 rejection: the recipient server looked up your SPF via DNS and found it invalid.

SPF checks depend entirely on DNS. There’s no fallback—no server will process a sender’s claims if the DNS record doesn’t exist or returns an error.

For a deeper look at how email authentication works, you can explore RFC 7208, the official specification for SPF. Industry-standard tools now expect your DNS to include correct SPF, DKIM, and DMARC records.

Even if your Mailgun account is set up correctly, a misconfigured SPF or outdated DNS entry will still block delivery. Fixing this requires checking your DNS zone file for the correct SPF record, ensuring it’s formatted properly, and confirming it includes only trusted sending servers. Tools like bulk email list validation can help uncover issues before you send by verifying sender infrastructure alongside domain health.

Common configurations that trigger Mailgun’s 554 5.1.8 DNS/SPF rejection

You’re getting Mailgun’s 554 5.1.8 error because your domain’s SPF record is missing, misformatted, or includes unauthorized services. This is a common senders’ mistake — especially when juggling multiple email platforms or forgetting outdated inclusions. Let’s walk through the real culprits that break delivery today.

Missing or invalid SPF records

Not having an SPF record at all is the most frequent cause of this rejection. Without a valid SPF record, Mailgun assumes your domain is unverified and blocks messages from it.
Using incorrect syntax — like missing quotes around strings, or placing the include directive in the wrong order — leads to parsing failures. SPF is strict about format; even one small typo breaks validation.
Exceeding 10 DNS lookups in your SPF record (e.g., with too many include statements) causes evaluation to fail. Each include counts as a lookup, and if you’re using services like Mailgun, SendGrid, and a legacy provider, it’s easy to hit the limit.

Overlapping or outdated configurations

Hardcoding a single IP in your SPF record blocks delivery if you use multiple senders. For example, if you use Mailgun for transactional mail and SendGrid for marketing, listing only one IP excludes the other sender, and the SPF check fails.
Adding a legacy or decommissioned service (like an old mail relay) into SPF can trigger rejections. Even if the service no longer exists, including it in SPF can cause Mailgun to reject your email unless you remove it.
Using a non-existent or misconfigured all mechanism (like ~all or -all) without proper alignment with your sending infrastructure can also invalidate the record.

SPF is not a one-time setup. It needs regular review — especially when adding new tools or deprecating old ones. The best practice is to keep your SPF record minimal and accurate: only include active, verified senders.

For teams using third-party services, RFC 7208 (the SPF standard) clearly defines the limits and structure. Following it strictly avoids common issues. You can find the full specification at IETF’s RFC 7208.

When managing large lists, ensure your sending domains are clean and properly structured. Use tools that scan for real-time SPF issues before you send. Bulk email list cleaning helps remove invalid or poorly configured senders before they cause delivery problems.

How to fix a 554 5.1.8 rejection step by step in 2025

You’re getting a 554 5.1.8 rejection from Mailgun because your domain’s SPF record is missing, malformed, or duplicated. Fix it by checking your DNS TXT records, ensuring only one valid SPF record exists with the correct syntax, and waiting for DNS propagation. Most cases resolve in under an hour after updating the record.

Check and correct your SPF record

Log into your domain registrar’s DNS management console. This is where you manage your domain’s email and web settings, such as Cloudflare, GoDaddy, or Namecheap.
Navigate to the DNS records section and look for a TXT record tied to your domain (not subdomains). SPF records are always specified as TXT records.
If no SPF record exists, create a new one with the exact syntax: v=spf1 include:mailgun.org ~all. This tells receiving servers Mailgun is authorized to send on your behalf.
If a record already exists, validate its syntax using a public tool like MxToolbox’s SPF checker or Google’s SPF validator. These tools will catch common errors like duplicate entries or incorrect modifiers.
Ensure you don’t have multiple SPF records. Only one is allowed per domain. If you find more than one, merge them or delete duplicates—multiple records invalidate the entire SPF setup.

Wait and verify propagation

After saving changes, wait 15 to 60 minutes for DNS propagation. This delay is typical globally, and you can check status via MxToolbox’s DNS lookup to confirm the record is live.
Send a test message through Mailgun using a verified email address. Monitor the delivery logs for any remaining 554 5.1.8 errors.
If issues persist, verify that the record is correctly formatted—no typos, no extra spaces, and no unintended include statements.
Remember: SPF is one part of sender reputation. You should also ensure your DKIM and DMARC records are set up properly for full deliverability.

The best defense against delivery failures is proactive list hygiene. Use tools like bulk email list cleaning to remove invalid or outdated addresses before sending, reducing the risk of SPF-related issues and improving sender reputation over time.

SPF vs DKIM vs DMARC — what each does and why they matter

You need SPF, DKIM, and DMARC to prove your emails are legitimate and avoid rejection like Mailgun’s 554 5.1.8 error. SPF checks if the sending IP is authorized, DKIM verifies the message wasn’t altered in transit, and DMARC tells receiving servers what to do if either SPF or DKIM fails—while also giving you reports on authentication results. Together, they protect your sender reputation and keep your messages out of spam folders.

SPF: authorizing sending IPs

SPF (Sender Policy Framework) is your IP address’s permission slip. It lists which servers are allowed to send emails on your domain’s behalf. If a message comes from an unlisted IP, it fails SPF—that’s often why Mailgun rejects emails. Most modern email systems check SPF before delivery, and a failure here can trigger a 554 rejection.

For example, if your email service sends from a new IP but it’s not in your SPF record, the receiving server sees it as a red flag. You can test your current SPF setup using tools like MxToolbox or check the official RFC 7208 for the full specification.

DKIM and DMARC: message integrity and policy enforcement

DKIM (DomainKeys Identified Mail) adds a digital signature to your email headers. Even if SPF passes, DKIM ensures the message content hasn’t been tampered with during transit. If a recipient validates DKIM and the signature doesn’t match, the email is considered forged—even if the IP is authorized.

Then there’s DMARC (Domain-based Message Authentication, Reporting & Conformance). It tells receiving mail servers: “If SPF or DKIM fails, reject the message, quarantine it, or just log it.” DMARC also sends aggregate and forensic reports, so you can see how your messages are being authenticated and spot impersonation attempts.

Think of DMARC as the enforcement team: SPF and DKIM do the checking, DMARC decides the consequences and shares the results. Running all three significantly lowers your risk of delivery failure and improves inbox placement over time.

Most ISPs and email platforms—like Gmail, Outlook, and Mailgun—expect proper use of these standards. Using them consistently helps maintain sender reputation, which directly impacts whether your emails land in the inbox or get blocked. To ensure your domain’s setup works, test your full authentication stack with third-party validation tools.

For deeper validation, you can verify your entire email list for domain and deliverability readiness using bulk email list cleaning, helping catch invalid or misconfigured addresses before they trigger system-level rejections.

How to test SPF and DNS records without sending emails

You can catch Mailgun 554 5.1.8 rejections caused by invalid DNS or SPF records before they happen. Use MxToolbox’s SPF lookup to check syntax and authorized senders. Run a DNS query via command line to inspect TXT records. Ensure only one TXT record is for SPF. Finally, validate delivery readiness with inbox-placement testing that simulates real-world conditions—no emails sent.

Check SPF syntax and authorized sources

Go to MxToolbox and use their SPF lookup tool. Paste your domain name to validate SPF record structure.
Check that all sending sources listed (like Mailgun, SendGrid, or your own server) are explicitly included using mechanisms like include: or ip4:.
Look for syntax errors—missing quotes, duplicate mechanisms, or over-length records (>255 characters) can trigger rejection.

Inspect DNS TXT records and detect conflicts

Open a terminal or command prompt and run: dig +short txt yourdomain.com to fetch all TXT records.
Review the output. Multiple TXT records are okay, but only one should define SPF. If multiple SPF records exist, they collide and break validation.
Use RFC 4408 as a reference for valid SPF record structure—especially the rules around record ordering and limit checks.
If you find more than one SPF record, consolidate them into a single, properly formatted TXT record. Avoid splitting SPF across multiple records.

Simulate sending with inbox-placement testing

Use Email List Validation’s inbox-placement testing feature to simulate delivery to major providers (Gmail, Outlook, Apple Mail).
This detects DNS-level rejections—like Mailgun 554 5.1.8—before you send any real emails.
It runs against real infrastructure, so you’ll catch SPF, DKIM, and DMARC issues early, reducing bounce rates and improving sender reputation.

How Email List Validation prevents 554 5.1.8 issues before they occur

Mailgun’s 554 5.1.8 rejection means your message was blocked due to a misconfigured DNS or SPF record. Email List Validation stops this before it happens by filtering out domains with broken mail systems, invalid DNS, or misconfigured SPF records during bulk or real-time verification. This avoids wasted sends and protects your sender reputation.

Bulk verification catches invalid domains early

When you upload a list of thousands of emails, many will point to domains that don’t accept mail—or are configured incorrectly. Bulk verification checks every domain’s DNS and SPF setup before you send. You’ll catch problems like missing SPF records, incorrect TXT entries, or non-existent mail servers long before Mailgun rejects your batch.

For example, if a domain lacks a valid SPF record, it’s flagged as “invalid” or “risky” during verification. You can clean the list before sending, avoiding the 554 5.1.8 block. Tools like Bulk Email List Cleaning process tens of thousands of addresses in minutes.

Real-time API checks SPF and DNS before each send

Even a few bad emails can trigger deliverability issues. With the Real-Time Email Verification API, you validate every address as it’s added—during onboarding, signups, or syncs. Each check includes DNS validation, SPF alignment, and MX record analysis.

This prevents you from ever sending to an address at a domain that doesn’t support incoming mail, which is exactly what causes Mailgun’s 554 5.1.8 response. The API runs a full check on the domain’s configuration in under 200ms, giving you immediate feedback.

And because Email List Validation’s accuracy is 98.9%, you’re not just relying on a guess. You’re relying on a system that consistently flags domains with broken configurations, including those that appear valid on the surface but fail to route mail. It’s not just about detecting inactive emails—it’s about catching systems that actively reject messages due to incorrect DNS or SPF policies.

Finally, inbox-placement testing confirms whether your domain’s mail server is accepted by major providers under real-world conditions. This goes beyond SPF and DNS checks to verify actual deliverability. You’ll know if your messages land in inboxes—or get blocked before they’re even seen.

According to RFC 7208, SPF is designed to allow senders to specify which servers are authorized to send on their behalf. When this is misconfigured, mail is rejected. Validating it early ensures your messages pass these checks before ever hitting Mailgun’s servers.

What to do when 554 5.1.8 keeps appearing despite fixing SPF

Even after correcting your SPF record, Mailgun’s 554 5.1.8 rejection may persist due to DMARC policies blocking non-compliant mail, missing A/MX records, blacklisted sending IPs, or domain-level restrictions. Let’s walk through the most common root causes and how to resolve them.

Check DMARC policies that block non-compliant mail

If you’re sending from a subdomain (like mail.yourcompany.com), a strict DMARC policy can reject your email even if SPF passes. DMARC doesn’t just enforce SPF—it also checks DKIM alignment. If your mail server signs SPF but DKIM alignment fails, DMARC will drop the message.

Check your DMARC record at MXToolbox or via DNS lookup tools to confirm the p=reject or p=quarantine setting.
Use a DMARC specification to validate the syntax of your record—errors here are silently ignored by many systems.
If you're not using DKIM, configure it or adjust your DMARC policy to p=none temporarily to test delivery.

Verify domain records and IP reputation

Mailgun requires your domain to have a valid A or MX record pointing to a working mail server. If those records are missing or misconfigured, Mailgun may block delivery regardless of SPF.

Use MXToolbox DNS lookup to check for A and MX records. If they're missing or point to dead servers, update your DNS.
Ensure your sending IP is not blacklisted. Mailgun uses shared IP pools; if one sender in the pool gets flagged (e.g., due to spam), all IPs can be affected.
Check your IP’s reputation at Spamhaus or Barracuda Central. If your IP is listed, contact Mailgun support immediately.

If you’ve verified DNS, SPF, and DMARC and the 554 5.1.8 error remains, your domain might be flagged by Mailgun’s internal systems due to high bounce rates or spam complaints.

Log in to Mailgun’s control panel and check the “Sending Statistics” tab. Look for spikes in bounces or complaints.
Use Mailgun’s built-in test tool to verify deliverability from a fresh IP.
If issues persist, contact Mailgun support. They may need to clear a block or adjust domain-level policies.

You can also reduce future issues by cleaning your email list before sending. Bulk verification helps catch invalid, disposable, and risky addresses before they harm your deliverability.

Use real-time verification to stop DNS issues before they cost you deliverability

Run every email address through a real-time verification API before sending—especially before using Mailgun—to catch invalid DNS or SPF records early. This stops bounces, protects your sender reputation, and prevents domains from being blocked before they even reach the inbox. You’re not just cleaning a list; you’re auditing sendability at the source.

Verify DNS and SPF configuration before you send

Mailgun’s 554 5.1.8 error isn’t just a technical hiccup—it signals a foundational flaw. If a domain lacks valid DNS records or has misconfigured SPF, the email won’t deliver, regardless of content quality. Let’s be clear: sending to a domain with broken DNS isn’t a "risk." It’s a guarantee of failure.

Using a real-time API, you can test each domain immediately upon collection. The tool checks whether the domain resolves in DNS, whether it has an SPF record published, and whether that record is correctly formatted. This catches issues like missing TXT entries or malformed SPF syntax—common causes of Mailgun rejection—before your first send.

Focus on domains with both functional DNS and valid SPF

Not all domains are equal. Some may resolve in DNS but lack any SPF record. Others might have SPF but misconfigured policies that trigger rejection. Only domains with both a working DNS and a properly published SPF record are safe to send to.

Tools like Email List Validation’s real-time API return verdicts like "valid," "catch-all," "risky," or "invalid" for each address. The "risky" tag often flags domains with SPF misconfigurations or unstable DNS—exactly the kind that trigger Mailgun’s 554 5.1.8 error.

By filtering out such domains before sending, you avoid the reputational cost of repeated hard bounces. According to the SPF standard (RFC 7208), proper DNS and SPF alignment are non-negotiable for deliverability. Ignoring them means you’re shipping on a foundation that’s already cracked.

Think of it this way: you wouldn’t send a package without checking if the address exists. Why send an email without verifying its sender infrastructure?

Conclusion: Preventing 554 5.1.8 rejections starts with domain-level hygiene

The 554 5.1.8 error is not about email content. It signals a misconfiguration at the domain level—specifically in DNS or SPF records.

Without correct DNS resolution and a properly published SPF record, Mailgun will reject your messages. This is a hard technical requirement, not a soft recommendation.

Verify both your sending domain and recipient addresses before sending. Use Email List Validation to catch invalid addresses and misconfigured domains early. Keep your list clean to maintain sender reputation and improve inbox placement.

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 a missing SPF record cause Mailgun 554 5.1.8 rejection?

Yes. A missing or improperly formatted SPF record causes recipient servers to reject emails during DNS validation, triggering the 554 5.1.8 error.

How long does it take for DNS changes to fix a 554 5.1.8 error?

DNS changes typically take 15 to 60 minutes to propagate. After updating, wait at least 30 minutes before testing delivery.

Does Email List Validation check SPF records?

Yes — through real-time domain verification, it checks DNS, SPF, and overall domain health to identify high-risk or invalid domains.

Can using multiple email services break SPF?

Yes — adding domains or platforms without proper SPF inclusion can violate SPF limits or cause conflicts. Use include:mailgun.org and include:sendgrid.net safely.

Why does Mailgun return 554 5.1.8 even with a valid SPF?

This can happen due to malformed TXT records, multiple SPF records, DMARC policies, or missing MX records — all detectable with a DNS check.

Can disposable email domains cause 554 5.1.8 errors?

Not directly — disposable domains may be blocked, but the 554 5.1.8 error typically results from DNS or SPF failures on the sending side.

How do I know if my domain’s DNS is valid?

Use tools like MxToolbox or dig to verify TXT, MX, and A records. A missing or unreachable DNS record causes delivery failure.

Is 554 5.1.8 a spam filter issue?

No. It’s a server-level rejection due to authentication failure — not content filtering. The message was never evaluated for spam.

What does '~all' mean in an SPF record?

'~all' means 'soft fail' for any sender not listed — it allows delivery but marks it as unverified. It’s a safer option than '-all'.

Can a subdomain cause a 554 5.1.8 error?

Yes — if the subdomain lacks proper SPF or DNS records, the sending attempt will fail. Each subdomain must be independently verified.

Should I test deliverability before sending to a full list?

Yes — use inbox-placement testing to simulate delivery to real domains and catch DNS, SPF, or policy issues before your campaign runs.

How can I prevent 554 5.1.8 errors at scale?

Validate all domains in your list with Email List Validation before sending, and ensure SPF records include all active sending services.