Everything for your OVHcloud email

Authenticate your domain when sending

For e-mails sent via OVH to be accepted by recipients, authenticate your domain with SPF, DKIM and DMARC.

SPF configuration (Sender Policy Framework)

SPF authenticates your e-mails by declaring which servers are allowed to send on behalf of your domain.

When possible, SPF is configured automatically when the email service is created. If the configuration is incorrect, go to the OVHcloud Manager, on your email service’s page, to re-trigger the automatic configuration; you can also configure SPF yourself in your domain’s DNS zone.

Example SPF record for OVH:

v=spf1 include:mx.ovh.net ~all

Recommendation: Use ~all (softfail) during the testing phase, then switch to -all (hardfail) once your configuration is validated.

DKIM configuration (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to your e-mails to prove their authenticity.

When possible, DKIM is configured automatically when the email service is created. If the configuration is incorrect, go to the OVHcloud Manager, on your email service’s page, to re-trigger the automatic configuration: OVHcloud generates the keys and publishes the matching DNS record.

DMARC configuration

DMARC combines SPF and DKIM to provide a policy for handling unauthenticated e-mails.

🚧 In progress. A recommended standard DMARC configuration is being prepared. It is not proposed yet, because redirections and mailing lists can break DMARC alignment: a policy that is too strict could cause legitimate forwarded messages to be rejected.

ARC (Authenticated Received Chain)

ARC preserves authentication results (SPF, DKIM, DMARC) when a message passes through an intermediary that forwards it — typically a forward (redirection) or a mailing list. These intermediaries often alter the message or the envelope, which breaks SPF and DMARC alignment; ARC lets the final server see that authentication was valid before that hop.

Nothing to configure on your side. OVHcloud automatically adds the ARC signature on the forward and mailing-list traffic it handles.

General recommendations

• OVH’s email services are intended for individual mailbox use. Transactional and communication use is tolerated but limited in volume.
• Keep a low spam complaint ratio
• Implement a clear unsubscribe process
• Only send to recipients who have explicitly opted in — no purchased or harvested lists
• Segment your sends based on recipient engagement
• Monitor your reputation via feedback loops
• Split bulk sending

Sending limits

Overview

Note: The hourly and daily limits are assessed against several criteria: the sender, the recipient, the sender/recipient pair, and the sending IP address.

Important: Exceeding the sending limits may result in a temporary block of your account. If you need higher limits, please contact our support team.

List of outgoing IP addresses

🚧 In progress. Work to rationalise the outgoing IP addresses is underway, so the list of IP ranges is not published for now.

If you need to whitelist OVHcloud’s sending servers, rely on stable criteria rather than fixed IP addresses:

• SPF — allow OVHcloud’s SPF record (include:mx.ovh.net).
• Reverse DNS (PTR) — sending servers have a reverse hostname ending in:
  • mail-out.ovh.net for Europe;
  • mail-out.ovh.ca for Canada.

SMTP error codes

Here are the main SMTP response codes our servers may return, and what to do about each:

Anything not in this table comes from the mail infrastructure behind the proxy and is passed through unchanged.

Outgoing email deliverability

Every outgoing email goes through an anti-spam analysis. If a message is detected as SPAM, it is not delivered.

Based on this anti-spam analysis of outgoing email, the account may be blocked.

To understand a block and resolve it, see the OVHcloud guide: Account locked for spam.

Receiving limits

* Subject to the anti-flood rate limiting (see below).

Acceptance conditions:

• Reverse DNS required — only IP addresses that have a reverse (PTR) record are accepted.
• Manual block possible — a manual block (IP, domain, or sender) may be applied in case of abuse.

Note: Receiving is not capped by volume, but remains subject to the mailbox storage quotas. A full mailbox rejects new messages (see SMTP 4xx/5xx codes). An anti-flood rate limit does, however, apply to incoming traffic (see below): it is a protection against mass arrivals, distinct from any volume cap.

Inbound rate limiting (anti-flood)

To protect its servers and users, OVHcloud applies an adaptive rate-limiting mechanism to incoming traffic. The arrival rate of messages is tracked over rolling hourly and daily windows, and the allowed margin adjusts automatically to each source’s behaviour: a regular, compliant sender sees its allowance evolve over time, while an unusual mass arrival is throttled.

This rate limiting is assessed against several independent criteria: the sender address, the recipient address, the sender/recipient pair, and the sending IP address.

When this limit is momentarily reached, the message is not permanently rejected: OVH replies with a temporary 4xx SMTP code such as:

450 4.7.1 Rate limit due to high number of emails sent, retry later

A compliant sending server retries automatically a little later, and delivery succeeds on its own.

On the sender side, to avoid being throttled:

• Honour 4xx temporary codes and retry with progressive backoff (do not treat a 4xx as a permanent failure).
• Spread your sends over time rather than dispatching large volumes all at once.
• Maintain a healthy reputation: SPF/DKIM/DMARC authentication, clean lists, low complaint and bounce rates.

Inbound security policy

When a message arrives, OVHcloud applies a series of security and authentication checks, covering both the incoming connection and the message itself.

What OVH checks

• SPF (RFC 7208) — the sending IP address is authorised to send for the sender’s domain.
• DKIM (RFC 6376) — the message’s cryptographic signature is valid.
• DMARC (RFC 7489) — SPF/DKIM alignment matches the policy published by the domain.
• ARC (RFC 8617) — the authentication chain is preserved when the message has passed through an intermediary (forwarder, mailing list).
• Reverse DNS (PTR) (RFC 1912) — the connecting IP address has a reverse record.
• Encryption (RFC 3207) — the incoming SMTP connection is established over SSL/TLS.

How these checks are applied

• Reverse DNS — strict rejection. A connection from an IP with no reverse DNS is systematically rejected. A valid PTR record is an absolute prerequisite for delivering to OVH.
• Other checks — no automatic rejection. An isolated failure on SPF, DKIM, DMARC, ARC, or the absence of encryption does not, on its own, trigger a systematic rejection. These signals feed into a broader set of rules (IP and domain reputation, message content, history, blacklists, etc.) that determines whether the message is accepted, quarantined, or rejected.

Key takeaway: get all of these criteria right. Even without an immediate rejection, degraded authentication results weigh on your reputation and increase the risk of being classified as spam or rejected later.

⚠️ Subject to change. These rules are part of a security framework that evolves continuously to adapt to threats. The behaviour described here may be adjusted without notice.

Improving deliverability to OVH

To maximise your chances of being accepted by OVHcloud’s anti-spam filter, follow these recommendations:

• Authenticate your e-mails — set up SPF, DKIM, DMARC, and ARC for your domain.
• Reduce unknown recipients as much as possible — regularly clean your subscriber lists and act on previous errors (bounces, complaints, invalid addresses) so you stop sending to addresses that fail.
• Avoid SMTP transaction errors — follow the protocol sequence and handle response codes correctly (see the “SMTP codes” page).
• Test your campaign before sending thousands of e-mails — validate rendering, links, and authentication on a small sample first.
• Be clear about the email content — explicit subject, identifiable sender, visible unsubscribe link; avoid misleading practices that trigger filters.

SMTP codes returned when sending to OVH

The replies below are the ones OVHcloud’s inbound MX actually returns. They arrive at two distinct points of the SMTP transaction:

• at RCPT TO, before the message body is transmitted — you know the message is refused before spending bandwidth on DATA. This is where almost every rejection happens;
• at END-OF-MESSAGE, once the body has already been transmitted — rate limiting is applied here, so the bandwidth is spent before you are told to come back later.

⚠️ A 4xx from OVH does not always mean “retry and it will work”. By convention 4xx is temporary and 5xx permanent, but the most frequent rejections here (missing reverse DNS, unresolvable sender domain, IP reputation) are returned as 4xx for a condition that will not clear on its own. Your server will retry until its queue lifetime expires, then bounce the message to your user. Fix the cause; do not just retry.

Rejections at RCPT TO

A message accepted for delivery gets a plain 250 2.0.0. Everything below is a refusal, ordered from the most to the least frequent. <sender> and <recipient> stand for the address the rejection applies to.

The stage is not the cause. The server evaluates the connection, HELO and sender rules but reports the outcome only at RCPT TO. A rejection you receive on RCPT TO may therefore be about your IP address or your envelope sender, not about the recipient at all. Read the text of the reply, not the command it answers.

Protocol limits and other refusals

Beyond the rejections above, the server’s own configuration produces these replies. They are rare in normal traffic, but each one points at a specific client-side mistake.

⚠️ Never pipeline toward these servers. The EHLO response deliberately omits PIPELINING — along with DSN and ETRN — and the server enforces that omission: a client that sends commands in batches without waiting for each reply is rejected with 503 5.5.0. Wait for every reply. ETRN is refused, and DSN requests are not honoured.

Rejection after the message body — rate limiting

450 4.7.1 Rate limit due to high number of emails sent, retry later

This one is applied at END-OF-MESSAGE, after your server has transmitted the whole message. Unlike the 4xx replies above, it is genuinely temporary: the arrival rate for your sender address, the recipient, the sender/recipient pair, or your IP is momentarily too high, and retrying later with progressive backoff succeeds on its own. Spread your sends over time rather than dispatching everything at once — see the “Receiving limits” page.

A clean transaction is not a clean authentication

An SPF, DKIM, DMARC or ARC failure does not, on its own, produce a rejection reply: as described in the inbound security policy, these signals feed your reputation, and therefore the later decision to accept, quarantine, or reject. So a transaction that ends on 250 2.0.0 is no proof that your authentication is in order — check it on the “Security policy” page and with the diagnostic tool on this site.

Connect to an OVHcloud mailbox

To set up your email client and connect to your OVHcloud mailbox (webmail, IMAP / POP / SMTP, email software), follow the official OVHcloud guide:

👉 OVHcloud documentation — Connecting to your email