Wszystko dla Twojej poczty OVHcloud

Uwierzytelnij swoją domenę przy wysyłaniu

Aby wiadomości wysyłane przez OVH były akceptowane przez odbiorców, uwierzytelnij swoją domenę za pomocą SPF, DKIM i DMARC.

Konfiguracja SPF (Sender Policy Framework)

SPF uwierzytelnia Twoje wiadomości e-mail, deklarując serwery uprawnione do wysyłania w imieniu Twojej domeny.

Jeśli to możliwe, SPF jest konfigurowany automatycznie podczas tworzenia usługi e-mail. W przypadku nieprawidłowej konfiguracji przejdź do Managera OVHcloud, na stronę swojej usługi e-mail, aby ponownie uruchomić automatyczną konfigurację; SPF możesz też skonfigurować samodzielnie w strefie DNS swojej domeny.

Przykładowy rekord SPF dla OVH:

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

Zalecenie: Używaj ~all (softfail) w fazie testów, a następnie przejdź na -all (hardfail) po zweryfikowaniu konfiguracji.

Konfiguracja DKIM (DomainKeys Identified Mail)

DKIM dodaje podpis kryptograficzny do Twoich wiadomości e-mail, aby potwierdzić ich autentyczność.

Jeśli to możliwe, DKIM jest konfigurowany automatycznie podczas tworzenia usługi e-mail. W przypadku nieprawidłowej konfiguracji przejdź do Managera OVHcloud, na stronę swojej usługi e-mail, aby ponownie uruchomić automatyczną konfigurację: OVHcloud generuje klucze i publikuje odpowiedni rekord DNS.

Konfiguracja DMARC

DMARC łączy SPF i DKIM, aby zapewnić politykę obsługi nieuwierzytelnionych wiadomości e-mail.

🚧 W toku. Zalecana standardowa konfiguracja DMARC jest w trakcie przygotowania. Nie jest jeszcze proponowana, ponieważ przekierowania i listy mailingowe mogą zepsuć zgodność DMARC: zbyt rygorystyczna polityka mogłaby spowodować odrzucanie prawidłowych, przekazywanych wiadomości.

ARC (Authenticated Received Chain)

ARC zachowuje wyniki uwierzytelniania (SPF, DKIM, DMARC), gdy wiadomość przechodzi przez pośrednika, który ją przekazuje dalej — zazwyczaj przekierowanie (forward) lub listę mailingową. Tacy pośrednicy często modyfikują wiadomość lub kopertę, co psuje SPF i zgodność DMARC; ARC pozwala serwerowi docelowemu stwierdzić, że uwierzytelnianie było prawidłowe przed tym przeskokiem.

Nie musisz nic konfigurować. OVHcloud automatycznie dodaje podpis ARC do obsługiwanego ruchu przekierowań (forward) i list mailingowych.

Ogólne zalecenia

• Usługi e-mail OVH są przeznaczone do indywidualnego użytku pocztowego. Zastosowania transakcyjne i komunikacyjne są tolerowane, ale ograniczone objętościowo.
• Utrzymuj niski wskaźnik skarg na spam
• Wdróż jasną procedurę wypisania się
• Wysyłaj tylko do odbiorców, którzy wyraźnie wyrazili zgodę — bez list kupionych ani zebranych
• Segmentuj wysyłki według zaangażowania odbiorców
• Monitoruj swoją reputację za pomocą feedback loops
• Dziel wysyłki masowe na części

Limity wysyłania

Przegląd

Uwaga: Limity godzinowy i dzienny są oceniane według kilku kryteriów: nadawcy, odbiorcy, pary nadawca/odbiorca oraz adresu IP wysyłki.

Ważne: Przekroczenie limitów wysyłania może spowodować tymczasowe zablokowanie konta. Jeśli potrzebujesz wyższych limitów, skontaktuj się z naszym zespołem wsparcia.

Lista wychodzących adresów IP

🚧 W toku. Trwają prace nad racjonalizacją wychodzących adresów IP, dlatego lista zakresów IP nie jest obecnie publikowana.

Jeśli musisz dodać serwery wysyłkowe OVHcloud do białej listy, opieraj się na stabilnych kryteriach zamiast na stałych adresach IP:

• SPF — zezwól na rekord SPF OVHcloud (include:mx.ovh.net).
• Reverse DNS (PTR) — serwery wysyłkowe mają nazwę odwrotną kończącą się na:
  • mail-out.ovh.net dla Europy;
  • mail-out.ovh.ca dla Kanady.

Kody błędów SMTP

Oto najważniejsze kody odpowiedzi SMTP, które nasze serwery mogą zwrócić, oraz co zrobić w każdym przypadku:

Wszystko, czego nie ma w tej tabeli, pochodzi z infrastruktury pocztowej za proxy i jest przekazywane bez zmian.

Dostarczalność wiadomości wychodzących

Każda wiadomość wychodząca przechodzi analizę anty-spam. Jeśli wiadomość zostanie wykryta jako SPAM, nie zostanie dostarczona.

Na podstawie tej analizy anty-spam wiadomości wychodzących konto może zostać zablokowane.

