Com enviar correus des de la teva app (i arribar a la safata d'entrada)

Per enviar correus des de la teva app de manera fiable, fes servir un proveïdor d'enviament de correu en lloc del teu propi correu, envia des d'una adreça del teu domini i afegeix els registres DNS que et dona el proveïdor perquè SPF, DKIM i DMARC passin tots. Mantén separat el correu transaccional (restabliments de contrasenya, rebuts, confirmacions) del correu de màrqueting, envia cada tipus només a qui l'espera i gestiona els rebots i les baixes. Primer ha d'estar bé l'autenticació: és la causa més habitual que el correu de l'app acabi a spam.

Correu transaccional vs de màrqueting

Aquests dos tipus de correu semblen similars en el codi, però els proveïdors de correu i la llei els tracten de manera molt diferent.

Mantén-los separats. Si una campanya de màrqueting rep queixes de spam, no vols que els restabliments de contrasenya del mateix flux en pateixin les conseqüències. Un enfocament habitual són subdominis separats, per exemple mail.example.com per al correu del compte i news.example.com per als butlletins, i alguns proveïdors els separen internament. Postmark, per exemple, descriu els seus "fluxos de missatges" transaccionals i de difusió com a infraestructures d'enviament separades, a setembre de 2026.

Triar un proveïdor

La teva app no hauria d'enviar correu directament des del seu propi servidor. Els proveïdors d'enviament gestionen la infraestructura, la reputació de les IP, els reintents i el processament dels rebots. Opcions conegudes són Postmark, Resend, SendGrid, Amazon SES i Mailgun; cadascuna té una API HTTP i accés SMTP, i els preus i els plans canvien, així que compara'ls a les seves pròpies webs.

Què cal comparar:

• Enfocament. Alguns proveïdors es concentren en el transaccional; altres combinen transaccional i màrqueting.
• Experiència de desenvolupament. Una API clara, biblioteques oficials per al teu llenguatge, registres útils que mostrin si cada missatge s'ha entregat, rebotat o marcat com a spam.
• Webhooks per als rebots, les queixes i les entregues, perquè la teva app hi pugui reaccionar.
• Plantilles: emmagatzemades al proveïdor o al teu propi codi. Tenir-les al codi les fa versionables i comprovables.
• Regió i gestió de dades, si tens requisits sobre on es tracten les dades.
• Cost al teu volum, incloent què passa quan superes el nivell gratuït.

Per als butlletins a una llista, una eina de butlletins o de correu de màrqueting dedicada sol encaixar millor que construir funcions de campanya dins de la teva app.

Configura el teu domini d'enviament

Envia des del teu propi domini: hola@example.com, no una adreça de Gmail o Outlook. El correu d'una adreça de correu gratuïta enviat a través d'un servei de tercers no supera les comprovacions d'autenticació i és probable que es filtri.

Considera un subdomini només per a l'enviament. Resend, per exemple, recomana enviar des de subdominis com updates.example.com per aïllar la reputació d'enviament (a setembre de 2026). A més, així els registres DNS del correu queden separats dels del teu lloc principal.

Després el proveïdor et dona registres DNS per afegir on gestionis el DNS del domini. Si el DNS et resulta nou, com funcionen els dominis i el DNS explica primer els registres.

SPF

SPF (Sender Policy Framework) és un registre TXT que enumera quins servidors poden enviar correu pel teu domini. Els receptors comproven si el servidor que envia és a la llista.

• Un domini hauria de tenir només un registre SPF. Si afegeixes un proveïdor, fusiona'l al registre existent en lloc d'afegir-ne un segon.
• SPF permet com a màxim 10 consultes DNS quan s'avalua; les cadenes llargues d'entrades include: poden superar-ho i provocar errors.
• Molts proveïdors configuren SPF en un subdomini de retorn que et demanen crear, de manera que potser no has de tocar el teu registre SPF principal.

DKIM

DKIM (DomainKeys Identified Mail) afegeix una signatura criptogràfica a cada missatge. El proveïdor signa amb una clau privada; tu publiques la clau pública corresponent com a registre DNS (TXT o CNAME, segons el proveïdor). Els receptors comproven la signatura per confirmar que el missatge ve d'un remitent autoritzat i que no s'ha alterat pel camí.

DKIM és sobretot el que fa el pas de "verificar domini" del proveïdor. No el saltis.

DMARC

DMARC uneix els altres dos. És un registre TXT a _dmarc.yourdomain.com que indica als receptors:

• Alineació: el domini de l'adreça From visible ha de coincidir amb el domini que ha superat SPF o DKIM.
• Política: què fer amb el correu que falla: p=none (només informar), p=quarantine (tractar-lo com a sospitós, sovint spam) o p=reject.
• Informes: on enviar els informes agregats (rua=), perquè puguis veure qui envia com el teu domini.

Un camí sensat és començar amb p=none i una adreça d'informes, confirmar que el teu correu legítim passa, i després passar a quarantine i finalment a reject. Una política estricta també dificulta molt que altres suplantin el teu domini.

Què exigeix Gmail

Des de setembre de 2026, les guies per a remitents de Google diuen:

• Tots els remitents cap a comptes personals de Gmail necessiten SPF o DKIM, DNS directe i invers vàlids per als servidors d'enviament, TLS, i una taxa de spam a Postmaster Tools inferior al 0,3%.
• Remitents massius (més de 5.000 missatges al dia cap a Gmail) necessiten SPF i DKIM, un registre DMARC (es permet una política p=none), alineació del domini From, i una baixa d'un clic més un enllaç de baixa visible als missatges de màrqueting i als de subscripció.

El proveïdor gestiona les parts del servidor. Els registres DNS i la gestió de les baixes són cosa teva. Encara que estiguis molt lluny dels 5.000 al dia, complir les regles per a remitents massius és la manera més senzilla d'estar tranquil.

Integra l'enviament a la teva app

Un cop verificat el domini:

1. Desa la clau d'API com a secret del servidor, mai al codi del front-end. Consulta què són les variables d'entorn i els secrets.
2. Envia des del servidor, després que l'acció que activa el correu hagi reeixit.
3. No facis esperar l'usuari pel correu. Per a qualsevol cosa més que l'app més senzilla, posa l'enviament en cua i reintenta en cas d'errors temporals, perquè una resposta lenta del proveïdor no alenteixi el registre.
4. Registra el resultat: l'ID del missatge i l'estat que dona el proveïdor, sense registrar la clau ni el cos complet dels missatges amb dades personals.
5. Gestiona els webhooks de rebots i queixes: deixa d'enviar a les adreces que rebotin de manera definitiva o que et marquin com a spam.

Un prompt que cobreix els fonaments:

Envia correu transaccional amb [PROVEÏDOR] fent servir el secret del servidor [NOM_ENV], des de "Acme hola@mail.acme.com". Envia un correu de benvinguda després del registre i una confirmació de reserva quan es desi una reserva. Mantén les plantilles al codi, amb una versió de text pla al costat de la HTML. Posa els enviaments en cua i reintenta els errors temporals fins a tres vegades. Registra els errors amb l'error del proveïdor però mai la clau d'API. Afegeix un endpoint de webhook que marqui les adreces no lliurables en cas de rebots definitius i queixes, i que les saltin en els enviaments futurs.

Els correus del compte (enllaços de verificació, enllaços màgics i restabliments de contrasenya) formen part de l'inici de sessió. Com afegir inici de sessió a la teva app explica com encaixen aquests fluxos; fes que aquests enllaços siguin d'un sol ús i de vida curta.

Hàbits d'entregabilitat

L'autenticació fa que el teu correu es consideri. El comportament et manté a la safata d'entrada.

• Envia només el que la gent espera. Registres confirmats, consentiment explícit per al màrqueting, cap llista comprada.
• Fes que donar-se de baixa sigui fàcil en tot el que no sigui estrictament transaccional, i respecta-la de seguida.
• Escalfa els dominis nous. Un domini nou que envia milers de missatges el primer dia sembla sospitós. Comença amb el correu transaccional i augmenta el volum de manera gradual.
• Mantén les llistes netes. Elimina de seguida els rebots definitius i considera eliminar les persones que fa molt que no obren res.
• Escriu com una persona. Un assumpte clar, un nom From reconeixible, una part de text pla, poques imatges i enllaços al teu propi domini. Evita els acortadors d'enllaços.
• Supervisa. Registra el teu domini a Google Postmaster Tools i llegeix de tant en tant els informes DMARC.
• Fes servir una resposta real que algú llegeixi. Les respostes són un bon senyal i una retroalimentació útil.

Prova sense enviar spam a ningú

• Fes servir el mode de prova o sandbox del proveïdor quan en tingui, o envia a adreces que siguin teves.
• En desenvolupament, envia a una safata de proves que accepti tot en lloc d'usuaris reals; una base de dades plena d'adreces que semblen reals és una manera fàcil d'enviar correus a desconeguts per accident.
• Comprova cada plantilla en diversos clients: Gmail a la web, l'app de correu del mòbil, Outlook, i també en mode fosc.
• Mira les capçaleres d'un correu de prova: mostren si SPF, DKIM i DMARC han passat.

Bases legals

Les normes varien segons el país. En general, el correu de màrqueting necessita consentiment en molts llocs, ha d'identificar el remitent i ha d'oferir una baixa que funcioni; el correu transaccional es tracta de manera diferent, però no s'ha d'usar per colar-hi màrqueting. Si recopiles adreces des d'una pàgina de llista d'espera, digues què enviaràs i emmagatzemaràs, i quan i com es va registrar cada persona. Si tens dubtes, consulta les normes del país on són els teus usuaris.

Llista de verificació del correu

• Proveïdor d'enviament triat; clau d'API desada com a secret del servidor
• Enviament des del teu propi domini o subdomini, no una adreça gratuïta
• Registres SPF, DKIM i DMARC afegits i passant
• Correu transaccional i de màrqueting separats
• Enviaments en cua i reintentats; resultats registrats
• Webhooks de rebots i queixes gestionats
• Baixa als correus no transaccionals, respectada de seguida
• Plantilles provades en diversos clients; els correus de prova mai arriben a usuaris reals

Enviar correu des d'una app de Mythex

Mythex no inclou un servei d'enviament de correu integrat per a les apps que construeixes, així que portes un proveïdor com Resend, SendGrid o Postmark. Desa la seva clau d'API com a secret del projecte (l'agent pot demanar-la amb una targeta de secrets al xat) i demana els correus que necessitis amb paraules senzilles. La documentació té un prompt inicial a enviar correu des de la teva app. Si has comprat el teu domini a través de Mythex en el pla Pro, pots afegir els registres TXT i CNAME del proveïdor a la configuració DNS del domini; consulta dominis personalitzats.

Preguntes