Escaping the spam folder: a technical guide to email authentication and domain reputation

This article explores email authentication protocols, how they work, and their impact on domain reputation and email deliverability. 

One of my daily tasks is to manage SWorld IT infrastructure, and we have recently been working on resuming our newsletter using Mailchimp. I expected it to be easy to send bulk emails and have our subscribers read about our upcoming relaunch. Surprisingly enough, my first test campaign went straight to spam. So I needed to understand how I could improve email deliverability without asking all subscribers to whitelist us. 

We had previously explored email headers with my recent article: read here. Below is an extract of the email headers sent from Mailchimp to my address. What we want to do is understand each email authentication protocol and verify that they have been implemented properly. 

-0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The
                             The query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              For more information.
                           [198.2.142.12 listed in sa-trusted.bondedsender.org]
  0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to
                              Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              For more information.
                             [198.2.142.12 listed in sa-accredit.habeas.com]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from the author's
                             domain

Improving email deliverability for large campaigns goes beyond SPF, DKIM, and DMARC, but the focus of this documentation is to ensure those mechanisms are properly configured. 

At first, everything seems fine, DKIM and SPF are defined and PASS. However, good email authentication requires not only those two, but DMARC as well. As much as those records are seemingly easy to set up, it is easy to make syntax errors. DNS records are very sensitive, so I will be using PowerDMARC to generate the records I need. 

Email deliverability is very dependent on your domain reputation, which spam filters also use against you. SPF, DKIM, and DMARC are the essential starter points in defining your online reputation. However, when using a service like the free version of Mailchimp, you are transferring that responsibility to a third-party service that may also be used by attackers. Thus, recipients’ servers tend to be wary of emails coming from that type of service. Beyond reputation concerns, there is a misalignment between the return-path and the FROM fields in the email header, as our domain is essentially spoofed (here is a great video explaining those concepts  - technical - 16min). 

In my DNS records, I do have a DMARC record added, but that, along with the SPF and DKIM records I have, were ignored, and only Mailchimp server information was used. 

Improving on your reputation means either upgrading to have control over those protocols and what domain is authenticated, or investing in a secure, fully managed email infrastructure with services like Amazon SES. We go over what it looks like to manage your email reputation and improve your odds of landing in an inbox.  So in the next sections, we explore SPF, DKIM, and DMARC settings in a fully managed environment. 

SPF (Sender Policy Framework) 

We still want to use Mailchimp, but this time, we are going pro and controlling all protocols. For that, we need to specify in our records that we want Mailchimp to send emails on our behalf. 

SPF defines authorized servers for a specific domain. We want Mailchimp to send emails for SWorldyouth.org.  With PowerDMARC, all SPF mechanisms can be defined with simple clicks.  Those mechanisms are explored in a later section, and we will also see how DMARC makes use of them. 

Because Mailchimp is the only service I will be using for now, here is the SPF record I generated: 

v=spf1 mx a include:servers.mcsv.net ~all

V, of course, defines the version, which until there is an update, is spf1. Everything else after the version is a mechanism, or in other words, a type -> value matching for all types of DNS records we may want to use to reference a service we are authorizing. 

The table explains all available mechanisms and the logic behind them. Depending on what the goal is, some may be more effective. 

SPF DNS lookup limit and SPF flattening

SPF has a hard limit of 10 DNS lookups — exceed that, and the check automatically fails. This “lookup cost” refers to the DNS queries made when resolving mechanisms like include, a, mx, or redirect in your SPF record. Each external service you authorize adds to this count. The more providers you include (like email marketing tools, CRMs, or forwarding services), the higher the risk of breaking SPF. To manage this, PowerDMARC offers tools that optimize and flatten SPF records, keeping them within the limit.

For our domain, we are including Mailchimp. I used MXTOOLBOX to check their SPF record. Here is the result. 

v=spf1 
ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.0.0/16 
ip4:129.145.74.12 include:_spf.google.com 
include:mailsenders.netsuite.com include:_spf2.intuit.com 
include:_spf.qualtrics.com ip4:199.33.145.1 ip4:199.33.145.32 
ip4:35.176.132.251 ip4:52.60.115.116 ~all

 If I were to use Azure as well, it would have to be included in my record. Here is Azure’s SPF record

