How to Fix SMTP Error 554 “Transaction Failed” When Emailing One Specific Company

Most of your email sends without a hitch. But every message to one particular company bounces back with SMTP error 554 and the short, unhelpful phrase “transaction failed.” The same message sends fine to everyone else, which makes the problem feel strange and personal.

Error 554 in this situation almost always comes from the receiving company’s server, not from your app. It is a final rejection: their system looked at your message, your server, or your sending reputation and decided not to accept it. This guide explains how to read the bounce, work out which reason applies, and get your mail accepted.

Quick Answer

When error 554 “transaction failed” happens with only one company, that company’s mail server is rejecting you — usually because of a blocklist entry, missing or failing SPF, DKIM or DMARC records, or a strict content policy. Read the full bounce text for the specific reason, test from webmail, check your domain’s authentication records, and then contact the company’s IT team with the exact bounce details so they can allow your mail.

What Error 554 Means

SMTP reply codes beginning with 5 are permanent failures: the receiving server will not accept this message as it stands, and your server will not keep retrying it. Code 554 is the general code for a failed transaction. It is deliberately broad, which is why the words after the code matter so much. A complete bounce might add phrases such as “Message rejected due to local policy,” “Your IP is listed on a blocklist,” or “SPF validation failed.” Two 554 errors can have completely different causes, so never skip the full message text.

The fact that only one company is affected is itself an important clue. Your account, password, and port settings are working — other recipients prove that. Something about that company’s checks is stricter than everyone else’s, and your sending setup is failing one of those checks.

Step 1: Read the Full Bounce Message Carefully

1. Open the delivery failure notice in your inbox, not just the preview line.
2. Find the diagnostic section, often labelled “Diagnostic information for administrators” or shown as server response text.
3. Look for extra phrases: blocklist names, “policy,” “reputation,” “authentication failed,” or a link to a lookup page.
4. Note the name of the rejecting server and the exact time of the rejection — the other company’s IT team will ask for both.
5. Save the bounce. Do not delete it; it is your evidence when you ask for help.

Step 2: Test from a Different Sending Path

Send the same recipient a short, plain message from your provider’s webmail instead of your email app. Then, if you have one, test from a different network, such as your phone with Wi-Fi turned off. These tests separate the possible causes:

• Webmail works, the app fails: your app’s settings or the IP address of your home connection may be the trigger.
• Everything from your domain fails: the problem is likely domain-level — authentication records or reputation.
• A plain one-line message works but your normal message fails: something in the content — a link, attachment, or signature — is tripping their filter.

For a broader method of tracing where a message stops, our guide to tracing delayed or blocked email shows how to read headers and bounce codes together.

Step 3: Check Your Domain’s Email Authentication

Strict corporate servers commonly reject mail that fails email authentication. Three DNS records work together:

• SPF lists which servers are allowed to send for your domain. If you recently changed providers or added a sending service and did not update SPF, strict receivers will fail your mail.
• DKIM adds a cryptographic signature to each message. If the signature is missing or does not verify, some companies reject outright.
• DMARC tells receivers what to do when SPF or DKIM fails, and some organisations reject unauthenticated mail from domains that publish a strict DMARC policy.

Ask your email provider or the person who manages your DNS to confirm all three records exist, are published correctly, and cover every service that sends your mail — including invoicing tools, website contact forms, and newsletter systems. Google’s guide to setting up DMARC for a domain explains how these checks work in practice, and the same principles apply whichever provider you use. Receivers increasingly treat missing authentication as a reason to refuse the transaction entirely, rather than simply delivering the message to a junk folder, which is why a record problem that went unnoticed for months can suddenly start causing hard rejections.

Step 4: Check for a Blocklist or Reputation Problem

The bounce text may name a blocklist directly. Even when it does not, a company with aggressive filtering may use reputation data that smaller providers ignore. If your messages are sent from a shared server — common with budget hosting — another customer’s behaviour can damage the reputation of the address you share. Your provider can check this and, if needed, move your sending to a cleaner server or request removal from the list. If the bounce mentions your own connection’s IP address rather than your mail server, restarting your router to obtain a fresh address from your internet provider sometimes resolves it.

Step 5: Review the Message Content

Corporate gateways scan content more strictly than consumer mail services. Triggers include:

• Attachments in formats such as .zip, .exe, or macro-enabled documents
• Shortened or mismatched links, where the visible text and the real destination differ
• Invoice and payment language combined with a new sending pattern
• Image-only messages, or a large signature image with very little text
• Sending the same message to many people at that company at once

Test with a plain text message containing no links or attachments. If it arrives, rebuild your normal message gradually to find which element caused the rejection.

Step 6: Contact the Company’s IT Team

If your authentication is correct and the content is clean, the remaining fix sits on their side. Email them from an alternative address, or phone them, and provide the exact bounce text, the sending address, the recipient, and the date and time. Ask whether your domain or sending server can be added to their allowlist. Companies do this routinely for suppliers and partners; a polite request with full diagnostics usually gets a quick result.

Common Mistakes to Avoid

• Resending the identical message repeatedly. Repeated rejected attempts can further harm your reputation with their filter.
• Assuming your settings are broken. If everyone else receives your mail, your basic setup works — do not tear it apart.
• Ignoring the text after the 554 code. That text usually names the actual reason.
• Changing DNS records without checking current values. A wrong edit to SPF can break delivery to everyone, not just one company.
• Asking the company for help without the bounce details. Their team cannot search logs without timestamps and addresses.

Conclusion

SMTP error 554 “transaction failed” at a single company is a targeted rejection, and it is fixable once you identify which of their checks you are failing. Read the full bounce, test from webmail and with plain content, verify your SPF, DKIM, and DMARC records, and rule out a blocklist problem. If all of that is clean, hand the company the exact bounce details and ask for an allowlist entry — that combination solves the large majority of one-company delivery problems.

Frequently Asked Questions

Why does error 554 only happen with one company?

Because that company enforces stricter checks than the providers you normally send to. A missing DKIM signature, an outdated SPF record, or a weak shared-server reputation may pass everywhere else and fail only at their gateway.

Is error 554 my fault or theirs?

Usually it is a mismatch between the two sides: their policy is strict and something in your sending setup does not meet it. The bounce text tells you which side needs the change — authentication fixes are yours, allowlist entries are theirs.

Should I keep retrying until the message goes through?

No. A 554 is a permanent rejection for that message in its current form. Fix the underlying cause first; repeated identical attempts can make reputation filters treat you worse.

Can an attachment cause a 554 rejection?

Yes. Many companies block archive files, executable files, and macro-enabled documents at the gateway. Sending a PDF instead, or sharing the file through a file-sharing link approved by the company, often works.

How long does an allowlist fix take?

Once you reach the right IT contact with the full bounce details, allowlist changes are often made the same business day. Delays usually come from missing information, so include the sender, recipient, timestamp, and the complete error text in your first message.