Email deliverability and brand protection

How to protect your brand and ensure email deliverability: A guide to SPF, DKIM, and DMARCEnsure email deliverability

Protecting your brand and ensuring email deliverability are crucial for maintaining trust and communication with your clients. As cyber threats like email spoofing and phishing attacks become more sophisticated. Implementing email security measures such as SPF, DKIM, and DMARC is essential. This guide will help you understand these methods and how they can safeguard your brand. Ensure that your emails reach your clients’ inboxes instead of getting flagged as spam.

Protect your brand and ensure email deliverability

Today it’s nearly impossible to experience some significant growth and not be targeted by spoofed, spammy emails of attackers trying to present as your brand.

Earlier this year, 2024, you might have seen articles online warning that Google and Yahoo will implement stricter rules. Their idea is to check incoming mail to protect clients from spam and fraud. Thankfully, there are a few simple steps to protect your brand! Ensure that your newsletters reach clients’ inboxes instead of spam folders. Also, you can prevent employees from sharing sensitive information with attackers posing as your company.

The methods we will present here are simple DNS TXT records (known as SPF, DKIM and DMARC). Combined together are a great start to tackling these issues. If you have decided to give us the honor and trust to be your email hosting and DNS partner, you’re in luck! We implement these methods by default for our customers the moment your account is created.

What is email spoofing and why should I care about it?

In theory, email spoofing is a technique used by malicious actors when conducting spam and phishing attacks. Their goal: try to deceive the person receiving the email into thinking they are communicating to someone from your brand.

To keep it short, they do it by forging email headers so that the email software (think of Webmail, Gmail, Outlook, Thunderbird etc.) of the person getting this email displays the false/spoofed email address instead of the original sender. The user then believes they got the email from your domain/brand. It’s leading them to either initiate in potentially dangerous communication with the attacker at worst, or getting angry at “you” and “your brand” for sending them horrible, virus riddled emails at best. The real sender can only be seen if they inspect the email header more closely.

So you see, it makes absolute sense that reputable email hosting providers have implemented safety mechanisms. Mechanisms such as (but not limited to) rejecting emails from domains with no SPF record as a bare minimum.



SPF” stands for “Sender policy framework” and may be the easiest of the three to comprehend. It is a simple DNS TXT record telling the mail server of the person getting the email “Hey, if this email from is not coming from these servers, it’s SPAM”.

On a more serious note, it contains a list of server IP-s and/or hostnames which are allowed to be the origin of the emails coming from your domain.

A simple example looks like this, let’s break it down: TXT v=spf1 +a +mx +ip4: -all

  • v=spf1 –  tells the server that this TXT record contains an SPF record. It must start with this.
  • +a –  this tells that the IP address of the server that is in your DNS zone listed as your A record for the domain is authorized to send emails on behalf of your domain.
  • +mx –  this tells that the IP address of the mail server that is in your DNS zone listed as your MX record for the domain is authorized to send emails on behalf of your domain.
  • ip4: – let’s say you have one more web application on a second/third server whose IP is and you are sending emails from that application. You’ll want to add that IP to the overall SPF record so that the email server of the receiving party knows that server is authorized as well.
  • +include:mailservers .com – the include tag comes in handy in cases where there are more than one email server and/or email workers included in the process of email delivery. This is most used in cases of email hosting providers. The idea is that, in this case, includes in it’s own SPF record a list of IP records that are authorized in the delivery chain. So if an IP in that chain changes (something gets added or removed), you don’t have to edit each of the clients SPF records, only the one of
  • -all –  this last part can come in two flavors, -all and ~all. ~all is known as “soft fail”. It means that if the email does NOT come from one of the IP-s authorized in the SPF record it will be accepted but marked as spam. Whereas -all is known as “hard fail” and it means that if the email does NOT come from one of the IP-s authorized in the SPF record it will be rejected.

One domain may only have one SPF record.



DKIM” stands for “DomainKeys Identified Mail”. It consists of two parts: the DKIM record which is the one you can see in your DNS zone (also a TXT record just like SPF) and the DKIM header that gets attached to all emails sent from your domain.

