In Feb of 2024 Google and Yahoo started rejecting emails set up incorrectly. I’ve had a couple of clients call me because their email was failing, not on our projects, but on other domains they own. I thought it would be good to recap email configuration requirements with the new policies rolling out. We will do all this for our clients on our projects.

This is just a quick overview with examples. You will work with your email provider to get the correct values to enter in each record. This assumes you know what a DNS record is (records you use to configure your domain on the internet).

1. Receiving email: You own a domain. You sign up with an email service. When people send email to your domain, they need to know where your email service is. You do this by updating your DNS records and adding an MX record, like this:

   Type	Priority	Target
   MX	10	aspmx.l.google.com.

2. Sending email: Now you want to send mail. Your new email service is going to require you to verify that you own your domain. There are a few ways to do this, but I recommend using your DNS records. This time we create a TXT record, like this:

   Type	Value
   TXT	"google-site-verification=ieSa6Icvt5UhPEKKZb-IDIcwfqda7NPDhQ5eiwr35us"

   The value in the record is a unique code provided by the mail service. You add the “secret code,” your email provider reads it off your DNS, which proves the person setting up the email can also edit the domain - hence ownership (or both sites hacked).

3. Connecting to your email: If you want to engage your email outside the client provided by the email service, like on your phone, the internet uses a few different protocols to manage the messaging. Most often the email service will provide a server that they call an SMTP server, often with its own subdomain, like smtp.gmail.com. Most likely, the newer setups will just ask you to login, but I am providing this for clarity.

   When we send mail from your application on your behalf, we are most likely using an API to connect to your email service. It's more efficient and allows further customization. API keys can be stolen, so you should restrict what IP addresses can use your key (if supported) and consider changing your keys on a routine basis.

If your email is getting blocked, it’s possibly because you haven’t set up security protocols that services like Gmail and Yahoo now require:

4. Sender Policy Framework (SPF): This is a record that tells the internet what email servers can send mail on your behalf. The record we added in step 2 was just to prove ownership and doesn’t follow a format that the internet understands. We do this by adding another TXT record to your DNS, but with a specific format:

   Type	Value
   TXT	"v=spf1 include:spf.tapfiliate.com include:_spf.google.com ~all"

   This stops email spoofing. A nefarious character would have to hack into your email provider to use your domain for sending mail.

5. Domain Keys Identified Mail (DKIM): This is a public encryption key that you publish (the email server keeps the private key). When you send an email, the message includes a digital signature based on the private key and message. The receiving email server can retrieve the public key and use it to confirm the email has not been altered since the signature was created. The public key is posted as another TXT record:

   Type	Value
   TXT	"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBi..."

   This prevents email tampering.

6. Domain-based Message Authentication, Reporting, and Conformance (DMARC): This is another TXT record and it tells email servers what to do when they do receive spoofed or altered email.

   Type	Value
   TXT	"v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"

   You still want to add a DMARC record even if you don't have a policy (p-none). The clarity adds security and is required for bulk senders. Implementing SPF, DKIM, and DMARC only takes a few minutes. You just need to get the correct settings for each protocol from your email provider and create these DNS records.

7. Email Encryption: When email was originally developed, it was open to all, like sending a postcard. Now it’s encrypted using TLS Encryption, but it does require that both the sending and receiving email servers support this protocol. Google currently reports that 98% of outbound email and 99% of inbound email is encrypted.

   https://transparencyreport.google.com/safer-email/overview?hl=en

8. Bulk Messaging: If you are doing email marketing, you need to do two additional things to make sure your emails are received:

   • Keep your spam rate below 0.3%. Spam is flagged by the users receiving your email, and your spam rates will be different for each provider. Google has provided a site where you can monitor your domains: https://postmaster.google.com
   • If you send over 5000 messages a day you need to have a one-click unsubscribe link in the message body.

   Even if you are just sending notifications to users, your volume of emails may still trigger the unsubscribe requirement. We can integrate this into your app if required, but it's usually best to let the email services manage it.

There are a few additional details for serious email users, but I don't believe they will be an issue for most of us. To learn more:

Google
Yahoo

To confusing? Feel free to reach out and we will help you get this setup.