This matter deserves your utmost attention the most, as it directly correlates with your email deliverability. It has come to my attention through our personal experiences that these acronyms might appear as unfamiliar, intimidating, and possibly dull for the fast life of the marketers. Alternatively, they may seem known, yet you have previously shown no inclination to investigate their true DKIM significance.
Regardless, it’s imperative now to gain some insight into what SPF, DKIM, and DMARC signify, and how to assimilate them into your DNS records on your respective mail server, assuming you desire to possess enhanced control over your email deliverability. It will be my responsibility to guide you on where one can verify within SendBuzz if they have been correctly implemented.
In an attempt to make the provision clear, I’d strive to elucidate in easily comprehensible terms, which not only software developers but anyone will be able to understand. And not only that, this blog will help you stay away from spam folder of your prospect as well!
To put it simply, the Sender Policy Framework (SPF) serves as a protective measure designed to inhibit cyber criminals from transmitting emails in your name. This protocol revolves around interactions between DNS servers, a concept that can initially appear daunting. However, fear not, as an attempt will be made to lay it out in the simplest terms possible.
Suppose you transmit an email to an individual named Liam. The challenge lies in how Liam’s DNS server verifies that the email was indeed transmitted by you. Unfortunately, without an SPF set on your DNS server, authentication is impossible.
The SPF designates which IP addresses are authorized to dispatch emails from your domain. To illustrate this, let’s conceptualize two potential server exchanges. To simplify our conversation, let’s say you are called William.
Scenario 1 : Your SPF records are not set!
William’s server: Holla, Liam’s email server. I’ve got an email from your lad William.
Liam’s server: Salutations, William’s server. Got an SPF with you?
William’s server: Ah, the SPF… Is there anybody who really gives an importance to that anyways? Nah, don’t have one. Take my word for it, it’s from William.
Liam’s server: With no SPF, how do I know it was really William behind this? Give me a lineup of William’s allowed IPs to matchup with yours.
William’s server: Not so sure what are you talking about!
Liam’s server: In that case, your message is a no-go. Delivery cannot be made. No hard feelings, mate…
Scenario 2 : Your SPF records are set!
William’s server: Greetings, Liam’s server. William has a new digital message for you.
Liam’s server: Hello, William’s server. Can I have your SPF?
William’s server: Sure, here is my SPF. It includes a comprehensive list of IPs personally authorized by William to represent him.
Liam’s server: Alright, let me check it out… The message from you is coming from IP 18.104.22.168. I see, it’s on the list, that checks out. Please forward the message, I’ll present it to Liam. Much appreciated!
We would apologize to the technical readers and marketing leaders who thought we oversimplified things! Kindly tolerate our writing and kindly acknowledge our admiration for your intensely analytical thinking capacities.
What apps should you include in your Sender Policy Framework?
You need to double-check that any apps sending emails for ya – assuming they’re using their own SMTP and not yours – are covered in your SPF. So, say you’re utilizing Google Apps to send emails out from your domain, then Google should definitely be in your SPF. Google’s gone and laid out all the steps for you on how to get that done.
Just don’t forget that if Google’s the only app you’re using, it got to be the only one you’re “allowing” in your SPF, got it?
Should you include SendBuzz in my SPF as well?
So, basically what we are saying is, don’t forget to add any apps that are firing off emails for you into your SPF record, especially if they’re rocking their own SMTP. Now, SendBuzz is a bit different because it sends your emails using your SMTP. Think of it like your online email sidekick with a ton of extra punch, rather than just some bulk email sender.
Just a heads up, how many emails SendBuzz successfully delivers depends on how well-liked your domain is. Setting up SPF and DKIM is like your domain’s personal bodyguard, helping to keep its reputation shiny and clean, and making sure your emails end up where they’re supposed to.
How to set up SPF record on your server step by step?
Finding your current SPF record :
- Tools: MxToolbox, Google Apps Toolbox
- Action: Enter your domain (e.g., sendbuzz.io).
- Outcome: Tool displays your current SPF record or a “not set” notification.
Adding an SPF record (next steps) :
- Process: Depends on your domain host (Google, Microsoft, etc.).
- Basic idea: Copy and paste a specific text line into your host’s control panel.
Example for Google Apps :
- Text line : v=spf1 include:_spf.google.com ~all
- v=spf1 : Identifies the record as SPF.
- include:_spf.google.com : Authorizes Google’s mail servers.
- ~all : Treats emails from other servers as “soft fail” (may be tagged as spam).
More complex scenarios :
- Multiple apps : Line gets longer as you include authorized servers for each app.
- Different hosts : Google uses _spf.google.com, other hosts have different formats.
Resources for specific hosts :
- Step-by-step guides : Dedicated instructions for Google, Microsoft, Zoho, Namecheap, GoDaddy, Amazon SES.
- Checking your current SPF record is crucial before setting up a new one.
- The specific text line you need depends on your email setup and domain host.
- Resources are available to guide you through the process for popular hosts.
Not sure if your SPF is all good with SendBuzz? You can simply check it out right in the app. Just head to SETTINGS then EMAIL ACCOUNTS, click on the tiny gear icon next to your email and then hit DOMAIN CHECK-UP on the left. No stress if you’re still having trouble doing it – just shoot us an email at [email protected] and we’ll help you out individually.
What is DKIM Record?
DomainKeys Identified Mail (DKIM) standard was created to the same reason as SPF was created. It helps preventing the bad guys from mimic you as an email sender. It is a great way to add a sign in your emails in a way that it can allow the recipients’ server to check if the sender was really you or not!
By setting up DKIM on your DNS server, you are adding another layer for your receivers to recognize your message as “yes it’s really you sending that message”.
Think of your emails like Chandler’s jokes: you want everyone to know they’re truly yours, not Joey just messing around. DKIM is like a secret handshake that confirms you’re the funniest friend.
Here’s how it works:
- Imagine Chandler has a super-secret laugh track (private key) tucked
away. He adds a tiny snippet of it to each joke (signature) before telling them.
- Everyone knows Chandler’s signature laugh (public key). It’s like
Joey himself! Chandler puts this laugh in the phone book (DNS records) so everyone can recognize it.
- When someone hears his joke, their brain (server) checks the phone
book for Chandler’s laugh. If it matches the joke’s secret snippet, boom! It’s a legit Chandler joke, not a Joey
- This secret handshake boosts Chandler’s joke-telling reputation (email
deliverability). People know his jokes are always hilarious and from the one and only Chandler Bing.
DKIM does the same for your emails :
- It adds a hidden signature you create with your secret key.
- It lets everyone else verify your signature using your public key, which you share
- If the signature matches, your email is authentic and more likely to land in
inboxes, not spam folders.
So, how does Chandler feel about DKIM? He probably wouldn’t even know
what it is, but hey, it keeps his jokes out of spam folders. And that’s what matters!
How to set up DKIM record on your server step-by-step Guide?
Primarily, you need to generate the public key. To do son, you will need to login to your email provider’s admin console. Then, it may differ depending on your email provider.
If you are using Google Apps to send your emails, here is how you can do it:
Setting up DKIM for Google Apps is pretty straightforward, and thankfully Google makes it fairly simple. Here’s a step-by-step guide:
1. Get your DKIM key:
- Sign in to your Google Admin console.
- Navigate to Apps > Google Workspace > Gmail > Authenticate email.
- Select your domain from the Selected domain dropdown menu.
- Click Generate new record.
- Choose a key length (1024 or 2048 bit is recommended) and click Generate.
- This will generate your private and public keys. Copy and save the DKIM value displayed.
2. Add the DKIM record to your DNS:
- Log in to your domain registrar’s website.
- Navigate to your DNS management settings.
- Create a new TXT record.
- For the Name field, enter the value shown in the Record name field in your Google Admin console.
- For the Value field, paste the DKIM value you copied earlier.
- Save your changes.
3. Turn on DKIM signing:
- Go back to the Authenticate email page in your Google Admin console.
- Select your domain again.
- Click Start authentication.
- Google will verify your DKIM record. This process can take up to 48 hours.
- Once verified, the page will display Authenticating email with DKIM.
4. Verify DKIM is working:
- After a day or two (to allow for DNS record propagation), you can use an email testing tool to check if your DKIM record is properly configured and authenticated. Some popular options include MXToolbox and dmarcian.
With very similar approach, you can also set up your DKIM records for your Zoho, Microsoft or NameCheap accounts.
Hey there! If you’re messing around with SendBuzz and don’t have a techie pal to bug for help with SPF and DKIM settings, don’t sweat it. Shoot us a line at [email protected] and we’ll sort you out.
Wanna know if your SPF and DKIM are all set up right? You can check that out in our app. Or pop over to our webpage : https://www.sendbuzz.io/spf-dmarc-record-checker/
Set Up SPF & DKIM and Improve Your Deliverability
If you’re frequently dispatching emails for promotional purposes or for business acquisition, the credibility of your domain becomes paramount and requires diligent maintenance. The last thing one would want is for their domain to be blacklisted, causing their emails to land in spam. It is thus necessary to correctly establish SPF and DKIM records on your DNS server to ensure your domain’s protection and the successful delivery of your correspondence.
This task may seem daunting, but the investment in effort holds significant worth. We would highly recommend reviewing the SPF and DKIM status in your SendBuzz account, or commission your IT department to do so, if you are currently utilizing their services. If you find that these records are not in order, don’t hesitate to request their assistance in rectifying this matter. It is not something that should be overlooked or dismissed lightly.
What is DMARC?
In essence, it’s a safeguard for email systems designed to prevent unauthorized use of your domain and to enhance your ability to manage email deliverability. This system leverages both SPF and DKIM mechanisms.
This peculiarly-named tool, DMARC, stands for Domain-based Message Authentication, Reporting and Conformance. But what exactly does this imply?
DMARC enables you to verify whether an email you received was indeed sent by the purported sender. This aspect is referred to as the authentication. Should the email fail to meet the DMARC criteria, it is treated according to the preset DMARC strategy of the recipient (this process will be further elaborated later in the article). This is known as the conformance aspect.
Furthermore, DMARC provides the recipient the ability to send feedback to the original sender detailing how the email was processed: was it allowed into the main inbox, directed to the spam folder, or dismissed altogether. This facet is referred to as the reporting aspect.
Overall, DMARC provides the functionality for email recipients to assess whether the received email is consistent with their understanding of the sender. In instances where it doesn’t match, DMARC instructs the recipients’ servers about the appropriate action to take towards such messages.
This system is not automatically configured, so it necessitates personal setup to offer an enhanced level of email security supplementing your SPF and DKIM mechanisms.
But what is the significance?
Why does DMARC matter? How does DMARC work?
There are various reasons, and out of all of them, these three reasons are valuable for majority of the email users :
1. It is a safety measure for the receiver.
On the sender’s side, it protects your domain agents unauthorized usage! For instance, phishers who try to steal your personal information in that manner. On the receiver’s end, it will make it tough for fraudulent email to go through your primary inbox.
DMRC protects against domain spoofing as well. This means, if somebody who is not allowed to use your domain tries to pretend that they are you or have your company to trick someone into believing they’re you. They generally do it to steal company or personal data, such as login information or credit card details.
2. It protects your brand's reputation.
If someone is impersonating you and attempting to deceive people into providing them with money or personal information, it can harm your brand’s reputation. DMARC can help prevent this.
DMARC, along with SPF and DKIM, is added to the DNS by the domain owner. It consists of a straightforward one-line record.
Here is an example:
v=DMRC1 ; p=none ; rua:[email protected];
3. It helps you take better control on email deliverability.
An additional advantage of utilizing DMARC is it enhances your ability to regulate the number of your emails deemed legitimate and reach your recipient’s primary inbox. Plus, it protects against attempts to impersonate you and send emails in your name, but more on that later.
How does DMARC work?
DMARC tells what has to happen for the messages that go through the inbox and what will happen if all the conditions are not met!
When an email is being tested by DMARC, here are a few things that happen:
- DKIM alignment – the parent domain matches with the Header ‘from’ domain.
- DKIM pass – an extra signature put in the header that needs to be validated. This private key matches the public key in DNS.
- SPF alignment – the domain in the Envelope ‘from’ matches with the domain in the email’s header ‘from’.
- SPF pass – the receiver’s server will take the domain included in the Envelop ‘from’ address and check for the SPF record.
A message will fail DMARC if both DKIM and SPF will fail in the test. So, keep in mind to keep your DKIM aligned.
What if SPF and DKIM already used in protecting email?
The mechanisms of SPF and DKIM serve to safeguard against unauthorized utilization. However, they function independently, with no globally recognized procedure dictating how receivers should react when these mechanisms fail. The response to failure varies across receivers. While some might immediately direct a failed message to the junk folder, others may implement further tests to ascertain its ultimate destination.
Moreover, the domain owner remains uninformed about the ultimate outcome of their emails and whether they arrived in the main inbox of the recipient.
DMARC offers the ability to create customized rules for dealing with non-compliant emails, thereby minimizing the probability of a domain being misrepresented. It further facilitates feedback to the email sender.
By incorporating a DMARC record into the DNS, you establish regulations for incoming emails, deciding whether they should be quarantined, rejected, or allowed to pass through.
DMARC Policies and Reporting
There are core three DMARC policies – None, Quarantine and Reject.
In terms of email communication, under a ‘none’ policy, all emails would be delivered, irrespective of whether they pass the SPF and/or DKIM verification. Meanwhile, with a ‘quarantine’ policy in place, non-verified emails would be automatically directed to the spam folder. Conversely, a ‘reject’ policy would result in such emails being bounced back.
A few days subsequent to the establishment of a DMARC record in DNS, Internet Service Providers (ISPs) will begin to send reports. These reports would comprise statistics on all emails dispatched from your domain, inclusive of those that purport to originate from your domain.
If the reported volume of emails exceeds the number you have actually transmitted, it can be inferred that an entity apart from you is utilizing your domain. The reports will provide a comprehensive snapshot of the origins of these emails and whether a ‘quarantine’ or ‘reject’ policy would bring their transmission to a halt.
These reports grant you the capability to evaluate the condition of your dispatched communications. What components are incorporated in them? They include the manner in which the messages have been managed in accordance with the established DMARC policies, the IP addresses which have employed your domain for email transmission (including the number of communications sent), as well as the results for SPF and DKIM.
How to set up DMARC?
- Establish SPF and DKIM Records
Primarily, it is necessary to confirm that your SPF and DKIM records are established. If you have given consideration to your deliverability in the past, there is a likelihood of having already addressed this matter.
- Create a DMARC Record
For the time being, opt for a ‘none’ policy for all outgoing emails.
- Incorporate your DMARC Record into DNS
- Gradually Adapt the Policy Based on Accumulated Data.
Evaluate the multiple reports that you receive and once you have grasped how to navigate through the DMARC policies, transition from the ‘none’ setting to ‘quarantine’, and later to ‘reject’.
A fusion of SPF, DKIM, and DMARC is considered the pinnacle of email authentication methods. If you are running cold outreach campaigns or doing outbound marketing efforts, SPF or DKIM are more recognized and extensively implemented. At present, DMARC policy is set and is essential, but it is likely that this will alter in the future as an increasing number of individuals are employing it for enhanced domain security to guard against spoofing and phishing.