v=spf1 include:sparkpostmail.com ~all

SPF hard limit for DNS lookup is very strict and is recursive. Meaning, not only will it count my now two lookups for Azure and Mailchimp, but it will count theirs as well. So far, we are at 7 lookups in total when considering their respective SPF records. The trick is, whatever they have included in their records will get looked up too.  

Flattening is a process of simply switching from mechanisms that need DNS lookup to the ones that do not (IPv4, IPv6). 

SPF softfail vs hardfail

The final tag on an SPF tells DMARC and recipients what is considered a failure of SPF. There are four possibilities: 

Three easy ways SPF fails automatically are: you made a mistake or typo in writing the records, you added more than one SPF record for the same domain, or the DNS lookup count went over 10.  But once set up, the next step for us is to configure DKIM. 

DKIM = Public Key Cryptography for Email

I did not set up DKIM on powerDMARC; my service provider had one set up for me on my server already. 

default._domainkey.sworldyouth.org. 14400 TXT v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzWpysIlUvDtqnddoa9SxlX3n8HatwhEOCV6oXTScDJLzfmGO1YuvDWHvxopNKVeomHj426dMkOhngfvymUOKU7DvdQ+GWcMZgvW/QT4116tOvmq3CrpbKAYA7qoUZCfEQ5nXjmozlP9CwDAepiBRJ6FKUwvInhWDgQTlum9tn2RYN7JB728/RRi/8MLup76M5

DKIM is a public/private key pair. It uses encryption algorithms to generate them. The idea is to sign all emails coming from the server for the receiver to authenticate them using the public key. 

• The sender (you or your service provider) signs parts of the message (usually headers + body hash) using a private key.
• The receiver (e.g., Gmail) looks up the public key in your DNS to verify the signature.

We won’t dive into Public Key Infrastructure (PKI) here, but grasping its fundamentals is key to fully understanding DKIM under the hood. So here is another snippet of my email header that landed in the spam folder. 

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sworldyouth.org;
    s=k3; t=1749241535; x=1749511535; i=hello@sworldyouth.org;
    bh=yaDXCDnHoisgxM8HbTKrK0F7jjLp51se6AgbhSPUubA=;
    h=Subject:From:Reply-To:To:Date:Message-ID:X-MC-User:Feedback-ID:
     List-ID:List-Unsubscribe:List-Unsubscribe-Post:Content-Type:
     MIME-Version:CC:Date:Subject: From;
    b=sGHZEhKh2nYkuHwuSSTKAyRDRdE3v8lhuDhYsMfVHJe9bsHU11pFNK98V4jMLEzik
     eYClgqpyoTbleKaIgA42OTnjJWjmLdUO57DVbXh1kt7ElYidvB96ZY/aQYAUhrSFDd
     JKfP8Ml+ylD1q4dwa0di+z/HvhTf6a0TdYrteW6gi5vxDW39BLLyPnuPxTR95fKia3
     ms/rvbNdHFsZ2OGCtuJcZgMO3LPxrqbLhXO0VIaOX5YLE1+ebdB6/ySysJX6SLMsnR
     unnkWSTUdBNga3f6qzipYWQmlxTXgL+v/FIpke+a0d0z6JJJ7VngKV4o0Rc+P9RbwT
     7E768NxqBOjww==

The table below explores each field of the record.

DKIM doesn't sign the raw message — it signs a normalized version based on the canonicalization rules defined in the c=a/b a/b value pairs. The first defines canonicalization for the header, and the second for the body of the email. The reason behind this is that emails can be slightly altered in transit. The normalized version is reflective of those possible changes. This is crucial because encryption algorithms that produce a hash are highly sensitive to even minor changes.  

Canonicalization (c=) Options Summary

In my case, I am using another service to send some of my emails. So if I were to decide to have Mailchimp use my domain instead of its own, I would have to specify another selector for Mailchimp in my DKIM records. This also means I can have multiple DKIM records in my domain. 

