DEV Community

Cover image for Setting Up DNS for SaaS Emails
Aidas Bendoraitis
Aidas Bendoraitis

Posted on Originally published at djangotricks.com

Setting Up DNS for SaaS Emails

When you create a Software as a Service (SaaS) or a social web platform, one of the often-overlooked parts of it is the email DNS configuration. I learned this too late with my own projects, and as a result, many of my initial emails landed in spam folders. Also, incorrect DNS records can make it easier for attackers to send emails pretending to be from your domain. Here are my learnings about it from 5 years of running a SaaS business.

Consider using separate subdomains for different types of email

The emails you send generally fall into these categories:

  • direct - emails that you send manually.
  • transactional - emails that your website sends for signup confirmations, two-factor authentications, password resets, etc.
  • marketing - onboarding emails, mailing-list newsletters, birthday greetings, etc.

Marketing emails are frequent and not always wanted, so recipients may mark them as spam, which can hurt your sender reputation. Deliverability also depends on factors such as authentication, engagement, list quality, and sending practices (You can check your existing email spamminess at SpamHaus or MxToolbox).

For this reason, it can be useful to separate marketing emails from direct and transactional emails using different subdomains.

If example.com is your marketing website, and app.example.com is your SaaS, your main emails could be:

  • info@hello.example.com - for marketing / newsletters
  • hello@mail.example.com - for transactional and direct emails

MX records for receiving emails

An MX record (Mail eXchange record) is a type of DNS record that specifies which mail server is responsible for accepting email on behalf of a domain. When somebody sends an email to you, the sending mail server looks up the MX record for your domain to find out where to deliver that message.

  • In the host field you would set your subdomain (or @ for the root domain).
  • The values contain the domain of the mail server and the priority of that server (a lower preference number means higher priority). If the server with higher priority is unreachable, the mail will fall back to the secondary one.
  • TTL (Time To Live) controls how long DNS resolvers are allowed to cache a record before checking back for updates. While configuring and testing the server you can set it to a low value like 5 min, but when everything is working reliably, you can switch to Automatic.

Here is an example setup pointing to FastMail servers.

Type Host Value TTL
MX Record hello in1-smtp.messagingengine.com. 10 Automatic
MX Record hello in2-smtp.messagingengine.com. 20 Automatic
MX Record mail in1-smtp.messagingengine.com. 10 Automatic
MX Record mail in2-smtp.messagingengine.com. 20 Automatic

Note that Fastmail does not allow its service to be used for automated or transactional emails, but you might need these settings for receiving your direct emails and replies.

SMTP setup for outgoing emails

SMTP (Simple Mail Transfer Protocol) is the protocol used to transfer email between mail servers and from mail clients or applications to mail servers. SMTP will be used no matter whether you send a direct email from an email client like FastMail, or a transactional email from Amazon SES, Postmark, Brevo, Mailjet, Resend, SendGrid, Mailgun, or Postal.

SPF records for outgoing emails: Which senders are allowed?

An SPF record (Sender Policy Framework) is a type of DNS TXT record that specifies which mail servers are allowed to send email on behalf of your domain. It's one of the core mechanisms used to prevent email spoofing. SPF has one record per domain or subdomain and multiple senders must be combined into one line.

Type Host Value TTL
TXT Record hello v=spf1 include:spf.messagingengine.com include:spf.mailjet.com -all Automatic
TXT Record mail v=spf1 include:spf.messagingengine.com include:spf.mailjet.com -all Automatic

Here:

  • v=spf1 - declares this is an SPF record, version 1.
  • include:domain.com - delegate to another domain's SPF record.
  • -all - hard fail - SPF fails for unauthorized senders.
  • ~all - soft fail - SPF fails, but the receiver may still accept the message.
  • ?all - neutral - SPF makes no policy statement.

Some of the well known includes:

  • include:spf.messagingengine.com - FastMail
  • include:_spf.google.com - Google Workspace
  • include:spf.mailjet.com - Mailjet
  • include:spf.brevo.com - Brevo
  • include:servers.mcsv.net - MailChimp
  • include:amazonses.com - Amazon SES or Resend (which is built on top of Amazon SES)
  • include:sendgrid.net - SendGrid
  • include:mailgun.org - Mailgun

DKIM records for outgoing emails: Is the sender valid?

A DKIM record (DomainKeys Identified Mail) is a DNS TXT record containing a public cryptographic key that lets receiving mail servers verify that an email genuinely came from your domain and wasn't altered in transit. Sometimes, it's a CNAME record pointing to the servers of the mail service, which contains the DNS TXT records with the cryptographic keys. Typically, the Host is <prefix>._domainkey.<your_subdomain>.

