Cum se configurează setările DNS cu un domeniu la mijloc pentru DKIM și SPF?

Lucrez la un instrument care îi ajută pe utilizatori să trimită e-mailuri. Intenționez să folosesc un MTA (Mail Transfer Agent) în back-end, cum ar fi AWS-SES sau Sendgrid etc. Pentru ca e-mailurile să ajungă cu succes în căsuțele de recepție cu rețete, utilizatorii vor trebui să configureze DKIM/SPF prin configurarea DNS-ului. setările domeniilor lor respective.

Acum, dacă iau SES de exemplu, le știu am un API care îmi permite pentru a adăuga o „identitate” și a prelua toate înregistrările DNS necesare pentru aceasta folosind API-ul. Sunt sigur că Sendgrid și alte MTA au API-uri similare care permit adăugarea de identități și returnarea înregistrărilor DNS pentru ca utilizatorul să le aplice.

Îi arăt utilizatorului setările DKIM DNS returnate și le adaugă furnizorului lor de DNS, iar după aceea, atunci când trimit e-mailuri, rețetele le primesc corect (fără chestii „via amazonses.com” în anteturi)

Acum, de dragul unui exemplu - să presupunem că instrumentul pe care îl construiesc este găzduit pe chillybilly.xyz și unul dintre utilizatorii care folosește instrumentul meu, are un domeniu numit frankthetank.xyz pe care doresc să-l folosească pentru a trimite e-mailuri prin platforma mea .

Când utilizatorul încearcă să își verifice domeniul prin platforma mea, voi accesa acel API menționat mai sus în AWS SES - și voi arăta ceva de genul acesta utilizatorului:

După care pot adăuga aceste înregistrări CNAMES și TXT pentru DKIM/SPF de succes și pot începe să trimită e-mailuri. Dar dacă te uiți cu atenție, ei pot vedea că folosesc SES din cauza valorilor acelor înregistrări CNAMES și TXT. Și asta este ceva ce vreau să evit, în schimb vreau să le numesc așa ceva 7nuk24xywyawocu6ctqjxmjasiaiq3vq.dkim.chillybilly.xyz care ar arăta branding-ul meu, dar în fundal va indica în continuare cel corect SES.

Acum sunt conștient că așa ceva este posibil pentru că atunci când m-am înscris la ConvertKit, mi-au arătat ceva de genul:

Cele două valori de acolo, după cum puteți vedea, indică spre converkit.com DAR când le rulez printr-o căutare DNS:

https://dnschecker.org/all-dns-records-of-domain.php?query=spf.dm-5mk8zo6m.sg7.convertkit.com.&rtype=ALL&dns=google

https://dnschecker.org/all-dns-records-of-domain.php?query=dkim.dm-5mk8zo6m.sg7.convertkit.com.&rtype=ALL&dns=google

Pot vedea că în fundal indică înregistrările MX și TXT care aparțin Sendgrid. Cum pot realiza acest lucru? (Cred că aceleași principii se vor aplica și pentru SES sau orice alt MTA)

EDITAȚI | ×: Am încercat câteva lucruri - Și am setat CNAME, MX și TXT în chillybilly.xyz (domeniul proiectului meu) și i-am indicat două CNAMES din frankthetank.xyz numit spf.frankthetank.xyz și dkim.frankthetankxyz

https://dnschecker.org/all-dns-records-of-domain.php?query=spf.frankthetank.xyz&rtype=ALL&dns=google

https://dnschecker.org/all-dns-records-of-domain.php?query=dkim.frankthetank.xyz&rtype=ALL&dns=google

După cum puteți vedea, am reușit să obțin rezultate foarte asemănătoare cu ceea ce face ConvertKit cu Sendgrid. Dar nu se verifică în acest fel. :(

Singura diferență pe care o văd când verific acele căutări DNS (link-urile de mai sus) este că și CNAME-urile apar în căutare pentru mine, dar nu și în cazul convertkit-ului. Deci cred că sunt aproape de o soluție, dar nu sunt sigur ce îmi lipsește, vreo idee? :)