Aby zrozumieć blokadę i ją rozwiązać, zapoznaj się z przewodnikiem OVHcloud: Konto zablokowane z powodu spamu.

Limity odbierania

* Z zastrzeżeniem ograniczania przepustowości anti-flood (zob. poniżej).

Warunki akceptacji:

• Wymagany reverse DNS — akceptowane są wyłącznie adresy IP posiadające rekord odwrotny (PTR).
• Możliwa blokada ręczna — w przypadku nadużyć może zostać zastosowana ręczna blokada (adresu IP, domeny lub nadawcy).

Uwaga: Odbiór nie jest ograniczony objętościowo, ale podlega limitom przestrzeni dyskowej skrzynki. Pełna skrzynka odrzuca nowe wiadomości (zob. kody SMTP 4xx/5xx). Do ruchu przychodzącego stosuje się natomiast ograniczanie przepustowości anti-flood (zob. poniżej): jest to ochrona przed masowym napływem, niezależna od jakiegokolwiek limitu objętości.

Ograniczanie przepustowości na wejściu (anti-flood)

Aby chronić swoje serwery i użytkowników, OVHcloud stosuje mechanizm adaptacyjnego ograniczania przepustowości dla ruchu przychodzącego. Tempo napływu wiadomości jest śledzone w ruchomych oknach godzinowym i dziennym, a dozwolony margines dostosowuje się automatycznie do zachowania każdego źródła: regularny i zgodny z zasadami nadawca z czasem zyskuje większy margines, natomiast nietypowy, masowy napływ jest spowalniany.

Ograniczanie to jest oceniane według kilku niezależnych kryteriów: adresu nadawcy, adresu odbiorcy, pary nadawca/odbiorca oraz adresu IP wysyłki.

Gdy ten limit zostanie chwilowo osiągnięty, wiadomość nie jest trwale odrzucana: OVH odpowiada tymczasowym kodem SMTP 4xx, na przykład:

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

Zgodny z zasadami serwer wysyłający ponawia próbę automatycznie nieco później, a dostarczanie kończy się powodzeniem samo z siebie.

Po stronie nadawcy, aby uniknąć spowolnień:

• Respektuj tymczasowe kody 4xx i ponawiaj próby ze stopniowym opóźnieniem (nie traktuj kodu 4xx jako trwałej awarii).
• Rozłóż wysyłkę w czasie, zamiast wysyłać duże wolumeny naraz.
• Utrzymuj dobrą reputację: uwierzytelnianie SPF/DKIM/DMARC, czyste listy, niski poziom skarg i odrzuceń.

Polityka bezpieczeństwa przy odbiorze

Po odebraniu wiadomości OVHcloud stosuje szereg kontroli bezpieczeństwa i uwierzytelniania, obejmujących zarówno połączenie przychodzące, jak i samą wiadomość.

Co sprawdza OVH

• SPF (RFC 7208) — adres IP nadawcy jest uprawniony do wysyłki dla domeny nadawcy.
• DKIM (RFC 6376) — podpis kryptograficzny wiadomości jest prawidłowy.
• DMARC (RFC 7489) — zgodność SPF/DKIM odpowiada polityce opublikowanej przez domenę.
• ARC (RFC 8617) — łańcuch uwierzytelniania został zachowany, gdy wiadomość przeszła przez pośrednika (forwarder, listę mailingową).
• Reverse DNS (PTR) (RFC 1912) — łączący się adres IP posiada rekord odwrotny.
• Szyfrowanie (RFC 3207) — połączenie SMTP przychodzące zostało nawiązane przez SSL/TLS.

Jak stosowane są te kontrole

• Reverse DNS — ścisłe odrzucenie. Połączenie z adresu IP bez reverse DNS jest systematycznie odrzucane. Prawidłowy rekord PTR to bezwzględny warunek dostarczenia do OVH.
• Pozostałe kontrole — brak automatycznego odrzucenia. Pojedyncze niepowodzenie SPF, DKIM, DMARC, ARC lub brak szyfrowania samo w sobie nie powoduje systematycznego odrzucenia. Sygnały te wchodzą w skład szerszego zestawu reguł (reputacja IP i domeny, treść wiadomości, historia, czarne listy itp.), który decyduje o przyjęciu, kwarantannie lub odrzuceniu wiadomości.

Najważniejsze: zadbaj o wszystkie te kryteria. Nawet bez natychmiastowego odrzucenia obniżone wyniki uwierzytelniania obciążają reputację i zwiększają ryzyko zaklasyfikowania jako spam lub późniejszego odrzucenia.

⚠️ Może ulec zmianie. Reguły te są częścią systemu bezpieczeństwa, który stale ewoluuje, aby dostosować się do zagrożeń. Opisane tu zachowania mogą zostać zmienione bez powiadomienia.

Poprawa dostarczalności do OVH

Aby zwiększyć szanse na akceptację przez filtr anty-spam OVHcloud, stosuj się do poniższych zaleceń:

• Uwierzytelniaj swoje wiadomości — skonfiguruj SPF, DKIM, DMARC i ARC dla swojej domeny.
• Maksymalnie ogranicz nieznanych odbiorców — regularnie czyść listy subskrybentów i uwzględniaj wcześniejsze błędy (odbicia, skargi, nieprawidłowe adresy), aby nie wysyłać ponownie na adresy, które zawodzą.
• Unikaj błędów transakcji SMTP — przestrzegaj sekwencji protokołu i poprawnie obsługuj kody odpowiedzi (zob. stronę „Kody SMTP”).
• Przetestuj kampanię przed wysłaniem tysięcy wiadomości — najpierw sprawdź wygląd, linki i uwierzytelnianie na małej próbce.
• Zadbaj o przejrzystość treści wiadomości — jasny temat, rozpoznawalny nadawca, widoczny link do wypisania się; unikaj mylących praktyk, które wyzwalają filtry.

Kody SMTP zwracane przy wysyłce do OVH

Poniższe odpowiedzi to te, które faktycznie zwracają serwery MX przyjmujące pocztę w OVHcloud. Pojawiają się w dwóch różnych momentach transakcji SMTP:

• przy RCPT TO, przed przesłaniem treści wiadomości — o odrzuceniu dowiesz się, zanim zużyjesz pasmo na DATA. Tu następuje niemal każde odrzucenie;
• przy END-OF-MESSAGE, gdy treść została już przesłana — tutaj stosowane jest ograniczanie tempa, więc pasmo zostaje zużyte, zanim usłyszysz, że masz wrócić później.

⚠️ Kod 4xx od OVH nie zawsze znaczy „ponów i się uda”. Umownie 4xx jest tymczasowy, a 5xx trwały, ale najczęstsze odrzucenia (brak reverse DNS, nierozwiązywalna domena nadawcy, reputacja adresu IP) są zwracane jako 4xx dla przyczyny, która nie zniknie sama. Twój serwer będzie ponawiał do wygaśnięcia kolejki, a potem zwróci wiadomość użytkownikowi jako błąd. Usuń przyczynę, nie poprzestawaj na ponawianiu.

Odrzucenia przy RCPT TO

Wiadomość przyjęta do dostarczenia otrzymuje zwykłe 250 2.0.0. Wszystko poniżej to odmowa, uporządkowana od najczęstszych do najrzadszych. <nadawca> i <odbiorca> oznaczają adres, którego dotyczy odrzucenie.

Etap nie jest przyczyną. Serwer ocenia reguły połączenia, HELO i nadawcy, ale wynik przekazuje dopiero przy RCPT TO. Odrzucenie otrzymane przy RCPT TO może więc dotyczyć Twojego adresu IP albo nadawcy koperty, a wcale nie odbiorcy. Czytaj treść odpowiedzi, nie polecenie, na które odpowiada.

Limity protokołu i inne odmowy

Poza powyższymi odrzuceniami konfiguracja serwera generuje następujące odpowiedzi. W normalnym ruchu są rzadkie, ale każda wskazuje na konkretny błąd po stronie klienta.

⚠️ Nigdy nie stosuj potokowania wobec tych serwerów. Odpowiedź na EHLO celowo pomija PIPELINING — a także DSN i ETRN — i serwer tego pominięcia pilnuje: klient wysyłający polecenia hurtowo, bez czekania na każdą odpowiedź, dostaje 503 5.5.0. Czekaj na każdą odpowiedź. ETRN jest odrzucane, a żądania DSN nie są realizowane.

Odrzucenie po treści wiadomości — ograniczanie tempa

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

To odrzucenie następuje przy END-OF-MESSAGE, po przesłaniu przez Twój serwer całej wiadomości. W przeciwieństwie do powyższych odpowiedzi 4xx jest ono naprawdę tymczasowe: tempo napływu dla Twojego adresu nadawcy, odbiorcy, pary nadawca/odbiorca albo Twojego adresu IP jest chwilowo zbyt wysokie, a ponowienie później ze wzrastającym opóźnieniem samo się powodzi. Rozłóż wysyłkę w czasie, zamiast wysyłać wszystko naraz — zob. stronę „Limity odbioru”.

Czysta transakcja to nie czyste uwierzytelnianie

Niepowodzenie SPF, DKIM, DMARC czy ARC samo z siebie nie powoduje odpowiedzi odrzucającej: jak opisuje polityka bezpieczeństwa przy odbiorze, te sygnały zasilają Twoją reputację, a przez to późniejszą decyzję o przyjęciu, kwarantannie lub odrzuceniu. Transakcja zakończona na 250 2.0.0 nie jest więc dowodem, że Twoje uwierzytelnianie jest poprawne — sprawdź to na stronie „Polityka bezpieczeństwa” oraz narzędziem diagnostycznym na tej witrynie.

Połączenie ze skrzynką OVHcloud

Aby skonfigurować program pocztowy i połączyć się ze skrzynką OVHcloud (webmail, IMAP / POP / SMTP, programy pocztowe), postępuj zgodnie z oficjalnym przewodnikiem OVHcloud:

👉 Dokumentacja OVHcloud — Połączenie z pocztą