Here comes the spam
Whether it’s a fraudulent offer or an ad to buy a service you don’t need, you’ll find it in your spam folder. Any email you have not requested may be considered spam. Simply put, it’s like the online world’s equivalent of countless discount flyers in your mailbox.
The term spam comes from a parody by the British satirical group Monty Python, in which innkeepers offer meals with spam as the main ingredient in all of them.
Hundreds of factors influence whether the email ends up in the spam folder or not. The most common ones include:
- Basic infrastructure settings
- Reputation verification (SPF, DKIM, DMARC)
- The reputation of IP addresses of servers sending mail (eg 212.45.5.60)
- The reputation of the sender’s domain (e.g. your-company.com)
- User reputation (ie, whether the user sends a lot of messages that are marked as spam), and many others.
The inner workings of email
Let’s take a quick look at how email works to better understand the issue. The model is based on real-world mail, where you put the paper with the text in an envelope. The envelope contains all the details, such as address, zip code, and delivery priority. In the email, the header works as an envelope and the message itself follows. You can view each header in your Gmail by clicking the three dots and selecting Show Original.
The sender writes the text of his email and adds a recipient in his program, e.g. Gmail (MUA, Mail User Agent). Gmail is also an email server (MSA, Mail Submission Agent) that checks for errors and moves messages to the same server for distribution (MTA, Mail Transfer Agent). SMTP (Simple Mail Transfer Protocol) then ensures that the message reaches the recipient. Originally, the protocol was able to deliver a message directly to the recipient’s server, but that was at a time when far fewer devices were on the internet.
Based on the target user’s address, the MTA determines where to forward the email. It finds the right way by looking at the domain part of the email address and typically according to the MX records in the DNS of the recipient’s domain. Email is sent sequentially between MTA servers until it reaches its destination. After arriving at the target computer, it is passed from the MTA to the MDA (Mail Delivery Agent), which finally adds the email to the user’s mailbox.
The SMTP protocol has no authentication and e-mail is sent in human-readable ASCII (attachments are then base64-encoded for transmission). Simply put, this allows anyone to send an email from any address and pretend to be someone else. For spammers, all you need to do is connect your SMTP server to the Internet or find a free server (Open Mail Relay), connect to it remotely, send commands designed to make the email look like it is sent under your domain and click the button.
The right Google Workspace setup
As you have read, sending emails under a foreign domain is not that complicated. If this happens, your domain may be identified as spam. Recipients can also mark their Gmail messages as spam.
How not end up in spam and ensure that the messages really come from you? There is a 3-step setup to help you with this.
Step 1: SPF
One of the first steps is to set up a Sender Policy Framework (SPF) record. Describes which email servers can send messages from your domain. It is set as a TXT record in DNS. The IP or Internet address of the server is entered in the record. There should only be one SPF record at a time. So, if you already have one in DNS, instead of adding more, edit the existing one. Activation and promotion may take up to 24 hours (depending on the setting of the TTL parameter).
The record reads naturally from left to right. For Gmail, we recommend setting it as follows:
Note that the SPF record must be valid. These are the most common mistakes that you can easily avoid now:
- Having more than 1 SPF record,
- Having too many nested calls (max. allowed is 10),
- Not having the right tool listed,
- If you use subdomains for different services, you need to have the SPF record correct for them as well,
- If you use other email services (e.g. Mailchimp, CRM, another email server, smart printer, scanner), enter all these sources.
You can test your settings using available online tools (e.g. DMARCIAN SPF Record Check ) or Google .
One more tricky thing about the SPF record is that it’s usually verified on the return address, which can be a different address than the one in the “From:” row. So, if you would only rely on the SPF protection of your domain, it’s not enough. Attackers would only need to set SPF on any domain and use it in the return path address.
Step 2: DKIM
Another level of security is DKIM (A Domain Keys Identified Mail).
Each email sent is digitally signed with your private encryption key. The principle is simple: in sending, selected parts of the message are taken, a so-called hash is calculated from them, and it is signed with your private key. The encrypted code is added to the header of every sent email.
The incoming server downloads the public key from the DNS record (specified by the domain of the DKIM signature), which it uses to decrypt your signature (and thus obtain the original hash). It calculates its checksum from the content of the message in the same way and then compares whether it is the same as the one that came in the DKIM header. If they match, then surely the parts of the message that were used to calculate the hash code have not changed along the way.
The DKIM signature is an extremely important factor in evaluating reputation because it is directly linked to your domain and much harder to exploit.
You set up DKIM from the Google Admin console, where Google prepares this public key for you. Then you put the key into the DNS record as a TXT. Even more detailed instructions are in the Google Admin tool Help, or you can contact us.
The catch of DKIM is that any domain can be specified in the key domain (parameter d=). A possible attacker can send an email from your domain but sign it with his key. From the DKIM standard point of view, such a message will be viewed as authentic.
Step 3: DMARC
The last step is setting the so-called DMARC (Domain-based Message Authentication, Reporting & Conformance). It is a technical specification to reduce the abuse of email servers. It helps you determine how receiving servers should behave with emails that do not meet your domain’s SPF or DKIM protection. To refresh: SPF tells which server IP addresses can send a message for a given domain (in our case Google or other external services). DKIM confirms that the email content is trustworthy and has not been modified during delivery. DMARC then uses the data obtained and summarizes what should happen to the message if it is in any way suspicious. For a message to comply with DMARC rules, there must be either a domain match in the SPF record or in DKIM.
This is one of the most valuable tools as it allows you to control what happens to the emails you haven’t sent, and you also get reports on what recipients think about your domain (i.e. how many emails you deliver and how to comply with DMARC standards). In addition, DMARC is the only standard that is directly tied to the “From:” domain and is therefore technically the only tool that can truly protect your domain.
The DMARC record is again set as a TXT record in the DNS record. Mandatory settings include record type (v) and then policy settings (p). It works like this:
- p=none – only reporting, no delivery restrictions,
- p=quarantine – if the message does not comply, it will end up in the spam folder,
- p=reject – if the message doesn’t comply, it will be rejected.
We also recommend setting up an email to which daily reports (rua) will be sent. You can also use a Google Group as an email with sending messages from recipients outside the domain enabled. There are a number of services that can visualize them so that you can get the most out of them.
When setting up DMARC, however, we recommend starting with sp=none and first checking if you have everything set up correctly – because if you started at a higher level of protection and didn’t have SPF and DKIM records set up correctly for all your e-mail channels, you could paradoxically harm yourself ( as some of your email communications would not be delivered).
But when setting up DMARC, we recommend starting with sp=none and checking that you have everything set up correctly. If you started with a higher level of protection and did not have SPF and DKIM records set correctly for all your email channels, absurdly some of your emails might not be delivered.
Apply the 3 described settings (SPF, DKIM and DMARC) and your domain will be effectively protected within a few weeks. If you need help with the setup and you don’t want to risk any unnecessary errors, write us at support@signaturesatori.com. And don’t worry, we check our spam folder from time to time as well.