I have set up DNS records to prevent important emails from being identified as spam – so it is

I have set up DNS records to prevent important emails from being identified as spam – so it is

SPF, DKIM and DMARC are authentication data sets that prevent your emails from being mistakenly identified as spam, and at the same time prevent criminals from falsifying your domain. There are three DNS entries that protect your domain and make sure your emails don't land in the garbage. If you use all three systems, you will get a complete coverage. You also protect your domain from a theft. If you send a lot of e-mails professionally and continue to be silent, your e-mails will most likely end up in another person's spam folder. There can be several reasons that do not always have to do with the content of your emails. In most cases, your domain may not be authenticated, giving all reason to receive mail servers to store your messages impliedly in the spam folder. I have experienced that this has been more frequent than expected by people, including teams with really good email content. Fortunately, there is a simple solution with three DNS entries called SPF, DKIM and DMARC. Together they prove to the Internet that your emails are legitimate. You also protect your domain from being captured by cyber criminals so that they can spend themselves in emails as you. Gmail and Yahoo started to enforce these authentication requirements for mass transmitters in February 2024. After that, Microsoft added the same requirements for Outlook.com, Hotmail and Live.com in May 2025. If you haven't set them up yet, they are no longer optional. What SPF, DKIM and DMARC actually do

Each of the three logs addresses another vulnerability in email authentication. SPF checks whether the server that sends your email is entitled to this. DKIM adds a cryptographic signature to your outgoing messages and confirms that they have not been changed during the transmission. DMARC connects both by publishing a directive that informs the receiving servers what to do when one of the checks fails and returns authentication reports to you. You really need all three. SPF alone cannot prevent anyone from falsifying the “From” address that your recipient sees in his inbox. DKIM alone cannot intercept emails sent by an unauthorized server. Only if you run all three, you will get complete protection from delivery problems and domain poofing. 1. SPF: Authorize the servers that send in your name

SPF (Sender Policy Framework) is a DNS-TXT entry that lists all IP addresses and mail servers that are entitled to send emails on behalf of your domain. If a recipient's mail server receives a message that is supposed to come from you, it compares this entry with the IP address of the sending server. If the IP is not included in the list, the message fails. To set it up, you must login to your domain registry (GoDaddy, Cloudflare, Namecheap etc.) and add a TXT entry in the root directory of your domain. This is how it works:

First ask your SPF value for your email service. Google Workspace, Microsoft 365 and most platforms provide the exact record value you need to copy and paste on their domain authentication page. For Google Workspace this looks like: v=spf1 include: spf.google.com ~all. If you send emails via multiple services, you should stack them in the same record, such as v=spf1 include: spf.google.com include:spf.protection.outlook.com ~all. Log in to the platform where you manage the DNS entries of your domain. These can be GoDaddy, Cloudflare, Namecheap, Route 53, etc. Create a new TXT entry on your DNS page, set the host to @ (your master domain) and paste the SPF value from the previous step. That's so easy! Note that your domain can only have a SPF-TXT entry with no more than 10 DNS searches. By creating a second SPF entry instead of processing the first, both are damaged. Therefore, keep your list of authorized senders clear. 2. DKIM: Add a tamper-proof signature to each email

DKIM (DomainKeys Identified Mail) uses public key cryptography to sign your outgoing messages. Your mail server adds a signature with the help of a private key stored by it, so that recipients can check it using a suitable public key that you have published in your DNS. If the email has been changed at any point between your server and the recipient's inbox, the signature check fails. Google Workspace, Microsoft 365 and most major email platforms like SendGrid generate a DKIM key pair for you. Your task is to copy the public key they provide and insert it as a new TXT entry into the DNS settings of your domain. While the exact setup steps depend on your email provider and domain registrar, you will find a general overview of what you need to do here. Google Workspace, Microsoft 365, SendGrid, Mailchimp and other email service providers generate a DKIM entry for you when you navigate to the page with the domain authentication settings. For example, if you are using Google Workspace, you will find it in “Apps” > “Google Workspace” > “Gmail” in the Google admin console. Click to create a new record and copy these values first. Next, navigate to the DNS setting page of your domain registry and create a new TXT entry, as you have done before with the setup of SPIF. Note that some providers may also require you to add this as a CNAME entry instead of a TXT entry. Therefore, look at the documentation of your email provider. Insert the host name and entry value you received from your email provider into the new DNS entry. Make sure that there are no typing errors, as this may affect domain security. Now return to the authentication settings of your email provider. Enable the DKIM signature for your domain. This is done in Google Workspace by retrieving the “authenticate email” page in the admin console and clicking “Start authentication”. Remember that you should do this after 24–48 hours, as the spread of DNS entries in your domain takes a while. DKIM is particularly useful for forwarded messages. The forwarding often interrupts SPF because the IP address changes, but the DKIM signature normally remains intact. This means that a forwarded email can pass authentication even if SPF had failed alone. 3. DMARC: Set the rules what happens when the authentication fails

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that makes SPF and DKIM enforceable. Without it, a receiving server that recognizes a failed check does not have instructions about what to do next, and you have no insight into the cause of the error. How to run it:

First create a special inbox for DMARC reports, such as “reports@yourdomain.com”. Most email providers offer a DMARC generator in their dashboard, but you can also use a third-party service such as MXToolbox or DMARCLY. Add a new TXT entry. The host name should be dmarc. Insert the record value directly from your DMARC generator. Keep an eye out for any error reports in your special inbox for two to four weeks. This reveals all problems with the mailbox that need to be resolved for better accessibility. Like the other two, DMARC is a TXT entry that was added to dmarc.yourdomain.com this time. A simple start data set looks as follows: v=DMARC1; p=no; rua=mailto:reports@yourdomain.com. The “p=none” setting means that receiving servers do not take any action on failed messages, but rather send you aggregated reports to the address you provide. These reports show what services are sending on your behalf and whether they are authentication. Once you have reviewed the reports for a few weeks and have confirmed that your legitimate emails will be redirected cleanly, you can sharpen the policy. Change to p=quarantine to forward faulty messages to spam, and finally to p=srest to completely block them. Jumping directly to p=reject before you check your reports is probably the most common implementation error I see and ultimately leads to your own marketing or transaction emails being blocked. Why you can't just choose one

Each protocol has a gap that fills the others. SPF checks the sending server, but not the “From” address that recipients actually see, so that an attacker can bypass SPF and still output himself as your domain. DKIM checks the message integrity, but does not check whether the signing domain matches the visible sender. DMARC forces all these elements to vote and applies the directive you have chosen if something is not in line. The combined accessibility increase can be measured. According to the E-mail benchmark report 2025 of Validity, properly authenticated domains record a 60 percentage points higher placement rate in the inbox than non-authenticated domains. For anyone who carries out cold-outreach campaigns or mass newsletters, this gap is the difference between a campaign that delivers results and one that completely disappears. To check if your records work

It usually takes between 15 minutes and 48 hours until DNA changes spread worldwide. Once this window has passed, free tools can immediately tell you if everything is correctly configured. MX Toolbox has separate testers for SPF, DKIM and DMARC. You can also send a test email to check@dmarcly.com, which answers with a complete authentication report for your domain. Their aggregated DMARC reports are the most valuable ongoing signal. Within one or two days of the publication of your DMARC entry, the reports are entered at the address you provide. They display any server that sends emails under your domain, and whether each server is authentication or not. Regular reading is the best way to detect misconfigurations at an early stage before impairing your accessibility or allowing abuse of your domain for phishing campaigns.