Private Key Management (What You Must Control)

Having multiple DKIM records also means we are managing multiple private keys. One thing to note is that, for security reasons, your key p[pairs should be updated regularly.  Here is what it looks like.

To avoid conflicts:

·       Each sender (e.g., Mailchimp, SES, Gmail) uses a different selector and publishes its own TXT record

·       You can have many DKIM records, one per selector:

You also want to remember the following when setting up DKIM

As mentioned earlier, the DKIM role is to sign the emails. The free version of PowerDMARC does not offer its hosted DKIM feature to help manage DKIM records. However, the DMARC tools are available. 

DMARC records.  

DMARC is an additional layer of security and is greatly responsible for improving a domain’s reputation.  It not only uses DKIM and SPF to define policies, but goes further to analyze alignment between the FROM field and the return-path of the header (ensure they both point to the same domain). 

When emailing, the From field is what we see as the sender in our inbox. The Return-Path contains the domain that sent the email and is responsible for handling bounces or delivery errors. It’s common for these two domains to be different. This isn't a problem as long as domain alignment is maintained, meaning that either SPF or DKIM can successfully authenticate the message using domains that match the one shown in the From address.

When using Mailchimp's free plan, emails are signed with Mailchimp’s domain (d=mailchimp.com), which fails DMARC alignment if your From address is you@yourdomain.com. Although DKIM may pass, DMARC will still fail because the signature doesn’t align with your domain. Upgrading to a paid plan allows you to configure custom DKIM, where Mailchimp signs your emails as your domain using a selector and public key you publish in DNS (e.g., mailchimp1._domainkey.yourdomain.com). This setup ensures DKIM passes and aligns, allowing DMARC to pass successfully and preserving your domain’s reputation.

Mailchimp’s free plan does not use DMARC, and after learning about domain alignment, it has become apparent why: our records do not have Mailchimp's public key, and thus we cannot add them to DKIM. 

Below is an example of a record generated using PowerDMARC tools: 

_dmarc.sworldyouth.org.    14400 TXT  v=DMARC1; p=none; rua=mailto:dsxgr72txg@rua.powerdmarc.com,mailto:no.reply@genzis.net; ruf=mailto:dsxgr72txg@ruf.powerdmarc.com,mailto:no.reply@genzis.net; fo=0:1:d:s; sworldyouth.org. 3600 TXT     v=spf1 mx a include:servers.mcsv.net ~all\

Our goal in this section is to understand how DMARC works and what policies can be defined. First, we need to understand that SPF and DKIM do not define nor do they enforce any policies; rather, they are mechanisms that allow a sender to authenticate itself and provide information that will be used to determine how the email will be treated by the recipient. 

DMARC Record Tags Explained

A DMARC record is a single TXT record published as dmarc.yourdomain.com, and it will typically make use of the following tags. 

DMARC polices are pretty straightforward. Once DMARC fails, we can either do nothing about it, ask the recipient to send it to spam, or have them reject the email altogether. 

DMARC Alignment Mode (adkim)

Your protocol alignment mode also plays a huge role in your messages passing or failing DMARC. You can choose from the following alignment modes for SPF authentication:

• Relaxed: This signifies that if the domain in the Return-path header and the domain in the From header are simply an organizational match, even then, SPF will pass.
• Strict: This signifies that only if the domain in the Return-path header and the domain in the From header are an exact match, SPF will pass.

You can choose from the following alignment modes for DKIM authentication:

• Relaxed: This signifies that if the domain in the DKIM signature and the domain in the From header are simply an organizational match, even then DKIM will pass.
• Strict: This signifies that only if the domain in the DKIM signature and the domain in the From header are an exact match, DKIM will pass.

Note that for emails to pass DMARC authentication, either SPF or DKIM needs to align. 

Common Real-World DMARC Record Example

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; sp=none; pct=100

This means:

"If an email from my domain fails DKIM or SPF, and neither is aligned, reject it outright. Send me reports. Apply the same strict rules to subdomains. Enforce the policy 100% of the time."

We have explored three mechanisms for email authentication: SPF, DKIM, and DMARC. One notable thing is that, unlike DMARC, SPF, and DKIM do not define any policies. 

BIMI, MTA-STS, TLS-RPT

Without going in depth, the technologies that are now included in setting up a resilient email infrastructure include: BIMI, MTA-STS, TLS-RPT, and more protocols that may or may not be directly linked to your email service.

BIMI (Brand Indicators for Message Identification) is a visual authentication standard that lets organizations display their official brand logo next to emails in supported inboxes. It builds on top of DMARC, requiring a strict enforcement policy (p=quarantine or p=reject) and often a Verified Mark Certificate (VMC) to confirm logo ownership. BIMI helps recipients visually identify trusted senders, improving brand recognition and reducing the likelihood of phishing.

MTA-STS (Mail Transfer Agent – Strict Transport Security) is a security protocol that ensures email servers only send messages to your domain over encrypted TLS connections. By publishing a policy via HTTPS and a corresponding DNS record, MTA-STS prevents downgrade attacks where malicious actors strip encryption to intercept messages. It guarantees that emails arrive securely, even if the sending server or network is compromised.

TLS-RPT (TLS Reporting) complements MTA-STS by providing detailed reports on email delivery attempts to your domain. These reports include whether messages were successfully encrypted and identify any failures in the TLS negotiation process. TLS-RPT gives administrators visibility into misconfigurations or malicious activity, making it easier to monitor and strengthen secure email transport.

Domain reputation management using PowerDMARC. 

With all we have explored, managing your domain reputation is essential to a successful online presence. But even more, it is the business’s responsibility to prove they are who they claim to be in the recipient's inbox. As much a third-party services make life easy to send bulk campaign emails and fast-track your marketing strategies, they can also seriously undermine your efforts by hurting your domain reputation. 

“If you want the privilege of landing in the inbox, prove who you are.”

So we made the senders publish:

·       SPF: Here are the servers I trust

·       DKIM: Here's how to verify my messages weren’t altered

·       DMARC: Here’s what to do if those fail

And the burden is on us, the domain owner, to:

·       Configure your DNS records correctly

·       Control who sends on your behalf

·       Monitor your domain’s abuse via DMARC reports

Business owners have the most to lose (brand damage, fraud, customer trust). They control the domain — and therefore can publish the records. If they use third-party senders (Mailchimp, SES, CRMs), they must explicitly approve them. If they send at scale, they will increase the risk if their domain gets abused. (spoofing attempts). 

It’s your job to protect your brand, domain, and customers recipients are the judges, and they require technical evidence

Inbound email security

As much as we spend a lot of resources managing our online presence and domain reputation in hopes of making it to our subscribers’ inboxes and being read, their service providers managing their email servers also implement everything they can to prevent any suspicious email from making it through. The game is to be as legit as possible, to bypass not only antivirus, any phishing software, but also antispam, which have proven to be particularly virulent in recent days. So, while we have defined what a good email authentication includes, a curated email body is still highly needed. The wrong title, wrong attachment, bad grammar, spelling, or the wrong keyword, links, or even can make all our efforts null and void. 

So why did my email land in spam? 

Mailchimp is a widely used provider, but that also makes it a common tool for attackers. As a result, their reputation with spam filters isn’t stellar. On top of that, in my case, Mailchimp was sending emails on behalf of my domain using their own SPF and DKIM records, not mine. In essence, they were spoofing my domain, with my permission, but without a DMARC policy in place to tell recipients how to handle this, the odds of my email landing in the inbox dropped even further.

To make matters worse, my newsletter still included Mailchimp’s default footer and promotional ads. That alone can tip off spam filters. Here's what my spam filter had to say about that test email:

X-Spam-Status: Yes, score=3.2

X-Spam-Score: 32

X-Spam-Bar: +++

The cutoff was 3.0, and my message scored 3.2. Just enough to get flagged and pushed into the spam folder. That was all it took to trigger a deep dive into email authentication, which led me through SPF, DKIM, DMARC, and much more. If you made it to this point, thank you for reading my rant about email authentication protocols.