It uses digital signature schemes which are based on public key cryptography with the purpose to authenticate emails origin. There are two keys used: the private key with which the sender signs its emails and a public one. Public key is used for the receiving party with which their system verifies signatures.

Not to get too technical, you can get this record from your email hosting provider. The public key is the one you will see in your domain’s DNS zone. What’s also important to note about DKIM is that its process ensures the email was not altered while “traveling” to the person receiving the email.

The DKIM record itself is a randomized string of letters and numbers which to a human eye might not mean much. They also have a standardized way they have to be formed.

Here’s an example how it may look like: TXT v=DKIM1; p=8FT8CP810IEGUNOO7G4GDQUS3JRDD57B9UXV1RIRGWWN2LFWVZ

  •– this part consists of two parts actually. “default” is the so called selector, you have the “._domainkey.” part that is always there and at the end you have your domain.
    selector” is a value defined by your email hosting provider. It’s part of the DKIM header which enables an email server to do the required DKIM lookup in the DNS zone. The weird “._domainkey.” part is standard and the “domain” is, of course, your domain.
  • v=DKIM1; –  tells the server that this TXT record is a DKIM record. It must start with this.
  • p=8FT8… – this is the public key we mentioned earlier.



“DMARC” stands for “Domain-based Message Authentication Reporting and Conformance”. Like the other two, DMARC is also a DNS TXT record. But unlike the other two, the DMARC record is intended to be updated over time. The purpose of this record is to tell the email server of the receiving party what to do after checking the sender domain’s SPF and DKIM records, to be more precise what to do if either or both of SPF and DKIM check fail.

How to setup DMARC

It’s best to explain it by breaking it down so let’s start, here’s a basic example of a DMARC record: TXT v=DMARC1; p=quarantine; adkim=s; aspf=s;

  • v=DMARC1;– as usual, it tells the server that this TXT record is a DKIM record. It must start with this.
  • p=quarantine – this is the “policy” and it can have multiple states. “quarantine” tells the email server that they should “quarantine” emails that fail SPF and DKIM checks as probably spam. Another policy that you can use is “none” and it tells email servers that emails that fail SPF and DKIM can be passed through. The “reject” policy tells them that emails that fail SPF and DKIM should be blocked.
  • adkim=s– this is optional. “adkim” refers to the alignment mode for the DKIM. A successful alignment is when the email’s main/root domain matches the “Header From” domain in the email header. “s” stands for “strict”, meaning that they must match. Using “r” for “relaxed” means they do not have to match.
  • aspf=s– this is the same as adkim, but it reffers to the SPF record/check instead f DKIM.

For these two alignment modes, we have to be careful and consider how we use our emails. If you set, for example, “adkim” to be “strict”, if you send a legitimate email from this will fail the check because the main/root domain does not match the “Header From”. In this case, you would use “r” for “relaxed”.

Use DMARC for reporting

The cool thing about DMARC is that it has a cool feature of reporting. Within the DMARC record, you could for example add “”. This way, you can put an email address of your choice and there you’ll receive reports about emails that failed SPF or DKIM checks. While the report itself is not very user friendly to read, there are plenty of third party services that can convert these reports in easy to read format, like that one of mxtoolbox’s or dmarcian’s. This is where we get to the part we mentioned earlier: “the DMARC record is intended to be updated over time.”. It is advisable to start with a more relaxed DMARC record with enabled reporting. Later gradually make it more strict as you learn how your attackers, but also your employees, behave in sending emails.

With the increasing complexity of cyber threats like email spoofing and phishing, implementing email security measures is essential. It is really important to be aware of SPF, DKIM, and DMARC security measures. These simple DNS TXT records help authenticate your emails. Also, they help preventing your emails from being flagged as spam and protecting your clients and employees from malicious attacks.
We hope we’ve somewhat demystified the concepts of these quite easy methods to protect your brand. In terms of DMARC, we highly recommend to check dmarcian and other educational resources. Also check all the possibilities DMARC has to offer you.
By following the guidance in this post, you can safeguard your brand’s reputation and improve your email deliverability. Plus Hosting can assist you in this process by implementing these security measures by default for all its customers. We can ensure your emails reach your intended audience securely and reliably.



Povezani članci