Deliverability

Cos'è un record MX e ne serve uno per inviare?

Un record MX indica i server per la posta in arrivo, senza essere un requisito di protocollo per l'invio.

Un'applicazione di invio e una casella di ricezione possono usare domini diversi. I record che instradano le risposte non devono trovarsi su ogni sottodominio usato per l'invio.

Come usa i record MX un server mittente?

Il server mittente cerca il dominio del destinatario per trovare i server che accettano la sua posta in arrivo.

Per person@example.org, cerca i record MX di example.org. Ogni record indica un server di destinazione il cui hostname si risolve in un indirizzo IP.

RFC 5321 definisce questo processo di ricerca per SMTP.

Il server mittente restituisce un errore quando il dominio del destinatario non esiste. Dopo un errore di ricerca temporaneo, accoda il messaggio per un tentativo successivo.

Cosa succede quando un dominio non ha un record MX?

Se non esistono record MX, SMTP tratta il dominio stesso come destinazione e prova i suoi record di indirizzo.

Questo MX implicito ha preferenza zero. Non c'è una lista MX esplicita che lo sovrasti, quindi la consegna procede verso l'indirizzo del dominio stesso quando utilizzabile.

Questo fallback si applica a una lista MX vuota. Non recupera un dominio i cui record MX pubblicati sono inutilizzabili.

Un null MX è un'istruzione diversa: RFC 7505 definisce un record esplicito che dichiara che il dominio non accetta posta. Un record assente consente il fallback. Un null MX rifiuta la consegna.

Cosa significano i numeri di preferenza MX?

I valori di preferenza più bassi identificano le destinazioni che il mittente deve provare per prime.

Con valori 10, 20 e 30, la destinazione con 10 è quella preferita. Le altre forniscono alternative se la consegna non può procedere verso quella. Assegnare a tutte le destinazioni lo stesso valore consente invece la distribuzione tra scelte a preferenza uguale.

Secondo RFC 5321, i server mittenti devono randomizzare le destinazioni a preferenza uguale a meno che non ci sia un motivo chiaro per preferirne una. Preferenze uguali non garantiscono una divisione esatta del traffico.

Punta il tuo record MX a un hostname di cui pubblichi l'indirizzo, così i mittenti possono connettersi. Usa un record A per il suo indirizzo IPv4 o un record AAAA per IPv6. Non usare un alias CNAME come destinazione. L'alias impedisce al DNS di includere l'indirizzo nella risposta MX. Questo aggiunge ricerche, come spiega RFC 2181.

I client SMTP devono supportare il tentativo verso destinazioni alternative. La specifica raccomanda di provare almeno due indirizzi quando disponibili. Un fallimento al primo non deve necessariamente interrompere i tentativi di consegna.

Serve un record MX per inviare?

SMTP non richiede un record MX esplicito sul tuo dominio solo per originare un messaggio.

La ricerca di consegna usa il dominio del destinatario. Il tuo dominio di invio ha comunque bisogno di un DNS valido e di un'autenticazione adeguata ai requisiti del ricevente. Un ricevente può applicare i propri controlli al dominio del mittente.

Un record MX mancante quindi non significa che un dominio mittente irraggiungibile sia accettato da ogni ricevente.

Dove vanno i fallimenti di consegna?

I fallimenti di consegna vanno all'envelope sender, l'indirizzo fornito per le notifiche di errore durante la consegna SMTP.

Dove vanno le risposte?

Le risposte usano normalmente Reply-To quando presente, altrimenti l'indirizzo From visibile.

Un sottodominio di invio non deve ospitare tutte le caselle aziendali. Per esempio, news.example.com può inviare mentre le risposte vanno a un indirizzo funzionante su example.com. Rendi esplicita questa scelta di instradamento negli indirizzi del messaggio.

Dove vanno le segnalazioni operative?

Indirizzi operativi come postmaster@ e abuse@ offrono agli altri operatori un modo per segnalare problemi di consegna o abuso.

Secondo RFC 5321, un server SMTP che inoltra o consegna posta deve accettare postmaster@ per i domini che serve. Questo fornisce un contatto per i problemi del servizio di posta.

RFC 2142 richiede alle organizzazioni di supportare caselle di ruolo dove esiste la funzione corrispondente. Per esempio, un fornitore di servizi Internet deve supportare abuse@ sul proprio dominio organizzativo. Questo instrada le segnalazioni al team responsabile.

Come si riceve la posta con Bird?

Abilita la ricezione per un dominio e pubblica i record MX che Bird restituisce.

Il campo inbound.enabled di API accetta true per abilitare la ricezione o false per disabilitarla. Pubblicare i record da soli non abilita la funzionalità.

Dopo la verifica, la posta indirizzata a quel dominio diventa messaggi in entrata. Usa un sottodominio dedicato alla ricezione perché sostituire i record MX del dominio aziendale cambia dove arriva la posta esistente.

Il record return-path di Bird gestisce le notifiche di fallimento di consegna separatamente da quei record MX in entrata. La guida alla ricezione spiega la configurazione del dominio. La guida al dominio bounce spiega la gestione dei fallimenti.

In breve

  1. I record MX instradano la posta in arrivo.

    Il server mittente cerca il dominio del destinatario per trovare una destinazione.

  2. I record MX mancanti possono ricadere sugli indirizzi.

    Quando non esistono record MX, il server mittente può usare i record di indirizzo del dominio.

  3. I valori di preferenza più bassi vengono provati per primi.

    Le destinazioni con preferenza uguale vengono distribuite casualmente quando non c'è motivo di preferirne una.

  4. Invio e ricezione richiedono decisioni separate.

    La posta in uscita ha comunque bisogno di una gestione adeguata per i fallimenti di consegna, le risposte e gli indirizzi di contatto operativi.

Costruisci sulla stessa rete.

Una chiave API di test è subito tua. L'accesso alla produzione si sblocca quando aggiungi un metodo di pagamento e verifichi un mittente.

La tua prossima idea.
Pronta a partire.