Primul SPF: dacă înlocuiți de ex. Înregistrarea SPF de ieșire a sendgrid, care este inclusă în înregistrarea dvs. SPF, cu propria dvs. marcă, v-ați asumat în același timp sarcina de a urmări toate lucrurile dinamice pe care sendgrid le-ar putea face cu numele și adresele serverului de e-mail de ieșire. Nu doriți să faceți asta, așa că, dacă trimiteți prin sendgrid, trebuie să includeți SPF-ul sendgrid. Deci, din moment ce utilizați sendgrid, nu există nicio modalitate de a scăpa de acel „include: sendgrid.net” din înregistrarea SPF fără a vă provoca durere.

DKIM este similar, exemplul Amazons creează CNAME pentru înregistrările care există în DNS-ul Amazon. Dacă vrei să-l înlocuiești cu al tău (ceea ce poți, fără nicio problemă), trebuie să pui acele înregistrări în propriul tău DNS. Ceea ce nu este o problemă, totuși, trebuie să transferați cumva cheia de semnare oricui semnează acele e-mailuri și asta ar putea fi o problemă. Cu soluția Amazon, ei creează cheia și vă oferă linkul către cheia publică pe care au pus-o în DNS-ul lor, care se potrivește cu cheia privată cu care vă semnează e-mailul.

Cu toate acestea, dacă doriți să eliminați „brandingul” de pe serverele de e-mail ale Amazon sau sendgrid, singura modalitate este să le cumpărați, deoarece acest lucru se face prin DNS invers și nu vor indica NICIODATĂ serverele lor de ieșire către nume din spațiul dvs. de nume DNS.

Deci, puteți face doar înregistrări CNAME care indică înregistrarea sursă originală sau pur și simplu puneți SPF-ul corect, cum ar fi exemplul convertkit, dar sub domeniul dvs.

sau aveți un middleware care trece prin procesul de verificare a domeniului în sendgrid/AWS, creând înregistrările DNS pe domeniul dvs., pe care apoi le spuneți clientului dvs. la CNAME la noile înregistrări DNS pe care le-ați creat și apoi finalizează verificarea odată ce clientul face clic pe un butonul pentru a spune că au făcut asta

acest lucru nu va opri antetele de e-mail sau urmărirea înregistrărilor DNS pentru a găsi furnizorul original, dar pentru o persoană obișnuită, acest lucru este probabil amenda.

Cu toate acestea, vreau să avertizez acest lucru - straturile de ofuscare doare de fapt la nivelul DNS.

De exemplu, SPF are o limită explicită de 10 căutări codificate în RFC - Sendgrid scriu ei înșiși despre asta - https://docs.sendgrid.com/ui/account-and-settings/spf-limitations

• RFC original. Aveți un risc ridicat de a atinge această problemă dacă faceți orice fel de ofuscare pentru SPF

căutările DNS suplimentare vor crește timpii de răspuns pentru orice căutare bazată pe DNS în fluxul de livrare a e-mailului și/sau în aplicația dvs. - acest lucru ar putea cauza multă durere la multe niveluri, mai ales că MTA-urile sunt procesate în timp real, orice întârziere are un impact uriaș potențial asupra impactului.

Pentru a pune niște calcule în acest lucru, imaginați-vă că un singur e-mail durează 20 ms pentru a fi procesat și trimis printr-un MTA cu DNS - acesta este exemplul cel mai bun caz presupunând această logică Valabil. Puteți trimite aproximativ 180.000 de e-mailuri pe oră. Dacă trebuie să dublăm acest lucru adăugând cel puțin 1 căutare suplimentară dns, aceasta se reduce la jumătate la 90.000 de e-mailuri pe oră. Dacă te bazezi pe volum, ar trebui să arunci acum de două ori mai multă cantitate de hardware pentru a menține același debit.