Postmaster
Why your message was refused or bounced.
A server running OxiMail returned an error referencing this page. Find the reason below — each explains what happened and what the sending side can change. OxiMail uses standard SMTP enhanced status codes (RFC 3463 / 7372); this page is the plain-language version. These are automated, standards-based decisions — not a permanent block on you: fix the cause below and resend.
550 5.7.26
Rejected by the sender domain’s DMARC policy
The From: domain publishes a DMARC policy of p=reject, and your message failed authentication: neither SPF nor DKIM passed and aligned with that domain. The domain owner has explicitly asked receivers to reject such mail, so OxiMail did.
How to fix it
- Send from a host listed in the From: domain’s SPF record (or via a service that is).
- Sign the message with DKIM using a key published under the From: domain.
- Ensure SPF or DKIM aligns with the From: domain (same organisational domain).
- If you operate the domain, check your SPF/DKIM/DMARC DNS records; a DMARC report will show what failed.
550 5.7.1
Refused: the From: address cannot be read as a single author
The receiving server checks the sender against the domain shown in the From: field (DMARC). It can only do that when the message has exactly one From: field naming exactly one address, written as the email standard defines it. This message had no From: field, several of them, several addresses in it, or a From: value that is not a valid address — so the domain the reader would see could not be established, and the message was refused before delivery. Large mail providers refuse these messages too.
How to fix it
- Send the message with a single From: field holding a single address, for example: From: "Jane Doe" <jane@example.com>.
- If a display name contains a comma, quotes, an @ or angle brackets, put it between double quotes.
- If the message comes from an application or a script, fix the header it generates; mail clients produce it correctly.
550 5.7.1
Refused as spam
OxiMail’s filtering pipeline scored the message as unsolicited or abusive and refused it before delivery. This is a content/reputation decision, not an authentication one.
How to fix it
- Make sure SPF, DKIM and DMARC all pass — unauthenticated mail is weighted as suspicious.
- Check your sending IP and domain reputation (blocklists, recent volume spikes, new/cold IPs).
- Avoid spam-shaped content (deceptive subjects, link shorteners, malformed headers).
- If you believe this is a false positive, contact the recipient directly through another channel so their administrator can review.
550 5.7.1
Refused for a dangerous attachment
The message carried a kind of file this server does not accept, and it was refused before delivery: nothing was stored. The reply names the rule, and the file name when one decided: an executable or a disk image (recognised by its content, whatever it is called), an extension on the blocked list, a double extension such as invoice.pdf.exe, an Office document with macros, a password-protected archive, or an archive that cannot be read. This is a decision on the type of the file, not a virus scan: the file was not found to be malicious, it is of a kind that should not travel by email.
How to fix it
- Share the file through a link (a file-sharing service or your own drive) instead of attaching it.
- For an Office document, save it without macros (.docx, .xlsx) if the macros are not needed.
- Do not send password-protected archives: their content cannot be checked. Use a shared link, with the password sent separately if needed.
- If you believe the refusal is wrong, forward the refusal message to the recipient by another channel: the queue= identifier it contains lets their administrator find the decision in the server log.
550 5.1.1
No such user — the mailbox does not exist here
The recipient address you sent to does not exist on this server. Most often the local part (the bit before the @) is misspelled, the account was closed, or the address was never valid.
How to fix it
- Double-check the spelling of the address, including the part before the @.
- If you copied the address from an old message or directory, confirm it is still current.
- If you are sure the address should exist, contact the recipient through another channel and ask them to verify it with their administrator.
550 5.1.1
This server does not accept mail for that domain
You connected to a server (typically a backup MX) and asked it to accept mail for a domain it does not host or back up. The server will not relay mail for arbitrary domains — that is by design, to prevent open-relay abuse.
How to fix it
- Check the recipient domain’s MX records and deliver to the correct host.
- If you operate a relay, make sure you are connecting to a server that is actually authorised for the recipient domain.
- If you believe this domain should be accepted here, the recipient’s administrator must add it to the server’s accepted domains.
451 4.3.5
Delivery postponed: the address is configured twice
The recipient address leads to more than one place on this server, for instance a mailing list and a mailbox with the same address. Rather than guess, and risk delivering to the wrong place, the server postponed your message with a temporary error. Nothing is wrong on your side: the recipient’s administrator has been alerted and must remove one of the two.
How to fix it
- You have nothing to do: your server keeps the message and retries automatically, usually for several days.
- Once the recipient’s administrator has fixed the address, the next retry is delivered normally.
- If the delay matters, tell the recipient by another channel so their administrator can act sooner.
DSN
Your message bounced (returned to sender)
OxiMail accepted the message for delivery but could not deliver it, and after retrying for several days it returned the message to you as a bounce (a Delivery Status Notification, RFC 3464).
How to fix it
- Read the “Diagnostic-Code” line in the bounce — it carries the exact SMTP error from the destination.
- Common causes: the mailbox does not exist (5.1.1), the mailbox is over quota, or a policy rejected it.
- A transient (4.x.x) failure means OxiMail retried for ~5 days before giving up; check whether the destination was reachable.
- Fix the address or the underlying cause and resend.
DMARC + ARC
Mail that was forwarded, or went through a mailing list
Forwarding and mailing lists break authentication: SPF now points at the forwarder, and a list that rewrites the subject or appends a footer invalidates the DKIM signature. The message then fails DMARC at our side through no fault of the original sender. OxiMail evaluates ARC chains (RFC 8617), so a forwarder that seals what it saw — and that we have reason to trust — lets the original result be honoured instead of discarded.
How to fix it
- If you operate a mailing list or a forwarder, seal your relays with ARC. Without it, you are silently breaking DMARC for every domain you handle.
- Avoid rewriting subjects and appending footers if you can — every modification invalidates DKIM.
- Oversign the headers that matter, so a header added downstream cannot be passed off as original.
- If you are the original sender, ask the intermediary whether it seals with ARC; the fix belongs to them, not to you.
Bulk mail
Newsletters and bulk mail: what we expect
Bulk sending is not refused as such, but it is held to the requirements the large providers now impose. A campaign that arrives without an unsubscribe a recipient can actually use is treated as suspicious, and the complaints that follow damage your reputation far more than one rejection would.
How to fix it
- Offer one-click unsubscribe (RFC 8058) and honour it immediately. Our client shows the button to the recipient, and when they mark a newsletter as junk we offer them the unsubscribe instead.
- Authenticate every send: SPF, DKIM aligned with the From: domain, and a DMARC policy you actually enforce.
- Send from a stable domain and IP, and warm them up gradually. A cold address that suddenly emits thousands of messages looks exactly like a compromised one.
- Remove hard bounces from your list rather than retrying them. Repeated sending to dead addresses is one of the strongest negative signals there is.
Still stuck? The recipient’s administrator can look up the rejection in their server logs.