Here is an example Mailjet config:

Type Host Value TTL
TXT Record mailjet._domainkey.hello k=rsa; p=<unique_id> Automatic
TXT Record mailjet._domainkey.mail k=rsa; p=<unique_id> Automatic

For FastMail, it would be:

Type Host Value TTL
CNAME Record fm1._domainkey.hello fm1.hello.<root_domain>.dkim.fmhosted.com. Automatic
CNAME Record fm1._domainkey.mail fm1.mail.<root_domain>.dkim.fmhosted.com. Automatic
CNAME Record fm2._domainkey.hello fm2.hello.<root_domain>.dkim.fmhosted.com. Automatic
CNAME Record fm2._domainkey.mail fm2.mail.<root_domain>.dkim.fmhosted.com. Automatic
CNAME Record fm3._domainkey.hello fm3.hello.<root_domain>.dkim.fmhosted.com. Automatic
CNAME Record fm3._domainkey.mail fm3.mail.<root_domain>.dkim.fmhosted.com. Automatic

DMARC records for outgoing emails: What to do with unauthorized senders?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS TXT record that ties SPF and DKIM together into a single policy, telling receiving mail servers what to do when a message fails authentication, and optionally sending you reports about it.

Type Host Value TTL
TXT Record _dmarc.mail v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@mail.<root_domain> Automatic
TXT Record _dmarc.hello v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@mail.<root_domain> Automatic

Here:

  • v=DMARC1 - declares this is an DMARC record, version 1.
  • p - stands for Policy and defines what receivers should do on failure:
    • none (monitor only, no action),
    • quarantine (send to spam),
    • reject (block outright).
  • pct= - the percentage of messages to which the policy should be applied.
  • rua=mailto:... - tells where to send aggregate reports as daily XML summaries of pass/fail volumes.

The daily aggregate reports are a little annoying, but they are required for the emails to have little probability to land in a Spam directory.

Brevo setup as an exception

Brevo requires its own set of CNAME and TXT records to authenticate your domain and improve email deliverability. You would get the setup instructions while onboarding.

BIMI records for the outgoing emails: What brand logo will be shown?

BIMI (Brand Indicators for Message Identification) is a DNS TXT record that lets your logo appear as the sender avatar next to your emails in supporting email clients and services such as Gmail, Yahoo Mail, Apple Mail, and Fastmail.

Here is an example of BIMI records:

Type Host Value TTL
TXT Record default._bimi.mail v=BIMI1; l=https://www.<root_domain>/static/0/email/img/bimi-logo.svg; a=<cert_url>; Automatic
TXT Record default._bimi.hello v=BIMI1; l=https://www.<root_domain>/static/0/email/img/bimi-logo.svg; a=<cert_url>; Automatic

BIMI defines not just a simple favicon, but rather the official logo of the brand. To fully support such an image, you would need to buy a certificate that costs from 650 to 1500 USD per year at the time of writing. There are two types: VMC (Verified Mark Certificate) for registered trademarks, and CMC (Common Mark Certificate) (cheaper one) for any logo. DigiCert and Entrust Datacard are the active BIMI-authorized certificate authorities.

If you set the BIMI record without the certificate, the image might still show up in some email clients, like the FastMail. It's just important that the used SVG file is of the SVG Tiny Portable/Secure (SVG Tiny PS). You can use https://makebimi.com/ to generate the SVG of an appropriate size and upload the logo to your website, e.g. under site_static/email/img/bimi-logo.svg.

Also, for BIMI, DMARC must use an enforcement policy (p=quarantine or p=reject) with pct=100.

Final words

So if you want to maximize your email deliverability, have two subdomains for the SaaS or web platform, and make sure to set all the guardrails as recommended:

Record/Setting Direction Purpose
MX record Incoming Tells senders where to deliver mail to your domain
SMTP server setting (in your email client) Outgoing Where you connect to send mail from your account
SPF record Outgoing (verification) Tells receivers which servers are authorized to send mail claiming to be from your domain
DKIM record Outgoing (verification) Cryptographically signs outgoing mail so receivers can verify it wasn't tampered with
DMARC record Both (policy) Tells receivers what to do if SPF/DKIM checks fail
BIMI record Outgoing Lets you display your brand's logo next to your emails in supporting inboxes

Cover picture by cottonbro studio

Top comments (0)